Как вы разрешаете архитектурные разногласия в вашей команде?

Question

Accepted Answer

Умные инженеры будут расходиться во мнениях по архитектуре, это нормально. Задача tech lead'а — превратить разногласие в **хорошее решение и вовлечённую команду**, а не выиграть спор. Большинство споров исчезают, как только все согласны с критериями.

## Процесс разрешения

```text
1. AGREE on the criteria first — what are we optimizing for?
   (scale, simplicity, time-to-ship, team familiarity)
2. Let each side make its STRONGEST case — steelman, don't strawman
3. Look for DATA — spike it, benchmark it, prototype it
4. If still tied — the TL decides, and explains why
5. DISAGREE AND COMMIT — once decided, everyone rows together
```

## Конкретный пример

Два инженера спорят о микросервисах против монолита. Вы переформулируете вопрос: "Что мы оптимизируем в течение следующего года?" Ответ — быстрая разработка с маленькой командой — делает монолит очевидным выбором. На самом деле спор был о неартикулированных целях.

## Когда принимать решение, а когда отложить

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

## Типичная ошибка

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

## Почему это важно

Неразрешённые архитектурные конфликты разъедают команду и расщепляют её на лагеря.

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