Останнім часом на співбесідах люблю задавати питання по типу: як ви розумієте, що команда рухається ефективно і за графіком/бюджетом? І часта відповідь: Я питаю на дейліках як там просуваються таски, девелопери дають мені статус і я дивлюсь чи встигаємо ми до дедлайну, який очікує клієнт.
Це може бути не поганою відповіддю, але тільки для роботи в маленьких командах, де є три девелопера і всі сидять поруч. Коли у вас великий проект, то ходити і всіх опитувати, вручну зводити інформацію у себе в блокноті - дурна робота. Метрики стають інструментом, який дає змогу не лише бачити прогрес, а й запобігати проблемам ще до того, як вони стануть критичними.
Крім того, ми знаємо, що є різні підходи і методології у веденні проектів. І для кожної з них можуть бути свої метрики. Адже, вимірювати velocity для waterfall - повне безглуздя. Тому нижче хочу розповісти про найпопулярніші метрики, їх плюси і мінуси. Звичайно, це не “керівництво” якого потрібно жорстко дотримуватися. Варто пам’ятати, що кожен проєкт - унікальний, і вимірювання різних показників для різних проєктів є абсолютною нормою.
Для план-бейзд (waterfall) підходів зазвичай використовують метрики, які прив’язані до первинного плану і дозволяють відстежити, наскільки проєкт іде за графіком і бюджетом.
Earned Value (EV) - порівнює запланований обсяг роботи з фактично виконаним (спожитим).
Плюси:
дозволяє оцінити відповідність витрат і прогресу плану
дає змогу прогнозувати дату завершення
Мінуси:
складний у розрахунках
не всі стейкхолдери розуміють, як читати звіти EV
WBS Tasks Completed - показує відсоток завершених задач у структурі робіт (WBS).
Плюси:
проста і наочна метрика
добре підходить для стабільного, передбачуваного середовища
Мінуси:
не показує цінності для бізнесу
не враховує зміни чи перерозподіл пріоритетів
Number of Change Requests - кількість запитів на зміну початкового плану.
Плюси:
вказує на нестабільність або слабкість початкового планування
допомагає виявити scope creep
Мінуси:
не кожна зміна - це проблема
метрика не враховує якість чи вплив змін
У гнучких (agile) підходах метрики служать не для контролю плану, а для адаптації, прозорості та фокусування на цінності.
Velocity - обсяг роботи (story points), який команда стабільно виконує за ітерацію.
Плюси:
допомагає планувати спринти
проста для розуміння в команді
Мінуси:
легко маніпулювати оцінками
не можна порівнювати між командами
Defect Density - кількість дефектів відносно обсягу виконаної роботи (наприклад, на тисячу рядків коду).
Плюси:
прямо впливає на рівень задоволеності замовника
дозволяє відстежувати динаміку якості продукту
Мінуси:
трудомістко для точного підрахунку
без контексту не показує складності чи критичності дефектів
У планових проєктах головне - чіткість і контроль, в Agile - гнучкість і якість. Як ми бачимо, у кожної метрики є свої плюси і мінуси. Тому найкраще - це погодити з командою набір параметрів, які дозволять побачити цілу картину. Вони, в свою чергу, можуть бути прекрасними індикаторами у роботі з ризиками. Також, добре мати можливість автоматизувати метрики для складання звітів, це зекономить купу часу як менеджеру, так і потенційно зменшить кількість “організаційних” чи “сінк” мітингів з командою розробки. Кожен зможе спокійно займатись своїми задачами. Цікаво було б послухати, хто які метрики використовує в своїх проєктах.
