Команда из Россельхозбанка выросла с 7 до 25 человек, и вместе с этим перестала работать привычная модель управления. История про рост команды звучит знакомо для любого тимлида, который однажды обнаружил: Scrum еще на месте, люди наняты, а контроля стало меньше, а не больше. Для русскоязычной IT-аудитории это важный сигнал: масштабирование ломает не только архитектуру продукта, но и архитектуру управления.
Об этом сообщает Habr / Карьера со ссылкой на менеджера ИТ-команды Россельхозбанка Аркадия Озерова, который описал, как менялась работа команды вокруг внутренней системы АКПР. Речь идет об автоматизированном конструкторе проектов решений, через который в банке готовят и согласуют проекты решений, а также оформляют кредитно-обеспечительную документацию по сделкам. За несколько лет проект прошел путь от небольшого MVP до одной из ключевых систем кредитного процесса. Но текст Озерова интересен не столько самим продуктом, сколько тем, как быстро управленческие практики маленькой команды начинают сбоить, когда людей становится в несколько раз больше.
На старте Scrum закрывал вполне земные задачи: синхронизацию, прозрачность, вовлечение новичков, управляемость при постоянно меняющихся требованиях. Для команды из семи человек этого хватало. Общий контекст держался в головах, договоренности принимались быстро, личные коммуникации заменяли половину формальных процессов. Затем продукт усложнился: пользователи получили больше инструментов для работы с текстом, документ стал сквозным артефактом по всему жизненному циклу процесса, несколько подразделений получили возможность работать над одним документом одновременно, а данные начали автоматически переходить между этапами. И вот здесь рост команды совпал с ростом цены ошибки: система уже не «песочница», а рабочий контур с реальной эксплуатационной нагрузкой.
Главная мысль, которую Озеров формулирует почти без менеджерской мишуры, проста: руководитель в такой момент больше не может тащить систему личным участием. Пока команда маленькая, менеджер ускоряет работу руками: подключается к сложным вопросам, держит весь контекст, стягивает людей в одну точку. Когда сотрудников уже 25, та же модель превращается в узкое место. Появляются не просто новые люди, а новые направления и специализации. Вместо одного тестировщика возникает группа из четырех человек со своим лидом. Общий контекст распадается на локальные зоны экспертизы, а старые схемы вроде «Саша посмотрит, потом вливай» внезапно оказываются не процессом, а бытовой привычкой, которая плохо переживает масштаб.
Из этого вырастают вполне практические проблемы. Одна из них всплыла на релизе, когда последние доработки влили за день до выкладки под обещание, что там «только исправления четырех дефектов». В результате из-за конфликтов слияния сломался один из этапов сквозного процесса. Вывод оказался неприятным, но полезным: дело не в том, что команда плохо работает, а в том, что решение о готовности релиза принимается слишком поздно. После этого в команде ввели code freeze за три дня до релиза, аналитики начали заранее готовить анализ влияния изменений, а разработчики — описывать это влияние даже для дефектов. По сути, проблема решилась не героизмом, а ограничением хаоса. Для многих команд это, вероятно, самая полезная часть всей истории: когда проект растет, спасают не дополнительные созвоны, а четкие точки остановки и заранее согласованные правила.
Второй показательный пример касается квартального планирования. Сложная функциональность, связанная с маршрутом согласования документов, в какой-то момент пересеклась в одном спринте и с квартальным планированием, и со сдачей нового функционала. Типичная реакция менеджера в таких случаях — договориться, ускориться, вручную подпереть самые тонкие места. Но здесь выяснилось, что команда просто смешала задачи с разным горизонтом планирования. После этого правило поменяли: квартальное планирование стали выносить на 1–1,5 месяца вперед, чтобы подготовка требований не конкурировала с текущей разработкой. Параллельно усилили аналитическое направление отдельным лидом. Это уже не косметическая правка процесса, а признание факта: рост команды требует промежуточных центров ответственности, иначе руководитель превращается в диспетчера аварийной службы.
Для рынка это не новая, но все еще недооцененная тема. В российском IT по-прежнему любят истории, где сильный лидер держит проект на личной энергии, а команда растет «по мере необходимости». Пока людей мало, такой подход даже выглядит эффективным. Проблема в том, что он почти не масштабируется. Чем больше разработчиков, аналитиков, тестировщиков и смежных ролей появляется в контуре, тем дороже становится зависимость от одного человека, который должен все помнить, все согласовывать и все вовремя подталкивать. В этом смысле текст Озерова полезен именно своей приземленностью: он не продает новую модную методологию, а показывает довольно банальную, но болезненную вещь. Договоренности между знакомыми людьми работают до тех пор, пока все участники живут в одном темпе и в одном контексте. После этого приходится строить систему.
Для разработчиков и тимлидов отсюда следует неприятный, но взрослый вывод. Зрелость команды измеряется не количеством стендапов и не тем, насколько красиво оформлен Jira-борд. Она видна в том, можно ли передать знания, развести полномочия, заранее определить критерии готовности и не устраивать каждый релиз как спецоперацию. Для бизнеса вывод еще проще: найм сам по себе не увеличивает пропускную способность линейно. Иногда он, наоборот, сначала добавляет организационный долг. Поэтому при расширении штата нужны не только новые люди, но и новые правила: лиды по направлениям, понятные зоны ответственности, отдельные контуры синхронизации и формализация там, где раньше хватало устной договоренности.
Самый интересный вопрос здесь даже не в Scrum и не в конкретном банковском проекте. Он в том, сколько российских IT-команд прямо сейчас находятся в точке, где старый стиль управления уже умер, а новый еще не собран. Переход от «руководитель знает все» к «система работает без ручного дожима» обычно воспринимается как потеря контроля. На деле это, похоже, единственный способ пережить рост команды без бесконечных авралов, срывов релизов и зависимости от нескольких незаменимых людей.