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

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

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

Мы всегда начинаем трансформацию бизнеса из какой-то нулевой точки. При этом вводные у компаний разные.

Именно такие компании потом рассказывают, как agile помог им ускориться на 300 %.

При этом, разумеется, agile — не волшебная пилюля. Я поняла это, когда попыталась применить его в строительстве, и это не сработало. Оказалось, что в run-деятельности, где нужно методично работать в настроенном процессе, новые ритуалы и инструменты принесут больше хаоса, чем пользы. Но этот опыт нельзя назвать неудачным: попробовав, я сделала выводы и стала строить процессы по-другому, находя и потихоньку убирая «узкие» места, чтобы повысить производительность.

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

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

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

Даже в сборной agile «полетел» не сразу. Поначалу мы видели сопротивление из-за привычки следовать выстроенным ранее процессам. К примеру, задачу нужно было согласовывать в Jira у пяти человек, но все эти люди перешли в сборную, и согласование как этап исчезло — теперь им достаточно было один раз встретиться и договориться. Поначалу это обескураживало: целые блоки привычных процессов стали ненужными.

Наш эксперимент со сборной оказался успешным. Для оценки эффекта от agile можно использовать разные метрики. Мы опираемся на скорость выпуска в продакшн. Если раньше процесс продумывания, конфигурирования и тестирования новой идеи занимал восемь-девять рабочих дней, то теперь за счёт появления кросс-функциональных команд и отказа от многоступенчатых согласований мы то же самое делаем за три дня. Используются и другие метрики и бизнес-показатели, например, eNPS (индекс счастья сотрудника), OIBDA сборной, NPS клиента. Все эти показатели так или иначе выросли.

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

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

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

Фактически информирование — это половина успеха. Другая половина — поддержка топ-менеджмента. МегаФону с этим повезло: топ-менеджмент максимально вовлечён в процесс.

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

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

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

Например, недавно у нас была ретро на 70+ человек, где выявлялись взаимозависимости, большие системные проблемы. Найденные инсайты помогают изменить к лучшему всю структуру сборной.

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

Вместе с ретроспективой появились обзоры спринта. Раз в две недели по итогам спринта мы рассказываем, какие готовые изменения получил клиент. Мы зовём всех, кому это может быть интересно, — не только топ-менеджмент, но и тех, кто является внутренним заказчиком изменений или может что-то посоветовать. И получаем развёрнутую обратную связь. Так мы синхронизируемся на уровне всей организации и празднуем маленькие успехи. Это помогает поддержать боевой дух команд.

Плотность взаимодействия IT и бизнеса существенно возросла.

Сотрудники, попавшие в сборную, довольны результатом. Им комфортно работать. По итогам эксперимента индекс счастья (eNPS) вырос на девять процентных пунктов.

Переходный период был непростым. Многие столкнулись со страхом неизвестного, ведь сборная — это как долгосрочная инвестиция. Ты не знаешь, придётся ли тебе через месяц быстро уходить, потому что поменяется что-то в организации, или это действительно длинная история. Для многих было челленджем отпустить контроль над своими старыми проектами или сроками. Но мы справились. Я заметила, что через два—три месяца многие расслабились — стало понятнее и комфортнее.

Мне кажется, гибкий подход, включая инструменты и практики, которые причисляют к agile, так или иначе развивает людей, помогает им стать лучше, прокачивает структурное мышление. Мы перестаём работать с продуктами и клиентами в формате менеджера (придумал — пошел реализовывать), начинаем отталкиваться от потребностей клиента и бизнеса. Учимся доверять команде и тем, с кем работаем плечом к плечу.

Конкретные люди, которые пишут код, тестируют его, прорабатывают маркетинг, лучше знают, что происходит в команде. И очень важно привлечь их в самом начале, сделав «соучастниками» процесса.

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

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

Трансформация компании не окончена. Чтобы двигаться дальше, мы развиваем в МегаФоне сообщество agile-коучей: нанимаем с рынка и тренируем специалистов внутри, разыскиваем на других позициях людей, разделяющих ценности гибкого подхода. Школа agile-коучей МегаФона скоро выпустит четвертый поток. Несколько человек, окончивших ее, сменили свою основную деятельность на коучинг — они работают с командами, продолжая обучение «в бою». Мы понимаем, что в первое время, прежде чем они узнают, как устроены процессы и как взаимодействовать с людьми, им ещё нужна поддержка, но поскольку это внутренние сотрудники, им уже не надо объяснять контекст и ценности компании. Так что они быстро втягиваются и начинают генерить свои идеи, даже связанные с переформированием команд.

Вместо заключения хочу сказать, что agile не высечен в камне. Мы постоянно меняемся. Если наступит момент, когда мы скажем: «Всё, теперь мы закончили», это будет означать, что мы умерли как большая команда. Процесс изменений — это непрекращающийся эксперимент.