Множественные перспективы при решении технических проблем

12 августа 2017 года

Автор: John Allspaw

I am currently a co-founder of Adaptive Capacity Labs, LLC. Previously, I was Chief Technology Officer at Etsy

За эти годы многие спрашивали меня о деталях процесса архитектурного ревью в Etsy.

В этой статье я хочу рассказать о роли рабочей группы архитектурного ревью в организации диалога вокруг технологических решений. Частично речь пойдет просто о рабочих группах в целом (их плюсы, минусы, форматы и т.д.), а частично — о философии, которую Дэн МакКинли изложил в своём посте/докладе. Советую сначала прочитать его материал, а потом вернуться сюда.

Фундаментальная идея: принятие инженерных решений — это социально сконструированная деятельность

Но сначала нужно заложить теоретическую основу. В 1985 году Билли Вон Коэн (ныне почетный профессор Техасского университета) представил концепцию «Инженерного метода», о которой я уже писал ранее. Ключевая идея — его наблюдение, что инженеров определяет не то, что они создают, а то, как они работают. Он сформулировал Инженерный метод очень лаконично:

«стратегия достижения наилучших изменений в плохо понятной или неопределённой ситуации в рамках доступных ресурсов»

Обратите внимание на оценочные термины наилучших и плохо понятной.

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

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

• Описания проблемы, которую, по их мнению, нужно решить. Это может быть как простым, так и сложным для объяснения, поэтому обычно требуется обсуждение туда-сюда, чтобы группа полностью поняла проблему.
• Формирования гипотез о том, нужно ли решать описанную проблему полностью или частично, исчерпывающе или нет. Некоторые описания проблем могут быть очень узкими или, наоборот, очень широкими, некоторые проблемы не обязательно решать полностью и сразу. Будет ли проблема существовать вечно?
• Оценки вариантов решений. Какие есть плюсы и минусы? Сможет ли команда, которой придётся поддерживать решение, действительно его поддерживать? Имеют ли некоторые решения «срок годности»? Какие непредвиденные последствия могут возникнуть в зависимых системах выше или ниже по цепочке?
• Укрепления уверенности в реализации конкретного решения. Насколько (и в чём именно) команда не уверена в том, как решение проявит себя в позитивном или негативном смысле?
• И так далее.

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

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

Концепция и намерение

Когда мы с Келланом пришли в Etsy в 2010 году, мы внедрили процесс, при котором инженер (или группа), планирующие реализовать что-то новое (отличное от того, что мы уже использовали), должны были представить проблему, которую пытаются решить, и объяснить, почему существующие решения в Etsy не подходят. Мы назвали это архитектурным ревью.

Мы называли эти «что-то новое» отступлениями (departures). Опять же, пост/доклад Дэна разбирает это подробнее, но основная идея в том, что отступления несут издержки (многие из которых могут быть скрытыми и неожиданными по многим направлениям). Попытка решить локальную проблему без учёта глобальных последствий для организации обходится дорого.

Отступления могут включать такие вещи как:

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

Эти пункты выше довольно размыты, вы наверняка заметили. Так как же понять, нужно ли запрашивать архитектурное ревью? Спросите коллег. Если вы сомневаетесь, нужно ли оно вам, скорее всего, нужно.

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

Суть можно описать так, с точки зрения инженера, желающего получить фидбэк:

«Эй, все — посмотрите на это: я считаю, что мне нужно решить проблему X, и я подумал об использовании A, B и C, но все они не кажутся идеальными. Думаю, мне придётся пойти на отступление Y как решение. Пожалуйста, попытайтесь меня переубедить».

Этот подход приводит к действительно хорошим отправным точкам для диалога, о котором я говорил выше. Например:

• «Может, мне вообще не нужно решать проблему X?»
• «Может, я что-то упускаю с A, B или C? Возможно, они сработают достаточно хорошо?»
• «Если я выберу Y, что нам нужно сделать, чтобы чувствовать уверенность в поддержке Y как решения для этого типа проблем?»

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

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

Однажды инженер показал довольно сложную диаграмму, описывающую, как он собирается собирать, обобщать, хранить данные и действовать на их основе для новой фичи. Его решение предполагало не только добавление нового языка в критический путь приложения, но и внедрение нового (и на тот момент относительно незрелого) хранилища данных в стек. После нескольких вопросов стало ясно, что нужные данные уже существуют, и он был всего в одном SQL-запросе и одной cron-задаче от реализации новой фичи.

Такие исходы случались не часто. Но когда случались, это было очень приятно.

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

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

Как эволюционировал диалог множественных перспектив

Однако была одна проблема: когда вы CTO и старший вице-президент, вас не должно удивлять, что люди приходят на встречи, когда вы их приглашаете. Я часто задумывался, есть ли вопросы и мнения, которые не озвучиваются из-за властной динамики в комнате. Я знал, что если критическая масса инженеров в комнате не продемонстрирует вес этой практики (то есть создание и поддержку диалога критического мышления, предназначенного помогать инженерам индивидуально и организационно), то есть хороший шанс, что всё деградирует в некое иерархическое судейство в стиле «American Idol» и жёсткое навязывание политики.

Идея, конечно, была в том, что лучшее принятие решений происходит, когда люди приходят и чувствуют себя комфортно, задавая вопросы, которые в другой обстановке могли бы показаться «глупыми» или наивными, а ведущие презентацию воспринимают критику как комментарии о дизайне, а не об их навыках. Это означало, что можно было зафиксировать происхождение дизайна (какую проблему он должен был решать в тот момент, какие опасения были у людей в тот момент и т.д.).

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

Рождение особого вида рабочей группы

Так появилась Рабочая группа архитектурного ревью, или «ARWG». Основная идея заключалась в том, что такая группа может продолжать практику без того, чтобы руководство инженерной службы привносило авторитарный флёр на встречи, и постоянно моделировать поведение, необходимое для поощрения множественных перспектив, которые нужны для отступлений.

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

Устав группы в целом был тем же, что и наши намерения на ранних архитектурных ревью: создать стабильную и доброжелательную среду, где инженеры могут открыто описывать, как они думают о решении проблем с потенциально новыми и непривычными технологиями и паттернами. Эта среда должна поддерживать вопросы и комментарии от остальной организации о компромиссах, предположениях, ограничениях, давлении, поддержке и ответственности, связанных с отступлениями. И наконец, документирование того, как принимались решения об отступлениях, чтобы существовал своего рода антропологический артефакт для информирования будущих решений и диалогов.

Вы можете подумать: «но где и когда принимается решение?»

Роль ARWG была не в том, чтобы принимать решение.

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

В этом месте я хотел бы провести семантическое различие между «диалогом» и «обсуждением», и я возьму это из предыдущего поста в блоге, где я рекомендовал книгу «Диалог: искусство мыслить вместе»:

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

Обсуждение — это принятие решения. В отличие от диалога, который стремится открыть возможности и увидеть новые варианты, обсуждение стремится к закрытию и завершению. Слово решить (decide) означает «разрешить трудности, прорубив их». Его корни буквально означают «убить альтернативу».

Роль ARWG — сначала фасилитировать диалог, затем обсуждение. Ключевая идея — пролить как можно больше света через «открытые и любопытные умы» на отступление (проблему и решение) до того, как перейти к фазе оценки вариантов. Диалог предназначен для того, чтобы сначала обратить внимание на детали отступления (и его предполагаемую необходимость), и только потом может происходить обсуждение достоинств разных вариантов.

По моему опыту, когда архитектурное ревью привлекает внимание к проблеме и предложенным решениям с множества перспектив, решения становятся менее спорными. Когда решение кажется очевидным для широкой группы («Вопрос: должны ли мы (или не должны) делать резервные копии критических баз данных? Решение: Да»), то способ принятия решения почти исчезает.

Только когда нет всеобщего согласия по решению (или даже по тому, необходимо ли решение), становится важно знать, как, кто и когда принимает решение. Идея архитектурного ревью — достаточно широко раскрыть пространство проблемы и предлагаемые идеи отступления в диалоге, чтобы путаница вокруг них была снижена настолько, насколько это возможно. Меньше путаницы вокруг темы может помочь снизить неопределённость и/или тревогу по поводу решения.

Теперь о некоторых подводных камнях:

• Инженеры (как делающие презентацию, так и участвующие как аудитория) должны понимать, что цель архитектурного ревью — разработать лучшие результаты. Вот и всё. Это не демонстрация их технического мастерства.
• Если появляется только фокус на «но кто принимает окончательное решение?», это сигнал, что критика и обратная связь (опять же, как по проблеме, так и по решениям) на самом деле не нужны, и инженеры думают, что их идеи отступлений должны получить индульгенцию от критики по какой-то причине. Спросить об этих причинах полезно.
• Без сильного и постоянного акцента на «критикуйте код, а не кодера» этот подход может (и будет, я гарантирую) деградировать в эпизоды оборонительности на множестве фронтов. В первую очередь, инженеры, ищущие обратную связь по своим идеям отступления, должны видеть это как часть своей роли зрелого инженера.

Иногда вы можете обнаружить инженера, настолько невероятно увлечённого решением, которое он разработал для данной проблемы, что он начинает фокусироваться на презентации как на «продающем питче» больше, чем на выражении желания получить обратную связь. Хорошая новость в том, что это относительно легко обнаружить, когда это происходит. Плохая новость в том, что цель ревью не всем ясна.

В другие разы вы можете обнаружить группу инженеров, ответственных за разработку решения, которые видят себя отличными от группы, ответственной за поддержку решения. Эта двойная связка «полномочия-ответственность» действительно проявляет себя даже в наименее силосных организациях. В этом случае, поздравляю! Архитектурное ревью смогло вывести на поверхность потенциальных слонов в комнате.

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

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

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

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

«Отлично, похоже, у вас есть гипотеза! Мы проведём архитектурное ревью. Если это такое очевидное решение, как вы думаете, остальной организации должно быть легко прийти к такому же выводу, и это сделает реализацию и поддержку намного проще. Если есть какие-то недостатки, которые не очевидны, у нас по крайней мере будет шанс их выявить!»