Технології постійно стають розумнішими та потужнішими. Але часто в міру їхнього впровадження продуктивність організації замість поліпшення знижується. До цього призводить збільшення складності та когнітивні навантаження розробників. У цій статті наведено фреймворк для максимізації ефективності розробника. Завдяки дослідженням визначено ключові цикли зворотного зв'язку, у тому числі цикли мікрозворотного зв'язку, які розробники виконують 200 разів на день. Їх слід оптимізувати, щоб вони були швидкими, простими та ефективними.

Автор досліджує, як деякі організації використовували ці цикли зворотного зв'язку для підвищення загальної ефективності і продуктивності.

Оригінал: Maximizing Developer Effectiveness
Автор: Tim Cochran

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

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

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

Підходи компаній із високою та низькою ефективністю розробки сильно відрізняються.

Найпростіший спосіб пояснити - на прикладі 1 дня з життя розробника:

День із життя у високоефективному середовищі

Розробник:

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

Розробник може досягти поступового прогресу за день і щасливим піти додому.

День із життя у малоефективному середовищі

Розробник:

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

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

Ефективність розробника

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

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

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

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

Давайте подивимося на приклад компанії, що оптимізувала ефективність розробників.

Приклад: Spotify

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

1. Фрагментація внутрішнього інструментарію. Внутрішня інфраструктура та інструменти Spotify були побудовані як невеликі ізольовані «острови», що призвело до переключення контексту та когнітивного навантаження на інженерів.
2. У Spotify не було централізованого місця для пошуку технічної інформації. Оскільки інформація поширювалася всюди, інженери навіть не знали, де шукати інформацію.

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

Негативний маховик Spotify

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

З чого почати?

Компанії з високоефективним середовищем повністю прийняли культуру DevOps, безперервне постачання та продуктове мислення. Цілком розумно, що більшість компаній знаходяться на шляху до досягнення цього середовища. Вони прочитали звіт Accelerate та State of DevOps. Вони знають, який тип організації хочуть побудувати. Чотири ключові показники (час виконання, частота розгортання, середній час відновлення та відсоток збоїв змін) є відмінними показниками продуктивності DevOps.

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

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

Цикли зворотнього зв'язку

Ключові цикли зворотного зв'язку наступні:

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

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

Цикли зворотного зв'язку під час розробки нової функціональності

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

• Розробники запускатимуть цикли зворотного зв'язку частіше, якщо вони коротші.
• Розробники будуть видавати більший результат, якщо вони бачитимуть реальну цінність у своїх діях, а не суто бюрократичні накладні витрати.
• Більш ранні та частіші перевірки скорочують доопрацювання надалі.
• Цикли зворотного зв'язку, які легко інтерпретувати у результати, скорочують обмін даними та когнітивні витрати.

Коли організаціям не вдається досягти цих результатів, проблеми швидко посилюються. Розробники витрачають багато зусиль та часу на очікування, пошук чи спроби зрозуміти результати. Це призводить до значних затримок у розробці продукту, що проявляється у нижчих індекаторів за чотирма ключовими показниками (зокрема, частотою розгортання та часом виконання).

Представляємо цикли мікро зворотного зв'язку

Потрібно закріпити основи того, що розробники роблять 10, 100 чи 200 разів на день. Їх називають цикли мікрозворотного зв'язку. Це може бути запуск модульного тесту під час виправлення помилки або зміна коду, перевірка у локальному середовищі чи середовищах розробки. Це також може бути оновлення даних у середовищі. Розробники, якщо вони наділені повноваженнями, природно оптимізуються, але часто циклами мікрозворотного зв'язку нехтують. Ці цикли навмисно короткі, тому доводиться мати справу з дуже короткими проміжками часу.

Цикли мікро-зворотного зв'язку об'єднуються, щоб впливати на більші цикли зворотного зв'язку.

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

Але ці дві хвилини можуть швидко накопичуватися та перевищувати 100 хвилин на день. Ці невеликі паузи – можливість втратити контекст та зосередитися. Їх достатньо, щоб розробник відволікся, вирішив відкрити електронний лист або піти випити кави, так що тепер він відволікається і не в стані потоку. Існують дослідження, які показують, що може знадобитися до 23 хвилин, щоб повернутися в стан потоку і повернутися до високої продуктивності.

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

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

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

Організаційна ефективність

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

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

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

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

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

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

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

Після зобов'язань, вимірювань та розширення можливостей настає масштабування.

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

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

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

Власне, ефективні організації скорочують цикли зворотного зв'язку з управління.

Приклад: Etsy

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

Одним із ключових показників Etsy є час виконання замовлення, яке вимірюється, відстежується та відображається в реальному часі у всіх офісах компанії. Коли виконання замовлення перевищить певний ключовий поріг, група розробки релізів постарається знизити його до розумного рівня. Їхній технічний директор Майк Фішер говорить про те, що інженери Etsy «безстрашні», щоб швидко рухатися вперед, але мають сітку страхування, щоб пробувати нові речі.

Швидке розгортання програмного забезпечення – це лише половина справи. Щоб програмне забезпечення було справді ефективним, воно має бути цінним для споживачів. Etsy робить це, використовуючи підхід, що базується на даних, де кожна функція має вимірні KPI.

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

У Etsy є поточна ініціатива, яка ставить на чільне місце досвід розробників. Він складається з чотирьох основних стовпів:

4 стовпи досвіду розробників

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

Допоможіть мені розробляти, тестувати та розгортати, орієнтовані на інженерів по продуктах, зокрема, на самі середовища розробки (IDE, лінтери), модульне / інтеграційне тестування, шаблони, а також на інструменти та процеси розгортання.

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

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

Ця політика є справжньою відданістю керівництва Etsy своїм розробникам. Вони постійно перевіряють свою ефективність, відстежуючи метрики, включаючи 4 ключові індикатори, і проводять щомісячні опитування з розробниками, щоб отримати Індекс Споживчої Лояльності (NPS).