Парадокс сокращений: как мы урезали ИТ-штат в два раза, а производительность выросла в 2 раза

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

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

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

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

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

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

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

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

«Эффект наблюдателя» и паралич контроля

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

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

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

Иногда единственный способ победить этот паралич контроля — физически "ликвидировать" толпу.

«Зарплатный каннибализм» и автономия смыслов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда мы увидели эти цифры на длинной дистанции в 6 месяцев, мы сами не поверили своим глазам. Наш управленческий инсайт полностью противоречил большинству классических учебников по менеджменту. Стало понятно: дело не просто в «удачном стечении обстоятельств», мы нащупали какой-то фундаментальный закон человеческой природы. В следующей статье я расскажу, как книга Дэвида Гребера «Долг: первые 5000 лет истории» помогли нам частично рассмотреть этот феномен с точки зрения антропологии и человеческой ментальности, и почему в больших командах неизбежно заводится паразитическая «бредóвая работа».

Продолжение темы читайте во второй части цикла