Управління технічним боргом за допомогою DX та AI

Кожна компанія, велика чи мала, турбується про технічний борг. За оцінками Gartner, близько 40% інфраструктурних систем мають цю проблему. У опитуванні CIO від McKinsey майже третина відчувала, що понад 20% їхнього нового продукту бюджету пішло на вирішення проблем, пов’язаних з технічним боргом. Але на відміну від того, що багато хто вважає, це не тільки проблема кодування; це також проблема досвіду розробника (DX). Адже коли розробники повинні працювати з недостатньою архітектурою, застарілими інструментами та низькоякісними процесами розробки, продуктивність, ефективність та моральний дух страждають.

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

Просування DX

Часто процес інтеграції нових розробників залишає багато бажань. Можна витратити кілька тижнів, перш ніж хтось почне внесок у проект. Як тільки вони нарешті змогли додати невеликі функції або патчі, не рідко трапляється, що безперервна інтеграція (CI) служби відмовляє через щось зовсім не пов’язане з змінами, над якими вони працювали. Це фактично тестовий набір, який відмовляє через низькоякісні проблеми, і розробник не надсилав змін, щоб зробити тестовий набір відмовляти. Це нестабільний, погано написаний тест, який працює лише 90% часу. Існуюча команда, ймовірно, задоволена цим – це тільки сповільнює процеси – але інструменти можуть бути застарілими та деморалізуючими для будь-кого поза організацією.

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

Є інструменти, які можуть допомогти, наприклад CircleCI, з вбудованими функціями, які відстежують нестабільність тестового набору. Що потрібно, так це хтось, хто візьме на себе лідерство та зупиниться після кожного спринту, щоб вирішити деякі зміни, які полегшать роботу з кодом у майбутньому. Це зводиться до наявності лідера, зацікавленого у поліпшенні DX. Щоб цього досягти, шукайте старшого інженера, супроводжуваного відносно новим співробітником, який може надати інформацію про можливі пробіли.

Також IDC очікує, що ринок автоматизації тестування програмного забезпечення, що працює на основі AI, продовжить рости на 31,2% до 2027 року, тому переконайтеся, що ви використовуєте цю технологію в повному обсязі.

Метрики та попередні сигнали

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

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

Інструменти з AI

Ріст інструментів, що працюють на основі AI, повинен підвищити продуктивність розробників та інженерів та прискорити відправку продукції, але технічний борг сповільнює це. Наприклад, якщо ви використовуєте інструмент, такий як GitHub або Copilot, щоб допомогти з змінами коду, потім надсилаєте запит на отримання, а CI займає кілька годин, щоб відповісти. Тим часом розробник працює над чимось іншим? Перевіряє електронну пошту? Це зміна контексту та вбивця продуктивності.

Розробники хочуть працювати над продуктами, де вони можуть просто зосередитися на коді. Інструменти повинні допомагати їм доставляти продукт у виробництво, а не бути постійною перешкодою. AI може зберегти час, але інженерним командам потрібно визначити自己的 стандарти прийнятної складності. Для цього спочатку переконайтеся, що будь-який код, доданий до вашої основної гілки, має прийнятний рівень технічного боргу. До цього проведіть відкриту дискусію та отримайте згоду інженерної команди щодо прийнятного порогу технічного боргу та якості коду. Переконайтеся, що всі знають, що перевищення цього рівня вимагає негайного виправлення. Як тільки ви визначили ці стандарти, AI вступає в дію.

Є підстави для агентів AI з інженерами, які діють як оркестратори. Опитування Capgemini серед 1 100 керівників великих підприємств показало, що 82% планують інтегрувати агентів AI протягом наступних трьох років, і вони вже впливають на майбутнє праці. Ви можете дивитися на звіт про помилку та бачити, що вона достатньо мала, щоб агент AI міг зайнятися цим з початку до кінця, зберігаючи час вашої команди та звільняючи її для більш складної роботи. Однак іноді, коли ми сліпо слідуємо цим інструментам, є компроміси, які AI не може враховувати.

Це тоді, коли людська думка стає вирішальною.

Вирівнювання технічного боргу з цілями

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

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

Нарешті, є метрики, які допоможуть спілкувати цінність переробки або погашення технічного боргу зацікавленим сторонам. Час може бути одним із них, від початку до виробництва, або від відкриття запиту на отримання до злиття та відправки у виробництво. Інша метрика – середній час до ремонту (MTTR). У цьому випадку ви можете знайти помилку або зламану збірку та виміряти, скільки часу вашій команді потрібно, щоб виправити це. Ви також можете відстежувати кількість помилок у виробництві. Якщо ви бачите, що це число зростає, може бути проблема, пов’язана з технічним боргом.

Технічний борг з відсотками

Кожна організація може присвятити кілька годин на тиждень поліпшенню свого DX, щоб допомогти скоротити технічний борг. Якщо ні, ви можете заплатити за це пізніше, ймовірно, через сповільнення продуктивності, значне сповільнення швидкості розробки або проблеми з безпекою. Наприклад, ваша команда інженерів та розробників могла відкладати оновлення Ruby on Rails протягом десяти років. Раптом вартість проекту збільшується на півмільйона доларів, оскільки версія Ruby відстоїть на чотири покоління, залишаючи вас із масою коду та застарілими залежностями.

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