Почему digital-команды становятся меньше — и выпускают больше чем когда-либо

Три года назад один клиент пришёл к нам с 22-человечной командой разработки и продуктом, где значимая фича выходила раз в четыре месяца. Сегодня мы работаем с компаниями, у которых команда из 4 человек деплоит в прод дважды в неделю. Нанимать лучше не стали. Просто изменилось то, что делает команду продуктивной.

Что мы видим прямо сейчас

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

Год назад SaaS-клиент среднего размера реструктурировался с трёх команд по шесть человек на две по три — тот же выпуск, меньший burn rate. Людей не увольняли — пятерых перевели на отдельный продукт. Меньшие команды стали быстрее. Не немного. Частота деплоев выросла с двух в месяц до одиннадцати.

Это не единичный случай. Мы видели такую же динамику в e-commerce, финтехе и B2B SaaS. Команды, которые двигаются быстрее всех в 2025 году, компактны по дизайну, а не по ограничениям.

Почему меньшие команды шипят больше

Ответ состоит из трёх частей.

• Накладные расходы на координацию растут быстро. У команды из 10 человек не вдвое больше накладных расходов на коммуникацию, чем у команды из 5 — примерно впятеро больше. Каждый хэндофф, каждый синк, каждый PR в ожидании ревью от нужного человека добавляет задержку, которая накапливается на каждой фиче. У маленьких команд этой проблемы в таком масштабе нет.
• AI-инструменты изменили юнит-экономику. Разработчик с хорошими AI-инструментами пишет, ревьюит и тестирует код значительно быстрее — в нашей работе оценки кластеризуются около 30–50% на рутинных задачах, выше на скаффолдинге и бойлерплейте. Это меняет расчёт: предельная ценность добавления ещё одной единицы найма ниже, когда ваша существующая команда уже работает ближе к 1,5× выпуска.
• Владение чётче. В маленькой команде нет неоднозначности в том, кто чем владеет. Нет "это проблема команды платформы" или тикета, который зависает потому, что никто не чувствовал ответственности. Когда три человека владеют продуктом — все отвечают за всё. Это меняет скорость и качество принятия решений.

Чего lean-команды не могут

У этого тренда есть границы, и стоит говорить о них честно.

Lean-команды быстры потому, что у них узкий скоуп. Команда из 4 человек, быстро выпускающая один продукт — это не модель, которую можно просто размножить для одновременного ведения пяти продуктов. Экономия на координации исчезает, как только нужна синхронизация между потоками. У вас будет не lean-монолит — а lean-юниты, которым всё равно нужна операционная модель для взаимодействия.

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

Что это значит для найма сегодня

Если вы принимаете решения о найме инженеров в 2025 году, вопрос не "сколько инженеров нужно, чтобы выпустить X?" Он ближе к "какая минимальная команда способна владеть этим end-to-end с правильными инструментами?"

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

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

Честная версия

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

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