top of page

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

Оновлено: 15 трав. 2023 р.

В цій статті я хочу поговорити про метрики які можуть застосовуватись для трекінгу ефективності роботи бізнес-аналітика на проєкті. Можливо мої приклади стануть комусь в пригоді та допоможуть зрозуміти які метрики потрібні вам. Я не буду описувати найкращі практики, які бувають метрики та для чого вони потрібні. Замість цього, я поділюсь власним досвідом і метриками які я збираю на своєму проєкті.

Трохи бекграунду: проєкт робимо ”з нуля”, скрам, команда близько 20 людей, я один бізнес-аналітик. На момент написання статті ініціативі 4 місяці.


Як я обирав метрики

Існує велика кількість метрик які можна використовувати для виміру продуктивності бізнес-аналітика. Коли я шукав їх для свого проєкту, я вивчав що пропонує BA Office у мене в компанії, що пишуть в книжках і в інтернеті.

Я склав список метрик, які мені здалися цікавими. Потім проаналізував, які найбільш підходять для мого випадку і пріоритизував їх за технікою MoSCoW.

Після пріоритизації в мене вийшло 4 категорії.

Must Have - метрики яки потрібно трекати постійно. Тобто кожного спринта або кожного тижня. За можливості варто автоматизувати їх збір.

Should Have - регулярний збір, але з більшим інтервалом - кожні два спринти. Автоматизувати не обовʼязково.

Could Have - регулярний збір, з більшим інтервалом - приблизно 5-6 спринтів.

Won't Have - все інше. Метрики які я не використовую, але не виключаю, що почну використовувати в майбутньому.


Метрики з якими я працюю

Далі розкажу більш детально про кожну метрику.


Backlog horizon

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

Що показує: Наскільки добре пропрацьований беклог “на перед”. Що, своєю чергою, допомагає уникнути ситуації, коли команда буде заблокована, через те, що вимоги не готові до імплементації.

Коли збираю: В день Backlog Refinement сесії. На цей момент, в беклозі повинні бути юзер сторі зі статусом “ready for dev” в кількості, достатній приблизно на півтора спринту роботи.

Як рахую: Порівнюю кількість юзер сторі зі статусом “ready for dev” із кількістю сторей закритих за попередній спринт.

Наприклад:

Кількість "Ready for dev" юзер сторі = 27

Середня продуктивність команди = 15

Backlog horizon, % = (27/15)*100 = 180

Цільовий показник ≥ 150

Тобто, беклог пропрацьований на 180% при необхідних 150%. Це означає, що команда має роботи майже на два спринта, якщо продуктивність не зміниться.

Щоб отримати більш надійні показники, замість кількості юзер сторі, можна використовувати сторі поінти. Звичайно для цього, всі сторі мають бути оцінені.


Requirements Completeness

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

Що показує: Рахує кількість юзер сторі, які були заблоковані через вимоги одразу після того, як їх взяли в роботу. Причина може бути в неповних, незрозумілих, або недостатніх вимогах.

Коли збираю: В день Sprint Retrospective або під час Daily Scrum.

Як рахую: Цільовий показник - не більше однієї заблокованої таки чином юзер сторі в спринті. Інформацію я отримую від команди або менеджера.


BA Velocity

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

Що показує: Рахує кількість юзер сторі які я передаю на ревʼю за тиждень роботи. На поточному проєкті опис вимог є моєю основною задачею. Я використовую цю метрику для того, щоб тримати свою продуктивність на сталому рівні та відстежувати, коли вона знижується.

Коли збираю: В кінці кожного робочого тижня.

Як рахую: Для того, щоб виставити цільовий показник, я використав історичні дані, а саме порахував скільки сторей я описував за попередні кілька спринтів. На це число я орієнтуюсь.


Bug’s root cause

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

Що показує: Кількість багів, які були так чи інакше повʼязані з якістю вимог. Наприклад, коли розробник і тестувальник зрозуміли вимоги по-різному, або щось було вказано на дизайнах, але не у вимогах.

Коли збираю: Кожні два спринта.

Як рахую: Для того, щоб збирати дані для цієї метрики, потрібна допомога QA команди і налаштований Bug Triage процес. Моя мета тримати кількість подібних багів близькою до нуля.


Approval Time

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

Що показує: Скільки ітерацій ревью проходить юзер сторі перед тим як отримати статус “ready for dev”. Додатково, я заміряю скільки часу займає перевірка вимог стейкхолдерами.

Коли збираю: Оскільки на моєму проєкті, ревью вимог не є блокером, ні для мене, ні для команди, я перевіряю це метрику вибірково, раз на два-три спринти.

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

Таргетом для мене є приймання вимоги стекхолдерами з другої спроби, і знаходження в ревью не більше 5 робочих днів.


CR's Number

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

Що показує: Рахує кількість Change Requests. Ця метрика скоріше якісна, ніж кількісна, тому що я вважаю причину CRʼів, важливішою за їхню кількість. Хоча, кількість я теж враховую.

Коли збираю: В кінці кожного майлстоуну, після Acceptance Testing з боку клієнта.

Як рахую: Трекаю Change Requests в Change Log і аналізую кожен із них. Звертаю увагу на CRʼи, які повʼязані з нерозумінням або неповнотою вимог. Конкретного таргета по цій метриці я не маю.


Stakeholder Satisfaction

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

Що показує: Якісна метрика, яка показує наскільки стейкхолдери задоволені моєю роботою і комунікацією зі мною.

Коли збираю: В кінці кожного майлстоуну.

Як рахую: Інформацію я збираю за допомогою короткого опитувальника, який розсилаю команді та клієнту. В опитувальник я додаю тільки відкриті питання на кшталт “Чи хотіли б ви покращити щось в тому, як описані вимоги?”


Інструменти

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

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




Останні пости

Дивитися всі

5 Comments


дякую. Я поки що тільки на етапі навчання ВА, але мені було дуже цікаво ознайомитися з вашим підходом. Аналітик - він аналітик у всьому:)

Like

Oleksandr Katrusha
Oleksandr Katrusha
May 15, 2023

Дякую. А шо робите, якщо метрики не виконуються? Які управлінські дії?

І чому саме такі таргети обрані?

Like
Ivan Pletin
Ivan Pletin
May 16, 2023
Replying to

В мене немає однозначної відповіді по реагуванню на просідаючі метрики)) Я роблю root-cause аналіз, щоб розібратись чому показники просіли.

Наприклад, нещодавно BA Velocity суттєво зменшилось. Я подивився, що в період який я проаналізував, в мене збільшилась кількість мітингів і я став проводити демо (до цього його робили тестувальники), ще й свята були. Я не став блокером для команди, тому вирішив поки спостерігати. Якщо ситуація не поліпшиться, буду говорити з РМом. Щодо таргетів. Якщо у вас є приклад з попереднього або схожого проєкту, то можна для початку орієнтуватись на них. Якщо для вашого проєкту/команди ці таргети не зовсім підходять, то їх можна корегувати. Якщо, це ви перший раз налаштовуєте метрики, спробуйте подивитись на історичні дані. Наприклад, той самий BA Velocity -…

Like

дуже класно розписано і головне метрики які можна в реальному житті застосувати) дякую

Like

Yevhen Kliukin
Yevhen Kliukin
May 15, 2023

Чудова стаття, дякую!

Like
bottom of page