Ты больше не управляешь людьми: почему это происходит и что с этим делать

Привет, Хабр! Меня зовут Аркадий Озеров, менеджер в ИТ-команде Россельхозбанка, и я продолжаю делится историей роста своей команды. Мы выросли с 7 до 25 человек, а я продолжал управлять так же, как раньше. И это превратилось в проблему. Как не утонуть в хаосе при росте команды в 4 раза?

Пять лет назад я впервые рассказал о команде, создавшей веб-приложение автоматизации кредитного процесса – Автоматизированный конструктор проектов решений (АКПР). АКПР — это внутренняя система Россельхозбанка, в которой происходит подготовка и согласование проектов решений и создание кредитно-обеспечительной документации по кредитным сделкам. За несколько лет проект вырос из небольшого MVP в одну из ключевых систем кредитного процесса банка. Scrum помог решить вполне прикладные проблемы: синхронизацию команды, прозрачность работы, вовлечение новичков и управляемость постоянно меняющихся требований. Для небольшой команды из 7 человек это работало: многие процессы держались на личных коммуникациях, общем контексте и быстром принятии решений.

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

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

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

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

В жизни хорошего проекта может случиться бурный рост, когда аппетиты бизнеса растут быстрее пропускной способности команды. И вот тогда это происходит: момент, когда просматриваешь резюме сотнями, на интервью знакомишься с десятками интересных людей, с кем-то из них строишь светлое будущее (привет, команда!). Не секрет, что в этот момент важно быть в центре найма. Попытка делегировать и заняться "делами поважнее" обернется потраченными временем и деньгами.

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

1. Больше людей: в команде появились специализации не по людям, а по направлениям: теперь вместо одного тестировщика команда из четырёх со своим лидом. Это удивляет, ведь мы продукт запустили всемером, а теперь одних только тестировщиков пятеро!
2. Специализации создают зависимости, а общий контекст разделяется на детализированные задачи внутри каждой группы.
3. Процессы, державшиеся на личном доверии и общем контексте, начали ломаться. "Саша посмотрит, потом вливай" оказалось не процессом, а временной договоренностью.
4. Функционал усложняется с каждым релизом.
5. Система перестала быть песочницей: количество активных пользователей растёт ежедневно, а вместе с ними возрастают цена ошибок и эксплуатационная нагрузка. Теперь нужно думать не только о разработке, но и о стабильности.
6. Руководитель из лидера превращается в пожарного, который всё еще пытается удержать весь контекст, но должен успеть на всех флангах.

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

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

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

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

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

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

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

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

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

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

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

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

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

Что изменилось

Надеюсь, что мои рекомендации о том, как при росте команды систематизировать работу, будут полезны. Делитесь своим опытом в комментариях!