Оборачиваемость бэклога :)

🎓 Обратился давний клиент с запросом: 

- Как бы нам срок оборачиваемости бэклога посчитать?

- Что, говорю посчитать? Оборачиваемость?! Это в каком это смысле?

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

- А зачем это надо? - спрашиваю

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

🤔 И тут я задумался...

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

👈 А с другой стороны, клиент-то уже обученный, метриками свой рабочий процесс давно обложил, и считает все что может считать. И узкие места своего процесса он тоже знает.

Вполне может получиться интересный дашборд для бизнеса

Вопрос на засыпку

❓Относительно чего эту оборачиваемость бэклога расчитывать? 

🧠 Здравый смысл нам говорит - относительно пропускной способности процесса. 

Хорошо. А процесс у вас устоявшийся? Стабильный? Если да - то все прекрасно, потому что значение пропускной способности будет более-менее постоянным значением в этом случае. Можно поделить размер бэклога на пропускную способность - вот вам и срок оборачиваемости бэклога. 

🤘 Круто да? 

Да, но так бывает в редких случаях. 

Потому что жизнь штука непредсказуемая. Все время как-нибудь гадость случается, то разработчик заболел, то СВО санкции, то срочный контракт на 100500 миллиардов. Расчитывать на постоянство пропускной способности - очень наивно. 

🤷‍♂ Как быть?

Давайте рассуждать логически. "Срок оборачиваемости бэклога" это по сути, суммарный Backlog Lead Time (BLT) всех задач в бэклоге на текущий момент.

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

Вот только как такое моделирование сделать?

Моделирование

Ответ на самом деле есть, но он не так прост в реализации, как хотелось бы.

❓Чем один сценарий реализации бэклога будет отличаться от другого? Разными событиями, которые могут влиять на скорость "съедания" этого бэклога. Скорость "съедания" бэклога - это пропускная способность нашей команды.

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

Шаг 1️⃣
Берем исторические данные о пропускной способности рабочего процесса за какой-то значительный период - 10, 15, 20 недель.

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

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

Собранные нами исторические данные о пропускной способности по неделям могут выглядеть вот так:

Шаг 2️⃣

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

Воспользуемся методом Монте-Карло для вероятностного моделирования времени за которое эти 1000 задач будут сделаны.

Метод Монте-Карло, это численный метод для изучения случайных процессов.

🎰🎲♠ Свое название метод получил в честь города Монте-Карло - района Монако, где находится много казино с рулеткой. Рулетка является самым известным генератором случайных чисел, поэтому этот метод назвали в честь места, где этих генераторов ну очень много :)

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

📈 Алгоритм моделирования выглядит следующим образом: представляем, что наш бэклог - это столбик, составленный из задач. И этот столбик, по частям каждую неделю съедает мистер Пакмэн. Каждую неделю у него разный аппетит и он съедает разное количество задач из этого столбика.

😋 Аппетит мистера Пакмана - это значение пропускной способности из нашей статистики. Каждую неделю мы будем брать случайное значение из статистики пропускной способности, и уменьшать наш столбик на это значение.

🍽 Когда мистер Пакман "доест" бэклог мы подсчитаем какое количество недель у него это заняло, и запишем это значение. Это будет наше первое значение Backlog Lead Time (BLT).

Чтобы построить частотную диаграмму BLT и найти вероятное значение нам нужно много раз провести такую симуляцию. Поэтому рекомендуемое количество симуляций по методу Монте-Карло равно 10 тысячам.

Для проведение моделирования можно воспользоваться аддоном для Excel, либо написать алгоритм на Python

А если вам будет интересно, я позже расскажу как можно облегчить себе задачу, используя ChatGPT для расчетов

Итог

Проведя 10 тысяч симуляций, мы получим ряд значения Backlog Lead Time (BLT), сможем нарисовать частотную диаграмму и определить вероятное значение Backlog Lead Time

В нашем случае для 1000 задач прогнозируемое время с вероятностью 90% составит 107 дней

P.S.

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

А дальше нам предстоит оптимизационная задача поиска и управления узким местом.

Но об этом - в следующий раз на канале "Данные в ДейSTвии"

Задать вопрос автору можно в личку