Почему так происходит? Изменение количества специалистов связано с этапами жизненного цикла продукта. В начале, на этапе проектирования и концепции, важнее всего «не промахнуться» с фундаментом, поэтому нужны опытные эксперты: архитектор, аналитик, сильные сеньоры. Это особенно критично, если вы строите решение на вырост, а не MVP, который можно выбросить в корзину после проверки гипотезы.
Дальше, на этапе активной разработки, состав становится более «рабочим»: основной объем закрывают мидлы, сеньоры остаются точечно — на сложные узлы, ревью, архитектурный контроль, а джуны берут рутинные, типовые задачи.
На этапе поддержки команда разработчиков обычно упрощается: в основном остаются джуны и мидлы, потому что задач много, но они мелкие, понятные. Сеньоры подключаются редко, архитектор чаще всего уже не нужен — архитектура заложена, а аналитика обычно требуется по-минимуму.
И тут важно помнить: дело не только в грейдах, но и в самом размере. Есть «правило двух пицц», которое придумал Джефф Безос, основатель Amazon: команда должна быть такого размера, чтобы ее можно было накормить двумя пиццами. Чем больше людей, тем быстрее множатся коммуникационные связи, появляются лишние согласования, правила, регламенты — и в какой-то момент вам нужны отдельные люди, чтобы управлять уже не продуктом, а самой командой. Самые сильные команды обычно небольшие, сфокусированы на одном участке.
Поэтому большие корпорации часто выбирают микросервисную архитектуру: когда команд много, систему проще делить на независимые части, чтобы каждая отвечала за свой сервис. Это связано с законом Конвея: «Организации проектируют системы, которые копируют структуру коммуникации в этой организации». Небольшому же проекту чаще разумнее стартовать с монолита: меньше инфраструктуры и проще разработка.
