Гарні, погані, злі показники продуктивності та ефективності, або Як нас правильно оцінювати

Привіт, я Андрій Сильчук, Delivery Director і голова центру розробки DataArt у Одесі та автор телеграм-каналу «Уютная галера». Сьогодні постараємося розібратись, як розумно оцінювати якість роботи в ІТ та чи існують загальні метрики для всіх.

Якість роботи є невіддільною від понять «продуктивність» і «ефективність». Пригадаємо, що продуктивність — це обсяг виконаної роботи, а ефективність — раціональність витрачених дій. Я 100 разів віджався — я продуктивний. Але заробив грижу — маю сумніви щодо своєї ефективності.

Навіть у цьому прикладі з простою повторюваною дією є конфлікт показників — важко зрозуміти, наскільки я молодець. А як оцінювати крутість QA-інженерів, які мають справу з сотнями різних багів? А рекрутерів, які хантять цих QA-інженерів? Програмістів, які за тиждень вирішили, як розв’язати складну проблему, але не написали жодного рядка коду?

Я завжди був противником стандартизації й типових підходів: якщо перенести критично важливі метрики з одного проєкту в інший, вони можуть не лише нашкодити, а й цілком зруйнувати бізнес. Чи не можуть? Тільки-но я про це замислився, одразу з’явився азарт довести можливість узагальненого підходу до оцінки ефективності та продуктивності, хай і з масою припущень і застережень.

Сподіваюся, мої роздуми стануть у пригоді для всіх, хто оцінює і кого оцінюють. Але насамперед — для керівників, які виносять вердикт на Performance Review.

Погані метрики

Щоб зрозуміти, який показник продуктивності може бути гарним, потрібно спочатку опуститися на дно, де мешкають погані кількісні метрики:

• кількість написаних рядків коду;
• кількість знайдених дефектів;
• кількість перевідкритих дефектів;
• кількість виконаних user stories;
• кількість закритих вакансій;
• кількість закритих тикетів;
• та ще тисяча подібних метрик.

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

Припустимо, ми знаємо, що QA-інженер Марина, яка дуже круто зарекомендувала себе в команді, знаходила 100 дефектів на місяць. Беремо Марину за ідеал, отримуємо оцінки: 90–100 дефектів — круто (A); 75–90 — добре (B); 50–75 — таке собі (C); 25–50 — погано (D); 0–25 — нікуди не годиться (F).

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

Рекрутер Сергій, зірочка в команді найму, закриває за місяць по 10 позицій. Значить, усі, що закривають меншу кількість, працюють гірше? Але ж закрити десяток позицій QA-трейні можна, просто виклавши пост у Facebook чи LinkedIn. А щоб найняти команду DevOps-інженерів, та ще й у межах маржинальності проєкту — знадобляться тижні, якщо не місяці завзятого пошуку.

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

Ви можете заперечити: «Андрію, але ж „у довгу“ чисельні метрики працюють. Сьогодні тобі дісталася складна фіча на тестування, завтра — мені; сьогодні ти шукаєш єдинорога, завтра — відбиваєшся від сотень рекомендацій на позиції джунів і трейні». Я відповім: «Навіть якщо в якихось командах таке усереднення працює, ми нікуди не сховаємось від однієї серйозної проблеми». Набираємо більше повітря — і пробиваємо дно!

Припустимо, QA-інженер Едуард, який працює разом зі згаданою Мариною, подивився на її показники та вирішив довести, що він не гірший. Едуард починає дробити один дефект на дрібніші та женеться за кількістю. У відповідь отримує від розробника масу дефектів назад з такими коментарями і статусами: «дублікат», «не відтворюється», «конфігурація, що не підтримується» і навіть «не дефект».

Не забуваймо, що у світі розробки одна метрика може мати різноспрямований ефект. Ми можемо порадіти за Едуарда, але розробника зовсім не тішить, що в зоні його відповідальності Едуард задокументував 100 дефектів. І ось ми знову переносимося в часи ненависті й ворожнечі між тестувальниками і програмістами. Стосунки в командах псуються, продуктивність — нижче за плінтус, релізи сирі та постійно переносяться.

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

Отже: персональні кількісні метрики несуть більше шкоди, ніж користі. Якщо потрібно виміряти продуктивність, їх краще не використовувати.

Гарні метрики

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

Отже, наше завдання — мінімізувати суб’єктивність. І тут нам на допомогу приходить Performance Review з методами «180 градусів», «360 градусів» та інших, більш екзотичних градусів.

Нагадаю, що в методі «180 градусів» співробітник сам оцінює свою роботу за якийсь період, плюс, його керівник дає оцінку. У методі «360 градусів» додається фідбек колег, з якими співробітник взаємодіє, підлеглих, замовників.

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

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

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

Загальний рівень професіоналізму та ставлення до робочих завдань:

• Чи ефективно колега працює під тиском або у кризовій ситуації?
• Чи працює більше, ніж зазвичай, коли цього вимагає робоче навантаження і дедлайни?
• Чи пунктуальний на зустрічах, у звітностях?
• Чи інформує керівника, коли відсутній на роботі?
• Чи шукає вихід з безвихідних ситуацій та чи готовий звертатися за допомогою?
• Чи вміє виявляти, чітко визначати проблеми та їхню критичність, чи шукає альтернативні способи розв’язати задачу?
• Чи бере на себе нові завдання самостійно, чи пропонує нові ідеї?
• Чи використовує кращі практики?

Робочі стосунки всередині команди:

• Якою є культура спілкування колеги?
• Чи шанобливо веде переговори, чи розв’язує конфліктні ситуації, чи досягає угоди на загальних умовах?
• Чи готовий допомогти колегам?
• Чи ефективно працює з людьми різних ступенів мачурності?
• Підтримує здорову атмосферу в команді чи навпаки?

Проєктна робота та компетентність:

• Чи використовує колега навички, необхідні для його посади?
• Чи опановує нові навички, коли це необхідно?
• Чи відповідає політикам і процедурам, які використовуються у проєкті?
• Чи дотримується термінів і естімейтів, чи повідомляє про перенесення дедлайнів завчасно?
• Чи забезпечує відповідність виконаної роботи стандартам якості, ухваленим у проєкті?
• Концентрується на цілях проєкту чи витрачає робочий час марно?

У межах бізнесу клієнтів:

• Чи розуміє колега потреби клієнтів?
• Чи знає доменну сферу?
• Чи ухвалює проєктні рішення, виходячи зі знання ринку й потреб клієнтів?
• Чи дотримується своїх естімейтів?
• Чи готує трейні з працевлаштуванням у проєкти?

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

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

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

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

Колега хоче стати мідлом? Дістаємо матрицю компетенцій, читаємо, що мідлу потрібно вміти працювати з REST API, а колега не вміє. Домовляємося з ним, що в наступне рев’ю ставимо REST API за мету та оцінюємо виконану роботу. На виході колега отримує бажаний грейд, а проєкт — людину, що вміє працювати з REST API. Win-win.

Отже, гарна метрика є актуальною в конкретній ситуації та адаптується під мінливі реалії. Є сумісною з потребами команди, проєкту, бізнесу. І якомога об’єктивнішою завдяки оцінці за методом «360 градусів».

Злі метрики

Ми домовилися, що існують погані кількісні персональні метрики, що ґрунтуються на неоднорідності вимірювань і сильно заважають продуктивності. На іншому полюсі — гарні метрики, що допомагають ефективності, але їх не можна назвати об’єктивними на 100%.

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

Цілі ставить безпосередній керівник, і в ідеалі це має бути частиною Performance Review, коли доходить до обговорення наступного періоду. Важливо: ціль має бути здійсненною з погляду колеги, якого оцінюють. Тверезо враховуємо поточні та майбутні завдання колеги, рівень його експертизи.

Цілі потребують додаткових зусиль від колег і контролю — бажано, щоб керівник моніторив прогрес, скажімо, щомісяця. Саме тому такі серединні метрики (між гарними та поганими) можна назвати злими: ніхто не любить зайвого контролю і надзусиль.

Зла метрика, як і гарна, прив’язана до потреб команди, проєкту чи бізнесу. Наприклад, бізнесу наступного року важливо автоматизувати техпідтримку — вважаємо за мету зменшення ручного втручання у процес на 80% або більше. У клієнта йде залучення нового раунду інвестицій, успіх залежить від точності розроблюваного алгоритму — ставимо за мету підняти точність із 90% до 95%.

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

Однак навіть в умовах максимальної неупередженості знайдуться колеги, які не погодяться з їхньою персональною оцінкою. Тому перш ніж запрошувати колегу на Performance Review, керівнику варто зрозуміти, де можливі розбіжності у поглядах на продуктивність і ефективність.

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

Пам’ятка для продуктивних і ефективних

1. Якщо метрика прив’язана до кількісних показників, що ґрунтуються на неоднорідності оцінки, — це погана метрика. Приклади: кількість дефектів, кількість закритих тикетів, кількість найнятих кандидатів.
2. Погана метрика сіє розбрат у команді, змінює фокус з якості на кількість.
3. Гарна метрика завжди прив’язана до потреб проєкту, бізнесу та команди.
4. Гарна метрика — не константа. Вона змінюється разом з потребами проєкту, бізнесу та команди.
5. Для збирання гарних метрик потрібно бути злим, але об’єктивним. Чудовим інструментом є методи «180» та «360 градусів».
6. Якщо є розбіжність в оцінці колеги іншими з його особистою думкою, наперед готуємо залізобетонні докази.
7. Для посилення ефекту об’єктивності на Performance Review ставимо цілі на наступний період і контролюємо їхнє виконання. Такі цілі — здійсненні, вимірні, мають однозначне трактування, прив’язані до потреб команди, проєкту або бізнесу. На відміну від просто гарних метрик, вони значно більш конкретизовані.
8. Пам’ятаємо, що цілі перетворюються на вимірну метрику тільки на наступному Performance Review, коли можна оцінити результати роботи за ними.
9. Ще пам’ятаємо, що загальних правил для всіх не існує. Іноді погані метрики на кшталт кількості закритих тикетів мають право на життя, якщо їх застосовують не до окремого інженера, а до всієї команди. Але тут стільки нюансів, що для них знадобиться окрема стаття.