«Как мы запускали Kanban в МегаФоне и сократили время выполнения задач»

Руководитель направления по системам взаимодействия с клиентами в цифровых сервисах ПАО «МегаФон» Иван Бондарев рассказывает, как за полгода удалось перестроить бизнес-процессы в компании, к каким результатам это привело, почему это оказалось довольно жёсткой трансформацией.

Я работаю в МегаФоне уже 13 лет. В моём подчинении более 70 человек из нескольких отделов по всей стране, в основном это разработчики. Их задача — разрабатывать, улучшать и поддерживать IT-системы для взаимодействия компании с клиентами. Это такие системы, как IVR, чат-боты, автоматизированные рабочие места для операторов контактных центров, базы знаний. Основные наши заказчики — подразделения обслуживания, продаж, развития бизнеса, маркетинга, клиентского опыта в компаниях B2C-сектора.

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

Чтобы понимать, сколько времени уходит на общение разработчиков и заказчиков, я попросил сотрудников фиксировать свою активность в JIRA по трём категориям: «я работаю», «я устраняю аварию», «я на совещании». В результате оказалось, что 50% времени сотрудники проводили на встречах, необходимость участия в которых вызывала вопросы. Любой заказчик считал своим долгом связаться с разработчиком лично, чтобы расспросить о статусе задачи и лишний раз напомнить о её важности.

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

Отправной точкой стало изучение моделей и концепций управления. Выбор пал на Кanban, он подходил нам идеально:

• Не требовал длительной подготовки и серьёзных трансформаций в текущей работе отдела.
• Решал проблемы с усилением фокусировки исполнителей на задачах и расставлением приоритетов. В Kanban список работ ограничен. Поэтому нет ситуации, когда сотрудник открывает список из нескольких десятков пунктов и не знает, за какой браться. Теперь выбирать нужно из 2–3 наиболее важных задач. Становятся яснее приоритеты, и работа идёт быстрее. Команда ежедневно обсуждает первоочередные задачи по текущим процессам и разделяет их между собой.
• Не требовал менеджмента — из управленцев в системе Kanban присутствуют только менеджер бэклога и менеджер потока. Менеджер бэклога отвечает за приоритизацию задач, а менеджер потока следит за тем, чтобы задачи правильно шли по потоку, не было заторов и блокеров. В результате разработчики занимаются разработкой, а не сторонними вопросами. Задачи руководителя в kanban-системе — устранять ограничения, давать ресурсы, а не думать, как команде решить задачу. Мы не говорим сотруднику: «Здесь ты делаешь так, а здесь вот так». Сотрудник сам решает, сам ошибается, сам ищет пути решения.
• Улучшал результаты работы. Если раньше за каждую задачу отвечал один сотрудник, то сейчас подключается несколько человек. Занимаясь проектом совместно, члены команды не перетягивают одеяло на себя, а заинтересованы в общем успехе. Люди начали больше доверять и помогать друг другу, появилась командная работа, улучшился микроклимат в коллективе.

На начальном этапе нам помог Валерий Кансузян, директор по проектному управлению, методологии и управлению ресурсами МегаФона: он привлёк коллег из МегаАкадемии и внешних коучей по Kanban.

Совместно с коучами и Валерием были сформированы цели по сокращению lead time на 30%, после чего было дано добро на начало трансформации направления.

Полтора месяца коучи помогали выстраивать работу в системе Kanban и готовили тренеров МегаАкадемии.

Мы провели два запуска: один в Самаре, а другой в Москве. Запуск мы спланировали таким образом, чтобы на месте были все сотрудники и все они прошли двухдневное обучение. Команды прослушали базовый теоретический курс — коучи рассказывали командам о сути системы, проектировали карточки задач, проводили игру Get Kanban с демонстрацией ошибок.

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

Во время обучения мы клеили на доску текущие задачи. Когда наклеили, оказалось, что у каждого их свыше 20. Получилось полотно из нескольких сотен квадратиков — о какой фокусировке и приоритетах могла идти речь?

Работать с Kanban мы начали, внедрив систему в несколько отделов. Но оказалось, что так это не работает, и формировать команды нужно вокруг конкретного продукта или сервиса.

Для эксперимента с работой по Kanban мы выделили несколько продуктов, в числе их обслуживание интерфейсов. В интерфейсах работает оператор контактного центра, чтобы максимально детализированно предоставлять информацию клиенту. По сути, это автоматизированное рабочее место. Работу над интерфейсом вели несколько команд и подрядчики.

Мы сформировали команду Kanban из разработчиков. Но поняли, что необходимо подключить и заказчиков. Потому что айтишники без них не смогут полноценно работать над продуктом. Объединив их в одну команду, нам удалось сломать подход «заказчик — исполнитель». И мы получили бонус: бизнес стал не сторонним наблюдателем, а был вовлечён в процесс. Это сняло неконструктивные претензии и объединило усилия.

Первая сложность, с которой мы столкнулись, — подрядчики не хотели работать в этой методологии. Уговаривать их пришлось довольно долго. Тем не менее со временем из состава команды выпала часть сотрудников подрядчика, в основном менеджеры. В системе Kanban в них просто не было необходимости, так как команда становилась самоуправляемой. Избавление от proxy-менеджеров — это органический процесс для Kanban, поэтому к нему нужно быть готовым.

Сотрудники также сначала восприняли идею работать по Kanban негативно: из зоны комфорта выходить никто не хотел. Проблемы возникли:

• с теми, кто не умеет или не хочет работать в команде;
• с интровертами, которые не умеют презентовать свои решения и планы, — с ними работали отдельно, объясняли, зачем нужна новая система, как лучше спланировать свой день, как обсуждать план на митингах.

Новую систему приняли, и её ценность стала понятна. Благодаря митингам мы начали понимать, кто готов меняться, а кто нет. Тем не менее с некоторыми сотрудниками мы вынуждены были попрощаться: с 19–20 человек команда сократилась до 15. Но Kanban стал и фактором удержания людей. У нас сократился отток сотрудников. Остались те, кому комфортно работать в команде. Некоторые отказались от предложений с более высокой зарплатой — важна команда, в которой идёт работа сейчас.

У нашей команды есть особенность: бывают аварии, которые появляются рандомно, а устранять их надо ASAP. Для этого нужен высокий уровень исполнительности. Аварии плохо вписывались в систему работы по Kanban, поэтому мы выделили людей, которым было некомфортно работать в Kanban, но которые были талантливыми инженерами, в команду «Непрерывность». Их мы переключили на решение аварийных ситуаций. Это позволило не отвлекать основную команду от работы над бизнес-задачами. Команда «Непрерывность» занимается только авариями или операционными изменениями. А в случае серьёзных аварий, где требуется помощь других команд, коллеги передают задачи по устранению дефектов разработчикам, используя механизм Fast Track. Такое решение сняло с основной команды риски и боли устранения аварий, которые срывали сроки по бизнес-задачам.

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

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

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

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

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

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

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

• Сократилась длительность митингов и повысилась их эффективность. В системе Kanban нужно проводить ежедневные митинги, чтобы спланировать работу. Сначала они занимали по три часа. Через полтора месяца мы сумели сократить их длительность до 30 минут. Чтобы достичь таких результатов, на еженедельных ретроспективах вырабатывали правила — например, приходить на митинги с уже готовым планом работ на день. Договорились не выносить спорные моменты на митинг, а обсуждать их ежемесячно более узким составом — только с теми, кого они касаются.

• Изменился подход сотрудников к задачам. В сознании сотрудников произошла трансформация. Сейчас команды задаются вопросом: «А то, что я делаю, полезно?». Ребята понимают, что правильно, что неправильно, доказывают заказчику эффект после реализации, сами просчитывают его и разговаривают с бизнесом.

• Научились работать с ретроспективами. Ретроспектива — это 3–4 часа диалога команды без руководителя. Единственное, о чём просит руководитель, — прислать итог ретроспективы в чат. Здесь происходит обмен опытом и мнениями.

• Достигли успехов по lead time — сократили его на 50%. Этот результат объясним тем, что методология Kanban не предполагает работы над большим количеством задач одновременно, а требует выделить основные, расставить приоритеты. И тут работает закон Литтла: чем больше задач в работе, тем больше времени придётся потратить на каждую из них.

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

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

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