В ИТ-индустрии долгое время доминировал стереотип: «Если проект буксует, а задач становится слишком много — нужно срочно нанимать людей». Размер штата часто путают с надежностью бизнеса. Кажется, чем больше разработчиков сидит на созвонах, тем компания стабильнее и сильнее.

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

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

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

Ловушка коротких спринтов и закон Брукса

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

Мы ввели жесткое правило: оценивать производительность только на длинных участках — от 3 до 6 месяцев. Когда мы положили на стол графики выработки за два последовательных полугодия, мы обнаружили скрытую проблему: команда росла численно, бюджет раздувался, но общая скорость развития продукта оставалась на месте. Большая команда просто буксовала.

В ИТ-менеджменте есть знаменитый закон Брукса: если в проект, который не укладывается в сроки, добавить людей, он задержится еще сильнее.

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

«Эффект наблюдателя» и ловушка контроля

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

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

Для слабого менеджера это повод для гордости («вот я пришел и всех построил!»). Для нас это стало жестким сигналом о системном провале. Если производительность команды критически зависит от того, смотрит на нее руководство в данный момент или нет, значит, здоровый контроль подменен микроменеджментом. В большой толпе разработчикам легко спрятаться друг за друга. Включается социальная леность: человек подсознательно надеется, что его пассивность размоется на фоне общего шума. Сильные инженеры при этом видит, что их сверхусилия тонут в общем болоте, теряют мотивацию и уходят.

Финансовая меритократия и автономия смыслов

Оптимизация штата не была карательной операцией. Это была пересборка системы ради людей, которые хотят и умеют работать. Мы поделили команду на малые автономные группы по 5–6 человек.

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

Когда этот смысл появляется, процессы перестают быть священной коровой. Команда выстраивает и пересобирает их на лету просто потому, что преследует главную цель — выкатить крутой, работающий продукт. Задачи «для галочки» в таск-трекере умирают сами собой.

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

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

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

Что это дает конечному клиенту?

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

Малая автономная группа, ведомая общими смыслом и подпитанная финансовой меритократией, выдает принципиально другое качество работы:

• Гибкая подстройка процессов под бизнес-задачи.

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

• Высокая личная ответственность каждого инженера.

  В команде из 5–6 человек невозможно сдать плохой код и сказать «это не я». Каждый отвечает за результат своим именем, репутацией перед коллегами и своим доходом.

• Максимальная скорость реакции без лишних менеджеров.

  Нет цепочки из пяти менеджеров. Бизнес-задача от клиента практически напрямую попадает к инженеру, который понимает её смысл и сразу внедряет в код. Клиент платит не за пустые часы на обсуждения, а за реальные действия.

Заключение: Меньше — значит больше

Оптимизация штата — это не про экономию денег. Это про возвращение людям субъектности, ответственности и смыслов.

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