ВІКТОРІЯ ФЕФЕЛОВА
Chief People Management Officer
Поняття “технологічного боргу в ІТ” сприймається новачками або не дуже досвідченими фахівцями, як щось неприємне, як те, з чим обовʼязково треба боротися. Натомість у світі бізнесу боргові чи кредитні кошти можуть стати корисним інструментом для масштабування бізнесу. Але і в ІТ, і у бізнесі борг допомагає швидше досягнути короткострокової мети, взявши на себе певні зобовʼязання.
Якщо технічний борг у розробці програмного забезпечення буде накопичуватися, то з часом він буде заважати команді у поточній діяльності. Тобто, як і фінансовий борг, він має свої відсотки — чим довше він триває, тим дорожчим він стає.
Саме те, як ІТ-фахівці володіють стратегією управління технологічним боргом, визначає, як це вплине на кінцевий продукт. Розуміння цінності якісного коду та довгострокового підходу до розробки є одним з критеріїв, який враховується, коли ми відкриваємо ІТ-вакансії та шукаємо спеціалістів.
У цій статті ми розповідаємо, що таке технічний борг, які існують його типи та причини виникнення, а також ділимося порадами, як ефективно ним керувати.
Що таке технологічний борг в ІТ та чому він виникає?
Ідея технічного боргу добре розкрита у роботах американського інженера-програміста Стіва МакКоннелла, зокрема у його книзі “Rapid Development: Taming Wild Software Schedules”.
МакКоннелл описував ситуації, коли розробники свідомо йдуть на компроміси задля швидшої реалізації продукту.
На основі його ідей можна виділити кілька узагальнених причин виникнення технічного боргу:
• Тиск дедлайну — потреба швидко випустити продукт змушує знижувати якість коду.
• Невизначеність вимог — через неповну інформацію про продукт приймаються тимчасові рішення, які згодом доводиться переробляти.
• Еволюція системи — із розвитком проєкту нові частини коду не завжди гармонійно поєднуються зі старими.
• Обмежений досвід або знання — на початку роботи команда не знає, як зробити краще, тому створює рішення, які з часом виявляються неефективними.
• Застарілі архітектурні рішення — навіть якісно розроблений продукт може старіти, якщо технології швидко змінюються.
Подальше висвітлення концепції технічного боргу у командах розробки пізніше зʼявилося у роботах британського інженера-програміста Мартіна Фаулера. Він запропонував одну з найвідоміших класифікацій цього явища, яка використовується й дотепер.
Мова йде про навмисний/ненавмисний та усвідомлений/безрозсудний технологічний борг в ІТ.
Комбінація цих чинників утворює чотири типи технічного боргу, кожен з яких має свої причини та ризики:
1. Усвідомлений та навмисний борг
Це дія, на яку команда йде свідомо та з розумінням наслідків технічного боргу. Розробники знають, що зараз спрощують щось, але мають план повернутися й усе виправити.
Наприклад, такий технічний борг у стартапах може бути стратегічним рішенням: коли потрібно швидко випустити продукт на ринок або продемонструвати прототип інвесторам. Цей тип є виправданим, якщо існує чіткий план його зменшення.
2. Усвідомлений та ненавмисний борг
Цей тип боргу виникає через розвиток технологій та покращення експертизи у команді. Наприклад, ви з колегами створили код, який на момент розробки здавався оптимальним, але згодом виявилося, що існують ефективніші підходи.
Іншими словами, борг зʼявляється не через недбалість фахівців, а через певний рівень досвіду чи доступних рішень.
3. Безрозсудний та навмисний борг
Найпроблемніший борг, який утворюється, коли команда свідомо робить неправильні кроки та не планує їх виправляти. Такі рішення можуть прийматися через тиск дедлайнів або через байдужість команди до якості коду.
Фаулер порівнює цей борг з ситуацією, коли людина усвідомлено бере позику під величезні відсотки, але не думає, як буде її повертати.
4. Безрозсудний та ненавмисний борг
Найнебезпечніший тип, коли команда навіть не усвідомлює, що створює борг, оскільки не має достатньо досвіду, знань тощо. Розробники можуть щиро вважати, що знають, як уникнути технічного боргу, але їхні дії виявляються неефективними. Тобто проблема виникає не тільки через якість розробки, а й через недостатній контроль роботи.
І МакКоннел і Фаулер популяризують думку про те, що ефективне управління технологічним боргом — це частина здорового процесу розробки програмного забезпечення.
5 практичних способів зменшення технічного боргу в проєктах
Щоб не опинитися у ситуації, коли кожна нова функція стає ризиком для коду, що існує, важливо ще на початку роботи над продуктом встановити певні стандарти для роботи з технічним боргом.
Ось кілька порад, які можуть вам допомогти:
1. Закладайте час на регулярне виправлення старого коду
Ви знаєте, що ідеального коду не існує і навіть якщо ви обрали найкраще рішення, то з часом воно все одно потребуватиме покращення. Регулярний рефакторинг коду дозволяє запобігати накопиченню боргу та зменшує ризики масштабних проблем у майбутньому.
2. Встановіть чіткі стандарти для написання коду та дотримуйтеся їх
Коли кожен у команді використовує власний підхід, стає важко зрозуміти чужу логіку, проводити тестування чи виправляти помилки.
Важливо створювати код, який буде відповідати внутрішнім стандартам, адже окрім зменшення ймовірності виникнення технічного боргу, це ще й спрощує онбординг нових працівників.
3. Намагайтеся не допускати Scoup Creep
Scoup Creep — це неконтрольоване зростання обсягів проєкту, коли нові вимоги та функції додаються вже після початку роботи над продуктом.
Проте кожне нове рішення може потребувати серйозних змін у вже написаному коді, а його реалізація може призвести або до затримки дедлайнів або до технічного боргу. Що варто робити?
• чітко фіксувати, що входить у поточний реліз;
• записувати нові ідеї;
• не змінювати вимоги посередині спринту без вагомих причин.
4. Використовуйте ШІ-інструменти з розумом
Інструменти на кшталт GitHub Copilot дійсно можуть прискорити розробку, автоматизувати рутинні завдання та у цілому стати корисними помічниками. Однак ШІ не знає, що саме потрібно вашому проєкту і без чітких інструкцій буде пропонувати рішення, котрі створені на здогадках.
Тож для попередження ризиків технічного боргу через ШІ варто завжди перевіряти згенерований код та фіксувати усі зміни, внесені за допомогою штучного інтелекту.
5. Думайте про технічний борг, як про частину продукту
Деякі ІТ-компанії цілеспрямовано лишають певний відсоток часу на роботу з технічним боргом, це може реалізовуватися через “боргові” спринти або cleanup day, коли покращенню коду присвячують цілий спринт або окремий день відповідно. Такий підхід допомагає не відкладати борг на невизначений термін і покращувати його поступово, а не тоді, коли дедлайни вже палають.
І найголовніше — важливо працювати з технічним боргом свідомо, щоб він не накопичувався, а контролювався.
У Computools ми цінуємо командну співпрацю та прагнення до постійного вдосконалення.
Якщо вам відгукуються наші цінності, запрошуємо стати частиною команди.
Дивіться актуальні ІТ вакансії, або одразу заповнюйте форму та очікуйте на повідомлення від наших спеціалістів з відділу рекрутингу.
