top of page

Метрики бизнес-аналитика на проекте

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

Чуть-чуть бэкграунда: проект делаем ”с нуля”, скрам, команда около 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%. Это означает, что у команды есть работы почти на два спринта, если производительность не изменится.