Case: Несговорчивый Архитектор

АрхитекторТренерская деятельность дает огромное количество кейсов, над которыми можно подумать. Один из участников тренинга (в качестве домашнего задания) прислал свою историю про Архитектора со стороны Заказчика.

Как по мне, такой кейс случается во многих, поэтому решил опубликовать его, чтобы коллеги могли подсказать пути решения или «плюсануть» актуальность проблемы.

В команде Заказчика есть главный Архитектор. В его работе есть особенности: он работает на пол-ставки (! IMHO, очень тревожный фактор для главного технического человека проекта с ~40 разработчиками – 2 аутсорсинговые и 1 внутренняя команды). Архитектор принимает решения самостоятельно, не желает делегировать (но при этом не углубляется в детали); дружит с CEOкомпании-Заказчика (! представляется незаменимым для CEO).

Не так давно Архитектор принял техническое решение, которое отразится на всём продукте, и объявил о нём, видимо, не сильно оценивая последствия. Наша команда, более приземлённая и больше работающая с кодом, заметила очевидные недостатки данного технического решения. Мы написали письмо об этом Архитектору, аргументировано и крайне вежливо. Архитектор и внутренняя команда без всяких аргументов старается не замечать проблему, просто отписываются – там велик авторитет Архитектора, никто не готов возражать ему, внутренняя команда просто применяет его решение, негативные последствия уже видны – дублирование кода, скрытые ошибки, проблемы масштабируемости.

Архитектор ввиду сильной занятости не оценил наше письмо, самоуверенно защищает своё техническое решение. Сейчас идёт переписка по этой проблеме, с каждым письмом он всё более пассивно-агрессивен. Как я расцениваю ситуацию (на основе знаний полученных во время тренинга, Сергей Бережной): на одной стороне чаши – Заботливость (решение важное, может привести к проблемам на проекте, мы этого не хотим), Честность, Профессионализм (мы понимаем, что данное техническое решение неправильное); на другой стороне – Оперативность (переписка по проблеме уже отняла время, ещё не закончена, затягивает), Дружелюбие, Вежливость (мы вежливы и дружелюбны, но Архитектор принимает наши письма агрессивно, отвечает без вежливости, воспринимает нас как угрозу своему авторитету).

Коллеги, ситуация сложная и я бы хотел разобрать это кейс вместе с читателями блога.

Были ли у вас такие случаи? Что делать коллеге? Как убедить Архитектора принять правильное решение?

Рассмотрение подобных кейсов и вопросов – часть программы тренинга “Аутсорсинг как сервис“.

Ближайший тренинг в Харькове 9-10 июля. Хотите получить ответы? Записывайтесь!


Jul 7th, 2011
  1. Jul 7th, 2011 at 07:08 | #1

    Есть две проблемы:
    1) то что архитектор проявляет враждебность по отношению к команде
    2) то что может быть принято нерациональное решение.

    По-моему первая проблема довольно стандартная. И по ней описаны алгоритмы решения: добиться встречи (должны же быть какие-то митинги один на один?), объяснить и т.д. Дать возможность человек понять что он может переменить свое решение и это не должно выглядеть как-будто он тупой и неповоротливый (т.е. пойми вам к нему на уступки, с целью повышения кармы в его глазах).

    После этого пытаться аргументировать свое решение.

    Если не прокатывает – поставить всех в известность что дальше количество проблем вырастет, мы вам об этом сообщаем. Потому как в будущем, если проблемы всплывут, всю вину все равно спихнут на разработку и стороннюю команду. У вас будет щит.

    Если все это не работает, то видимо сейчас самое время задуматься о том чтобы выйти из проекта с минимальными потерями. Либо оценить этот риск при повторении ситуации.

  2. Да, ситуация действительно сложная.
    Сам попадал в схожие ситуации.

    В личном опыте в одном случае я остановил разработку и под “обоснованным” предлогом начал долбить в Заказчика в направлении рефакторинга или расширения бюджета проекта, ибо то что предлагал архитектор, нам становилось сильно в убыток. Надо сказать – за 2-а месяца и 2 координационных комитета приняли наш вариант.

    НО! не как более технически лучший -), а как компромиссный по стоимости/рискам/времени разработки

    Во втором случае сделал как просили (интеграционный модуль) (ибо не сильно дороже было), и по быстрому свалили (благо долгосрочных отношений не предполагалось). Получилось как в анекдоте – к пуговицам претензий нет, а то что использовать нельзя так это к нерабочей модели данных.

    В теории я всегда стараюсь встретится лично с архитектором и попытаться договорится – твое решение ууууух, но мы не успеем/видим риски/ТВОЙ проект провалится/ и по нарастающей от похвалы к лести.

    В любом случае рекомендую обратить внимание на такой инструмент как на координационный комитет с вопросом не архитектуры, а увеличения денег и сроков. Что бы не играть на поле архитектора и перейти на поле СЕО.

  3. Jul 7th, 2011 at 12:51 | #3

    Была абсолютно такая же ситуация. Из-за ошибки архитектора на стороне заказчика пришлось переделывать всю архитектуру за месяц до выпуска релиза, причем мы работали по ночам и выходным.
    Сразу скажу, что переубедить их достаточно трудно. Поэтому обязательно запаситесь четкими доказательствами, что вы предлагали как лучше, но вас не послушали: “мы предупреждаем, что данная архитектура приведет к проблемам, которые не позволят использовать продукт. Пожалуйста подтвердите, что вы берете на себя всю ответственность за данное решение”. Мы в свое время не озаботились подобными письменными доказательствами (мы все обсуждали на митингах словами), поэтому виноватыми во всем сделали нас.

  4. Jul 7th, 2011 at 13:45 | #4

    если время позволяет, то падать на дурачка и наглядно демонстрировать несостоятельность решения, что-то типа:

    “вот глядите, согласно вашей архитектуре эту фичу надо реализовать так-то, но это ведёт к дублированию кода\потери масштабируемости\ещё какой-то ужас. но этого быть не может, т.к. архитектура клёвая. значит мы не что-то недопоняли и просим помочь с решением – как же всё-таки _правильно_ делать?”

    вам ответят что-то типа “ну да – это частный случай, мы согласны на дублирование кода\потерю масштабируемости\ещё какой-то ужас”

    а вы тут же “да? а вот кстати ещё 1 частный случай – тут тоже ужас получается – мы правильно понимаем как делать?”

    ну и при случае вворачивать “а вот если бы делали так-то, то гемора не было бы, ну да ладно. всё равно не успеем переделать. кстати, это _ты_ нам подсказал когда-то такой подход”.

    ну и т.д. и т.п.

  5. Jul 7th, 2011 at 13:47 | #5

    короче, если человек не воспринимает критику, то надо чтобы он пожинал плоды проблемного решения _как можно раньше_, когда ещё будет время развернуть оглобли. потому что если вы полгода побежите по его дорожке, то надо будет или придумывать постепенный способ смены курса или забыть о смене курса навсегда. такие дела.

  6. Jul 7th, 2011 at 14:24 | #6

    2COTOHA: иными словами – старый добрый принцип “дай козлу почаще ошибаться” :)

    • Jul 7th, 2011 at 14:59 | #7

      не давать ошибаться, а создать острую необходимость астро-архитектору спускаться на землю из эмпиреев и валидировать своё решение кодом.

  7. Jul 7th, 2011 at 16:33 | #8

    Вижу ещё одну проблему в словах “Мы написали письмо” и “…переписка…”.
    И её же – в каментах, кроме @Андрея.

    Не навели контакты. Не создали человеческое общение. Не желаем стать на место другой стороны.

    В кейсе почти полностью отсутствует анализ личности и мотивов “Архитектора” (ирония в наименовании с Большой Буквы – это тоже пассивно-агрессивный подход, не правда ли?).

    В зависимости от оных с ним надо или договариваться (полностью открыто, показывая всяческую готовность сотрудничать), или торговаться, или провести чисто техническую дискуссию, или, в предельном случае, гнать его в шею через СЕО (или уходить самому). Правда, последний случай означает, что Ваша контора потеряет заказчика на отдел из 50 человек – учитывайте, возможно ли это, и не лучше ли пойти на компромисс самому :)

    В любом случае, в этом месте Вы делаете максимально дружелюбный телефонный звонок. Если можно и комфортно заказчику – с видео. Сначала Архитектору, ещё раз, потом, если не поможет СЕО. Помните, что поссориться вы всегда успеете, а сотрудничать надо ещё долго.

    Ну а если затеваете подковёрную борьбу и саботаж на местах в стиле “подставь начальника” – будьте уверены, что обладаете умением в этом деле и переиграете человека, который сумел сделать карьеру и в друзьях у СЕО :D

  8. Михаил Петрук
    Jul 7th, 2011 at 18:35 | #9

    Я предполагаю такую модель поведения, что раз человек имеет большой авторитет ему труднее признавать свои ошибки из-за нежелания выглядеть некомпетентным идиотом.

    В таких ситуация я обычно начинаю фразу типа “а вы не думали, может сделать так” и далее правильный с вашей точки зрения вариант. Желательно, чтобы это было совместимо с его решением, ему легче будет согласится. Если он подумает в этом ключе, скорее всего он будет считать, что это его идея и это гуд для проекта в целом. Не мытьем, так катаньем.

  9. Jul 8th, 2011 at 08:06 | #11

    Несколько смутили некоторые фразы в кейсе:

    и объявил о нём, видимо, не сильно оценивая последствия

    Архитектор ввиду сильной занятости не оценил наше письмо, самоуверенно защищает своё техническое решение. Сейчас идёт переписка по этой проблеме, с каждым письмом он всё более пассивно-агрессивен.

    мы вежливы и дружелюбны, но Архитектор принимает наши письма агрессивно, отвечает без вежливости, воспринимает нас как угрозу своему авторитету

    Как можно быть вежливым и дружелюбным одновременно считая собеседника самоуверенным, невежливым, агрессивным и упертым типа?

    Представьте себе такую ситуацию.

    Вы наняли прораба с его бригадой строителей чтобы сделать ремонт у себя в квартире. В это время жена попросила вас сделать ей подарок к годовщине вашей свадьбы и положить в ванной оранжевую плитку. Когда пришла очередь класть плитку, прораб привел плиточка, которого отрекомендовал как отличного специалиста. Плиточник посмотрел на плитку которую вы выбрали и сказал что это неправильная плитка для ванной – нужно класть белую.
    Вы сказали ему – “Хорошо, я понял. Положите пожалуйста оранжевую плитку”. Он уперся и принес вам журналы по строительству и устройству квартир с хорошими и детальными статьями о том что белый цвет в ванной – это модно, а яркие расцветки признак – дурного вкуса. О том что белый цвет в ванной по статистике повышает настроение, а оранжевый – агрессивность.
    Вы посмотрели статьи и попросили плиточника положить оранжевую плитку как вы сразу и хотели.
    Плиточник вместо того чтобы браться за работу, размахивает журналами и требует у вас обьяснений почему вы игнорируете его подробные и грамотные вргументы.
    Ваши действия?

    • Jul 8th, 2011 at 08:37 | #12

      Андрей,
      Очень уважаю тебя за пример. Он показыает, что мы не всегда докапываемя до причин проблемы. Круто про плитку! В Мемориз!

      С другой стороны, если к нему придут друзья и скажут “что-же ты, дорогой, как последний крестьянин положил не по фен-шую плитку”, то виноваты может быть будет и человек, который ее положил.

      • Jul 8th, 2011 at 09:10 | #13

        хорошая аналогия – как диагональная лягушка (с) Кай Краузе.

        если говорить про архитектуру ПО в разрезе строительства, то хозяин попросил провести трубы по внешней стороне дома, чтобы сэкономить место в ванной.

        строители говорят, что зимой трубы будут замёрзать и лопаться…

        но вообще аналогии – ЗЛО! они уводят разговор зону, которая удобна для обсуждения, но бесполезна для решения исходной проблемы.

      • Jul 11th, 2011 at 11:46 | #14

        Сергей,

        Да, ты прав. Можно оказаться и крайним. Обычно здесь достаточно объяснить какие есть последствия у предложенного варианта и предложить альтернативы. Причем хорошо бы сделать это в присутствии прораба, чтобы в последствии была возможность на это ссылаться.

        С другой стороны заказчик может катить бочку и при наличии всех письменных договоренностей и документов с approval’ами. Всегда можно найти к чему придраться.
        Что лишний раз говорит о необходимости тратить время и ресурсы чтобы построить плотные и доверительные отношения с заказчиком – то о чем ты рассказываешь на тренингах :)

  10. Jul 11th, 2011 at 11:21 | #15

    если говорить про архитектуру ПО в разрезе строительства, то хозяин попросил провести трубы по внешней стороне дома, чтобы сэкономить место в ванной.
    строители говорят, что зимой трубы будут замёрзать и лопаться…

    Я видимо не совсем понятно сформулировал свою мысль. Я не имел виду что надо всегда кидаться делать все что скажет заказчик без всяких уточнений и возражений.

    Просто часто заказчик – это люди, про которых мы мало что знаем кроме их имен и емейл адресов, которых мы даже не видели никогда в жизни. Поэтому бывает что мотивы их поведения нам непонятны и сходу считать что мы лучше заказчика знаем что ему нужно (что видно в кейсе и в большинстве комментов) – это несколько самонадеянно.

    Возможно что заказчик предложил провести трубы снаружи потому что он не знает что зимой они могут замерзать и лопаться. И тут задача добросовестных строителей рассказать ему почему это плохо, а еще лучше предложить более грамотные решения экономии места в ванной.

    Но если после этого заказчик почему-то продолжает настаивать на своей идее, то имеет смысл остановится и подумать – почему он настаивает. Конечно возможно что он упертый дурак, но все таки чаще оказывается что мы чего не знаем или не понимаем:
    * Возможно мы собираемся строить дом где-нибудь в Израиле. Там не бывает отрицательной температуры и там это стандарное решение – тянуть трубы по внешней стороне.
    * Или заказчику нужно какое-то временное строение на несколько месяцев и ему не важно что будет зимой.
    * Или ему настолько важно увеличить площадь ванной что он готов потратится на то чтобы трубы утеплить или на зиму туда заливать специальную жидкость (если это дом только для летнего использования).

    Я обычно стараюсь задавать вопросы из такой позиции что не заказчик дурак, а мы наверное что-то недопоняли. И пытаюсь уточнить почему то или иное решение было принято заказчиком. Иногда понимание все равно не появляется и приходится делать то что заказчик хочет не понимая этого. В такой ситуации приходится несколько циклов/итераций подождать, посмотреть как отреагирует заказчик и его клиенты на сделаную фичу, попытаться выстроить более тесные и доверительные отношения с заказчиком и т.п.

  11. Jul 12th, 2011 at 14:30 | #16

    а я имел в виду, что предпологать, что человек из єтого кейса “просто не спросил, зачем єто архитектору” – єто неуважать его интеллект.

    обьічно в кейсьі вьіносятся практически тупиковьіе ситуации, у которьіх нет хороших решений, и надо вьібирать между двумя плохими.

    а так да – хорошо бьіть богатьім и здоровьім.

    и не надо вносить аналогии – они ничему не помогают.

Leave a comment