Как PM-у настроить дашборды по своим проектам?

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

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

Чтобы аналитика оказалась действительно полезной, она должна выполнять следующие условия:

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

Теперь расскажем про возможности TFS в этом отношении.

Сначала о дашбордах по умолчанию

Мы спросили наших PM-ов, какие данные из базового набора они используют в своих панелях, и получили следующий список:

Lead Time. Показывает время прохождения одной задачи через весь процесс – от создания до закрытия.
Cycle Time. Показывает время, которое задача находится в разработке с того момента, как ей начали заниматься, до конечной поставки.
Качество поставок. Это количество багов, которые были заведены и прошли проработку в рамках спринта. При нажатии на график можно посмотреть, что это за баги, фильтр позволяет их сортировать (например, можно ввести «спринт 64» и получить всё, что к нему относится).

Эти показатели дают примерное представление о том, как обстоят дела в команде. Как это часто бывает с базовыми фичами, весь потенциал аналитики они не раскрывают. Например, Lead Time – вроде бы полезный показатель, который показывает, сколько задача висит в бэклоге. Но вот если ваши разработчики, как и мы сами, заводят задачи на несколько спринтов вперёд, ценность этих цифр оказывается небольшой. Можно поставить себе цель – приблизить Lead Time к длительности спринта. Но получается, что вы подстраиваете свои процессы под дополнительный инструмент – зачем это делать, если всё и так работает? Поэтому команды в итоге и отказываются от дашбордов, которые оказываются пятым колесом в прекрасно едущей повозке.

С другой стороны, в TFS можно настроить дополнительные панели, чтобы получать аналитику именно в том ключе, который нужен PM-у.

Какие дополнительные дашборды используем мы

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

Так что у каждого PM-а будет свой набор дашбордов, которые нужны именно ему. Для общего представления о том, с какими данными можно так работать, вот несколько примеров из нашего опыта:

Незавершённые задачи по текущему спринту. Помогает быстро понять, на чём сосредоточить усилия, чтобы всё успеть.
Задачи, не прошедшие ревью. Сюда попадают работы, которые могут попасть проблемную категорию из-за того, что команда слишком поздно или некорректно оценит нужные ресурсы.
Незакрытые задачи на PROD. Это уже переданные заказчику задачи, которые по какой-то причине остаются висеть в списке. Для PM-а это повод связаться с клиентом и узнать, нет ли с этими тасками каких-то проблем.
Задачи – кандидаты на релиз. Эти данные помогают PM-ам строить планы, понимать, когда каждая задача поступит в релиз. Эта же метрика позволяет проверить полноту релиза - если сборки отличается по составу от дашборда, нужно искать сбой.
Высокая оценка в спринте - задачи с трудозатратами более 40 человекочасов, к которым явно требуются особое внимание.
Новые задачи в активном спринте - помогает бороться с появлением несогласованных работ поду спринта.

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

Какой мы почувствовали эффект от проектной аналитики

PM-у не нужно совершать лишние движения, чтобы получить представление о положении дел по спринту. Менеджеры получили удобный доступ к данным, за которыми раньше приходилось идти в разные системы.
Если назревают трудности, специальный алёрт заранее о них предупредит. Появляется тревожный сигнал – можно его сразу отработать, пока он не вырос в реальную проблему.
Повысилось качество управления – стали дробить PBI на более мелкие таски, ускорили выдачу релизов. Здесь, кстати, помог дашборд Cycle Time из базового набора, так что вовсе отказываться от них не стоит.
Не только PM, но и другие участники команды пользуются аналитикой – все говорят на одном языке и знают, какие показатели играют важную роль для релиза. Эти технологии можно легко масштабировать дальше, чтобы вся компания работала по единым успешным практикам.