Как в банке Дабрабыт внедрили Kaiten и через 3 месяца сделали пустым бэклог
История о том, как S.T.A.T.I.K, Kaiten и WIP-лимиты привели к пустому бэклог и устранили хаос в команде белорусского банка.
В ОАО «Банк Дабрабыт» внедряли улучшение — всем подразделениям, которые отвечали за перемены и управление ими, нужно было заметно уменьшить очередь из задач на доработку.
Чтобы справиться с этой задачей, они пригласили Максима Якубовича — партнера Product Lab, который разбирался в продуктовом подходе к решению задач. Рассказываем, как Максиму удалось это сделать с помощью Kaiten и метода S.T.A.T.I.K.
Анализ ситуации перед использованием Kanban
До начала всех работ по проекту и внедрения изменений, Максим собрал и изучил всю информацию о текущих в компании процессах.
Для этого он:
- Встретился с представителями заказчиков.
- Зафиксировал, чем они не довольны в действующей системе и работе.
- Распределил по типовым категориям все запросы, с которыми обычно встречается команда.
- Изучил и определил примерные промежутки времени, которые нужны на выполнение каждого из типов запросов — выяснил Lead time для каждого из них.
Все замечания к работе от заказчиков удалось собрать в небольшой список:
- каждый запрос долго выполняется, так как ждет, когда стартует его реализация в бэклоге;
- во время приемки работ может оказаться, что всю доработку выполнили не так, как ожидали, из-за чего в части случаев приходилось начинать сначала;
- заказчикам неизвестно, в каких статусах их запросы;
- плановую стоимость доработки для IT-команды тяжело согласовать — заказчики не технические специалисты и не знают реальных расценок, но надеются на аналитиков, которые могут упростить требования и снизить общие затраты;
- регулярно образуются критичные баги, которые нужно исправлять вне очереди;
- заказчики опасаются, что некоторые задачи вообще никогда не закончат;
- в бэклоге отдельные задачи «зависают» на 900 дней, что совершенно неприемлемо.
Все недовольства удалось типизировать и собрать в единый вид. Команда изучила статистику и стало понятно, что все обращения и заявки на новые функции регистрируются в неудобной и неподходящей IT-системе.
Но самое неприятное — стало понятно, что запрос на новую функцию может занимать от 40 до 180 суток.
На встречу с Максимом пришли 15 руководителей разных подразделений. Вместе они смогли обсудить, как команде нужно подходить к приоритизации и как задействовать Kanban-метод при работе с доской.
Нужно было определиться, с помощью какого ПО получится выстраивать работу по Kanban. Первым желанием было купить Jira, но компания ушла из России, поэтому стали изучать возможности дальше и остановились на Kaiten.
Сначала использовали тестовый период 14 дней, в рамках которого можно изучить все инструменты Kaiten и начать с ним работать.
За этот период у команды получилось:
- взять заполненную доску в Excel и перенести ее в Kaiten без потери информации;
- определить WIP-лимиты, которые необходимо соблюдать на каждой стадии;
- выяснить, какие правила работы нужно применить в первую очередь, зафиксировать их и сохранить в разделе «Документы».
Меняем правила с Kaiten и внедряем WIP-лимиты
3 месяца ушло на изучение системы и создание схемы работы с системой. Управляющие банком следили за правилами — удаляли неэффективные и добавляли новые. Постепенно поменяли пространства и заметно их упростили.
Как это было: изначально в работе использовали сложную доску, а команда проводила еженедельные митинги о том, как двигать задачи слева направо по потоку.
Во время таких совещаний стало понятно, что:
- Структуру нужно поменять так, чтобы все этапы оказались на доске;
- Часть стадий не имеют смысла и не нужны, а другие — наоборот нужно добавить;
- Некоторые задачи зависли в блокировке уже больше, чем на 15 дней.
В результате переработали и интегрировали:
- правила, по которым задача может вернуться в бэклог;
- дизайн карточек с указанием самых ценных данных на фасаде и кастомными полями внутри;
- распределение задач между сотрудниками команды.
Затем для каждой стадии процесса продумали размер WIP-лимита. Для этого изучили, сколько задач находится на доске в момент создания новой и сколько сотрудников нужно, чтобы решать задачи на каждом из этапов.
Приведем пример: над одной задачей работает сразу три разработчика. Это означает, что WIP-лимит тоже должен быть равен 3.
На встречах регулярно обсуждалось, устраивают ли команду лимиты — если было необходимо, то пересматривали и меняли по необходимости правила работы.
Метрики: какие и для чего решили измерять
Чтобы понять, насколько корректно выстраиваются процессы внутри ОАО «Банк Дабрабыт», замеряли некоторые метрики, например:
- время, которое требуется на выполнение цикла;
- SLA — сколько нужно времени, чтобы закрыть заявку определенного типа в 80% случаев;
- пропускную способность;
- какое время задача может находиться в блокировке.
Сначала Максим собрал статистику для анализа ситуации. Эти данные помогли увидеть, какой SLA можно использовать в команде. Чтобы проанализировать процессы, сотрудники тоже собирали отчетность:
Если изучить диаграмму, то становится понятно — пока процесс работает непредсказуемо, а на команду разработки это влияет негативно. Например, если бы это был понятный процесс, в котором легко отслеживаются будущие этапы, то плотность у столбцов была бы намного выше.
Диаграмма команды отразила, что для выполнения некоторых запросов требовалось 2 дня, а для других — 62 дня. Нужно было работать дальше. Чтобы оценить пропускную способность команды, собирали отчеты и анализировали объем выполненных задач.
Также с помощью Kaiten можно было проверить, сколько времени задача находится на каждом этапе и сколько — в заблокированном положении.
Максим сосредоточился не только на анализе разных графиков и отчетов, но также проводил собрания для обсуждения задач и их статусов. На таких встречах обсуждали, почему зависают задачи и как минимизировать количество подобных ситуаций.
Встречи проходили в разных форматах — от Канбан-митингов до собраний и совещаний по обзору рисков.
Результаты
Через три месяца после начала внедрения изменений бэклог заказчиков опустел — все задачи были выполнены. Грамотное использование S.T.A.T.I.K и методологии Канбан привели команду к результатам.
Что делать, если у вас тоже перегружен бэклог
Любая компания может оказаться в схожей ситуации, где не справляется с потоком задач и многие из них зависают в бэклоге месяцами. С чего начать перемены:
- Проанализировать текущие процессы. В первую очередь нужно разобраться, как ведется работа над карточками прямо сейчас.
- Создать пространство. Это может быть одна или несколько Kanban-досок в Kaiten, где обязательно есть базовые колонки для задач — «Ожидает», «Выполняется» и «Готово».
- Продумать WIP-лимиты. Важно изучить, сколько задач одновременно в работе выполнимо для команды и следить за тем, чтобы оно не превышало установленный лимит.
- Работать с аналитикой. Регулярно изучать, как изменилась эффективность команды, стало ли проще работать с задачами, как еще можно оптимизировать процессы.
Так с помощью Kaiten и S.T.A.T.I.K. можно значительно упростить управление проектом и повысить его эффективность, организовать действия команды и сделать их более прозрачными.
А как дела в вашей компании с бэклогом? Тоже накопилось много задач или вы уже оптимизировали работу с ним?