Привет, Хабр! Меня зовут Антон Ивахненко, я заместитель генерального директора по технологиям группы Рунити. Последний год ко мне всё чаще приходят с одним и тем же вопросом, только в разных формулировках. «А действительно ли команде нужно столько людей?», «Давайте сделаем ее меньше, но будем успевать больше», «Как нам сделать команду эффективнее?». Обычно это звучит от нетехнического топ-менеджмента, и за этим стоит понятное давление: рынок с одной стороны, новые технологии с другой, и от ИТ ждут оптимизаций.

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

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

Этот текст будет полезен, прежде всего CTO, руководителям разработки, техлидам и продактам, которые защищают размер команды перед бизнесом и часто слышат «сократить» или «нанять». Но здесь есть рамка для разговора: почему ценность, эффективность, объем задач и форма команды важнее, чем сам найм или увольнение. Речь о том, как разработка превращается в кост- или профит-центр. 

Навигация по тексту:

• От дефицита кадров к сокращениям

• Причины роста команд

• Причины сокращений

• Ревизия текущей команды

• Чек-лист перед расширением

• Четыре рычага

• Общий язык с бизнесом

• Кейс с платформой вместо трех команд

• Кейс с ростом выше рынка

• Разные ситуации — разные решения по команде

• Правила сокращения

• Ключевые выводы

От дефицита кадров к сокращениям

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

С 2022-го тренд поменялся. Сначала было затишье с разнонаправленными сигналами, а дальше команды начали сдуваться — сначала в мире, а следом и в России. Один и тот же процесс: снижение численности, сокращение расходов.

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

Причины роста команд

У роста две причины, совершенно разные по своей природе.

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

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

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

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

1. Команда замедляется. Новых людей нужно погружать, и это отнимает время у остальных;

2. Управленческие издержки растут: пирамида становится выше, добавляются уровни управления;

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

Всё это бьет по текущим инициативам: они идут медленнее и не дают моментального отклика.

Причины сокращений

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

Эти качели происходят постоянно. Но сокращение — тоже не бесплатная операция. Сократить можно не тех и не вовремя. Можно развалить команду так, что оставшиеся потеряют в эффективности, а продукты — в качестве и скорости вывода на рынок. Причем пострадать может даже та часть команды, которую сокращение напрямую не задело.

Ревизия текущей команды

Прежде чем задаваться вопросом о размере, стоит осмотреть то, что уже в наличии. Проверьте базовые вещи. Правда ли все понимают, за какие направления они отвечают и что конкретно делают? Правда ли каждая команда отвечает за конкретную зону? Если нет, скорее всего, вопрос вообще не в размере, а в форме, и сначала надо поправить ее.

Дальше — что приходит на вход. Измерим ли объем задач? Правильно ли эти задачи поставлены, влияют ли на бизнес-результат, как этот результат оценивается? И что с производительностью самой команды: какая нагрузка на людей, велика команда или мала относительно текущего объема задач? Такая диагностика должна опираться на измеримые показатели, чтобы на основании фактов можно было сделать выводы и принять меры.

Чек-лист перед расширением

Если есть подозрение, что команду пора расширять, ответьте сначала на несколько вопросов.

• Есть ли бизнес-драйвер под расширение? Правда ли оно оправдано?

• Исчерпан ли текущий ресурс внутри команды и в каких местах? Может оказаться, что всё перебалансируется: сбросить ненужные активности, применить другие технологии и подходы;

• Есть ли критичные пробелы в компетенциях? Правда ли они существуют и какой импакт оказывают на продукты?

• Есть ли утвержденный план действий по продуктам? Без него не посчитать ресурсы.

• Устраивает ли отдача от текущих вложений, в том числе в ФОТ? Если отдача и сейчас низкая, расширение может просадить показатель еще сильнее.

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

Четыре рычага

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

1. эффективность — как команда работает;

2. объем задач, которые приходят на вход;

3. форму, в которой команда организована;

4. размер команды.

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

Сначала — эффективность.Проверяем, можно ли повысить эффективность текущих процессов: правда ли процессы совершенны и за их счет ничего не улучшить? Смотрим на инструменты — с развитием ИИ их стало больше, и повлиять они могут существенно.

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

Затем — форма. Команды бывают продуктовые, сервисные, платформенные, и при одинаковых вложениях в ФОТ они дают разный результат. Выделенные продуктовые команды обычно дороже, зато быстрее двигаются к целям, гибче управляют бэклогом и фичами.

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

Порядок тут не случаен. Прийти к продуктовикам и сказать «давайте выкинем часть задач, мы не справляемся» — так себе стратегия. Вам справедливо ответят: «Сначала наладьте свои процессы, а потом предлагайте пересматривать задачи». Поэтому всегда начинаем с эффективности и только во вторую очередь смотрим на объем.

Общий язык с бизнесом

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

Профит-центр — это когда продукт растет, вы занимаете новые ниши, растет рынок и потребление, и вы напрямую влияете на доход. Здесь главное — скорость, которая позволяет занять большую долю рынка. Это язык про объемы и рост.

Кост-центр — наоборот, сервисная функция, которая снижает риски и обеспечивает стабильность бизнеса. Здесь язык про экономию: задача не заработать, а построить максимально эффективные процессы.

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

Сам разговор можно строить по простому каркасу. Сначала понять, в какой ситуации мы находимся: дефицит ресурсов или, наоборот, дефицит продуктовых идей. Потом выбрать, каким из четырех рычагов воздействовать. Затем определить язык, на котором говорить с бизнесом. И только после этого идти договариваться и фиксировать обязательства. Честный, понятный, прозрачный подход.

Кейс с платформой вместо трех команд

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

Первой идеей было объединить команды. Но быстро стало понятно: если просто поменять оргструктуру, работа никуда не исчезнет. Останутся три реализации, в каждую по-прежнему придется вносить изменения, каждую — тестировать и выпускать.

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

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

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

И только из этой картины можно было выводить целевой состав команды. Причем высвобождение людей ещё не означало экономию ФОТ: если переводим их на другие задачи, расходы сохраняются, но появляется ресурс для развития. Если уменьшаем состав — отдельно считаем снижение затрат.

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

Кейс с ростом выше рынка

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

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

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

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

Смотрели на три группы показателей:

• Скорость: сократилось ли ожидание приоритетных инициатив и стали ли они раньше доходить до пользователей;

• Качество: не выросла ли доля выпусков, после которых приходилось откатывать изменения или срочно выпускать исправления. Ускорение за счет нестабильности нас не устраивало;

• Экономика: изменились ли целевые продуктовые метрики и какой дополнительный маржинальный доход дали выпущенные инициативы относительно дополнительных затрат на команду. В затраты включали не только ФОТ, но и найм, адаптацию и необходимые инструменты.

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

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

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

Разные ситуации — разные решения по команде

Теперь по видам роста — они требуют разных решений.

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

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

У меня в практике было несколько историй, где это не получилось. Под большие целевые изменения нанимали три-пять человек. По численности немного, но по ФОТ — существенное вложение, которое непросто было согласовать.

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

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

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

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

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

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

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

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

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

Смысл такого подхода — не доказать, что старую команду теперь легко заменить. Смысл — сделать трансформацию менее зависимой от готовности конкретных людей ее проводить. ИИ здесь — один из инструментов снижения этой зависимости, а не гарантия безопасной замены команды.

Правила сокращения

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

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

Поэтому важно заранее понимать, что вы будете делать с этими людьми дальше. Правда ли они навсегда? Если вы нанимаете под новый продукт или стратегический рост — сколько из этих людей останется, когда продукт перейдет в стабильную фазу? Сценария по сути два: либо продукт не выстрелит и люди не понадобятся, либо он стабилизируется. Стабильный продукт нужно просто обслуживать и поддерживать, и бизнес должен понимать, что люди в ноль не исчезнут. Но держать численность, которая была нужна на фазе интенсивного роста, смысла нет.

Отсюда несколько практических правил.

1. Ещё на этапе найма стоит понимать, что произойдет с нагрузкой после завершения проекта и можно ли будет перевести сотрудников на другие задачи;

2. Не каждый всплеск активности требует найма. Под пиковые перегрузки берите аутстафферов и подрядчиков, но только на короткие интервалы: на длинной дистанции это экономически нецелесообразно и бьет по качеству;

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

Ключевые выводы

Три тезиса, которыми хочу закончить.

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

Второй. Когда влияете на масштаб и численность команды, говорите на понятном языке и с понятной мотивацией для того, кто принимает решение.

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

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