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

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

Итак, я хочу рассказать про интересную задачу, с которой столкнулся в компании Reg.Ru около двух лет назад и как ее решал.

Немного о компании:
REG.ru регистрирует доменные имена, предоставляет услуги хостинга и другие цифровые услуги. Каждый второй домен в России регистрируется в REG.RU, общее количество клиентов насчитывает более 2.2 млн.
В штате — более 700 человек. Это команды разработки, поддержки, HR-ов, бухгалтерии и т.д. Сейчас практически 100% сотрудников работает в таск-трекере Кайтен.

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

Назовем их “Инциденты”. Таких инцидентов поступало 200-350 в месяц и они неконтролируемо распределялись по всей компании, с нечеткими правилам и непонятными сроками. От этого возникал хаос — было непонятно кто, как и когда должен реализовывать эти задачи, нужно ли их вообще делать, постоянно возникали вопросы о том, почему простые запросы, которые можно исправить силами служб поддержки, передают разработчикам. Профильные продуктовые команды разработки испытывали расфокусировку из-за постоянно и неконтролируемо поступающей работы в их поток. В итоге, могло происходить такое, что решались мелкие и незначительные задачи вместо важных и стоящих для бизнеса.
Нам было важно организовать входящий поток задач и сделать его более предсказуемым для служб поддержки и клиентов, а так же разгрузить продуктовые команды от такого потока, чтобы они могли сфокусироваться на важных для бизнеса фичах.
Расскажу, как мы решали эти проблемы при помощи практик Канбан-метода и Кайтен.

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

Команда разработки, которая находится внутри этого сервиса, исправляет или осуществляет доработки и старается в первую очередь решить “боль” клиента, а во вторую предотвратить системное повторение ошибки.

В Кайтене мы реализовали две потоковых системы:

• Первая сортирует задачи и доводит до конкретной разработки с нужным функционалом - назовем её Upstream;
• Вторая исправляет инциденты так, чтобы, как можно скорее закрыть боль клиента, старается чинить системно повторяющиеся ошибки, должна быть стабильной и прогнозируемой - назовем её Delivery;

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

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

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

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

Инциденты начали скопом падать в одно место и копиться с огромной скоростью. Спустя буквально месяц на обзоре сервиса поставки (Service Delivery Review) мы получили обратную связь от служб поддержки, что некоторые инциденты являются более приоритетными, но, поскольку матрица приоритетов находится дальше по процессу, такие инциденты могут “зависать” в бэклоге, а мы добирались до них только в порядке очереди.

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

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

Вторая система должна была принимать подготовленные задачи из Upstream и обеспечивать предсказуемую и стабильную реализацию. Итак, как мы проектировали эту систему:

• Сначала мы просто визуализировали реальный рабочий процесс, по которому работали разработчики (с набором этапов: в работе, ревью, выкатка и т.д.)

• Определили и визуализировали классы обслуживания на основании матрицы приоритетов (Срочно, приоритетно, не приоритетно, рефакторинг).

• Затем настроили входной буфер в виде этапа “План” и договорились о том, что пополняем этот план ежедневно на дейли-митинге, а чтобы понимать объем пополнения, мы сразу же установили входной лимит, который был рассчитан на основании ежедневной пропускной способности. Таким образом, система пополнялась ежедневно, но задачи в плане не “протухали”

• Далее мы договорились об элементах визуализации (обязательные чек-листы, описания и т.д.), явных политиках взаимодействия друг с другом (например, как делаем ревью, как устанавливаем блокировки, что считаем блокировками, как тэгируем тикеты и т.д.) и соседними командами (зафиксировали все скриншоты договоренностей в Кайтен, что нам сильно помогало дальше в спорных ситуациях), какие мероприятия проводим

В итоге, у нас получилась Канбан-система под наше предназначение: “снижение негатива пользователей от багов и шероховатостей системы”. Под негативом мы понимали долгое ожидание клиента в решении блокирующих вопросов.

Отдельно стоит сказать про дорожку “Рефакторинг”. Рефакторинг не является классом обслуживания (Class of Service), а скорее его можно отнести к типу рабочего элоемента (Work Item Type). Однако мы решили его визуализировать отдельной дорожко. Дело в том, что в зоне компетенций данной команды такой работы не было, однако в процессе в разных местах Legacy находились места, которые имело смысл рефакторить. Таким образом, помаленьку накапливался бэклог с информации о таких местах. Такая работа не стоила внимания профильных команд разработки, однако облегчала жизнь в наиболее сбоящих частях системы. Поэтому, мы решили параллельно и маленьким ”ручейком” делать такую работу.

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

Теперь важно было систематизировать поток и смотреть аналитику по нему.

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

На основании аналитики мы выстроили дашборд важных для нас метрик, таких как пропускная способность в период (Throughput), показатели распределения времени производства (Lead Time) по типам работ и классам обслуживания, данные по количеству и времени блокировок системы. Для метрик мы определили целевые и пороговые значения, на которые стали ориентироваться, как на ключевые показатели нашего процесса, а так же транслировать заказчикам, как внутренний SLA (Service Level Agreement). Данные показатели мы отслеживали раз в две недели/месяц для понимания изменений динамики нашей системы и возможности принимать оперативные решения.

Например, анализ пропускной способности первого Upstream (уточнение и сортировка инцидентов), который мы смотрели с момента поступления инцидентов в бэклог” до момента, когда рабочие элементы (Work Item) Готовы к разработке показал интересную картину.

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

• примерно 26% отбрасывалось сразу из-за неактуальности, еще около 30% отбрасывалось по работе на Upstream
• около 13% инцидентов решались силами менеджеров и служб поддержки на Upstream
• около 16% инцидентов отправлялись на Delivery, как более приоритетные и около 12% инцидентов, как менее приоритетные.
• и небольшое количество распределялось по другим командам компании

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

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

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

Мы изначально понимали, что всё не сделать, но, если делать только приоритетное, мы не доберемся до менее приоритетного, поэтому и организовали классы обслуживания. А чтобы работа шла управляемо и не было перекосов, мы установили лимиты на незавершенную работы (WiP лимиты) на дорожки (классы обслуживания).

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

Лимит доски по горизонтали позволил наладить вытягивающую систему, которая сама подсказывала разработчикам, на какую дорожку можно вытягивать задачи в случае освобождения. Это избавило меня, как менеджера от ежедневных коммуникаций на тему “что взять в работу, “что следующее” и т.д.. Свободная емкость системы сама подсказывала, куда вытягивать следующий рабочий элемент ,в случае, если в плане пусто.

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

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

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

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

Мы внедрили простую договоренность о том, чтобы каждый день после дейли митинга (это около 10-15 минут) тратить несколько минут на то, чтобы просматривать самые близкие к плану рабочие элементы на предмет явных источников задержки. Если рабочие элементы вызывают подозрения, то это сигнал на Upstream о том, что нужно дополнительно доработать элемент к взятию в работу.

За счет решения данной проблемы, время производства по двум классам обслуживания сократилось примерно на 1 день.

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

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

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

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

Основные шаги и практики, которые мы применили:

- Гибкая фильтрация и сортировку задач на Upstream по понятным правилам;
- Capacity allocation и ограничение WiP в Delivery;
- Анализ блокировок и устранение выявленных проблем;
- Постоянные Service Delivery Review с применением информации ,полученной по его результатам;
- Постоянное взаимодействие менеджеров из Upstream и Delivery

С помощью применения инструментов канбан-метода и грамотного использования инструментов Kaiten нам удалось разгрузить профильные команды разработки, решить вопрос с непрозрачностью процесса для служб поддержки. За счет такого перераспределения удалось сэкономить на ФОТ значительную сумму ежемесячно.

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

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

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

Время экономит не сам инструмент, а умение им пользоваться.