Як виміряти ефективність роботи технічного відділу. Обираємо метрики правильно
Привіт! Мене звуть Антон Водолазький, я СТО OBRIO — продуктової IT-компанії з екосистеми бізнесів Genesis. У цьому матеріалі я розповім про ключові метрики, які відображають ефективність роботи технічного відділу. А також про власні кейси їх запровадження на етапі побудови відділів, правильної оцінки та коригування на кожному етапі зростання команд та проєкту.
Щоб зрозуміти, наскільки швидко та послідовно зростає проєкт, чи відповідає робота команд стратегії зростання бізнесу, необхідно мати орієнтир — метрики, які дають змогу оцінити продуктивність. Навіть якщо бізнес приносить прибуток і все працює добре, для CTO важливо постійно переконуватися в тому, що команда використовує всі можливості для покращення робочих процесів. А також не втрачає темп на кожному з етапів зростання проєкту.
Крім цього, при правильному використанні метрики можуть стати елементом мотивації й давати чітке уявлення про продуктивність як команд, так і окремих спеціалістів.
Вимір продуктивності розробників — усе ще непросте завдання
Варто одразу зазначити, що не існує універсальних метрик, які підійдуть для всіх типів компаній — аутсорсингових чи продуктових. А під час їх вибору потрібно враховувати цілі бізнес-стратегії компанії, яка закладає шлях розвитку проєкту, структуру команд, цінності та етапи розвитку продуктів. Також треба розуміти, що вимір продуктивності розробників — все ще непросте завдання.
Бо розробка ПЗ — складна, творча та спільна робота, яка потребує багаторівневих метрик оцінювання. До того ж традиційні метрики можуть вимагати використання систем та додаткового програмного забезпечення, які дають змогу зробити більш точні та всебічні виміри.
Для деяких стандартних метрик необхідно переналаштувати цілі технологічні стеки та конвеєри розробки, щоб забезпечити правильне відстеження. А безпосередньо впровадження необхідних інструментів та засобів може вимагати великих довгострокових інвестицій. Варто пам’ятати й про те, що ландшафт розробки програмного забезпечення швидко змінюється. Оскільки генеративні інструменти, як-от Copilot X чи ChatGPT, мають потенціал, який допомагає розробникам виконувати завдання набагато швидше.
Навіщо використовувати метрики оцінки
Правильний вибір метрик може прокласти шлях до постійного вдосконалення процесів роботи, а неправильний не дасть можливості об’єктивно оцінювати роботу команди.
Відстежування метрик дає змогу виконувати одразу кілька ключових задач:
- Виявлення неефективності та вузьких місць. Метрики допомагають знаходити проблеми у розробці, які могли б залишитися непоміченими, або були б неправильно сприйнятими. Наприклад, відстеження часових показників дозволяє виявити затримки у процесі перевірки коду або на етапах тестування, які не були очевидними раніше.
- Інформування про розподіл ресурсів. Маючи конкретні зацифровані дані про те, куди та на які задачі було витрачено час і зусилля, CTO можуть ухвалювати обґрунтованіші рішення. Це може бути як перерозподіл членів команди, так і інвестиції у нові інструменти чи пріоритетність скорочення технічного боргу.
- Демонстрація велью стейкхолдерам. Завдяки використанню метрик можна будувати ефективну комунікацію та демонструвати цінність і прогрес інженерної роботи зацікавленим сторонам, які не мають технічної освіти. З іншого боку, це корисно й для мотивації команди, щоб кожен спеціаліст розумів, який наразі ми маємо рівень якості та швидкості.
- Драйвер постійного вдосконалення. Встановлюючи базові показники ефективності та відстежуючи процеси із часом, команди можуть ставити собі наступні цілі та вимірювати результати їхнього досягнення. Це допомагає створити культуру постійної оптимізації, а не реактивних змін.
При правильному розумінні та трактуванні відстежування показників також допомагає підвищувати точність оцінки проєкту, а ще керувати очікуваннями стейкхолдерів щодо термінів реалізації.
Які є загальноприйняті технічні метрики
Серед технічних метрик найчастіше використовуються фреймворки DORA та SPACE, а також метрики методології Agile та Lean.
Зробімо короткий огляд на них.
DORA (DevOps Research and Assessment)
Фреймворк, яких має чотири ключові метрики: частота випусків, час до відновлення, час на зміни та відсоток помилок. Вони дають змогу зрозуміти, як швидко команда може доставити зміни в продуктивне середовище застосунка.
SPACE (Satisfaction, Performance, Activity, Communication, and Efficiency)
Цей фреймворк пропонує багатовимірний підхід до оцінки продуктивності команд. Він враховує як якісні, так і кількісні показники. Зосереджений на задоволеності команди, виконанні завдань, комунікації та ефективності.
Agile Metrics
Agile-фреймворки, такі як Scrum та Kanban, мають свої набори метрик. Наприклад: швидкість (Velocity), продуктивність команди (Team Performance) та покриття тестами (Test Coverage), які допомагають оцінити, як команда виконує задачі в спринтах.
LEAN Metrics
Lean-методологія спрямована на зменшення витрат та підвищення цінності. Метрики, як-от час виконання (Lead Time) і час на виконання (Cycle Time), допомагають виміряти ефективність процесів.
Важливо розуміти, що ці метрики не є універсальними та не підходять для кожної компанії чи команди, їх завжди потрібно обирати індивідуально.
Наприклад, якщо проаналізувати метрики DORA, то можна дійти висновку, що вони більше підійдуть командам DevOps, і зовсім не підійдуть QA.
У нашій команді відібрані метрики більше схожі на метрики фреймворку SPACE, який розробила команда Microsoft, тому що ми також використовуємо багатовимірний підхід до оцінки. Але використовувати їх ми насправді почали не одразу, і з самого початку поступово інтегрували в інтерактивній формі. А, наприклад, метрики Agile та LEAN ми майже не використовуємо, бо вони краще підходять аутсорсинговим компаніям.
Чому важливо використовувати кількісні та якісні метрики
Підвищення продуктивності вимагає чіткого визначення, на чому варто зосередитися, і здатності кількісно оцінити вплив змін.
Всі метрики можна розділити на два типи — кількісні та якісні:
Кількісні метрики — це умовно всі ті, які можна зацифрувати. Наприклад, метрика Delivery effectiveness дає змогу побачити: скільки задач було виконано, скільки часу на них було витрачено, яку кількість багів виправили. Загалом всі кількісні метрики вирізняються своєю об’єктивністю. Але якщо використовувати лише їх, не вийде бачити повну картину роботи команди. Тому кількісні метрики потрібно гармонійно поєднувати із якісними.
Якісні метрики дають повну картину. Загалом до цього виду метрик можуть належати будь-які, які неможливо порахувати. І також важливо розуміти, що вони мають суб’єктивну оцінку, такі метрики насправді дуже важко правильно запровадити із першого разу. Наприклад, ви хочете ввести опитувальник. На початку може задаватися, що в ньому достатня кількість запитань і частота використання дібрана правильно. Але згодом стає зрозуміло, що ще потрібно додати, та як правильно його використовувати — один раз на спринт, чи один раз на квартал.
Якщо працювати з кількісними та якісними метриками, вдається відстежити стан команди, ефективність її роботи. А також правильно планувати наступні етапи, мотивувати співробітників, показуючи їй горизонт. Можливо, вам буде корисно звернути увагу на спеціалізовані сервіси, які надають вже готові інструменти для покращення ключових задач у напрямках досягнення продуктивності праці розробників. Одними із таких платформ є Swarmia та DX.
Огляд метрик, які ми використовуємо в OBRIO
Наразі у нашому фокусі два основні вектори метрик, які ми постійно досліджуємо. Це метрики продуктивності команди та метрики якості коду, його стабільності. При цьому маємо одну високорівневу ціль, на яку орієнтуємося постійно, і яка дозволяє нам бачити, як ми рухаємося — Delivery effectiveness. В якомусь сенсі вона дуже схожа з метрикою Story points completed.
Їх різниця в тому, що замість оцінки в сторі поінтах ми робимо оцінку в годинах. Але суть залишається та сама — виконати замір і дізнатися, скільки команда змогла зробити за спринт. Ця метрика показує нам, що кожен член команди наприкінці спринта має свої таски закритими. Також вона може демонструвати й те, що хтось не встиг їх виконати. В такому разі потрібно виявити причини, чому так склалося.
При цьому я рекомендую не керуватися лише однією метрикою, а проводити всебічний аналіз. І для цього використовувати додаткові метрики.
Я вже відзначав, що ми маємо одну високорівневу ціль, яку називаємо Delivery effectiveness. Зазвичай починаємо аналізувати роботу з неї, бо вона банально є найкращим індикатором. Та варто розуміти, що цією метрикою важливо вміти не маніпулювати. У нас гарна культура цінностей всередині компанії. Ми її використовуємо для того, щоб зрозуміти, кому із команди та на якому етапі потрібна допомога, і яка саме. Другий індикатор цієї метрики може навпаки показувати овероцінку спеціаліста — коли було закладено дуже багато часу на роботу, а людина впоралася швидше.
Крім того, що ми маємо високорівневу метрику Delivery effectiveness, запускаємо опитувальник Sprint result questionnaire, який дає змогу порівнювати результати кількісних та якісних метрик:
Наші головні метрики продуктивності:
- OKR.
- Delivery effectiveness.
- Sprint result questionnaire.
Основні метрики коду та стабільності
- Кількість багів в беклозі — індикатор, який може вказувати на те, що команда набрала дуже швидкий темп, і їй не вистачає часу на фікс багів. Якщо правильно аналізувати цей показник, можна розуміти, коли саме потрібно робити донайм.
- Кількість нових багів та багів від команди support — метрика, яка допомагає відстежити, наскільки перформить кожний окремий спеціаліст, і скільки багів він робить. Також дає змогу проаналізувати, наскільки ефективно та якісно працюють QA.
- Тест кавередж — дозволяє аналізувати, наскільки ми покриваємо наш проєкт тестами. Метрика конвертується в ціль на команду.
- Кількість багів, знайдених автоматизацією. Оскільки ми переходимо від мануального до автоматичного тестування, ця метрика дозволяє аналізувати, наскільки ефективно та рентабельно використовувати автотести.
- Time saved — це кількість часу, який ми зберігаємо коштом автотестів.
- SLI інфри — визначена метрика стабільності інфраструктури наших сервісів.
Замість завершення
Дані про продуктивність розробників, хоч би якими цінними вони були, можуть завдати шкоди компаніям чи командам, якщо їх використовувати неправильно, тому при запровадженні та оцінці метрик важливо уникати помилок. Серед основних, які найчастіше допускають у компаніях, — неправильне використання метрик і нездатність команд подолати старі установки.
Також часто трапляється, що у команді намагаються використовувати надто прості вимірювання, як-от кількість написаних рядків коду або кількість комітів. Такі метрики не тільки не генерують дійсно корисних ідей, а й можуть спровокувати зниження ефективності робочого процесу. Крім того, залучення та утримання кращих талантів у IT багато в чому залежить від наявності інструментів, які дають змогу інженерам виконувати свою роботу найкращим чином та заохочують їх креативність на системному рівні.
Варто зазначити, що запровадження метрик допомагає і стейкхолдерам. Правильна оцінка дозволяє побачити приховані точки тертя, які перешкоджають роботі та креативності, і створити кращі умови для роботи технічних команд.
5 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів