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

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

Дано: производственная компания, внутри которой функционируют шесть департаментов, у каждого есть свой директор. Для эффективного управления деятельностью каждого департамента существует аналитический отдел, который готовит разнообразные отчеты: управленческие, финансовые и прочие-прочие-прочие бизнес-отчеты. Каждый отчет это уникальный продукт, для которого дата-инженеру нужно собрать данные из разных источников (Битрикс, 1С, финансовые системы отчётности и т.д.), правильно их агрегировать, а бэкенд- и фронтенд-разработчики должны их вывести в нужном для заказчика виде, и организовать регулярную доставку электронных версий отчетов заказчику. Заказчику важно буквально все — от компоновки данных до количества цифр после запятой. Так что создание отчёта — это работа, требующая аккуратности, точности и кропотливости.

Все 6 директоров направляют свои запросы в этот нерезиновый аналитический отдел с определенным числом специалистов. Конечно, эти отчеты играют важную роль в принятии решений и каждый департамент считает, что именно его отчет самый важный и значимый :)

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

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

1. Определяем Lead Time

Мы начали с разбора статистики, связанной с работой этого аналитического отдела. Нам повезло, потому что команда уже пользовалась трекером задач и доской, что позволило собрать данные для анализа. В начале мы с менеджером отдела определили точку взятия обязательств и точку отдачи обязательств. Время между этими двумя точками — Lead Time — самая главная метрика рабочего процесса, которая нужна нам для анализа. Это время, которое ждёт заказчик — от момента, когда ему сказали: «Будем делать эту задачу», до момента, когда он эту задачу получил в готовом виде.

2. Вычисляем Cycle Time

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

Что же мы в итоге получили?

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

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

Почему это происходит? Мы провели анализ с командой, и выяснилось, что самые длительные временные интервалы оказались результатом совпадения сразу нескольких неблагоприятных обстоятельств. Такие ситуации, как уход заказчика, болезнь ключевого разработчика, неопытность нового сотрудника или сбой сервера. Однако подобные случаи не являются нормой, скорее, это аномалии, а не закономерности и по ним нельзя судить о долгосрочной эффективности работы этого подразделения. Такие аномалии можно отсекать, главное проанализировать причины их возникновения и не допускать сочетания множества этих факторов вместе.

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

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

Например, в компании был тип работы «Правка рассылок». Под рассылкой мы понимаем ежедневную отправку отчета директору, но иногда возникают сбои, когда эти рассылки не работают, падают, потому что что-то сломалось. Соответственно восстановление процесса отправки — это определенный workflow со своим распределением времени выполнения. Если же мы имеем дело с другим типом работ, например, созданием нового отчета, тогда перед нами совсем другой рабочий процесс, с другими этапами. Разумеется, в этом случае мы наблюдаем совершенно другое распределение времени для разных этапов работы.

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

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

Еще мы обратили внимание на разницу по времени между Lead time (время ожидания заказчика) и Cycle time (чистое время работы над задачей), а именно — Lead time имеет интервал от 8 до 24 дней, в то время как Cycle time составляет всего от 4 до 7 дней. Это говорит о том, что чистое время работы над задачей почти в 2-3 раза меньше, чем время, которое ждёт заказчик.

И если мы начнем погружаться в эти детали дальше, то поймем, что где-то скрыто время ожидания. На изображении ниже видно, что до начала работ есть колонка «можно брать» и именно там задачи ждут, когда же освободится специалист аналитического отдела и приступит к работе над следующей задачей.

О чем это говорит? С точки зрения потока это означает, что заказчики пытаются впихнуть гораздо больший объем работы, чем тот, с которым аналитический отдел может фактически справиться. И это хороший аргумент для обсуждения с заказчиками и согласования РЕАЛЬНЫХ возможностей отдела и ожиданий от него.

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

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

Оказалось, что некоторые задачи могут просто лежать в колонке «можно брать» до 13 дней, ожидая, пока их возьмет в работу первый освободившийся специалист. Затем на этапе проверки и приемки, они также могут ждать до 7 дней, пока заказчик соизволит принять задачу.

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

Наиболее часто повторяющимися причинами задержек задач были:

— долгие согласования,

— отсутствие необходимой документации,

— ожидание заказчика на этапе приемки.

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

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

Собрав всю эту статистику вместе, мы получили возможность согласовать с заказчиками условия SLA (Service Level Agreement), то есть договоренности об уровне обслуживания — некоторых ожидаемых, нормативных значениях времени в течение которого задачи будут выполняться.

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

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

Но и это еще не финал нашей истории! Мы решили пойти дальше и проанализировать внутренние аспекты работы аналитического отдела, которые могут быть скрыты, не очевидны и поэтому не решены.

На доске была всего одна колонка «В работе», соответственно не было видно, что происходит внутри нее, как именно идет работа над задачами.

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

Однако в этом рабочем процессе есть повторяющиеся этапы, которые следовало бы проявить на рабочей на доске. Так мы сможем измерять не только общее время «в работе», но получить более детальное представление о том, на каком именно этапе работы над задачей происходят главные задержки и проблемы. Забегая вперед, могу сказать, что главной проблемой оказался этап «Подготовка источников», на котором ребятам надо было найти источники нужных данных и договориться с владельцами систем, где эти данные лежат, о доступах, выгрузках и вообще о получении нужных данных. Именно в этом взаимодействии со «смежниками» и заключались главные причины задержек.

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

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

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

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

Прежде всего:

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

2. Провели совместный (заказчики и ИТ) анализ этих данных и пришли к единому мнению о причинах проблем.

3. Договорились о SLA и дальнейшем плане изменений и начали его выполнять, отслеживая с помощью данных развитие ситуации.

В следующей статье поговорим о том, что нужно сделать, чтобы задачи выполнялись вовремя. Просто добавить больше людей или же есть вариант эффективнее? Stay tuned!

Автор: Василий Савунов, Agile-коуч и эксперт ScrumTrek