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

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

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

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

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

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

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

На начальном этапе нам помог Валерий Кансузян, директор по проектному управлению, методологии и управлению ресурсами МегаФона: он привлёк коллег из МегаАкадемии и внешних коучей по 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 действительно был жёстким. Сейчас мы начинаем развивать лидерство и принимать новые вызовы современного рынка, чтобы наш клиент был счастлив.