Дайджест "Вимірюючи успіх: як Google, LinkedIn та інші оцінюють успіх своїх інженерів"

Всім привіт! Мене звуть Дмитро Руденко. Я – засновник спільноти SaaS Founders. Допомагаю власникам IT-компаній знаходити нових великих клієнтів за допомогою LinkedIn. Сьогодні ми поговоримо про те, як провідні компанії, як Google, LinkedIn та інші, оцінюють успіх своїх інженерів. Справа в тому, що вимірювання продуктивності розробників набуває все більшої актуальності вимог жорсткої конкуренції на IT-ринку. Тобто компаніям потрібно максимально ефективно використовувати свої інженерні ресурси, ну і, звичайно, шукати якісь оптимальні підходи до оцінки ефективності своїх розробників. Ми зараз розглянемо, які метрики продуктивності використовують технологічні гіганти, як Google, LinkedIn, Microsoft, Peloton, та подивимось, які метрики використовують компанії меншого розміру, від 100 до 1000 людей. Порівняємо їх та зробимо висновки, які метрики будуть найбільш цікавіші для вашої компанії. Отже, Такі гіганти використовують декілька типів метрик, наприклад, якісні та кількісні метрик. Наприклад, легкість діліверії, швидкість експериментів, стабільність сервісів, задоволеність розробників, час виконання розробки. Зазвичай відстежуються від 5 до 10 різних метрик одночасно. Давайте подивимось, як це робить Google. У Google має окремий відділ, називається він Developer Intelligence, в якому працює більше 50 аналітиків та data scientists. Їх основне завдання – збирати дані про продуктивність розробників, аналізувати їх та готувати регулярні звіти та ідеї щодо покращення результату. За останніми даними з щоквартального звіту, В Google виділяють три ключові виміри продуктивності. Перший – швидкість, тобто відстежується середній час виконання задач, кількість задач на розробника на тиждень, час виходу оновлень. Наприклад, за останній рік вони збільшили показники на приблизно 15-20%. Другий тип показника виміра – це легкість. Аналізується рівень задоволеності процесами та інструментами шляхом регулярного опитування та інтерв'ю. За той самий період рівень задоволеності виріс з 78 до 85%. Якість. Відстежується процент дефектів, виявлених на етапах тестування та після виходу продуктів. Частка дефектів на етапі тестування зросла за той період. Також використовуються якісні методики опитування, інтерв'ю, фокус-групи. Тут важлива штука. Справа в тому, що найважливіше, щоб при опитуваннях, а не при фіксації якихось конкретних результатів, люди відповідали широ, тобто, щоб вони розуміли, що їх відповідь не вплине на фінансові результати їх роботи. Бо тоді вони будуть намагатися маніпулювати цими показниками для того, щоб показати свою корисність і так далі. Тобто, коли є жорсткі показники, які ви моніторите за допомогою зовнішніх систем, час виконання, швидкість, кількість і так далі, це окей. Але коли ви опитуєте, дивіться, щоб формулювання питань Взагалі завдання, які ви ставите, не були такі, що люди розуміють небезпеку щирої відповіді. Тобто ви не маєте не преміювати за відповіді, ні карати за такі відповіді, розумієте? Це важливо. Йдемо далі. Давайте подивимось на підхід LinkedIn. LinkedIn функціонує цілий відділ, називається він Developers Productivity, що складається з 30 фахівців. Вони аналізують дані за такими напрямками. Щоквартальні опитування розробників щодо процесів та інструментів. Тобто це фактично NPC, Net Promoter Score. Ви його зустрічали, наскільки ви порекомендуєте, умовно, своєму другу. Це в B2C так працює. В B2B це може бути, наскільки ви задоволені таким-то процесом. Друге – це система зворотнього зв'язку від команд, тобто які зауваження є по командах. Третій блок – це автоматичні метрики. Час збірки, частота релізів, процент помилок. Наприклад, за останній період у них час збірки скоротився на 20%, що досить непогано. І такий спосіб зібрані дані дозволяють LinkedIn ефективно відстежувати динаміку та вчасно реагувати на проблеми в продуктивності команди. Давайте розглянемо, як це працює в компанії Peloton. Вони фокусуються на чотирьох ключових напрямках. Перший – це engagement, тобто рівень задоволеності розробників роботою в компанії. Такий happiness indicator. До речі, в минулому році він зріс на 5 відсотків, що досить немало, і склав 87 відсотків. Швидкість, тобто це час виконання, частота розгортання нових деплоїв і так далі. Третій – якість, тобто відсоток успішних деплоїв. Він відслідковується, ну і відносно робиться оцінка ефективності команди. Стабільність, тобто кількість інцидентів на тисячу користувачів. Тобто цей показник має знижуватися. Давайте розкажу трохи про нас. Ми, звичайно, хоч ми не займаємося безпосередньою розробкою, але у нас є також ділівері, ділівералі дегенерації, і нам також дуже важливо було вибудувати процеси для оцінки ефективності наших співробітників. Тому тут ми використовуємо поєднання кількісних та якісних методик. З кількісної сторони ми аналізуємо обсяг виконаної роботи в оданицях продукту, відсоток завдань, виконаних часно відповідно до поставлених критерів, та кількість помілок та виправлень у роботі. З якісної сторони ми звертаємо увагу на рівень професійних навичок – hard skills, soft skills, дотримування вимоги стандартів якості роботи. І от власне така комбінація дає можливість об'єктивно оцінити внесок кожного співробітника в загальний результат. Це допомагає нам ефективно управляти продуктивністю та розвитком персоналу. Скажу так, що коли ми впровадили персональні плани, додатково до планів компанії і планів відділів, персональні плани розвитку, то це допомогло нам всім, і співробітникам, і керівництву компанії зрозуміти, які можливості в наших співробітників є для особистого розвитку, і ми поєднали роботу в компанії не тільки з тим, щоб людина могла заробити собі гроші з гігієнічними факторами, а ми поєднали їх з цілями особистого розвитку. Тобто ми знайшли зв'язок, як досягнення цілеї компанії допомагає нашим співробітникам досягати особистих цілей. І це крута історія, тому що от тоді почала працювати команда. Тоді люди зрозуміли, що разом ми досягнемо більшого, що нам потрібно комбінувати свої зусилля, треба відмовлятися від нерозумних речей, від того, що від неефективних речей, та виносити більш ефективні речі вперед. Давайте подивимось, як працюють компанії середнього розміру. Це компанії по розробці також. Частіше за все використовуються такі показники продуктивності. Легкість доставки, час виходу нової функції, залученість розробників і витрачений час на виправлення дефектів завдяки поліпшенню процесів тестування. Важливо сказати, що компанії різноманітні, тобто компанії не мають певного стандарту, і кожна компанія встановлює стандарти для себе. Це залежить, я думаю, ще від специфіки індустрії, з якій компанії працюють, бізнес-моделі і так далі. Але важливо широко використовувати якісні методики. До речі, цікаво, що деякі компанії роблять акцент на вимірювання фокусного часу. тобто безперервної глибокої залученої роботи над проєктом. От, наприклад, Stripe та Uber використовують конкретні показники такі, як кількість днів з достатнім фокусним часом, той час, як інші вимірюють його в рамках опитування розробників. Є різні унікальні методики, такі як коефіцієнт адопції у компаніях Dordish, частка розробників, що активно використовують продукт чи сервіс, кількість технічних документів на розробника, оцінка дотримання практики попередньої документації, швидкість експериментів тощо. Важливо використовувати певну методологію при виборі власних метрик. Наприклад, спочатку визначити цілі, потім сигнали про їх досягнення, і нарешті обрати відповідні метрики. Фактично, це може бути, наприклад, 3 категорії бізнес-вплив-проєктів, продуктивність систем та ефективність інженерної організації. Немає універсального підходу, ви можете або скопіювати вже існувачі підходи і оптимізувати їх для себе відповідно до тих завдань, які стоять перед вашою командою. Тому будьте гнучки, контролюйте ефективність роботи своїх розробників, а ми допоможемо вам зробити так, щоб у ваших розробників була робота. Бажаю всім нових великих контрактів, до скорої зустрічі, пака-пака.