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