Дайджест "Чи можливе вимірювання продуктивності інженерів?"

Dmytro Rodenko explores whether you can actually measure engineer productivity. He covers ROI, OKRs, and value-add capacity, with practical advice for IT company owners on improving team efficiency and client relations.
Всім привіт. Мене звати Дмитро Руденко. Я — засновник спільноти SaaS Founders, де допомагаю власникам IT-компаній знаходити нових великих клієнтів за допомогою LinkedIn. Сьогодні ми проговоримо про таке важливе питання, як вимірювати продуктивність інженерів. Існують різні точки зору з цього приводу. Це складне завдання. Є експерти, такі як Мартін Фаулер та Кент Бек, які стверджують, Продуктивність неможливо виміряти в сфері програмної розробки. Тим не менше, це дуже важливе питання і є інші альтернативні підходи, які дозволяють це зробити. Отже, як це можна зробити? Давайте подивимось на варіанти. Одна з можливостей – це визначення певного ідеального продукту та встановлення індикаторів для того, щоб зрозуміти, наскільки ми наблизились до того ідеального продукту. Якщо говорити про впровадження цього підходу, то дослідження Accelerate State of DevOps 2021 року показало, що компанії, що використовують цей підхід, витрачають 22% свого часу на роботу, не пов'язану з розробкою нових функцій. Тоді, як у компаніях, які не використовують цей підхід, чи взагалі не вимірюють продуктивність роботи інженерів, цей показник становить 42%. Тобто, умовно кажучи, 20% часу витрачається на 20% більше часу витрачається на неефективну роботу. А це п'ята частина завантаження і п'ята частина оплати. А це досить великий Досить велика можливість для збільшення результативності. Інший підхід – це встановлення цілей та ключових результатів, ОКР так званий. За даними опитання BMO Partners, 56% компаній використовують ОКР для вимірювання та покращення продуктивності. Тобто це досить поширена методика, яка дозволяє вимірювати продуктивність роботи інженерів та планувати її збільшення. Одним з можливих індикаторів є ROI – return on investment – віддача інвестицій. Якщо це можливо, це буде класно, оскільки ви розумієте, як впровадження тієї чи іншої функції приведе до покращення результатів клієнта. фінансових результатів клієнта. Це взагалі ідеально. Ми кажемо, ця функція збільшить ваші доходи, збільшить вашу віддачу настільки-то, тому вона коштує стільки. Це, до речі, питання щодо ціноутворення. Друге питання – це фактично ми фокусуємося лише на тих функціях, які є найбільш вигідними, найбільш цікавими для самого клієнта. Але тут є звичайне «але». Справа в тому, що точний розрахунок, фактичний ROI, може бути проблематичним через складність виокремлення зусиль інженерних команд. Тому, якщо ви можете, ви окримите це і поставите цей показник як експеримент, це як експеримент, буде набагато краще. який можна використовувати, який можна Він тоснує використовувати, який можна використовувати, який альтернативний можна використовувати, який підхід, називається можна використовувати, який можна використовувати, можна використовувати, він концепція продуктових ставок. Тобто що це значить? Що кожна функція визначає, для кожної функції визначаються критерії досягнення, тобто що має бути досягнене, очікувана цінність, сума інвестицій, обґрунтовується сама цінність та спосіб її вимірювання. За даними дослідження компанії McKinsey, компанії, які використовують процес пріоритізації ініціатив на основі ROI, чи OCR, чи концепції продуктових ставок, вони мають від 20 до 40 відсотків вищу продуктивність, ніж їх конкуренти. Наступна можливість – це так звана value-add capacity, або визначення міри продуктивності. Тобто визначається відсоток часу інженерів, що витрачений на роботу, що додає цінність для клієнтів та користувачів. Це, звичайно, менш об'єктивний показник, ніж ROI, але тим не менше він може, якщо ви не можете, виділити ROI чи визначити його. то ви можете зрозуміти, яка, скажімо так, інвестиція в яку функцію дає більшу цінність для користувачів і в такий спосіб збільшити продуктивність роботи. Дослідження компанії Puppet показало, що високопродуктивні команди витрачають близько 70% свого часу на роботу, яка створює цінність для клієнтів, тоді як команди з низькою продуктивністю – лише 30%. Тобто в два рази різниця, це досить важливо. Звичайно, в цього показника є також певні недоліки, тобто тут є можливість маніпулювання даними. Якщо з ROI чи фінансовими показниками все чітко і зрозуміло, там проблема лише в виділенні, скажімо так, цінності, яку реалізують технічні або інженерні команди, то тут Існує спокуса ігнорувати деякі необхідні види робіт, які не створюють цінність, але вони дуже важливі. Наприклад, це виправлення помилок, технічне борщ, оновлення безпеки, щоб штучно збільшити значення метри. І в принципі це може мати згубні наслідки для якості продукту в довгостроковій перспективі. Ну звичайно, якщо ми ігноруємо виправлення помилок, технічний борг та безпеку, ми наражаємося на досить високі ризики існування всього продукту в цілому. Важливо, що потрібно також виділяти певну долю показників на обслуговування тих питань, про які ми говорили. можливо домовитися з клієнтом, тобто яку частину робіт має бути виділена на ці питання, і в такий спосіб, скажімо так, показувати цінність, показувати цінність своєї роботи. Це дуже важлива історія, тому що в багатьох випадках клієнти не розуміють, на що витрачаються години, який вплив того чи іншого фахівця взагалі на результат проєкту і тому вони не купують ваші послуги далі. Бо вони кажуть, ну окей, ви роботу зробили, далі ми можемо самі. А чи можуть вони самі без підтримки технічної, без оновлення систем безпеки, без апдейту серверів і так далі і тому подібне. Тому, якщо ви навчитися вимірювати продуктивність для себе з одного боку, для клієнта з іншого боку, і показувати зв'язок між своєю роботою та результатами клієнта, ви зможете, по-перше, продавати свої послуги набагато дорожче, Друге, ви покращите довіру клієнтів до себе. Клієнти будуть розуміти, окей, я витрачаю ці гроші не просто кудись там в команду за такі витрати, я не розумію на що, але це потрібно, бо інакше працювати не буде. А клієнт чітко розуміє, що він витрачає, чому і як. Ну і третє, через прозору систему Тобто, якщо ви вирішуєте працювати з інфі-постачальниками, то вирішуєте працювати з інфі-постачальниками. Тобто, якщо ви вирішуєте працювати з інфі-постачальниками, то вирішуєте працювати з інфі-постачальниками. Якщо ви вирішуєте працювати з інфі-постачальниками, то вирішуєте працювати з інфі-постачальниками. Тобто дивіться, використовуйте вимірювання продуктивності інженерів для того, щоб підвищити ефективність роботи своєї команди, для того, щоб краще продавати своїм клієнтам, працювати з ними довше та заробляти більше. Бажаю всім великих контрактів, до зустрічі, гарного дня.
More from Dmytro

Лайфхак "Какие ошибки в лидгене убивают ваши шансы на сделку по IT разработке"









