Какие метрики избавят PM-ов от неприятных сюрпризов по ходу спринта

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

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

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

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

Разумеется, все показатели еще и нужно автоматически собирать. Но это у нас обеспечено по умолчанию – мы работаем в трекере TFS (Azure DevOps), так что вся информация по задачам и проектам всегда под рукой, а штатные средства помогают создавать дашборды для любых задач.

Какие метрики нужно отслеживать

В итоге у нас получилось восемь базовых показателей, которые легко умещаются на экран TFS – сверху «светофор» для быстрой оценки, снизу более подробная информация по каждому показателю:

Какие метрики вошли в панель:

Без декомпозиции в спринте. Показывает, какое количество PBI не разбито на задачи (таски). А это значит, что по PBI в спринте не зафиксирована загрузка на команду. Без этого у команды нет как такового плана реализации, а у PM-а – понимания, каков объем работы на данный спринт.

Понятно, что иногда «цельные» PBI имеют право на жизнь (например, дизайн может быть непросто распределить на отдельные задачи). Поэтому PM волен установить те пороговые значения, которые считает нужным. Плюс ко всему, мы автоматически отсеиваем PBI со статусами Done, Ready for Estimate, Ready for Release, Blocked, задачи в аналитике – предполагается, что такие темы не требуют немедленного внимания.
Задачи без Description. Описание важно отслеживать, чтобы в будущем разработчикам и прочим заинтересованным лицам было проще понять, о чем речь в данной PBI. Кроме того, в неописанные задачи часто попадают темы, которые в экстренном режиме прилетают от заказчика – их тоже важно не пропустить.
Задачи без Activity. Этот показатель служит корректному учету ресурсов по итогам спринта. PM-у важно понимать, сколько времени ушло на аналитику, дизайн, разработку, тестирование и прочие активности. Как следствие, корректно указанная Activity используется для анализа второго порядка: загрузки команды, динамики исполнения и «узких мест» в планах реализации.
Задачи без Area. Этот показатель ранжирует задачи по функциональным блокам продукта, а на некоторых проектах – по платформе (мобильная, веб-фронтенд, бэкенд). Также используется, чтобы контролировать оперативную загрузку и динамику разработки в командах, отслеживать, на какие функциональные блоки прикладываются наибольшие усилия (в количестве задач в работе и запланированным/затраченным часам).
Забытые в New. Cюда попадают задачи и баги, у которых есть описание и нет статуса Blocked. То есть их пора брать в аналитику или разработку, но по каким-то причинам этого еще не произошло. Иногда TFS сам «забывает» переключить статус и оставляет PBI в «новых», но проверить все равно стоит.
Не назначенные. Здесь все очевидно – у каждой задачи должен быть ответственный «хозяин».
Таски без оценки. Таска – это работа, а каждой работе нужно время. Наличие задач без времени повышает риск, что либо на них не хватит ресурсов, либо придётся выбрасывать из спринта другие работы.
Задачи больше 8 часов. Такие таски могут говорить либо о некорректной декомпозиции, либо о некорректной оценке ресурсов у кого-то из команды. Либо задача действительно большая и неделимая, но тогда она встает в зону риска и требует постоянного наблюдения за прогрессом.

Главная ценность этой панели в том, что она сразу привлекает внимание к ключевым моментам, которые в перспективе могут серьезно повлиять на проект. Пропустили экстренную задачу от заказчика, неправильно распределили ресурсы, перегрузили спринт темами – получили головную боль через пару недель. А так можно раз в пару дней быстро оценить ситуацию, кликнуть на красные квадраты, сразу зайти в PBI и устранить трудности или оставить комментарий ответственному.

А если чуть докрутить механику, то можно отслеживать и более высокоуровневые показатели – например, Time-To-Market (скорость создания фичи от идеи до выпуска на рынок), недогруз/перегруз команды в моменте, соответствие приоритетов бизнеса нагрузке на команду и т.д.

Как подсчитывать Time-To-Market по метрикам TFS

По умолчанию, в TFS довольно малоинформативная аналитика по затраченному на задачи времени. Трекер выдает всего два показателя:

Lead Time – время от создания PBI до ее перехода в завершенное состояние.
Cycle Time – время от начала работ по PBI до ее перехода в завершенное состояние.

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

Поэтому для контроля Time-to-Market мы используем OLAP-куб, которому «скармливаем» данные из TFS. Получаем таблицу, где видны все закрытые PBI и период, который они провели в каждом статусе. Так выглядят исходные данные из куба (здесь все закрытые за спринт задачи и время их нахождения в каждом статусе):

PM видит, сколько времени занимает аналитика, а сколько – разработка, может посчитать медиану (или 85-й процентиль), чтобы узнать, на каком шаге задачи проводят больше всего времени. Распределение времени можно дальше предметно обсуждать с командой. Становится понятно, откуда берутся большие сроки Lead Time – например, когда своего часа дожидаются старые задачи из бэклога. Их легко отделить от крупных фич, которые проводят много времени в разработке. И можно делать выводы – где команда действовала неоптимально, и что можно улучшить в процессе.

Что имеем в итоге

В результате PM может отслеживать динамику, смотреть, в каком направлении двигаются цифры от спринта к спринту. Ему становится проще держать под контролем команду, а продукт-оунер может давать бизнес-заказчику реалистичные прогнозы по выпуску фич.

А самое главное, команда избавляется от всех проблем, которые могут вырасти из одного небольшого риска. Еще Сунь-цзы говорил, что лучший бой – это тот, который не состоялся. В продуктовой разработке это могло бы звучать так: «Лучшая проблема – это та, которую вы устранили за две недели до».