Полювання на привидів: як побачити реальний внесок розробників

«Ghost engineers» — кожен десятий розробник майже не робить нічого корисного, а лише переконливо імітує бурхливу діяльність. Справжні причини такої бездіяльності — робота на стороні, вигорання чи звичайне неробство — можуть дуже довго залишатися непомітними для керівництва. (Стенфордське дослідження 2024 року: оригінальний тред)

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

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

А може, хай уже будуть, ці привиди? Зрештою, компанія цих грошей навіть не помітить.

Але є один нюанс…

Коли я кажу про низьку ефективність, то не маю на увазі ситуацію, коли Олексій сидить, пихтить і робить на 10% менше за Богдана. Йдеться про інше: на кожному стендапі вся команда вислуховує чергову жалісливу історію — суміжна команда підвела, задача поставлена нечітко, зорі не зійшлися. Але завтра все точно буде готово. Зуб даю.

От тільки це «завтра» вже було вчора й позавчора — і встигло стати традицією.

Команда швидко помічає такі речі. У тих, хто справді тягне роботу, закономірно виникає запитання: навіщо гарувати, якщо можна розповідати небилиці — і тобі за це нічого не буде?

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

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

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

Чи може керівник помітити проблему раніше — побачити відхилення, запитати про контекст і розібратися до того, як команда втратить терпіння, а компанія — час і гроші?

Маючи достатньо досвіду, такі історії можна заздалегідь розпізнати за характерними моделями поведінки:

• Успіхи — мої, провали — твої.
• Виправдання провалу задачі ще до того, як робота над нею почалася.
• Брак компетентності компенсується надмірною балакучістю.
• З часом саме керівника дедалі частіше виставляють «винуватцем».
• На відміну від людини, яка справді має труднощі, така поведінка не змінюється на краще навіть після прямого зворотного зв’язку.

Але щоб перевірити підозри, потрібні цифрові сліди.

Розгляньмо найпоширеніші інструменти оцінювання ефективності розробки й те, чи допомагають вони виявляти привидів.

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

Щоб оцінювати ефективність саме розробки — не бізнесу чи продукту загалом, — я використовую просту тріаду: швидкість, якість і обсяг. Швидкість показують метрики DORA, якість — тести й дефекти. З обсягом складніше: тут найменше протоптаних стежок і саме тут ховаються привиди, яких ми шукаємо.

DORA: швидкість і надійність релізів

DORA показує, наскільки швидко й без збоїв команда доставляє зміни в продакшен. Модель охоплює п’ять метрик: час від коміту до продакшену, частоту релізів, частку релізів зі збоями, час відновлення та частку незапланованих виправлень.

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

Ці метрики ще й напрочуд зручні для KPI. В одній компанії, де я працював, їх доїли з 2018 року: успішно фарбували всі дашборди в зелений, і всі були щасливі. Актуальна модель DORA.

Тести й дефекти: наскільки добре зроблено роботу

Підходи давно відомі й успішно працюють на практиці. Якість контролюють за допомогою код-рев’ю, тестів і статичного аналізу, а наслідки відстежують за дефектами та інцидентами.

Але ці сигнали нічого не говорять про обсяг. Одна маленька бездоганна правка зробить усі показники зеленими — і привид залишиться невидимим.

Jira та story points: скільки задач закрито

Jira показує закриті задачі та story points, але оцінки визначає сама команда. Ту саму роботу можна оцінити в три бали або в тринадцять, розбити на п’ять задач або об’єднати в одну.

Для планування story points корисні, але як оцінка особистого внеску — ненадійні. Щойно бали стають ціллю, люди починають оптимізуватися під них.

Для KPI вони теж зручні. Дані вносять і задачі пересувають винятково заради проходження quality gates. Купа марної ручної роботи.

Коміти та рядки коду: факти без контексту

Git не залежить від командних оцінок, тому коміти й рядки коду хочеться просто порахувати. Але п’ять комітів можуть бути однією дрібною правкою, а один squash-коміт — тижнем роботи.

Форматування, генерація, копіювання й перенесення коду роздувають кількість рядків, тоді як складне виправлення може вміститися лише в десять.

Swarmia, LinearB і Waydev: уся інженерна система в одному місці

Swarmia, LinearB і Waydev об’єднують Git, таск-трекер і CI/CD. Керівники бачать метрики DORA, черги на рев’ю, час проходження змін та результати опитувань.

Це дає корисну картину інженерної системи — і часто показує, що проблема в процесі, а не в людині. Але порівняння обсягу роботи конкретного розробника — не головне запитання, на яке відповідають ці платформи. Swarmia, LinearB, Waydev.

GitClear: що залишається після кодового шуму

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

Так розраховується Diff Delta — власна одиниця GitClear для змістовних змін, що залишилися в кодовій базі. Скопійований або швидко викинутий код важить менше за компактну зміну, яка продовжує працювати в продакшені. Як працює Diff Delta.

Diff Delta відповідає не на запитання, скільки роботи було потрібно, а скільки змістовних змін залишилося після шуму й переробок. Найсильніші сторони GitClear — вимірювання довговічності та якості коду й аналіз впливу ШІ.

Уже тепліше. Сервіс публікує бенчмарки, але Diff Delta залишається власною одиницею: число 10 000 мало що скаже без доречного порівняння та розуміння методики. Чіткої точки відліку на кшталт «100% — це норма» тут немає. Бенчмарки Diff Delta.

BlueOptima: те саме запитання в масштабі корпорації

З BlueOptima я знайомий не з чуток. Я почав працювати з платформою у 2019 році. Саме цей досвід надихнув мене створити власний продукт.

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

Це дає змогу порівнювати розробників із різних команд і технологічних стеків, зокрема з глобальним бенчмарком. Для мене це була перша переконлива спроба відповісти не на запитання «Скільки рядків написав цей розробник?», а на запитання «Скільки змістовної роботи стоїть за цими змінами?». Методика BlueOptima, глобальний бенчмарк.

У моєму випадку ці корпоративні можливості вимагали досить важкого впровадження: агент потрібно було розгорнути в закритому мережевому контурі, ціна була високою, а результати потребували експертної інтерпретації.

Для компанії з тисячами розробників це може бути виправдано. Для стартапу чи невеликої команди — навряд. Саме цей розрив згодом став однією з причин появи DevGhost.

Та сама шкала — без тендера

Створюючи DevGhost, я не намагався зібрати ще один комбайн з усіма можливими інженерними метриками.

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

Логіка проста: DevGhost аналізує самі зміни — що додали, видалили й перебудували та наскільки складно було створити й перевірити результат. Форматування, перенесення коду, масові автоматичні заміни та згенерований код відокремлюються від змістовної роботи.

Результат — оцінка зусиль в еквівалентних годинах: скільки часу знадобилося б розробникові середнього рівня, який знає кодову базу й працює без ШІ, щоб написати такий самий код. Це не фактичний час за клавіатурою й не оцінка якості або бізнес-цінності коду, а спільна шкала для порівняння змін. Докладніше про методику DevGhost.

У Ghost% ця оцінка порівнюється з очікуваним результатом розробника середнього рівня з урахуванням того, яку частку свого часу людина справді витрачає на розробку. 100% означає відповідність нормі. Нижчий результат — привід розібратися в причинах; вищий варто вивчити й, можливо, перетворити на найкращу практику.

Еталон навмисно передбачає роботу без ШІ. DevGhost не намагається визначити, хто написав конкретний фрагмент — людина, Copilot чи автономний агент. Він оцінює фінальні зміни: скільки зусиль знадобилося б розробникові середнього рівня, щоб створити й перевірити їх без допомоги ШІ.

Тому ефект від ШІ не губиться всередині метрики, а стає помітним. Якщо за певний період розробник створює й перевіряє результат, який раніше потребував би у два-три рази більше зусиль, Ghost% це покаже. Водночас форматування, масова генерація та інший кодовий шум не повинні давати такого самого ефекту.

А судді хто?

Найочевидніше запитання: чому машинній оцінці взагалі варто вірити? Коротка відповідь — сліпо вірити не варто.

Оцінювання складності роботи за визначенням суб’єктивне. Ми це перевіряли: давали ті самі зміни кільком досвідченим розробникам і отримували помітно різні цифри. У кожного своя швидкість, свій досвід і своє уявлення про складність.

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

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

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

«Я й так знаю, хто як працює в моїй команді»

Один із клієнтів DevGhost — технічний керівник швидкозростаючої AI-компанії. Спочатку він скептично ставився до самої ідеї вимірювати ефективність розробки. Його позиція була простою: хороший технічний керівник і без дашборда знає, хто як працює.

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

Згодом, коли розробники почали звільнятися, з’ясувалося, що весь цей час вони паралельно створювали власні продукти. DevGhost не міг знати причини. Він лише показав те, чого не було видно з кількості комітів, pull request’ів і щоденного спілкування у Slack: обсяг роботи був помітно нижчим за очікуваний.

Але аналіз не перетворився на список на звільнення. Ще двом розробникам низький результат допоміг дати предметний зворотний зв’язок, розібратися в причинах і підвищити продуктивність. Обидва залишилися в команді.

Розробники, яких він вважав сильними, теж опинилися саме там, де він і очікував. Причому стало видно не лише хто перевершує очікування, а й наскільки стабільно це відбувається.

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

А якщо один розробник видає результат за трьох?

Полювання на привидів — найгучніша частина цієї історії. Але верхня частина графіка може виявитися кориснішою.

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

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

Один обмежується автодоповненням. Інший уміє передавати агентам потрібний контекст, формулювати чіткі правила, вести кілька задач паралельно й ретельно перевіряти результат. Тому однаковий доступ до ШІ дає зовсім різний приріст продуктивності.

Високий Ghost% допомагає знайти розробників, у яких ця зв’язка людини й агентів уже дає сильні результати, — і зрозуміти, які практики може перейняти решта команди.

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

Не перетворюйте шкалу на кийок

У будь-якої метрики одна доля: рано чи пізно хтось намагається зробити з неї KPI. Ghost% для цього не підходить.

Зробіть Ghost% командним KPI — і люди почнуть оптимізувати роботу під нього. Опублікуйте рейтинг — і довіра зникне. Перетворіть показник на кнопку звільнення — і помилки стануть неминучими.

Я б зафіксував чотири правила:

• Не робити висновків за одним вимірюванням або коротким періодом.
• Враховувати роль людини, частку її часу на розробку та роботу поза кодом.
• Показувати результат розробникові й давати можливість пояснити контекст.
• Не використовувати Ghost% як єдину підставу для кадрового рішення.

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

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

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

Швидкість, якість і обсяг потребують різних інструментів. DORA показує рух змін до продакшену. Тести й дефекти показують якість. DevGhost додає оцінку роботи, що стоїть за змінами в коді.

Жодна з цих метрик не повинна ухвалювати рішення замість керівника.

Цінність цифри не в тому, що вона виносить вирок. А в тому, що складна розмова починається раніше й спирається на факти.

Як ви оцінюєте обсяг роботи розробників — і де для вас проходить межа між корисною прозорістю та стеженням?