Agile в телекоме. Почему команды МТС, Билайна и Мегафона работают спринтами, а релизят кварталами
В МТС, Билайне, Мегафоне и Ростелекоме agile внедрили несколько лет назад. Команды работают спринтами, скрам-мастера в штате, Jira отлажена. При этом релизы по-прежнему выходят раз в квартал, а иногда и реже. И если спросить, почему, ответ обычно звучит знакомо: «ну, у нас же инфраструктура, тут так быстро нельзя».
В этом объяснении есть правда. Биллинговые системы, сетевое оборудование, интеграции с регуляторами. Любое изменение потенциально затрагивает миллионы абонентов, и цена ошибки высока. Сложнее принять другое: что agile часто внедрялся поверх существующего релизного процесса, и двухнедельный спринт стал просто удобной единицей планирования, а не циклом доставки ценности. Код готов через две недели, а в прод попадает через два-три месяца.
Когда «done» в спринте и «done» для пользователя означают разные вещи
Продуктовая команда в одном из операторов разработала новую функцию для мобильного приложения. Работа заняла полтора спринта, три недели. Функция прошла ревью, тесты написаны, на демо показана стейкхолдерам. В Jira статус «Done».
Но функция требует изменения в API биллинговой системы. Биллинг обслуживает другая команда с собственным релизным циклом: раз в квартал, с двухнедельным регрессионным тестированием. Ближайшее релизное окно через два с половиной месяца.
Продуктовая команда отмечает задачу как выполненную и берётся за следующие фичи. Два месяца спустя функция наконец попадает в прод. К этому моменту конкурент уже запустил аналог. Через неделю обнаруживается баг в интеграции, но команда, которая писала код два месяца назад, с трудом вспоминает детали. Исправление, которое в момент разработки заняло бы пару часов, растягивается на три дня.
Эта ситуация знакома многим, кто работает в телекоме. И она прекрасно иллюстрирует разрыв, который agile-церемонии сами по себе устранить не в состоянии.
Зависимости между командами как настоящий bottleneck
В типичном телеком-проекте участвуют 5-10 команд одновременно. Каждая из них может быть продуктивной внутри своих спринтов. Но общая скорость определяется тем, как быстро результаты одной команды попадают к другой и проходят через общий пайплайн.
Scrum хорошо работает внутри одной команды. Для координации между командами он предлагает немного готовых решений. В результате каждая команда отчитывается о стабильной velocity, а совместный продукт выходит с задержкой в месяцы. На уровне руководства создаётся впечатление, что agile «не работает», хотя проблема лежит на другом уровне.
Что помогает в этой ситуации
Cycle time от постановки до пользователя. Ключевой момент: считать до момента, когда пользователь получил результат, а не до момента, когда задача стала «Done» в Jira. Когда эта метрика измеряется системно, разница между «сделали за 3 недели» и «пользователь увидел через 3 месяца» становится видимой и обсуждаемой.
Kanban вместо Scrum для команд с длинным релизным циклом. Если команда не может доставить результат каждый спринт, двухнедельный ритм Scrum создаёт скорее иллюзию цикла обратной связи. Kanban с WIP limits и визуализацией очередей честнее отражает происходящее и помогает находить узкие места в потоке между командами.
Постепенное сокращение релизного цикла. От квартала к месяцу, от месяца к двум неделям. Каждый шаг сокращает время между написанием кода и получением обратной связи, и каждый шаг снижает потерю контекста. Это реалистичная траектория, которую многие телеком-компании уже проходят.
Где развивать навыки
Менеджерам проектов и delivery-менеджерам в телекоме полезна программа Agile Project Management. Метрики потока, управление зависимостями между командами, прогнозирование в условиях множества ограничений. Сертификат ICP-APM от ICAgile подтверждает эти компетенции.
Скрам-мастерам и agile-коучам программа Advanced Scrum Master & Agile Coach даёт инструменты фасилитации для сложных организаций. Как проводить ретроспективу, когда проблемы выходят за пределы одной команды. Как адаптировать agile-подходы к среде, где есть регуляторика и тяжёлая инфраструктура.