Цифри важливі, довіра — безцінна: оцінка роботи інженерної команди

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

Відповідно до нещодавнього опитування, третина розробників вважає, що їхні інженерні перешкоди залишаються непоміченими керівництвом. І це ще не все! Уявіть собі: 56% технічних директорів приймають стратегічні рішення, не усвідомлюючи негативного впливу на свою команду, 51% перепризначають людей, не знаючи повних наслідків, а 44% зрештою перевантажують розробників. Шокує те, що 96% розробників кажуть, що незнання пріоритетів, до яких прагне керівництво, заважає більшій частині команди.

Отже, що можна зробити, щоб розв’язати цю проблему? Перш за все, ми повинні заглибитися в корінь проблеми, досліджуючи моделі та ставлення, які сприяють зростанню розриву між розробниками та менеджментом. Як людина, яка успішно сприяла співпраці між інженерами та керівниками, я дотримуюся власних ідеалів, якими готовий поділитися, не нав’язуючи їх нікому.

Вплив роз’єднаності на інженерів виходить за рамки простих практичних наслідків. На рівні міжлюдських відносин це глибоко впливає на розробників, залишаючи без відповіді запитання про політику компанії. Інженери хочуть бути активними учасниками процесу прийняття рішень, але часто зізнаються, що не хочуть брати на себе цю роль. Натомість вони покладаються на своїх менеджерів, щоб розв’язувати проблеми, й сподіваються на рішення, які будуть відповідати їхнім інтересам. Однак, коли голос інженера не має ваги в компанії, рішення навряд чи будуть на його користь.

Як представник delivery я чітко усвідомлював інтереси своєї команди. Я зосередився навколо трьох основних стовпів: клієнта, моїх людей і вищого керівництва. З цієї точки зору моєю метою було знайти найкращий можливий результат для всіх учасників. Окреслимо головне: без згуртованої команди проєкту не буде існувати. Команда, що працює в хаосі, також не зможе зберігати проєкт довго. Люди формують фундамент у цій структурі стейкхолдерів.

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

Як результат, топменеджмент часто виявляється відірваним від реальності. Підтримувати зв’язок між інженерами та лідерами стає дедалі складніше. Ця проблема стає ще більш помітною у великих компаніях із сотнями співробітників, де неможливо уникнути ієрархічної комунікації. Кожен рівень у цій ієрархії додає власні суб’єктивні інтерпретації, що призводить до викривлених цифр і думок, які відхиляються від фактичної реальності.

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

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

У 2019 році я приєднався до своєї нинішньої компанії як керівник та архітектор з чіткою позицією: я не визнаю субординацію, особливо у сфері технологій. Натомість я наголосив на важливості поваги. На відміну від моїх попередніх менеджерів, наш СЕО розуміє фундаментальну істину, що інженери керують прибутковістю компанії.

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

• По-перше, керівництво має демонструвати відкритість і готовність дивитися не тільки на цифри та маржу.

• По-друге, лідери мають бути залучені до ключових процесів й бути в курсі справ, навіть якщо вони не займаються цим особисто. Топменеджмент може призначати представників, наприклад chief delivery officer або chief operating officer, які будуть занурюватися у справи компанії.

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

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

Для підтримки зв’язку розробників та менеджменту потрібні люди, які готові представляти інтереси своїх інженерів. Крім того, проактивні лідери серед інженерів повинні мати можливість безстрашно висловлювати реальну ситуацію. Саме завдяки такому узгодженню досягається справжня синергія, що дозволяє приймати рішення, які враховують інтереси обох залучених сторін.

Чесно кажучи, я не прихильник метрик. Сьогодні існує незліченна кількість показників, які вимірюють ефективність, технічні аспекти та особливості delivery. Але ось у чому справа (я завжди кажу своїй команді та тим, хто шукає поради з інших компаній): коли справа доходить до ефективності, жоден із цих показників не визначає її. Показниками можна маніпулювати, і кожен трекер можна обійти. Можна створити ілюзію роботи. Порівнювати попередні спринти з поточним непрактично, оскільки завдання, середовище та фактори продуктивності можуть відрізнятися.

Існують технічні показники, які вказують на «хороші» чи «погані» результати, наприклад, проблеми з production або помилки. Однак навіть показники якості коду є суб’єктивними та залежать від конфігурацій. Незалежно від показників у вашому наборі інструментів, вам все одно потрібен лідер, менеджер, який враховує людський фактор. Хтось, хто розуміє причини, мотивацію та, що найважливіше, контекст — нематеріальні аспекти, що знаходяться поза контролем механізмів. Я виступаю за баланс показників і управлінського розуміння. Щоб досягти цього, нам потрібно більше довіряти своїм людям.