Мікроменеджмент чи data-driven: як реально побудувати процес оцінки перформансу dev-команди

Привіт, я Андрій — project manager в BUKI, і сьогодні я б хотів поділитися нашим досвідом побудови dev-команди та підходом до аналізу того, як перформить команда.

Ми перформимо чи ні?

Настали часи, коли high-performance командами називають не тих, хто генерує рулони рядків коду на одиницю часу, а тих хто «створює цінність». Це досягається через формування чітких та осяжних sprint goals або чогось у цьому дусі. І все це фокусується на тому, який outcome створює команда. У всякому випадку, якщо так офіційно не говорити — то можуть закенсилити. Але можна так говорити і одночасно ставити mouse трекери команді, і скажіть, що не бачили такого?

Отже в кінці 2024 року команда прийшла з чітким запитом: «Я, як член команди, хочу розуміти, де я та як можу зрозуміти, що я гарно роблю роботу». Це стало поштовхом для переосмислення процесу аналізу перформансу та пошуку рішення, яке створить нову, кращу систему координат, у якій кожен розробник буде відстежувати себе та знати, скільки грошей просити на перформанс-рев’ю)

Культурна прошивка, яка дає зростати

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

BUKI — це продуктова компанія, яка зосереджується на створенні якісного рішення світового рівня в сфері EdTech. Тому в команді культивується розвиток «продуктового мислення» та побудована якісна система зворотного зв’язку. Тобто будь-який член dev-команди завжди може запропонувати будь-яку ідею на спільних грумінг-сесіях з product-менеджерами — та буде почутий. Це не умовна «Банка з ідеями», які створюють для імітації — це реально частина процесу. Відсутність «робимо так, бо я так бачу» створює реальний вплив на кінцевий продукт та розуміння: «я розробник, і я впливаю на outcome».

«Бермудський» трикутник делівері

Робота над запитом почалася з усвідомлення та прийняття реальності. Ніхто не працює по 8 год на день. І якщо хтось ще досі живе в цій архаїчній моделі — то швидшої вам еволюції. У свою чергу ми провели відверту розмову з командою та визначили, що середньодобовий за спринт час, який dev може витрачати на роботу над тасками — це 5 год. Для прозорості додам, що час на регулярне «поговорити» закладається окремо, і у команди, на жаль, не 5 годинний робочий день(

Окремо варто відповісти на очевидне питання: як ми взагалі дізнаємось, скільки часу витратив розробник? Відповідь проста — через ворклоги в Jira. Кожен самостійно фіксує витрачений час на задачу. Так, це не хронометр з точністю до хвилини, і ми це розуміємо. Але нам і не потрібна хірургічна точність — ми аналізуємо тренди на дистанції кварталу, де одиничні похибки вирівнюються і не спотворюють загальну картину.

І ось у нас починає вимальовуватись перша вісь координат — це Utilization. Я, як менеджер, і розробник хочемо розуміти, навантаженість та який відсоток його доступного ресурсу використовується для виконання задач.

Коротко поясню, яка від цього користь. Менеджмент розуміє, який є ресурс та як він використовується. Розробник розуміє: він працює за двох чи за трьох)

Наступний показник було очевидно, де шукати. Оскільки dev-команда реалізує бізнес-цілі, то бізнес має розуміти, коли йому очікувати реліз своєї кілер-фічі. Щоб очікування та реальність були максимально близькими, комітменти команди мають бути реалістичними. А реалізм комітментів починається з оцінки. Тому з’явився такий показник, як Ratio.

Ratio — це відношення реальності до очікувань. Оцінили щось на 2 дні, а зробили за 4 — от і Ratio = 2. Ми добре розуміємо, що невизначеність та ризики чекають на всьому шляху від To Do до Done, тому Ratio = 1 — це таке часте явище, як повністю актуальна документація: всі про неї чули, але ніхто не бачив. Тому Ratio має нижню межу в 0.9 (для тих, хто в дзені) та верхню 1.1 (для тих, хто тільки думає його шукати).

Для фінальної, останньої координати потрібно було віддати розробникам ownership над частиною процесу delivery, щоб кожен усвідомлював, що він тут «ґазда». Так кристалізувався Dev rate — це життя задачі в спринті починаючи з To Do до Testing ready.

Отже, тепер система координат виглядає так:

Utilization — Навантаження члена команди — який % доступного ресурсу витрачається на задачі спринту. У більшості випадків розробник не впливає на нього напряму.

де Workload — сума оцінок усіх задач розробника у спринті; Capacity — доступний ресурс розробника за спринт

Норма: 90% — постійне навантаження 100% знижує продуктивність так само, як зношений акумулятор iPhone. Невеликий люфт на непередбачувані ситуації обов’язковий.

Ratio — Відношення реальності до очікувань — наскільки точно команда оцінює задачі.

де ΣSpent — сума фактично витраченого часу на задачі; ΣEstimate — сума початкових оцінок задач

Норма: 0.9 — 1.1.

Dev rate — % задач у зоні відповідальності розробника на момент закінчення спринту — від To Do до Testing Ready.

де Σ Estimate (In Dev) — сума оцінок задач, що не досягли статусу Testing Ready до кінця спринту; Σ Estimate — сума оцінок усіх задач розробника у спринті

Норма: чим нижче — тим краще 😅

Чесно кажучи, ці метрики не є нашим винаходом. Ratio — близький до estimation accuracy, Dev rate — різновид sprint predictability, Utilization — класичне capacity management. Ми свідомо обрали ці три, бо шукали мінімальний набір, який команда може утримати в голові й обговорювати без словника agile-термінів. Цінність — не в самих метриках окремо, а в тому, як вони читаються разом як єдиний трикутник.

Інтерпретація

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

Окремо ці показники створюють певний вакуум та не дають цілісного розуміння результату. Пазл починає складатися тільки тоді, коли аналізувати їх разом. І не менш важливе — це розуміння їхнього зв’язку один з одним. Разом вони створюють трикутник, де зміна одного показника так чи інакше буде впливати на інші.

(Трикутник метрик: зміна кожного показника так чи інакше впливає на два інших)

Ось декілька прикладів з реальних показників команди за Q1 2026

Стабільний delivery

(Frontend розробник, Q1 2026 — Utilization і Ratio в нормі, Dev rate нижчий за середній по команді)

Це приклад гарного квартального показника frontend розробника. Utilization — в зеленій зоні, що свідчить про достатнє навантаження та вище за середнє навантаження frontend команди за Q1. Ratio — теж в межах норми та покращився відносно попереднього кварталу та значно кращий за середній показник команди. Так Dev rate трохи погіршився відносно попереднього кварталу, але все ще нижчий за середній показник команди.

Тут варто врахувати frontend часто залежний від backend розробки і може не впоратись вчасно віддати задачі далі по процесу до кінця спринту, але це не його вина тому якщо у frontend розробника Dev rate < 10% це вже перемога.

Shit happens

(Два показники в червоній зоні: низький Utilization пояснює оманливо зелений Dev rate)

Цей приклад абсолютно протилежний попередньому. Тут одразу бачимо дві червоні зони. Utilization маякує про те, що навантаження нижче за попередній звітний період та за середнє навантаження команди (чому так сталось це окреме питання тут ми просто констатуємо цей факт). Ratio теж значно перевищує верхню межу в 1.1 та значно вище за середній показник команди (який теж на правду вище за норму). Проте Dev rate яскраво горить зеленим та трохи оманливо натякає на те, що він покращився.

Але аналізуючи ці показники разом, одразу стає зрозумілим, що таке зниження Dev rate доволі логічне і далеко не точно є результатом роботи над помилками минулого кварталу, де Dev rate = катастрофічні 34.3% Реальна причина, чому Dev rate знизився, в тому, що насправді надлишок вільного ресурсу був використаний для вчасного завершення задач та пішов в over log. Тобто якщо Utilization був би вище в межах 90 −100% при такому ж Ratio, то Dev rate був би мінімум на рівні минулого кварталу, а то і вище.

Що з цим робити? Досліджувати які задачі мали аномальний Ratio. В якому спринті та чому так сталось. Спойлер: я вже дослідив та знаю, що це були 2 здоровенні задачі та кожна з яких мала Ratio > 2

«Ні туди ні сюди»

(Показники в допустимих межах, але нестабільні — є над чим попрацювати)

Це приклад трохи неоднозначної ситуації, яка і «ні туди ні сюди». Тобто результати не еталонні, але і тривогу бити рано. Utilization яке мінімально зменшилось можна ігнорувати. Ratio погіршилось порівняно до минулого кварталу та гірше за середній показник команди, але все ще в допустимих межах. Позитив в тому, що Dev rate покращився до попереднього показника, але все ще вище за середній показник команди.

В такому випадку можна хвалити за гарну проведену роботу над помилками (якщо вони звісно були), але показники доволі хиткі та можуть легко погіршитись в наступному періоді, якщо розслабити булки

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

Варто відзначити, що для front- та back-end розробників dev rate може інтерпретуватися по-різному. Бо часто є залежні, спільні «грядки», і інколи front не може взяти задачу так, щоб встигнути її віддати далі по процесу, і вона впаде йому якорем в dev rate. Але це все можна пояснити, якщо не просто дивитись на цифри, а ще їх аналізувати.

Квартальні не листи «щастя»

Можна «зірвати флягу» остаточно та почати кожного спринту збирати ці дані та влаштовувати екзекуції команді в очікуванні, що зараз конвеєр запрацює, але насправді процес інтеграції не менш важливий, ніж дані, які ви отримаєте. Ми, як команда, прийшли до висновку, що такий recap має сенс бути раз на квартал. За цей час через розробника проходить достатній об’єм роботи. Є гарні і не такі гарні спринти. Тому на такій дистанції доречно провести рефлексію. Конструктивну рефлексію! Щоб цей recap був змістовним, ми надаємо графік того, як змінювались показники за весь квартал. Він підсвічує спринти з «нюансами» та ті, які пройшли гладко.

Важливо сказати пару слів про формат. Це не класичні листи «щастя», які приходять на пошту в папку — спам. Це час реально зібратись та поговорити. Про хороше та не дуже, але так щоб кожен член команди в кінці мав чітке розуміння, де він та над чим варто працювати.

Для цього ми розробили систему автоматичного формування звітів, де кожен розробник може в будь який момент переглянути власні показники та порівняти їх з попереднім періодом або ідентифікувати точкові спринти з відхиленнями та самостійно зробити висновки. Або ж ознайомитись з коментарем від менеджера, який вже дослідив ці відхилення та описав фактори, які потенційно могли вплинути на показники.

(Вигляд типового квартального звіту)

Чому це може працювати?

Давайте чесно: це все може виглядати як спроба загнати команду в рамку та сказати: «тепер всі під нігтем!». Але чи це того варто та яку користь це принесе? Це було перше питання, яке ми поставили собі перед тим, як взагалі братись за цю ідею. І найбільшим викликом було створити розуміння, що ця система не створена для контролю, а є свого роду «чекапом» як персонально для кожного, так і для команди як єдиного організму.

Ми чудово розуміли, що можуть бути цифри, які будуть не подобатись, але вони не вирок, а сигнал. Тому до кожних результатів надається коментар, який інтерпретує ситуацію, яку відображають цифри. В розробці може бути різне, і не кожен «фейл» — це вина розробника. Тому, якщо ви не готові аналізувати весь флоу та шукати зв’язки, чому відбулись ті чи інші події — не влазьте в це!) Якщо ваша ціль не карати, а краще розуміти та шукати способи вирішення проблем — то можете створити собі такий челендж.

«Apes together strong»

Тепер про те, як ми «знущаємось» над командними цілями та як все працює разом. Логіка тут проста: якщо на рівні кожного розробника показники збалансовані і ніхто не згорає в «червоній зоні», то і весь потяг їде рівно та передбачувано.

Ми хочемо творити стабільно хороший продукт, але ринок такий, що хто швидкий — той і забирає більший шматок. Тому для команди важливий time to market. На даному етапі ми інтерпретуємо його через те, який обсяг робіт ми запланували та який реалізували за ітерацію. Ми спробували пошукати залишки об’єктивності та зв’язку з реальністю, тому визначили, що для команди зараз ціль — стабільно релізити 70% того, під що комітимося в спринті.

Багато це чи мало — вирішувати вам, але це та прогнозованість, яка задовольняє всіх на даний момент та враховує особливості delivery-процесу такі як, до прикладу, реліз в четвер, що робить практично неможливим, реліз в пʼятницю задач, які перейдуть в release ready після основного релізу. Хоча збрешу, якщо скажу, що такого ніколи не було.

Що ми маємо зараз:

1. Реалістичне розуміння Workload розробника. ~50h на спринт.
2. Avg ratio — відношення реальності до очікувань у межах від 0.9 до 1.1, бо всі помиляються.
3. Avg dev rate — чим нижче, тим краще, але через призму реальності. Бо якщо залетіла таска з high-пріоритетом за день до кінця спринту, спробуй сказати бізнесу, що тут показник горить)
4. Team commitment 70% in Done від всього скоупу на кінець спринту.

Що ми не отримали?

• Ми не стали перформити ідеально. Додаю скріни з OKR команди, і якщо брати рік 2025 до 2024, можемо спостерігати стриманий приріст. Так, ми не закріпились на рівні стабільних 70% в 2025 році, але продукт і команда живі, а невизначеності менше не стає. Проте до кінця Q1 2026 року ми вийшли на стабільні результати та концентруємось над їх утриманням.

(Done rate команди за 2024–2025 по двох проєктах: стриманий, але стабільний приріст)

(Q1 2026: вперше вихід на стабільні 70% Done rate)

• Відтоку команди. Це було надважливо — зберегти команду та відносини всередині.
• Премії за таку розробку теж)

Епілог

Цей framework (давайте тепер його називати так) — не silver bullet. Він не вирішить ваші проблеми та не зробить все за вас. Це великий обсяг роботи, як технічної (зібрати ці дані), так і менеджерської (усвідомити, інтегрувати та підтримувати його). Якщо чесно — головний урок тут не про метрики. Він про те, що команда, яка готова говорити про свої результати відкрито, вже може перформити краще. Три цифри — це лише спільна мова для цієї розмови. Без довіри і культури вони перетворюються на ще один інструмент тиску. З ними — на систему координат, де кожен розуміє де він і куди рухатись.

Тому перш ніж надихатись формулами — запитайте себе: чи є у вашій команді ґрунт, на якому ці розмови взагалі можуть відбуватись?