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

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

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

Чтобы получить более надежные показатели, вместо количества User Story, можно использовать Story points. Конечно для этого все стороны должны быть оценены.

Requirements Completeness

Категория: Must Have

Что показывает: Количество User story, которые были заблокированы из-за требований сразу после того, как их взяли в работу. Причина может быть в неполных, непонятных или недостаточных требованиях.

Когда собираю: в день Sprint Retrospective или во время Daily Scrum.

Как считаю: Целевой показатель – не более одной заблокированной таки образом User Story в спринте. Информацию получаю от команды или менеджера

BA Velocity

Категория: Must Have Что показывает: Количество User story, которые я передаю на ревью за неделю работы

Когда собираю: В конце каждой рабочей недели.

Как считаю: Для того чтобы выставить целевой показатель, я использовал исторические данные, а именно посчитал сколько User Story я описывал за предыдущие несколько спринтов. На это число я ориентируюсь.

Bug’s root cause

Категория: Should Have

Что показывае: Количество багов, так или иначе связанных с качеством требований. К примеру, когда разработчик и тестировщик поняли требования по-разному, или что-то было указано на дизайнах, но не в требованиях.

Когда собираю: Каждые два спринта.

Как считаю: Для того чтобы собирать данные для этой метрики нужна помощь QA команды и настроенный Bug Triage процесс. Моя цель держать количество подобных багов близко к нулю.

Approval Time

Категория: Should Have

Что показывает: Сколько итераций ревью проходит User Story перед тем, как получить статус “ready for dev”. Дополнительно я замеряю, сколько времени занимает проверка требований стейкхолдерами.

Когда собираю: Поскольку на моем проекте, ревью требований не являюсь блокером ни для меня, ни для команды, я проверяю это метрику выборочно, раз в два-три спринта.

Как считаю: Случайным образом выбираю несколько User Story, которые были описаны за предыдущую итерацию. В Jira смотрю, сколько времени задача находилась в статусе “requirements in review” и сколько раз статус менялся, возвращаясь в работу к бизнес-аналитику.

Таргетом для меня является прием требования стекхолдерами со второй попытки и нахождение в ревью не более 5 рабочих дней.

CR's Number

Категория: Could Have

Что показывает: Количество Change Requests (запросы на изменение). Эта метрика скорее качественная, чем количественная, потому что я считаю причину CR'ов важнее их количества. Хотя, количество я тоже учитываю.

Когда собираю: В конце каждого этапа (milestone), после приемочного тестирования со стороны клиента.

Как считаю: Трекаю Change Requests в Change Log и анализирую каждый из них. Обращаю внимание на CRы, которые связаны с непониманием или неполнотой требований. Конкретного таргета по этой метрике у меня нет.

Stakeholder Satisfaction

Категория: Could Have

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

Когда собираю: В конце каждого этапа (milestone).

Как считаю: Информацию я собираю с помощью краткого опросника, который рассылаю команде и клиенту. В опросник я добавляю только открытые вопросы типа “Хотели бы вы улучшить что-то в том, как описаны требования?”

Инструменты

Для управления метриками я использую два инструмента: Jira и Excel. Первая является основным источником информации, вторая – хранилищем. Когда нужно показать стейкхолдерам отчет по метрикам, я формирую графики в Excel и вставляю их в презентацию. В планах автоматизировать сбор информации из Jira и настроить дашборд для обновления данных.

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

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

Расписание тренингов от Art of Business Analysis Новости и статьи по бизнес-анализу - https://t.me/artofba