В цій статті я хочу поговорити про метрики які можуть застосовуватись для трекінгу ефективності роботи бізнес-аналітика на проєкті. Можливо мої приклади стануть комусь в пригоді та допоможуть зрозуміти які метрики потрібні вам. Я не буду описувати “бестпрактіс”, які бувають метрики та для чого вони потрібні. Замість цього, я поділюсь власним досвідом і метриками, які я збираю на своєму проєкті.
Трохи бекграунду: проєкт робимо ”з нуля”, скрам, команда близько 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 та налаштувати дашборд для візуалізації даних.
Наразі в мене нема окремого процесу для аналізу метритів. Фактично я аналізую їх кожного разу, коли збираю дані. Я одразу звертаю увагу якщо метрика є нижчою за очікувану і думаю, які коригувальні дії можна провести.
Вибір метрик, як часто їх збирати, де зберігати, автоматизувати чи ні, який таргет обирати – це цілком залежить від вашого проєкту і команди. Процес, який я описав зараз працює для мене і закриває потреби по моніторингу роботи бізнес-аналітика на проєкті. Можливо якісь ідеї будуть корисними і для вас.
Автор статті Іван Плетін
Оригінал статті знаходиться тут