Трайб MTS Web Services вырос с двух до девяти команд, и вместе с масштабом пришел знакомый многим набор проблем: сорванные договоренности, потерянные зависимости и сроки, которые стабильно уезжали вправо. Внутри пришлось заново собирать квартальное планирование, причем в среде, где команды воспринимали новые процессы как лишнюю бюрократию. Для российских IT-команд это показательный кейс: когда продукт разрастается быстрее управленческой системы, одного набора митингов уже недостаточно.
О том, как эту схему перестраивали, сообщает Habr / Менеджмент в колонке скрам-мастера МТС Web Services Кристины. По ее словам, два года назад она пришла в трайб, который быстро масштабировался с двух до девяти продуктовых и сервисных команд. Процессы за ростом не успевали: коммуникации между командами сыпались, зависимости терялись, а конфликты приходилось разбирать на уровне C-level. Отдельной проблемой было то, что каждое новое квартальное планирование фактически начиналось с нуля, без устойчивой общей рамки.
В качестве базы команда взяла SAFe, который внутри компании уже использовался как рекомендованный подход для масштабирования планирования и релизов. Логика понятная: если соседние трайбы читают планы в одном формате, проще сверять ожидания, оценивать зрелость команд и не тратить лишнее время на расшифровку чужих таблиц и ритуалов. Но использовать SAFe в чистом виде, как признает автор, не получилось. Его адаптировали под реальное устройство трайба и дополнили моделью ADKAR, то есть не только меняли процедуру, но и пытались провести людей через понятную траекторию изменений: от осознания проблемы до закрепления новой привычки.
На бумаге такой конструктор выглядит аккуратно. На практике первый заход провалился. Квартальное планирование провели по готовой внутренней схеме, согласовали формат с руководством, собрали команды, заставили всех что-то заполнить и отработали мероприятие. Но для самих участников это выглядело как типичный процесс ради процесса: пришел новый человек, ввел непонятный ритуал, а что будет дальше и зачем это нужно, никто толком не объяснил. Команды остались вне контекста, поэтому после сессии все быстро откатилось в привычный режим. Главный вывод Кристины был довольно жестким, но полезным: внедрять процесс сверху вниз, не объяснив людям смысл и механику, бессмысленно. Если команда не понимает, как именно новый формат снимет ее текущую боль, она будет считать его бюрократией, даже если методология называется модно и дорого.
Сначала доверие, потом фреймворки
После этой неудачи акцент сместили с шаблонов и церемоний на людей. И это, пожалуй, самая практичная часть кейса. Девять команд означают девять разных динамик, девять наборов неформальных правил и девять вариантов реакции на любые перемены. Часть техлидов согласилась попробовать новый подход и стала пилотной площадкой. С ними считали capacity, отдельно выделяли техдолг, разбирали зависимости между командами и тестировали более прозрачный способ подготовки к кварталу. Именно эти команды затем стали внутренним доказательством того, что изменения не обязательно заканчиваются лишними отчетами и потерянным временем.
Были и более осторожные участники. Они не спорили открыто, но предпочитали смотреть со стороны и ссылаться на занятость. Здесь ставка делалась не на давление, а на наблюдение и индивидуальную работу. Скрам-мастер приходила на ретроспективы и другие командные ритуалы, если команда была не против, а затем обсуждала наблюдения с техлидом один на один. Для руководителей вели отдельный документ с зонами внимания по каждой команде: что именно мешает работать, где застревают коммуникации, какие проблемы никто не хочет выносить в открытую. В этом же контуре всплывали тихие конфликты, которые не горели в календаре, но стабильно замедляли работу сильнее любого формального блокера.
Самый тяжелый сценарий, как обычно, был не в явной конфронтации, а в вежливом саботаже. Автор описывает знакомую многим картину: разговор уводят в сторону, накидывают параллельные темы, процесс обсуждают бесконечно, но до изменений дело не доходит. На такой случай у нее было правило трех заходов. Если после трех итераций выстроить рабочий контакт не получалось, она возвращалась к заказчику изменений и прямо говорила, что дальше двигаться с конкретным техлидом не готова. Это важная деталь: в историях про трансформацию команд часто романтизируют идею, что договориться можно со всеми. На масштабе девяти команд это не всегда так. Иногда рациональнее не ломиться в закрытую дверь, а выстраивать рабочий контур там, где есть шанс получить результат.
Что в этом кейсе важно не только для МТС
Отдельно автор выделяет one-to-one как главный рабочий инструмент. Причем не в формате дежурного разговора о процессах, а как способ понять реальные запросы человека, его ограничения и страхи внутри команды. В материале есть показательный пример: один техлид переживал из-за слабого сотрудника, но не мог нормально проговорить этот вопрос с CTO, потому что ответ был бы слишком очевидным и слишком формальным. В приватном разговоре со скрам-мастером такой запрос можно было разобрать без защитной стойки, а потом перевести эмоции в решение. Для бизнеса здесь довольно прямой вывод: зрелость квартального планирования зависит не только от досок, артефактов и таблиц, но и от того, есть ли в системе человек, с которым можно обсуждать управленческие проблемы до того, как они начнут ломать delivery.
За год эта история пришла к результату, который звучит куда интереснее любой методологической терминологии. Квартальное планирование в трайбе выстроили на базе адаптированного SAFe, специалисты научились проводить его самостоятельно, зависимости между командами сократились до минимума, а руководители перестали тратить управленческое время на разборки в духе «кто за что отвечает». То есть эффект измерялся не красотой процесса, а тем, что C-level больше не приходилось работать диспетчером между командами. Для разработчиков и продактов это, возможно, самый понятный критерий качества организационных изменений: хороший процесс убирает ручное героическое управление, а не требует еще больше героизма.
На российском рынке, где многие продуктовые команды быстро растут внутри крупных экосистем, этот кейс хорошо подсвечивает неприятную, но устойчивую закономерность. Масштабирование почти всегда сначала ломает коммуникацию, потом сроки и только потом заставляет компанию вспоминать о системном планировании. Вопрос уже не в том, нужен ли крупным трайбам общий контур квартального планирования, а в том, кто и как будет продавать его командам. Если ответ снова сведется к «вот шаблон, заполняйте», через квартал все вернется в исходную точку. Если же компании начнут воспринимать такие изменения как управленческий продукт с пилотами, обратной связью и доработкой под реальную среду, у SAFe и любых его локальных адаптаций появится шанс быть не декорацией, а рабочим инструментом.