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