Архитектурный комитет: как он работает и как в нём участвовать менеджеру

← назад к разделу

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

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

Зачем компании архитектурный комитетспросят на собеседовании

Комитет (в англоязычных компаниях Architecture Review Board, ARB) нужен ради трёх вещей, и если ни одна из них не болит, он не нужен.

• Цена необратимых решений. Выбор СУБД для платёжного контура, формат событий между доменами, публичный API для партнёров. Ошибку здесь исправляют кварталами, и второй взгляд до начала работы дешевле любой переделки.
• Согласованность платформы. Каждая новая технология это обучение, мониторинг, обновления, лицензии, дежурства. Десять команд, каждая из которых выбрала «лучшее для себя», в сумме получают худшую систему.
• Память решений. Через два года никто не помнит, почему выбрали Kafka, а не RabbitMQ. Комитет, который требует записанного решения, создаёт архив, по которому новый человек восстанавливает логику.

Хорошая рамка для разговора о том, зачем всё это, есть у Джеффа Безоса в письме акционерам 2015 года: решения бывают «дверями в одну сторону» (Type 1), необратимыми, которые принимают медленно и с консультациями, и «дверями в обе стороны» (Type 2), которые можно откатить и которые должны принимать быстро отдельные люди или небольшие группы. Там же предупреждение, которое стоит повесить над входом в любой комитет: с ростом организации тяжёлый процесс для первого типа начинают применять почти ко всем решениям, а результат это медлительность, неосмысленное избегание риска и недостаток экспериментов. Комитет нужен для дверей в одну сторону и вреден для дверей в обе стороны.

Состав и полномочияспросят на собеседовании

Типичный состав для компании на 10-30 команд, 5-8 человек:

Полномочия стоит записать в одном документе на страницу, иначе каждый спор начинается со спора о правах. Три уровня, которые реально встречаются:

1. Совещательный. Комитет даёт рекомендацию, решение остаётся за командой. Это модель advice process, которую Эндрю Хармел-Ло описал в 2021 году: решение может принять любой, но обязан спросить совета у тех, кого оно затронет, и у тех, кто разбирается, и записать полученные советы. Согласия при этом не требуется.
2. Обязательное согласование для заданного класса решений. Всё, что выходит за tech radar или задевает общие контракты, без одобрения не едет в прод.
3. Право вето. Комитет может запретить решение. Это сильный инструмент, и его границы должны быть записаны: на что распространяется, кто может вето снять, за какой срок оно выносится.

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

Что выносить на комитет, а что нетспросят на собеседовании

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

Выносят:

• новую технологию вне радара: СУБД, брокер, язык, облачный сервис;
• изменение общих контрактов: формат событий, публичный API, схему, которую читают другие команды;
• решения, которые затрагивают три и больше команд;
• всё, что касается персональных данных, платёжного контура, требований регулятора;
• решения с ценой сверх порога: например, дополнительные расходы на инфраструктуру больше заранее оговорённой суммы в месяц или переделка дороже квартала команды;
• отказ от уже принятого решения: уход с технологии, вывод сервиса из эксплуатации.

Не выносят:

• внутреннее устройство сервиса за его контрактом: слои, библиотеки из радара, структуру пакетов;
• выбор между вариантами, которые оба в кольце Adopt;
• всё, что откатывается за спринт без последствий для соседей.

Полезный тест для команды: «если через полгода окажется, что мы ошиблись, кто кроме нас будет переделывать?» Если никто, это решение команды.

Критерии допуска решения

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

1. Проблема и ограничения. Что решаем, какие нагрузки, какие сроки, какие требования регулятора.
2. Минимум две альтернативы с честным сравнением, включая «ничего не менять».
3. Соответствие радару и принципам. Если решение выходит за радар, отдельный абзац: почему существующее не подходит.
4. Эксплуатация. Кто дежурит, как мониторится, что будет при отказе, есть ли в компании экспертиза.
5. Цена владения. Инфраструктура, лицензии, обучение, на горизонте года.
6. Путь отката или выхода. Что делаем, если не взлетело, и сколько это стоит.
7. Безопасность и данные. Какие данные, где хранятся, кто имеет доступ.

Tech radar как способ снять половину вопросов

Thoughtworks публикует Technology Radar дважды в год, его составляет их Technology Advisory Board, около двадцати старших технических специалистов. Радар делит технологии на четыре сектора (техники, платформы, инструменты, языки и фреймворки) и четыре кольца: Adopt (стоит всерьёз рассматривать для использования), Trial (готово к использованию, но проверено меньше), Assess (стоит внимательно изучить, но пока не пробовать в бою) и Caution (то, с чем у авторов был негативный опыт и от чего отрасли стоит рассмотреть альтернативы или даже заранее отказаться). Ещё в подкасте Thoughtworks 2024 года последнее кольцо называлось Hold («не начинайте на этом ничего нового»), а в текущем, 34-м выпуске, апрель 2026, оно называется Caution.

Главная ценность для менеджера не сам радар Thoughtworks, а их прямая рекомендация строить свой. Внутренний радар компании отвечает команде заранее: PostgreSQL в Adopt, значит, комитет не нужен; ClickHouse в Trial, значит, можно в одном сервисе с отчётом через полгода; MongoDB в Caution, значит, нужна защита с очень сильным обоснованием. Комитет обновляет радар раз в полгода, и это снимает с повестки большую часть рутинных вопросов.

Как устроить свой радар за месяц: собрать от команд список того, что реально используется, разложить по кольцам на одной встрече комитета, опубликовать с одной строкой обоснования на каждую позицию, и договориться, что переход из Trial в Adopt требует хотя бы двух команд с опытом в проде.

Право вето и эскалация

Вето без правил превращается в способ затянуть решение бесконечно. Минимальный набор правил:

• Вето всегда письменное и с причиной, которую можно исправить: «нет плана отката», «нет дежурства», а не «нам не нравится».
• Срок на решение. Например, десять рабочих дней с момента подачи полного документа. Комитет, который не уложился, не может потом сказать «нет» по умолчанию.
• Путь эскалации известен заранее. Команда, не согласная с вето, идёт к CTO или к тому, кто владеет бюджетом, с документом и записанным возражением комитета. Это обычный путь, а не скандал.
• «Не согласен, но поддерживаю». Безос в письме 2016 года называет это disagree and commit: если решение принято, несогласные его выполняют, а не саботируют. В комитете это работает в обе стороны: команда, которая проиграла спор, делает как решили, комитет, который был против, не мстит на следующем ревью.

Как готовить решение к защитеспросят на собеседовании

Документ к комитету это design doc, а итог защиты фиксируется в ADR. Формат ADR предложил Майкл Найгард в 2011 году: заголовок, контекст, решение, статус, последствия. Он же дал определение того, что вообще стоит записывать: решения, которые влияют на структуру, нефункциональные характеристики, зависимости, интерфейсы или способы построения системы. Это почти дословно совпадает со списком «что выносить на комитет».

Порядок подготовки, который экономит недели:

1. Пред-ревью у одного-двух членов комитета за неделю до подачи. Главные возражения вы услышите здесь и успеете учесть.
2. Документ отвечает на все критерии допуска, сводная таблица альтернатив на первой странице.
3. Отдельно перечислено, что от комитета нужно: одобрение, выбор из двух вариантов, исключение из радара. Комитет, которому не сказали, какой вопрос решить, обсуждает всё.
4. Цена ожидания. Если команда стоит, пока нет решения, это пишут прямо: «каждая неделя без решения сдвигает релиз на неделю».

Шаблон шапки документа на комитет:

Решение: переход сервиса уведомлений с RabbitMQ на Kafka
Что нужно от комитета: одобрение исключения из радара (Kafka в Trial)
Затронутые команды: уведомления, профиль, аналитика
Тип решения: необратимое для формата событий, обратимое для брокера
Цена: +N руб/мес инфраструктура, 6 недель команды
Откат: двойная запись в оба брокера первые 4 недели
Срок нужного решения: до 15.11, иначе сдвиг релиза

Роль менеджера на комитетеспросят на собеседовании

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

• Кто будет это поддерживать через год, и сколько людей в компании это умеют?
• Что мы перестанем делать, чтобы это сделать?
• Это дверь в одну сторону или в обе? Если в обе, зачем мы здесь?
• Сколько стоит ожидание решения, и кто за это ожидание платит?
• Что произойдёт с командами-соседями: им нужно что-то менять, и есть ли это в их планах?
• Как мы узнаем через три месяца, что решение было ошибкой?

И ещё две обязанности, которые часто никто не берёт на себя: следить, чтобы решение комитета дошло до команды с объяснением, а не одним «одобрено/отклонено», и вносить в технический долг то, что комитет принял как временное исключение.

Как не превратить комитет в бюрократиюспросят на собеседовании

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

Что помогает:

• Асинхронное ревью по умолчанию. Документ идёт как запрос на изменение в репозиторий, комментарии до срока, явная отметка от двух-трёх обязательных ревьюеров. Встреча нужна только для спорных развилок. Подробно механика описана в разделе асинхронного ревью дизайна.
• Пороги, а не «всё через нас». Список того, что выносится, короткий и публичный; всё остальное команда решает сама и записывает ADR.
• Радар как предварительное разрешение. Чем полнее Adopt, тем меньше повестка.
• Открытое заседание. Как в модели Хармел-Ло с еженедельным открытым часом: приходит кто хочет, слушает, учится. Это лучший способ вырастить новых архитекторов.
• Метрика самого комитета. Время от подачи до решения, доля возвратов, сколько решений через полгода пересмотрели. Комитет, который меряет других, должен показывать свои числа.

Типичные ошибки

• Комитет решает за команды то, что они сделают лучше. Внутреннее устройство сервиса, выбор библиотеки из радара. Команда теряет ответственность: «так решил комитет».
• Решения в протоколе встречи, а не в ADR. Через год протокол никто не найдёт.
• Вето без срока и причины. Команда ждёт месяц и делает в обход.
• Комитет из одних архитекторов. Нет эксплуатации и безопасности, и решение «одобрено», но его невозможно дежурить.
• Менеджер не участвует, «это техническое». Потом выясняется, что одобренное решение требует трёх месяцев, которых нет в плане.
• Ретроспективы решений нет. Никто не проверяет, сбылись ли последствия, и комитет не учится на своих ошибках.

Глубже: комитет в регулируемой средерасширенное

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

Глубже: что ответить на собеседовании «как у вас принимаются архитектурные решения»расширенное

Сильный ответ называет механизм, а не орган. Например: «Решения внутри сервиса принимает команда и записывает ADR в репозиторий. Решения, которые выходят за радар, меняют общие контракты или затрагивают три и больше команд, проходят асинхронное ревью design doc с двумя обязательными ревьюерами от платформы и безопасности, срок десять рабочих дней. Если спор не решается, открытая встреча по развилкам, дальше эскалация к CTO. Радар обновляем раз в полгода». Затем пример: какое решение провели, какое возражение было, что изменили. Слабый ответ: «у нас есть архитектурный комитет, всё согласуем с ним».

Коротко

• Комитет нужен для необратимых решений, согласованности платформы и памяти решений; для обратимых он вреден.
• Полномочия записывают заранее: совет, обязательное согласование узкого класса или вето с правилами.
• Порог выноса формальный: вне радара, общие контракты, три и больше команд, данные и регулятор, цена сверх порога.
• Критерии допуска: проблема, две альтернативы, радар, эксплуатация, цена владения, откат, безопасность.
• Свой tech radar с кольцами Adopt, Trial, Assess, Caution снимает с повестки большую часть вопросов.
• Вето письменное, с исправимой причиной и сроком, путь эскалации известен заранее.
• Менеджер на комитете отвечает за сроки, людей, деньги и соседей и спрашивает про цену ожидания и поддержку через год.
• Против бюрократии: асинхронное ревью по умолчанию, пороги, открытое заседание, метрики самого комитета.

Что почитать дальше

• Design doc - как писать документ, который проходит ревью.
• ADR - как записывать решение после защиты.
• Роль архитектора - чем занят архитектор и как не стать узким местом.
• Технический долг - куда девать временные исключения, одобренные комитетом.
• Стейкхолдеры и ожидания - как эскалировать спор как обычное действие.
• Масштабирование процессов - как устроена координация, когда команд много.