ТехноТекст 2020
Agile начинается со здравого смысла. В этой системе ценностей главное — вовлечь людей в сотрудничество и диалог. Мой рассказ о том, что изменения в компании должны запускаться не только по директиве сверху, но и при деятельном интересе всей команды.
Привет, меня зовут Наталья, я agile-коуч в МегаФоне и участвую в цифровой трансформации бизнеса. Я присоединилась к этому процессу одной из первых, поэтому могу отследить изменения с самого начала. Мы не «внедряем agile», а используем его как один из инструментов масштабного преобразования компании, и этот процесс сейчас в самом разгаре. О том, почему мы трансформируем бизнес, и как это отражается на нашей разработке, читайте под катом.
Я пришла в МегаФон полтора года назад как менеджер потока (канбан). До того у меня была своя небольшая компания, мы занимались разработкой и внедрением ПО на базе 1С. В какой-то момент я поняла, что мне нравится не разрабатывать и внедрять, а работать с людьми, причём в аспекте их бизнес-задач. К своему уже тогда высшему образованию информатика-экономиста я получила дополнительную специализацию по бизнес-психологии, и чуть позже стала оказывать услуги бизнес-консалтинга и поддержки малых проектов/стартапов, параллельно преподавая в университете.
Мой случай, когда вначале рождается майндсет, а после подтягиваются подходящие инструменты, которыми пользуешься. Как выяснилось, agile я практиковала давно, просто не пыталась подобрать термин для описания подхода.
“
В системе agile-ценностей люди и взаимодействие важнее процессов и инструментов, а мне это всегда было близко. В контексте бизнеса это также означает, что взаимодействие с заказчиком важнее, нежели подписанные контракты и договорённости.
На момент моего прихода в МегаФоне сформировались так называемые функциональные колодцы, когда разные подразделения, которые решают одну задачу, находятся слишком далеко друг от друга. Ни одно нововведение нельзя было опробовать быстро, поскольку разработчики, тестировщики и поддержка клиентов находились в разных структурах. Как Змей Горыныч: одна голова что-то придумала, а остальные не могут это реализовать.
“
Упрощение пути к клиенту стало основной причиной, почему в МегаФоне задумались о трансформации.
Однако было и множество смежных проблем, но все они так или иначе были связаны с плохой коммуникацией между командами, потерей информации на пути сверху вниз и обратно.
С чего начать трансформацию
Мы всегда начинаем трансформацию бизнеса из какой-то нулевой точки. При этом вводные у компаний разные.
“
Опыт показывает: гибкий подход отлично взлетает при условии, что процессы в компании хорошо описаны, у неё есть инновационный продукт и подходящий контекст.
Именно такие компании потом рассказывают, как agile помог им ускориться на 300 %.
При этом, разумеется, agile — не волшебная пилюля. Я поняла это, когда попыталась применить его в строительстве, и это не сработало. Оказалось, что в run-деятельности, где нужно методично работать в настроенном процессе, новые ритуалы и инструменты принесут больше хаоса, чем пользы. Но этот опыт нельзя назвать неудачным: попробовав, я сделала выводы и стала строить процессы по-другому, находя и потихоньку убирая «узкие» места, чтобы повысить производительность.
Еще перед стартом трансформации в МегаФоне было понятно, что большую часть процессов в компании точно можно усилить, используя гибкий подход. Именно поэтому и был запущен эксперимент.
Нельзя просто разогнать команды, собрать их в новые структуры и сказать, что теперь мы будем работать иначе.
“
В МегаФоне мы начали с того, что запустили фронтраннер — сборную, которая собралась вокруг реализации основных продуктов для B2C-клиентов. Это был bottom up-запрос от ребят, которые реализовывали продукт и страдали от длительных коммуникаций, и top down-инициатива вокруг ключевого направления компании. Более того именно здесь контекст больше всего подходит под применение agile-практик.
На мой взгляд, человек может быть мотивирован только тогда, когда он действительно хочет делать то, что делает. Поэтому, несмотря на то, что над продуктом уже работали люди, мы провели опрос всей организации, чтобы выяснить, кто готов присоединиться к эксперименту. Откликнулось около 100 человек, из них 73 присоединились к сборной и дали потом хорошую обратную связь об этом опыте. Кстати, в новой команде оказались не все, кто работал над продуктом раньше. Несколько человек восприняли этот опрос как повод поговорить с руководителями о смене позиций в рамках своего личного курса развития.
Даже в сборной agile «полетел» не сразу. Поначалу мы видели сопротивление из-за привычки следовать выстроенным ранее процессам. К примеру, задачу нужно было согласовывать в Jira у пяти человек, но все эти люди перешли в сборную, и согласование как этап исчезло — теперь им достаточно было один раз встретиться и договориться. Поначалу это обескураживало: целые блоки привычных процессов стали ненужными.
“
Именно в этот момент и проявилась главная ценность agile: люди и взаимодействие важнее процессов и инструментов.
Как мы масштабировали подход
Наш эксперимент со сборной оказался успешным. Для оценки эффекта от agile можно использовать разные метрики. Мы опираемся на скорость выпуска в продакшн. Если раньше процесс продумывания, конфигурирования и тестирования новой идеи занимал восемь-девять рабочих дней, то теперь за счёт появления кросс-функциональных команд и отказа от многоступенчатых согласований мы то же самое делаем за три дня. Используются и другие метрики и бизнес-показатели, например, eNPS (индекс счастья сотрудника), OIBDA сборной, NPS клиента. Все эти показатели так или иначе выросли.
Сейчас мы расширяем периметр охвата. Сборная займётся и другими продуктами. При этом расширение мы начинали точно так же: запустили опрос на всю компанию, кто ещё хочет попробовать. Увеличивая периметр, мы планируем масштабировать сборную в два раза.
У нас есть автономная сборная с максимальным количеством ресурсов. Но мы находимся в корпорации, где процессов намного больше, чем людей. Нам всё ещё приходится решать вопросы, связанные с получением ресурсов за периметром сборной, и тут мы пытаемся договариваться о приоритизации или квотах.
“
Приходится стыковать процессы разработки в сборной с другими командами, находящимися за периметром, так как мы бежим быстрее, чем они. И это пока открытый вопрос.
Когда начинается трансформация, на уровне топ- и мидл-менеджмента принимается много управленческих решений о том, какую стратегию мы выбираем и на какие ценности будем опираться в ближайшее время. Но чтобы все начали понимать, что происходит, об этом должны говорить из каждого утюга. Это сильно упрощает взаимопонимание между людьми и сам процесс принятия agile. Поэтому мы ведём дела максимально открыто.
Фактически информирование — это половина успеха. Другая половина — поддержка топ-менеджмента. МегаФону с этим повезло: топ-менеджмент максимально вовлечён в процесс.
Трансформация для конкретных сотрудников и команд
Мы пошли по пути создания новых кросс-функциональных команд, где собрали людей из разных подразделений в зависимости от необходимых компетенций. Их ежедневная работа немного изменилась.
Каждый день начинается с дейли, когда команда собирается и синхронизируется: кто и что сделал вчера, как продвинулся, что мы планируем сделать сегодня, кто и чем может помочь. Так мы получаем все обновления по задачам.
В задачах появился порядок, нет такого пожара, как раньше. Сократилось количество «левых» задач. Ежедневный ритуал дейли призвал людей от IT говорить больше, хотя для них это стрессовый фактор. Бизнес, в свою очередь, больше слушает и не перетягивает на себя всё время, отведённое для выступлений.
Встречи стали продуктивнее, наметились понятные правила работы. Раньше ответственность лежала на одном человеке или подразделении, при этом задача упиралась в совершенно другие структурные единицы. Они могли тебя выслушать и не ответить, а правил, регулирующих это, не было. Теперь не надо лично отвечать за всех — есть распределение ответственности. Изменения в процессах облегчили нам жизнь с точки зрения организации выпуска продуктов.
Встречи стали продуктивнее, наметились понятные правила работы. Раньше ответственность лежала на одном человеке или подразделении, при этом задача упиралась в совершенно другие структурные единицы. Они могли тебя выслушать и не ответить, а правил, регулирующих это, не было. Теперь не надо лично отвечать за всех — есть распределение ответственности. Изменения в процессах облегчили нам жизнь с точки зрения организации выпуска продуктов.
Вера Диковская
команда «Развитие и удержание клиента. CVM-продукт»
Я приведу банальный пример. У нас есть два направления, у каждого из которых свой пул задач, своя приоритизация. Все идут по своим карточкам. Но в какой-то момент эти направления пересекаются в одной задаче — и появляется куча собраний, люди начинают обсуждать, как сделать общее дело в оговоренные сроки, хотя у каждого уже запланировано много всего. В итоге каждое направление теряет темп.
В новой парадигме работы мы все в сборной синхронизируемся — я уже знаю, например, что в октябре торговых представителей нельзя отправлять на поиск новой точки, а надо бросить все силы в другом направлении. Не нужно проводить кучу собраний, чтобы выяснить это. Вы понимаете, как поставить реалистичные сроки, и идёте с одной скоростью.
В новой парадигме работы мы все в сборной синхронизируемся — я уже знаю, например, что в октябре торговых представителей нельзя отправлять на поиск новой точки, а надо бросить все силы в другом направлении. Не нужно проводить кучу собраний, чтобы выяснить это. Вы понимаете, как поставить реалистичные сроки, и идёте с одной скоростью.
Сергей Пацынко
команда «Управление привлечением»
У ребят появилась ретроспектива, когда мы думаем о том, что необходимо улучшить. Мы проводим её каждые две недели по итогам спринта: ретро хорошо актуализирует фокус и делает наглядным тот факт, что каждый в команде является участником трансформации. Решения, которые сегодня принимаются на таких ретроспективах, уже завтра начнут помогать нам в работе.
Например, недавно у нас была ретро на 70+ человек, где выявлялись взаимозависимости, большие системные проблемы. Найденные инсайты помогают изменить к лучшему всю структуру сборной.
“
Через эти инсайты мы в том числе поняли необходимость расширить сборную, чтобы, с одной стороны, увеличить количество продуктов внутри, а с другой — нарастить объём экспертизы. Это поможет сделать нас ещё более кросс-функциональными.
Так мы сокращаем зависимости, о которых говорили ребята, чтобы лучше взаимодействовать с вендорами.
Вместе с ретроспективой появились обзоры спринта. Раз в две недели по итогам спринта мы рассказываем, какие готовые изменения получил клиент. Мы зовём всех, кому это может быть интересно, — не только топ-менеджмент, но и тех, кто является внутренним заказчиком изменений или может что-то посоветовать. И получаем развёрнутую обратную связь. Так мы синхронизируемся на уровне всей организации и празднуем маленькие успехи. Это помогает поддержать боевой дух команд.
Плотность взаимодействия IT и бизнеса существенно возросла.
До сборной я больше двух лет была в команде разработки Личного кабинета. Там, в разное время, мы работали и по строгому Waterfall и по Kanban. Раньше, чтобы сделать свою работу, нам нужно было дождаться пока коллеги из других подразделений доделают свою. Когда у одного подразделения свои процессы, а у другого подразделения совсем другие, на задачу уходит очень много времени. В сборной почти все нужные люди у тебя под рукой, вы работаете по единому процессу и знаете друг друга лично. Это упрощает общение и позволяет быстрее принимать решения.
Маргарита Нижельская
команда «Диджитал опыт»
Аналогичная история была в маркетинге. В старой схеме работы для того, чтобы твоя идея попала в реализацию, она должна была быть сверхкрутой и денежной, либо нужно было её долго пушить, доказывая, что реализация действительно нужна. Со стороны маркетинга всё выглядело так, будто во всём выстраиваются непонятные очереди и барьеры, поэтому я и попросился в сборную. Теперь же, если команда поддерживает идею, её можно сразу реализовывать. Мне эта идеология очень понравилась. Честно говоря, минусов я вообще не вижу. Со мной сидят все те люди, которые делают продукты, — к ним есть прямой доступ без приоритизаций. Сложно сказать, может быть разработчикам приходится больше работать, но для заказчика это практически идеальная схема.
Антон Дубин
команда «Дизайн продукта и CJ»
Со стороны разработки остались еще нерешенные вопросы. Например, нам нужно научиться приоритизировать техдолг, который появляется в результате работы над срочными задачами. Подобные темы мы обсуждаем на ретро команды и всей сборной.
Маргарита Нижельская
команда «Диджитал опыт»
Сотрудники, попавшие в сборную, довольны результатом. Им комфортно работать. По итогам эксперимента индекс счастья (eNPS) вырос на девять процентных пунктов.
Самым сложным было отпустить те проекты, которые ты делал, погрузиться в структуру agile, осознать, что у тебя нет зависимостей, в сборной ты можешь бежать еще быстрее. В переходные моменты помогали и продолжают помогать agile-коучи. Когда ты втягиваешься во всё это, понимаешь контекст — о чем говорят ребята, и почему мы должны жить по-новому — становится легче. Начинаешь привыкать. Без дейлика, без ребят, команды, задач и энергии, которой мы заряжаем себя каждое утро, я уже не представляю свою жизнь.
Сергей Пацынко
команда «Управление привлечением»
Почти каждому в команде нужно было учиться планировать свое время по-новому. Для нас новыми были не столько принципы agile, сколько обязательные процессы, принятые в сборной. Новые встречи, иногда непривычно длинные и в новом формате, и новые люди из других подразделений. Нас, конечно, «поштормило», но мы постепенно привыкаем к новому процессу.
Маргарита Нижельская
команда «Диджитал опыт»
Переходный период был непростым. Многие столкнулись со страхом неизвестного, ведь сборная — это как долгосрочная инвестиция. Ты не знаешь, придётся ли тебе через месяц быстро уходить, потому что поменяется что-то в организации, или это действительно длинная история. Для многих было челленджем отпустить контроль над своими старыми проектами или сроками. Но мы справились. Я заметила, что через два—три месяца многие расслабились — стало понятнее и комфортнее.
Мне кажется, гибкий подход, включая инструменты и практики, которые причисляют к agile, так или иначе развивает людей, помогает им стать лучше, прокачивает структурное мышление. Мы перестаём работать с продуктами и клиентами в формате менеджера (придумал — пошел реализовывать), начинаем отталкиваться от потребностей клиента и бизнеса. Учимся доверять команде и тем, с кем работаем плечом к плечу.
“
В целом за годы практики я поняла, что самая выигрышная тактика — не изобретать решения из воздуха, а спрашивать у людей, какие есть проблемы.
Конкретные люди, которые пишут код, тестируют его, прорабатывают маркетинг, лучше знают, что происходит в команде. И очень важно привлечь их в самом начале, сделав «соучастниками» процесса.
Встречаясь с противниками изменений, я исхожу из позиции, что намеренно люди таким процессам вредить не будут. Необходимо искать причину, и она всегда обнаруживается.
Например, при сборе команд каждый, кто попадает в сборную, уходит от своего линейного руководителя и у того возникает вопрос, как ему достигать тех же показателей с меньшим числом людей. Такие руководители часто сопротивляются нововведениям только потому, что постоянно перерабатывают. В этой ситуации достаточно выявить коренную причину проблемы и заново договориться о целях и показателях.
Какой будет трансформация завтра?
Трансформация компании не окончена. Чтобы двигаться дальше, мы развиваем в МегаФоне сообщество agile-коучей: нанимаем с рынка и тренируем специалистов внутри, разыскиваем на других позициях людей, разделяющих ценности гибкого подхода. Школа agile-коучей МегаФона скоро выпустит четвертый поток. Несколько человек, окончивших ее, сменили свою основную деятельность на коучинг — они работают с командами, продолжая обучение «в бою». Мы понимаем, что в первое время, прежде чем они узнают, как устроены процессы и как взаимодействовать с людьми, им ещё нужна поддержка, но поскольку это внутренние сотрудники, им уже не надо объяснять контекст и ценности компании. Так что они быстро втягиваются и начинают генерить свои идеи, даже связанные с переформированием команд.
Вместо заключения хочу сказать, что agile не высечен в камне. Мы постоянно меняемся. Если наступит момент, когда мы скажем: «Всё, теперь мы закончили», это будет означать, что мы умерли как большая команда. Процесс изменений — это непрекращающийся эксперимент.
Комментарии 65
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.