Метрики — це не лише цифри, а спосіб зрозуміти поведінку команди.
Правильні показники допомагають розвиватися, а неправильні — демотивують, породжують ігри з числами та втрату сенсу.
Розгляньмо три популярні метрики з Agile / Scrum і типові управлінські помилки.
🎯 Focus Factor
Метрика прийшла зі Scrum.
Вона показує, наскільки команда точно оцінює свої задачі:
скільки часу повинно було піти — і скільки пішло фактично.
📈 Це індикатор концентрації команди на проекті.
💸 Чи можна платити за цим показником?
Теоретично — так. Але якщо менеджери не розуміють технічний контекст,
програмісти почнуть свідомо завищувати оцінки часу,
щоб мінімізувати ризики і виглядати “ефективно”.
Наслідок — розтягнуті дедлайни, зіпсовані відносини і нескінченні суперечки на планерках.
⚡ Velocity
Velocity (швидкість) показує, скільки роботи команда може взяти в наступний спринт,
виходячи з того, скільки зробила в попередньому.
Звучить просто, але тут криється пастка:
менеджери часто починають використовувати метрику для тиску —
“ви зробили 30 сторі-поінтів минулого тижня, тепер зробіть 35”.
❗ Але Velocity не є точним показником ефективності,
адже команда змінюється після кожного спринту:
з’являється досвід, нові обставини, нові знання.
Тому стара формула більше не працює.
Velocity — це барометр, а не батіг.
Вона потрібна для планування, а не для оцінки.
⏱ Cycle Time
Cycle Time — це час від ідеї до реалізації фічі.
Це ключова метрика ефективності процесів,
але нею не можна прямо вимірювати роботу розробників.
Якщо менеджер вирішує платити зарплату команді на основі Cycle Time,
це означає, що він просто знімає відповідальність із себе
і перекладає її на команду.
“Я роблю свою роботу добре, бо я професіонал.
Але якщо мене починають гнобити дурними метриками —
я почну оптимізувати дурні метрики.”
Це класичний приклад підміни внутрішньої мотивації зовнішньою:
людина перестає думати про якість і починає думати про цифри.
🧮 KPI і фінансові розрахунки
Кожен керівник має чесно відповісти собі:
чи готова організація до вимірюваної моделі KPI.
Можна рахувати середню вартість години роботи розробника,
множити її на кількість годин або на “вагу” проєктів.
Наприклад, складні завдання оцінюються в 10 балів,
простіші — у 7, 5 або 3.
Щоб зробити систему справді мотивуючою, варто враховувати:
- ⏰ Понаднормові години;
- 🤝 Допомогу в суміжних проектах;
- 💡 Впровадження нових ідей;
- 🎤 Майстер-класи, менторинг, внутрішні тренінги.
Тоді бонуси стають не лише матеріальним стимулом,
а й визнанням професійного внеску.
🧭 Висновок
Метрики — це не засіб покарання,
а інструмент усвідомленого управління.
Якщо використовувати їх без розуміння контексту —
вони зруйнують довіру, мотивацію і культуру.
“Міряйте не цифри — міряйте сенси.
Бо справжній фокус команди — не у звітах, а в результаті.”