«Когда это будет сделано?»: как статистика на основе данных таск-трекера помогает спрогнозировать сроки

- Когда работа будет завершена?
- Успевает ли команда к назначенному сроку?
- Какие сроки указывать в договоре?
Нет вопросов насущнее для исполнителей заказной работы. Ответить на них помогает статистика. Как именно, рассказываем в статье.

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

· даты начала и окончания работ;

· данные о количестве задач;

· промежутки времени, в которые задачи пребывали в различных статусах;

· типы задач (или любые другие способы атрибутирования задач по типу поставляемой ценности);

· информация о блокировках (если таковые есть в вашем таск-трекере).

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

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

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

Что мы видим на этой диаграмме?

· Точками обозначены задачи — их расположение зависит от даты закрытия (ось x) и времени цикла (времени, прошедшего с момента взятия задачи в работу до момента ее закрытия, — ось y), цветовое деление применено в соответствии с типами (справа есть легенда);

· Пунктирными линиями отображены перцентили — линии, делящие общий массив изучаемых задач на части в зависимости от их времени закрытия. На приведенным графике отображен 80-й перцентиль, для каждого типа свой — цвет пунктирной линии совпадает с цветом, присвоенным типу в легенде. Задачи — точки того же цвета, — расположенные ниже линии, составляют те 80% от общего числа задач, чей цикл не превышает отметку, по которой перцентиль проведен. Остальные 20% задач — расположенных выше линии перцентиля — имеют цикл, превышающий перцентильное значение. На них-то и стоит обратить внимание при анализе потока работ — их время цикла значительно превышает тот же показатель у прочих задач (такой задачей со сравнительно большим временем цикла является задача WFA-13280 на графике.)

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

Для наглядности разберем диаграмму с одним типом, например с WF. Bug.

Выбранный тип присваивается задачам, суть которых состоит в исправлении ошибок. В соответствии с диаграммой 80% ошибок исправляются в течение 42 дней. Таким образом, мы можем предположить, что и в дальнейшем цикл времени подобных задач не превысит этого срока. Но для большей уверенности необходимо также посмотреть на 95-й перцентиль.

В 95% случаев ошибки исправляются в течение 125 дней. Здесь мы наблюдаем очень сильный разброс времени цикла у разных задач. Это может говорить в том числе о проблемах процесса, например о неграмотном подходе к декомпозиции, сильном старении отдельных задач в статусах (когда задачи «застревают» в определенном статусе и не продвигаются дальше) или о значительном влиянии блокировок на производственный цикл. Диаграмма времени цикла может «подсветить» проблемы — причины же их возникновения индивидуальны в каждом случае: для их определения необходимо погружаться в процесс и анализировать его.

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

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

Визы в материале сформированы на основе прототипов аналитической системы WFlow Analytics.