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

Привіт, я Андрій Сильчук, 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. Ще пам’ятаємо, що загальних правил для всіх не існує. Іноді погані метрики на кшталт кількості закритих тикетів мають право на життя, якщо їх застосовують не до окремого інженера, а до всієї команди. Але тут стільки нюансів, що для них знадобиться окрема стаття.

    Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

    👍ПодобаєтьсяСподобалось92
    До обраногоВ обраному28
    LinkedIn
    Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
    Ctrl + Enter
    Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
    Ctrl + Enter

    У меня в Фейсбуке при вводе комментария публикация съезжает вверх и не видно, что пишу. И это лишь одна из метрик, как работают вообще программисты. Вот эта вся размазня по контролю всего — лишняя трата времени и нервов. Снимите людей с галер, если они там сидят, дайте больше свободы и оно само наладится. Один человек начальнику задницу лижет, порожняк гонит в работе, а другой может начальника послать. но сделает так, чтобы комментарий не ехал.

    Ось все було гарно в статті, навіть згадав коли вводили метрику «покриття тестами» й люди почали крити тестами конструктори, сетери, використовувати рефлексію, бізнес логіку крили через verify.returnsAnyObject({}) (тобто функція щось повернула, байдуже що, але зарахувалось). Навіть згадав наскільки реально добре працювало 360.
    Але коли це прочитав:

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

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

    Чи ефективно колега працює під тиском або у кризовій ситуації?

    якщо це реально у листі ваших запитань — звільняйте менеджмент. Наявність цього запитання — це антиметрика менеджменту.

    Коротше конкретні питання — шляпа. Але з головною ідеєю статті згоден.

    Це тілки приклади щоб направити вас. Як я казаз далі у статті — кожне опитування повинно бути привʼязане до бізнес цілей та цілей проекту. Якщо у вас погано з перформансом, то може і навіть таке питання буде допомогати. Але, anyway, гарне опитування може бути тільки унікальним та адоптованим до конкретних потреб. Я не пропонує використовувати ці самі питання зі статті, у тому самому текстуванні.

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

    Метод 360 є суб‘єктивним інструментом і в команді де немає відкритості та присутні міжособистісні конфлікти такий метод краще не використовувати.

    Взагалі все є яд і все є ліки, одне точно треба дивитись на середовище та бізнес потреби.

    Дякую за доповнення. В мене якось не складалося за кількісними метриками якщо вони індивідуальні, завжди знаходились якісь гострі кути. Тому я все ж таки рекомендую їх використовувати (с коефіцентами чи ні) тільки у випадку коли це командна метріка, а не індивідуальна. Коефіценти теж не пацанея, як до мене.

    Взагалі то так, серебряних куль не існує. Головне це те, що каже нам бізнес

    Правду кажете що кількісні метрики — це погано.
    Однак і «360 градусів» — це суб’єктивщина, яка часто зводиться просто до того чи подобається людина оточуючим. І ніяк не пов’язана з ефективністю.
    Майже кожне питання таких опитувань, як от «Чи знає доменну сферу?» не супроводжується доказами і навіть не релевантне, тому що у мене як інженера немає компетенцій відслідковувати чи перевіряти як мої колеги чи менеджери знають доменну сферу.
    З іншого боку, для менеджера хакнути систему для отримання гарного фідбеку так само легко як і з кількісними метриками. Коротко кажучи — справляти хороше враження на всіх, бути на виду. Це вимагає в рази менше зусиль ніж реальна робота.

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

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

    «Заделіверити 5 фіч основного проекту в місяць» — це одночасно і гарна і погана метрика.
    Як з квантами, коли щось одночасно перебуває у декількох станах. Назву цей приклад квантовим KPI.

    За статтю дуже дякую.

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

    Сподіваюсь це допоможе :) Краще знайти однозначно гарну метрику, але завжди є місце вийняткам. Наприклад, якщо ніяк не можно без KPI про фічі, то я би спускав таку на команду, а не на окремого інженера.

    Квантовый KPI — это просто хит, возьму фразу на вооружение))))

    Підписатись на коментарі