Метрики бизнес-аналитика на проекте
В этой статье я хочу поговорить о метриках, которые могут применяться для треккинга эффективности работы бизнес-аналитика на проекте. Возможно, мои примеры пригодятся кому-то и помогут понять какие метрики нужны вам. Я не буду описывать лучшие практики, какие бывают метрики, и для чего они нужны. Вместо этого, я поделюсь собственным опытом и метриками, которые я собираю на своем проекте.
Чуть-чуть бэкграунда: проект делаем ”с нуля”, скрам, команда около 20 человек, я один бизнес-аналитик. На момент написания статьи инициативе 4 месяца.
Как я выбирал метрики
Существует большое количество метрик, которые можно использовать для измерения производительности бизнес-аналитика. Когда я искал их для своего проекта, я изучал, что предлагает BA Office у меня в компании, что пишут в книгах и в интернете.
Я составил список метрик, которые мне показались интересными. Затем проанализировал наиболее подходящие для моего случая и приоритизировал их по технике MoSCoW.
После приоритизации у меня получилось 4 категории.
Must Have – метрики которые нужно трекать постоянно. То есть каждого спринта или каждую неделю. По возможности следует автоматизировать их сбор.
Should Have – регулярный сбор, но с большим интервалом – каждые два спринта. Автоматизировать не обязательно.
Could Have – регулярный сбор, с большим интервалом – примерно 5-6 спринтов.
Won't Have – все остальное. Метрики, которые я не использую, но не исключаю, что начну использовать в будущем.
Метрики, с которыми я работаю
Далее расскажу более подробно о каждой метрике.
Backlog horizon
Категория: Must Have Что показывает: Насколько хорошо проработан беклог "наперед". Что, в свою очередь, помогает избежать ситуации, когда команда будет заблокирована, потому что требования не готовы к имплементации.
Когда собираю: В день Backlog Refinement сессии. Сейчас, в бэклоге должны быть User Story со статусом “ready for dev” в количестве, достаточном примерно на полтора спринта работы.
Как считаю: Сравниваю количество User Story со статусом “ready for dev” с количеством User Story, закрытых за предыдущий спринт.
К примеру:
Количество "Ready for dev" User story = 27
Средняя производительность команды = 15
Backlog horizon, % = (27/15)*100 = 180
Целевой показатель ≥ 150
То есть, бэклог проработан на 180% при необходимых 150%. Это означает, что у команды есть работы почти на два спринта, если производительность не изменится.