Технічний борг ROI: пояснення рефакторингу для бізнес-зацікавлених сторін
Навчіться пояснювати технічний борг бізнес-англійською: відсотки проти основної суми, ROI для рефакторингу, навмисний проти ненавмисного боргу і шаблони спілкування з зацікавленими сторонами.
Одним з найскладніших завдань комунікації для інженерів програмного забезпечення є пояснення технічного боргу нетехнічним зацікавленим сторонам. Лідери бізнесу розуміють поняття боргу у фінансовому сенсі — вони розуміють відсоткові платежі і альтернативні витрати. Ключ - це використовувати фінансову аналогію точно і пов’язати її з результатами, які їм не байдужі.
Технічний словник
Словник технічного боргу навмисно запозичує з фінансів, що робить його доступним для бізнес-аудиторії, коли використовується послідовно.
Технічний борг — накопичена вартість скорочень, компромісів і неоптимальних проектних рішень, зроблених під час розробки програмного забезпечення. Як і фінансовий борг, він з часом накопичує відсотки. « За нашими оцінками, поточний технічний борг у службі оплати коштує нам приблизно два тижні розробників на місяць у повільнішій доставкі і частіших інцидентах »
** Відсотки ** — постійна вартість технічного боргу: повільніший розвиток, більше помилок, більша частота інцидентів, довше залучення нових інженерів. « Ми платимо відсотки за цей борг кожного спринту — приблизно 20% потужностей команди йде на роботу навколо застарілого коду, а не на створення нових можливостей. »
** Основна сума ** — початкова кількість робіт, необхідних для вирішення кореневої причини технічного боргу. « Сплата основної суми — рефакторинг у три спринти — значно зменшить наші щомісячні відсоткові платежі. »
** Навмисний технічний борг ** — борг, який було прийнято свідомо в обмін на швидкість, зазвичай задокументовано з наміром погасити його пізніше. « Ми навмисно обирали простішу модель даних, щоб врахувати термін запуску; ми задокументували компроміс і запланували переробку на другий квартал. »
** Ненавмисний технічний борг ** — борг, який накопичується ненавмисно, через відсутність знань, погану практику або зміну вимог. « Сполучення між цими службами було ненавмисним; це не був свідома компроміс, а наслідок зростання кодової бази без чіткої архітектури. »
** Рефакторинг ** — поліпшення внутрішньої структури існуючого коду без зміни його зовнішньої поведінки, з метою зменшення технічного боргу. « Рефакторинг не додасть ніяких нових можливостей, але значно спростить зміну і тестування коду, що безпосередньо збільшить нашу швидкість доставки у майбутньому. »
** Legacy code ** — часто використовується неформально для опису коду, який важко змінити, погано перевірено або використовує застарілу технологію. У бізнес- розмовах визначайте, що ви маєте на увазі. « Коли я кажу « застарілий код », я маю на увазі код, який не пройшов тестування, тісно пов’ язаний зі старим монолитом і вимагає спеціалізованих знань, якими на даний момент володіє лише один інженер у команді. »
ROI Framing для рефакторингу
Щоб обґрунтувати інвестиції у рефакторинг, вам потрібно кількісно оцінити як вартість роботи, так і очікувану віддачу. Використовувати цю структуру:
** Крок 1: Визначити поточну вартість відсотків ** «Поточна архітектура вимагає в середньому 3 дні інженерних зусиль на одну нову функцію в цьому модулі, порівняно з 0,5 днями для еквівалентних функцій в наших новітніх сервісах. Додаткова вартість на одну функцію становить приблизно 2,5 днів розробника»
** Крок 2: Оцініть, як часто ви платите ** «Ми надаємо приблизно 4 функції на місяць в цій області, що означає, що ми платимо приблизно 10 днів розробників на місяць в надлишковій вартості — приблизно місячний обсяг одного інженера»
** Крок 3: Вкажіть суму інвестицій** «Цільовий рефакторинг займе двох інженерів три спринти (шість тижнів), щоб завершити»
** Крок 4: Обчислити рівень прибутку ** «При 10 днях розробника, збережених на місяць, ми зрівняємося з шеститижневими інвестиціями приблизно за три місяці, і збережемо один інженерний місяць потужності кожен місяць після цього»
Переклади з англійської мови
| Technical statement | Business-language translation |
|---|---|
| ”The codebase has poor test coverage" | "Changes to this area carry a high risk of regressions; every release requires significant manual testing, which costs X hours per sprint." |
| "The services are tightly coupled" | "A change in one area breaks three others unpredictably, which means we cannot safely deploy independent updates — slowing us down significantly." |
| "We have no observability" | "When something goes wrong, we cannot identify the cause quickly; our average incident resolution time is 4 hours instead of the 20 minutes we see in our well-instrumented services." |
| "The build pipeline is slow" | "Engineers wait 45 minutes for each feedback cycle; this idle time costs approximately X hours of productive engineering per week across the team.” |
Як вести переговорний процес
Выразите это как управление рисками, а не как уборку: «Я хочу підняти ризик: поточний стан платіжної служби створює значний бізнес-ризик. Частота інцидентів удвічі зросла за останній квартал, і наша здатність додавати нові способи оплати серйозно обмежена. Я пропоную розглянути це зараз, перш ніж це стане проблемою, що стоїть перед клієнтом»
Настоящие варианты, а не ультиматум: «У нас є три варіанти: продовжити як є і прийняти поточну вартість відсотків, зробити фокусований три-спринт рефакторинг зараз, або запланувати більш всеоб’ємну міграцію протягом двох кварталів. Я рекомендую середній варіант, тому що він балансує невідкладність з обсягом»
** З’ єднатися з графіком дорожньої карти: ** «Наступний редизайн чеку буде значно дорожчим, якщо ми спробуємо його на вершині поточної кодової бази — моя оцінка — додаткові шість тижнів зусиль. Рефакторинг зараз є ефективною передумовою для цього пункту дорожньої карти»
Приклади слів у контексті
-
«Технічний борг не є технологічною проблемою — це бізнес-ризик. Відсотки, які ми платимо за це сьогодні, становлять приблизно 25% від місячної потужності команди, яка не є доступною для нових функцій»
-
«Це був навмисний технічний борг: під час запуску, ми свідомо обрали простіший підхід до корабля вчасно, і ми задокументували цей вибір з обов’язком розв’язати його в Q2. Цей зобов’язання є тим, що я тут, щоб обговорити сьогодні»
-
«Розрахунок ROI для цього рефактору простий: три спринти інвестицій відшкодовуються у скороченому часі доставки і нижчій частоті інцидентів протягом чотирьох місяців, а економія складається безперервно після цього»
-
«Коли я кажу, що послуги тісно пов’язані, що це означає на практиці, що кожна зміна вимагає координованих випусків у чотирьох командах — накладні витрати на координацію коштують нам приблизно два дні на спринт»
-
“Я хочу бути чесним: залишити цей борг на місці не безкоштовно. Ми платимо за це кожним спринтом у повільнішій швидкості, більше вад і більшу навантаження на служби. Питання не в тому, чи платити — це чи ми платимо зараз із запланованими інвестиціями, чи продовжуємо платити нескінченно через неефективність»
Визначення цінності: практичний підхід
При обговоренні технічного боргу з зацікавленими сторонами, які не глибоко залучені в сам код, важливо оформити його не як проблему, яку потрібно негайно вирішити, а як інвестиційне рішення, наприклад, управління відсотками проти головної суми кредиту. Спочатку, деякі скорочення («ціна») можуть здатися доцільними, що дозволяє швидше доставляти функції. Однак, ігнорування цих накопичених технічних боргів - дозволяючи їм накопичуватися і складатися (“головний”) - в кінцевому підсумку призведе до набагато більших витрат вниз по лінії: сповільнення швидкості розробки, збільшення ризику помилок і, можливо, нездатність пристосуватися до змінних бізнес-потреб.
Розглянемо сценарій в рамках команди проекту, що використовує Jira. Під час зустрічі з планування спринту менеджер продукту запитує: «Тоді, ця нова функція здається швидкою для впровадження. Чи ми вкладаємо в це якийсь «технічний борг»? » Доброю відповіддю не було б технічне пояснення запаху коду або застарілих систем. Замість цього, головний розробник міг би сказати: «Це справедливе питання. Ми навмисно прийняли трохи менш ідеальний підхід — спрощення деяких тестів і документації — щоб швидко випустити цю функцію і дотримуватися поточного терміну. Це представляє початкову інвестицію — невелику суму технічного боргу — для створення негайної цінності для клієнта. Однак, ми відстежуємо ці рішення в нашому спринті, відзначаючи потенційну майбутню вартість, якщо ми не звернемося до них проактивно. “Ця фраза відразу ж розташовує її як розрахований компроміс, а не невдачу.
Крім того, важливо розрізняти між навмисним технічним боргом і ненавмисним боргом. Навмисний борг визнається заздалегідь - задокументований в дорозі проекту, обговорений з зацікавленими сторонами і бюджетований. На відміну від цього, ненавмисний борг виникає від нехтування рефакторингом або вирішення невеликих питань просто для виконання негайних термінів. Ключове повідомлення тут переходить до акценту на проактивне управління: «Ми зобов’язані регулярно переглядати нашу базу коду - близько 10% кожного спринту - особливо шукаючи області, де ми можемо зменшити цей технічний борг і запобігти його зростанню». Пізніше повідомлення Slack до менеджера продукту може бути таким: «Просто хотів пояснити, що, поки ми приоритизуємо швидкість тут, ми також будуємо вчасно для невеликого рефакторингу наступного тижня, щоб забезпечити довгострокову підтримку»
Нарешті, під час написання описів запитів на завантаження, уникайте жаргонних слів. Замість того, щоб сказати « Рефакторинг для вирішення високого технічного боргу », спробуйте щось на зразок: « Цей PR покращує ясність і стабільність потоку автентифікації користувача, зменшуючи потенційні майбутні проблеми, пов’ язані з масштабованістю і безпекою — запобіжний захід проти накопичення технічного боргу. » Сфокусування на * результаті * — підвищена надійність або зменшений ризик — легше зрозуміти зацікавленим сторонам, ніж технічну термінологію.