Найти в Дзене

Как банк «Дабрабыт» внедрил таск-трекер Kaiten и выстроил процесс управления задачами

В начале 2023 года подразделения ОАО «Банк Дабрабыт», занимающиеся внедрением и сопровождением изменений, получили задачу — сократить очередь запросов на доработку. Для реализации этой цели был приглашён эксперт по продуктовому подходу Максим Якубович, партнёр компании Product Lab. В этом материале мы рассмотрим, как Максим применил методологию S.T.A.T.I.K. и платформу Kaiten для проектирования эффективной системы управления сервисом. Перед тем как внедрить Kanban-метод в работу команды разработки, Максим собрал максимально полную информацию о текущих процессах. Это позволило понять реальные проблемы и подготовить основу для дальнейших изменений. Следующим шагом стала типизация запросов. Для этого команда подняла статистику из старой IT-системы, где регистрировались все обращения. Анализ показал, что внедрение новых функций занимало от 40 до 180 дней — сроки были чрезмерно длительными. На встрече присутствовало 15 руководителей подразделений банка. Вместе с Максимом они обсудили подход
Оглавление

В начале 2023 года подразделения ОАО «Банк Дабрабыт», занимающиеся внедрением и сопровождением изменений, получили задачу — сократить очередь запросов на доработку. Для реализации этой цели был приглашён эксперт по продуктовому подходу Максим Якубович, партнёр компании Product Lab.

В этом материале мы рассмотрим, как Максим применил методологию S.T.A.T.I.K. и платформу Kaiten для проектирования эффективной системы управления сервисом.

Внедрение Kanban через S.T.A.T.I.K

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

Что нужно было сделать

  • Провести встречу с представителями заказчиков.
  • Выявить и зафиксировать все недовольства относительно текущей системы и процессов.
  • После встречи структурировать и типизировать поступающие запросы.
  • Проанализировать время выполнения различных типов задач (Lead Time).

Какие проблемы отметили заказчики

  • Долгое выполнение запросов из-за ожидания старта работ в бэклоге.
  • На этапе тестирования может выясниться, что доработка реализована не так, как ожидалось.
  • Отсутствие прозрачности статусов запросов.
  • Сложности согласования плановой стоимости, особенно с учётом того, что заказчики не технари.
  • Появление критичных багов, которые нужно оперативно устранять.
  • Опасения, что некоторые задачи могут никогда не быть завершены.
  • В бэклоге находились задачи с «просрочкой» до 900 дней.

Следующим шагом стала типизация запросов. Для этого команда подняла статистику из старой IT-системы, где регистрировались все обращения. Анализ показал, что внедрение новых функций занимало от 40 до 180 дней — сроки были чрезмерно длительными.

-2

На встрече присутствовало 15 руководителей подразделений банка. Вместе с Максимом они обсудили подход к приоритизации бэклога и дизайн доски, с которой предстояло работать по Kanban.

Как выбирали инструмент для Kanban

  • Изначально планировалось использовать Jira, однако система стала недоступна в России.
  • Начали искать альтернативы и остановили выбор на Kaiten.

Решение протестировать Kaiten приняли благодаря доступному двухнедельному пробному периоду. В ходе тестирования команда выполнила важные шаги по переходу на Kanban.

Что сделали сотрудники

  • Перенесли рабочую доску из Excel в Kaiten.
  • Определили WIP-лимиты для всех стадий процесса.
  • Согласовали базовые правила работы, визуализировали их и сохранили в разделе «Документы» внутри Kaiten.
Пример дизайна первой доски в Kaiten
Пример дизайна первой доски в Kaiten

После внедрения Kaiten: новые правила и WIP-лимиты

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

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

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

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

Например: если над задачами на определённой стадии одновременно работают три разработчика, то и WIP-лимит для этой стадии должен быть равен трём.

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

Пример правил
Пример правил

Какие метрики измеряли

При выстраивании процессов разработки в ОАО «Банк Дабрабыт» команда не стала использовать весь перечень рекомендуемых Kanban-метрик, сосредоточившись только на ключевых показателях:

  • время цикла (Cycle Time);
  • пропускная способность (Throughput);
  • SLA — количество дней, в течение которых в 80% случаев закрываются задачи определённого типа;
  • время нахождения задач в блокировке.
Накопительная диаграмма потока в Kaiten
Накопительная диаграмма потока в Kaiten

После накопления достаточного объёма данных стало понятно, какие SLA сможет поддерживать команда. Для анализа процессов сотрудники использовали встроенные отчёты в Kaiten.

Спектральная диаграмма в Kaiten
Спектральная диаграмма в Kaiten

Диаграммы показали, что на раннем этапе процесс был непредсказуемым: одни запросы выполнялись за 2 дня, другие — за 62. Низкая плотность распределения указывала на необходимость улучшений.

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

Отчет о пропускной способности команды
Отчет о пропускной способности команды

Дополнительно проводили совещания, на которых разбирали причины долгих блокировок и обсуждали способы предотвратить такие ситуации. Какие встречи проводились:

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

Через три месяца работы бэклог заказчиков оказался полностью пустым. Таким образом, внедрение Kanban-метода и подхода S.T.A.T.I.K. продемонстрировало высокую эффективность и быстрый результат.

Что можно сделать уже сейчас, чтобы разобрать бэклог и внедрить Kanban

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

  • Определить текущий процесс. Проанализируйте, как сейчас выполняются задачи, какие этапы проходят и где возникают задержки.
  • Создать доску. Настройте простую Kanban-доску в Kaiten с ключевыми этапами: «Очередь», «В работе», «Готово».
  • Установить WIP-лимиты. Ограничьте количество задач, которые команда может одновременно выполнять, чтобы избежать перегрузки.
  • Использовать аналитику. Отслеживайте узкие места в процессе, анализируйте данные и постепенно улучшайте рабочий поток.

Применяя метод S.T.A.T.I.K. и возможности платформы Kaiten, вы сможете сделать управление задачами проще, процессы — прозрачнее, а работу команды — более организованной. Начните с малого уже сегодня, чтобы увидеть позитивные изменения в ближайшее время.