KPI vs OKR. Як використовувати метрики на користь команді й демонструвати найкращі результати

Мене звати Дмитро Штепура, я співпрацюю з ЕРАМ на позиції delivery менеджера. Ця роль, а також обов’язки керівника юніту, передбачає багато роботи з людьми та генерацію результатів для бізнесу.

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

Почнемо з визначень

КРІ (або Key Performance Indicators) — це вимірювані показники діяльності, які допомагають оцінити поточний стан і ефективність обраного напрямку розвитку. Їхнє завдання — допомогти організації реалізувати обрані стратегічні і тактичні цілі.

OKR (або Objectives and Key Results) — це методологія постановки і реалізації цілей, до роботи над якими залучені і менеджери, і співробітники. Вона дозволяє вибудовувати прозорі процеси, стимулює кооперацію і допомагає досягати результатів протягом визначеного часу.

Чому КРІ — не найвдаліший варіант для інженерів

Одразу зауважу, що КРІ можуть бути корисними, але на мою думку краще працювати з ними менеджерам. Адже key performance indicator — це про той стан справ, який притаманний команді саме зараз, або ж про порівняння того, як команда працювала раніше і як тепер. Ці метрики можуть наочно демонструвати вузькі місця, зони для покращення роботи певної групи. Керівнику вони допомагають не стільки оцінити, чи добре працює інженер, скільки побачити, як допомогти команді стати ефективнішою.

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

Банальний приклад: розробник може просити тестувальника штучно зменшувати кількість багів у системі, а про інші просто писати йому приватно. Або ж якщо у тестувальника також є схожий KPI, але на кількість знайдених багів — і тоді може виникнути битва за те, що це не три баги, а один, і навпаки.

Це призводить до того, що люди намагаються не показати реальні результати, а виконати свій КРІ. Через це зазвичай руйнуються відносини між спеціалістами та в цілому в команді.

Також коли КРІ фокусується на конкретній людині — це тисне на її продуктивність. Мовляв, твої результати псують якість делівері — ти винен, бонусу не буде. Хоча насправді — завдання керівника зібрати оптимальну команду та підтримати процеси. Адже загальна сила команди дорівнює силі найслабшої ланки.

Окрім того, важливо розуміти, що КРІ частіше за все люди не обирають, їм їх «спускають» зверху, майже нав’язують. В той час як OKR дозволяють разом з командою зробити ретроспективу, знайти проблеми або ж що може/має бути покращено та нагенерувати шляхи їх вирішення. Це включає людей у спільну роботу і мотивує досягати позитивних результатів. Я бачив це неодноразово на прикладі різних команд.

Звісно, КРІ ефективно показують себе у Scrum чи Kanban. У випадку зі Scrum має значення і підлягає зрозумілому оцінюванню velocity — швидкість і продуктивність команди, те, як вона встигає виконувати роботу, яку запланувала, та чи робить це у запланований відрізок часу тощо. Використовувати цю метрику варто регулярно, щоб скеровувати роботу команди у вірному напрямку та розуміти, де потрібно допомогти. Але головне у Scrum — це саме командна робота, яка дозволяє виконати ціль самого спрінта та побудувати продукт загалом.

У Kanban можна ставити за КРІ lead time — час, необхідний від приходу задачі до її виконання, cycle time — час, необхідний від моменту як задачу взяли до роботи, та до ії виконання, та інші показники. Але знову ж таки: мова про вимірювання результатів команди/ групи розробників та про використання цих показників менеджером, а не безпосередніми інженерами.

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

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

За і проти КРІ

✅ Вам скоріше за все стануть в пригоді КРІ, якщо необхідно визначити прогрес команди, складнощі в конкретних місцях, зони, які потребують змін.
✅ Також вони будуть корисними, якщо треба зрозуміти кількість задач, які повертаються на допрацювання, перевірити якість вимог чи те, як добре розуміють завдання працівники.
✅ КРІ допоможуть також визначити метрики для того, щоб задачі були зараховані, як успішно виконані, покажуть зони розвитку команди, напрямки, у яких потрібна допомога, можливий прогрес.

❌ А от індивідуальні КРІ здатні створити нездорову поведінку в команді через прямі зауваження і конкуренцію, яка зробить клімат у робочій групі гіршим. Найкращих результатів досягти у такому форматі роботи буде складно.

ОКR як вдала альтернатива для досягнення командою цілей

Особисто я — великий прихильник саме ОКR. У дніпровському офісі ЕРАМ я був одним з відповідальних за той, що спрямований на посилення Cloud-експертизи. Це передбачає розробку та добір найякісніших матеріалів для навчання, створення програм різного рівня, аналіз напрямків та аудиторій, які проходитимуть навчання, впровадження курсів у розгалужену екосистему внутрішніх платформ компанії тощо.

На мою думку, Objectives and Key Results — це те, що дозволяє прямувати до мети, якої необхідно досягти командою чи компанією. Відмінність від КРІ полягає саме у тому, що вони орієнтовані на майбутнє, на результати, які чекають попереду. І це допомагає фокусуватись на роботі, гуртувати команду, мотивувати учасників процесу. ОКR нагадують — чим далі ви просунетесь, то краще.

Інша важлива особливість — ОКR позбавлені негативу, адже будь-яке просування до мети і будь-який результат є позитивним, демонструє бажання і готовність до змін. Уявіть, що разом з командою ви погодили OKR для покращення якості коду. Переконаний: у цьому разі вся робоча група долучиться до завдання і буде зацікавлена у досягненні позитивних результатів.

Варто мати на увазі при використанні OKR

Щоб бути впевненим у вірності напрямку руху, необхідно постійно синхронізуватися з командою, тримати руку на пульсі того, що відбувається. Керівник має бути впевненим у тому, що всі члени команди однаково і вірно розуміють мету і шлях до неї. І от тут саме попередні КРІ допоможуть менеджеру зрозуміти поточний стан справ. А далі, разом з командою, ви зможете планувати майбутні цілі у форматі OKR.

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

Це можуть бути запровадження глобальних програм у вашій компанії або великий проєкт для важливого замовника. За необхідності, OKR можна легко перетворити або продублювати за допомогою КРІ. А головне — від OKR у людей горять очі, підвищується мотивація працювати у команді і зникає фактор страху потенційного покарання за недостатній, на думку керівництва, результат.

Звісно, ви не зможете виміряти перфоманс команди і зміни з минулого періоду роботи. Для цього та інших робочих потреб менеджер може традиційно звертатись до КРІ. Наприклад, я їх використовую, щоб перевірити стабільність lead time. Якщо КРІ демонструють велику проблему, на її базі можна побудувати OKR і направити команду на вирішення завдання.

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

Я впевнений: лідери скоріше будуть обирати OKR, а менеджери більш консервативного складу триматимуться за КРІ. При цьому я не закликаю відмовитись від КРІ зовсім. Все ж таки, для роботи керівника та розуміння еволюції команди та результатів її роботи їх можна і потрібно використовувати. Головне — розумно і помірковано.