Как Agile помогает управлять десятками микросервисов на базе сети Wi-Fi в метро

МáксимаТелеком — компания, которая разворачивает Wi-Fi в московском и петербургском метро. В 2018 году компания внедрила Agile в пяти командах разработчиков при поддержке ScrumTrek.

О проекте рассказал Илья Волынкин, консультант по развитию бизнеса. Илья пришел в компанию, чтобы создать в сети Wi-Fi дополнительные ИТ-сервисы: решение для авторизации пользователей, систему персональных предложений для пассажиров и другие сервисы. Илья управлял группами разработки и развивал команды с ростом компании.

Какие задачи стоят перед МáксимаТелеком?

МáксимаТелеком создавалась как телеком-стартап, который решал проблему доступной связи в метро. Компания строила сеть для бесплатного Wi-Fi и для организации работы использовала традиционные подходы, принятые в телеком-индустрии. Управление строилось на основе проектной методологии.

Чтобы монетизировать сеть бесплатного Wi-Fi, мы решили предложить пассажирам дополнительные ИТ-сервисы. Таких решений на рынке еще не было, нужно было запустить разработку с нуля. Для этой задачи нам не удалось найти сторонних подрядчиков с компетенциями на стыке сети и разработки. Так что мы создали свою группу разработчиков внутри компании.

Как компания пришла к внедрению Agile?

В 2015 году компания стала быстро расти, и в 2016 году разработчики поддерживали уже десятки независимых ИТ-продуктов. Стек разработки расширялся: для разных сервисов мы выбирали разные языки программирования и базы данных. Команда разработки тоже выросла и поделилась на группы по компетенциям.

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

Это стало отправной точкой для поиска новых методов управления. Разработчики и бизнес-заказчики надеялись, что гибкие методологии решат проблемы роста бизнеса. Но внутри компании не было единого видения, как перейти на Agile. Тогда мы обратились в ScrumTrek за помощью и пригласили Сергея Баранова как agile-коуча.

Как построили процесс внедрения?

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

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

Менеджеры после обучения возглавили команды в роли процесс-мастеров. Запуск пяти основных команд прошел при участии Сергея Баранова и занял 3 месяца. Совместно с Сергеем мы обсуждали наиболее подходящие инструменты, пробовали разные механики. Начали с классического скрам-борда и бумажных карточек, внедрили стендап-митинги и ретроспективы.

На первом скрам-борде разместили карточки всех пяти команд

Почти сразу стало понятно, что активностей у команд много, и вести работу в бумажном виде не очень удобно. Мы перенесли процессы в Jira. Команда каждого продукта могла сама выбрать подходящие инструменты Agile. Например, кто-то придерживался канбана, кто-то делил разработку на спринты.

Для синхронизации команд на верхнем уровне мы выбрали два инструмента.

На продуктовом комитете мы обсуждали эпики всех команд — задачи верхнего уровня. Так менеджеры видели зависимости продуктов друг от друга и расставляли приоритеты в разработке.

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

Через 3 месяца в командах сформировались компетенции для самостоятельной работы в роли владельцев продукта.

Какие открытия произошли на этапе запуска?

У зрелых продуктов накапливалось много задач разного уровня, в том числе рутина: запросы клиентов, исправление багов. Для таких задач мы ввели дежурство на неделю. Дежурные на поддержку сменяли друг друга в командах из 5-6 человек, так что за неделю никто не уставал от однотипных задач. Благодаря этому разработчики лучше погрузились в разные части кода и были в курсе всего проекта.

Со временем мы также заметили, что работа команд отличается в зависимости от стадии жизненного цикла продукта. Мы распределили наши продукты по стадиям: проверка гипотезы, рост, повышение перформанса или вывод из эксплуатации. Для каждой стадии назначили свои KPI и дали рекомендации владельцам продуктов, как вести работу на этой стадии жизненного цикла.

Какие результаты получили после внедрения?

Одним из показателей успеха стало сокращение времени выхода на рынок в 2,5 раза. Когда мы рассказали о результатах проекта внутри компании, многие подразделения захотели повторить этот опыт. Для запуска новых продуктов и проектов появился понятный сценарий, и всем хотелось его использовать.

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