Как в REG.ru избавились от хаоса во входящих задачах с помощью Канбан-метода в Kaiten

• Проблема
  Ежемесячно в разработку поступает около 250 задач от от внутренних и внешних заказчиков. Все они свалены в кучу — нет понятных приоритетов, профильные команды разработки заняты разбором инцидентов и нет общих прозрачных подходов к их разбору.
• Задача
  Освободить профильные команды разработки от нагрузки, выработать общие стандарты обработки инцидентов и в первую очередь решать наиболее важные для бизнеса задачи. А также сократить время ожидания решения инцидентов конечными клиентами.
• Решение
  Наладили процесс фильтрации и приоритизации входящих задач, применили практики канбан-метода, ввели классы обслуживания, ввели WIP-лимиты, значительно сократили блокировки задач на входе, провели анализ дальнейших блокировок.
• Результат
  Сократили срок решения большинства инцидентов с 12 до 7 дней. Разгрузили команду разработки и стали выполнять действительно значимые для бизнеса задачи.
• Автор кейса
  Андрей Сидоренко, главный специалист по процессному управлению REG.ru, канбан-тренер и консультант в компании Neogenda

REG.ru — лидер на рынке доменных имен в России. Предоставляет более 3 300 000 доменов. Каждый второй домен в России регистрируется в REG.RU, общее количество клиентов насчитывает более 2.2 млн. В штате — более 700 человек.

REG.ru — одна из крупнейшиз IT-компаний на рынке доменных имен в России

REG.ru регистрирует доменные имена, предоставляет услуги хостинга и другие цифровые услуги. Каждый второй домен в России регистрируется в REG.RU.

В штате — более 700 человек. Это команды разработки, поддержки, HR-ов, бухгалтерии и т.д.

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

Есть и команды, которые последовательно взаимодействуют друг за другом в плане задач. Условно, бэкэнд что то разработал, передает во фронтенд, дальше — тестирование.

В общем присутствует весь набор взаимодействий: и последовательный, и параллельный, и самостоятельный, и поддерживающий.

Сейчас практически 100% сотрудников работает в Кайтен. Не только разработка, но и бухгалтерия, и HR, и остальные.

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

У нас в компании была проблема, типичная для большинства крупных IT-компаний: в разработку поступало большое количество запросов и они неконтролируемо распределялись по всей компании, с нечеткими правилам и непонятными сроками. От этого возникал хаос — было непонятно кто, как и когда должен реализовывать эти задачи.

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

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

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

Шаг 1. С нуля создали процесс обработки входящих задач, состоящий из двух разных флоу

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

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

Мы создавали такой процесс с нуля, раньше его вообще не существовало.

В Кайтене мы реализовали два флоу:

• Первый флоу отсортировывал задачи и доводил до конкретной разработки с нужным функционалом;
• Второй флоу — непосредственно команда разработки, которая должна стабильно и прогнозируемо эти задачи реализовывать.

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

Дальше есть четыре варианта того, что происходит с задачей:

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

Шаг 2. Создали флоу, который предотвращает ожидания, задержки и блокировки, еще до этапа вхождения во второй деливери флоу

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

Мы выделили определенные этапы, приоритеты, Definitions of Done — критерии готовности к взятию. И собрали такой флоу, в который просто грузили все поступающие задачи.

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

Поэтому мы дополнительно разделили этот флоу на 2 дорожки: «Срочно» и «Не срочно», чтобы было понятно, какие задачи из всего потока следует рассматривать в первую очередь. Мы сказали заказчикам: «Что считаете более срочным — кладите на определенную дорожку».

Казалось бы, простой инструмент и довольно субъективный, но путем эксперимента мы поняли, что он работает — сотрудники поддержки на уровне ощущений понимают, насколько задача срочная, и не засовывают туда все подряд.

На этом этапе важно размечать задачи и смотреть аналитику

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

Смотрели показатель «Пропускная способность» — сколько задач пришло в бэклог и сколько реально дошло до «Готово к разработке».

Оказалось, что около 80% задач отсеивалось по пути к «Готово к разработке»: либо отправлялось в другие команды, либо отменялось как ненужное.

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

Шаг 3. На втором флоу ввели канбан-систему из 4-х классов обслуживания

Второй флоу — это уже конкретный деливери.

• Сначала мы просто визуализировали в Кайтене обычный рабочий флоу, который соответствовал этапам — в работе, ревью, выкатка и т.д.
• Затем настроили входную колонку плана с лимитами и классы обслуживания — более высокий и более низкий. Классы зависели от характера проблемы. Если инцидент единичный, то у него более низкий приоритет, чем у проблемы, с которой сталкиваются 100% пользователей.

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

Шаг 4. Ограничили количество одновременно выполняемых задач по каждому классу обслуживания — ввели WIP-лимиты

На этом этапе мы мы настроили capacity allocation — распределение емкости при помощи WIP-лимитов. Причем не только в столбцах, но и по горизонтали.

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

В Кайтен можно снять данные по Control chart (контрольная диаграмма) и по Спектральной диаграмме и показать команде, где у тебя слабая предсказуемость. Если с субъективным мнением кто-то может поспорить, то, видя конкретные данные, команда легко соглашается на эксперименты.

Распределение емкости дало нам увеличение прогнозируемости, и мы на 5 дней сократили срок работы над задачами по 85% процентилю. Это произошло примерно за 2 месяца. При условии что у нас выпуск задач по 60-80 в месяц, это очень хороший результат.

Шаг 5. Ввели сбор информации о блокировках и их анализ

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

У нас было много задач, которые блокировались сразу на входе, потому что по ним не хватало какой-то информации.

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

Соответственно проблема была не в разработке, а в первом флоу. Мы обсудили это с менеджером первого флоу и нашли конкретные причины, почему так происходило.

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

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

Как проводить анализ блокировок задач в Кайтене

1. Нужно явное правило при котором ставится блокировка в Кайтене.
2. Блокировка в Кайтене ставится через кнопку «Заблокировать» и вписывается контекст блокировки. Контекст должен вписываться в понятном для всей команды виде. Не просто «ЖДЕМ», а конкретная причина. Это очень важно.
3. Дальше есть период времени через который нужно собрать данные по блокировкам. Например, раз в месяц. Это делается в «Отчете по блокировкам» в Кайтене.
4. Потом нужно посмотреть, какого типа были блокировки, в каком соотношении и на каком этапе возникали. Можно это сделать в экселе по тегам, например. После этого появляется понимание, почему задачи блокируются чаще всего. И уже можно придумать решение, что с этим делать.
5. После внесения изменений, самое важное — в следующий месяц  снова собрать данные конкретно по этому кластеру блокировок, и понять — работают ли изменения или нет.

Я очень рекомендую проводить такую работу. В Кайтене удобно собирать отчеты по блокировкам, это очень крутой инструмент для сокращения лид-тайма.

Результат: сократили срок решения входящих задач на 5 дней

Когда мы только создали команду и поработали первый квартал, мы посчитали, что у нас в среднем уходит 12 календарных дней на решения задач по 85% процентилю.

Что сделали:

• Фильтрацию задач на входе;
• WIP-лимиты по горизонталям доски;
• Анализ блокировки карточек и устранение выявленных проблем.

В итоге мы сократили время решения входящих задач до 7 календарных дней. И сегодня стабильно продолжаем держаться на уровне 6-7 дней.

Общие выводы: Время экономит не сам инструмент, а умение им пользоваться

С помощью внедрения канбан-метода и грамотного использования инструментов Kaiten нам удалось:

• избавиться от 40% «мусорных» задач, попадающих в разработку;
• на 100% сократить блокировки задач прямо на входе;
• сократить срок обработки входящих задач с 12 до 7 дней.

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

Кроме того, благодаря Kaiten, мы значительно сократили время на коммуникации — теперь не нужно постоянно задавать друг другу вопросы и узнавать, что вообще происходит с проектом. Нам видна вся система целиком. А автоматическая отчетность и графики значительно экономят время менеджерского состава.

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

Вот что еще очень важно отметить: Kaiten действительно экономит значительно много времени, но только если ты его настроишь, договоришься с командой и будешь использовать не только карточки и доски, а более расширенный функционал — WIP-лимиты, отчеты, метки, блокировки.