Втілення ваших ідей у життя
через управління проєктами

Угору

Технічний борг на боржнику верхи їздить

Технічний борг на боржнику верхи їздить

20 травня 2021

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

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

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

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

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

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

У своєму квадранті технічного боргу розробник Мартін Фаулер виділяє чотири типи техборгу:

Інакше кажучи, ви берете на себе технічний борг одним з чотирьох способів:

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

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

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

4 ефективних способи управління технічним боргом:
  1. У більшості випадків поява технічного боргу – це сигнал про те, що стратегія проєкту та процеси створення продукту не були ретельно продуманими. Отже, найкращий спосіб впоратися з технічним боргом, коли він вже існує, – переглянути поточну стратегію проєкту, виявити слабкі місця в управлінні й процесах, які змусили вашу команду взяти на себе технічний борг, і заповнити ці прогалини. Рішення може містити встановлення нових стандартів написання коду, перегляд критеріїв готовності деталей програмного продукту, критеріїв готовності вимог до початку дизайну і розробки тощо.
  2. У гнучких проєктах технічний борг зустрічається особливо часто. Якщо ви працюєте за скрамом, подумайте про те, щоб виділити в кожному спринті 15-20 відсотків ресурсів команди на рефакторинг і виправлення недоліків створюваної ІТ системи. Інший спосіб – використовувати спеціальний технічний спринт для негайного усунення великого обсягу технічної заборгованості. Правда, це значно порушує правила скраму. Але ви самі вільні вирішувати, що вам важливіше – слідувати інструкції чи виправляти техборг швидко. Подумайте про те, наскільки усунення технічного боргу створює цінність вашому замовнику – в поточному і майбутньому спринтах. Навіть якщо ви не робите постачання готової нової функціональності, ви виправляєте глибинні проблеми в коді, що спрощує і здешевлює розвиток і підтримку ІТ системи. Хіба це не цінність? Ваш вибір буде залежати від обсягу, складності техборгу, лояльності замовника, готовності команди й наявності часу. Ну і пріоритетів, звичайно.
  3. Найпростіший спосіб накопичити технічний борг – це попросити занадто багато від ваших розробників в стислі терміни. Або ж коли менеджмент «грається в аджайл», хоче гнучкого змісту, але терміни змінювати не хоче. Тобто це про культ карго, а не про справжній аджайл. Тому при розробці дорожньої карти продукту слід консультуватися з інженерами, щоб переконатися, що ваші очікування щодо термінів відповідають їх оцінкам і розумінню реалістичних можливостей. І будьте готові піти на поступки щодо термінів і змісту. Інакше технічного боргу не уникнути. Також не зайвим буде визначення та узгодження з усіма зацікавленими сторонами та командою того, як повинен виглядати фінальний результат. Не слід вважати щось завершеним, поки воно не буде відповідати критеріям, за якими стейкголдери прийматимуть результати.
  4. Ще один спосіб зменшити технічний борг – його кількісна оцінка за допомогою метрик. Мета полягає в тому, щоб перетворити абстрактне поняття технічного боргу в щось, що можна виміряти, щоб члени команди могли відстежувати й аналізувати його «погашення». Команди можуть використовувати різні метрики: кількість дефектів за реліз, за спринт, т.зв. «дефекти-втікачі», тобто виявлені на бойовому середовищі після релізу, час циклу дефекту, швидкість відгуку на дефект – все це корисні метрики для моніторингу якості продукту. Покращення в даних показниках можуть зокрема свідчити про зниження технічного боргу, і навпаки. Загалом ці показники допоможуть командам точніше відстежувати технічний борг і заощадити час проєкту, якщо він буде поступово усуватися. Однак пам'ятайте, що неправильне використання метрик може привести до помилкового визначення завдань і цілей. Метрики слід використовувати в динаміці виключно для моніторингу загальної продуктивності й спостереження за поліпшеннями, а не як кінцеву самостійну мету.

Іноді буває складно визначити, яке рішення найкраще підходить для вашого випадку. Всього існує 3 робочих стратегії:

  1. Погашення боргу через рефакторинг коду, заміну фреймворка або платформи, які вважаються джерелом технічного боргу;
  2. Конвертація боргу: замініть поточне рішення «хорошим, але не ідеальним» рішенням. Це компромісний варіант, якщо створення ідеального рішення занадто дороге;
  3. Просто прийміть факт боргу, тому що рефакторинг може коштувати дорожче, ніж робота системи з недосконалим кодом. Особливо це стосується дуже старих корпоративних ІТ систем, що не мають критичного значення.

Однак усе-таки найкраще мінімізувати наслідки технічного боргу, пам'ятаючи про його причини й відповідні профілактичні заходи. Перераховані вище поради допоможуть вам впоратися з технічним боргом та одночасно поліпшити процеси створення нових результатів у вашому проєкті, в кінцевому підсумку покращуючи якість не тільки продукту, але і проєкту в цілому. Що не кажи, а в проєкті дві найприємніші речі – це успішні релізи та високий NPS від зацікавлених сторін! Чого і вам бажаємо!

 

СПИСОК ДЖЕРЕЛ:

  1. Technical debt: 5 ways to manage it
  2. Allie Dyer Bluemel (2020) Project managing your way through technical debt
  3. E.Wolff, S.Johann Managing Technical Debt

Усі дописи