Розмова про технічний борг зазвичай проходить за одним і тим самим сценарієм. Тімлід приходить до бізнесу й каже: «Нам потрібен рефакторинг». Що він має на увазі? Код розсипається, прод падає у критичні моменти, команда страждає.
А що чують представники бізнесу? «Ми хочемо витратити час і гроші на щось, що не приносить прибутку». На цьому діалог закінчується — сторони розходяться незадоволені одна одною.
Як це змінити? Треба правильно «продати» рефакторинг.
Визначте свою «систему координат»
Щоби бізнес до вас прислухався, треба знайти правильні аргументи. А для цього потрібно ідеально розуміти ваш проєкт і місце техборгу в ньому. Адже технічний борг — не абсолютне зло. Він по-різному виглядає залежно від моделі проєкту. І від цього залежить, які аргументи взагалі спрацюють.
В аутсорсі, наприклад, будь-яка розмова про рефакторинг виглядає як спроба «продати ще раз». Якщо подивитися очима замовника, це навіть логічно: він уже заплатив за цей код, а тепер ви приходите та пропонуєте переробити наново. Це більше схоже на подвійний чек, ніж на інвестицію.
В аутстафі інша крайність. Вас фактично не видно. Є віддалений CTO або менеджер, який дивиться на одну метрику — Jira. Скільки завдань закрито і з якою швидкістю. У цій системі координат будь-який рефакторинг — це просто уповільнення.
У стартапі своя реальність. Там техборг — це не помилка, а рішення. Ви свідомо жертвуєте якістю заради швидкості, бо інакше не виживете. Але якщо цей борг не контролювати, у якийсь момент система просто не витримує. І тоді йдеться вже не про код, а про гроші, які згоріли.
У продукті починає працювати час. Техборг поводиться, як іржа — тихо з’їдає швидкість. Сьогодні все ще нормально, але через пів року кожна фіча дається вдвічі важче. Начебто нічого критичного не сталося, але ви вже повільніші за конкурентів.
Коли ви це для себе чесно розклали, можна починати розмову про техборг. Бо аргументи, які працюють у продукті, проваляться в аутсорсі.
Тімлід — не Proxy, а API Gateway
Друга проблема, яка ламає комунікацію з бізнесом: тімлід просто передає скарги команди.
«Ми не встигаємо», «усе ламається», «код — лайно».
Тобто команда намагається донести, що працювати з таким техборгом стає дедалі складніше, і що в якийсь момент усе може впасти остаточно.
Тим часом бізнес думає: «Розробники ниють, шукають виправдання і не хочуть працювати швидше».
Очевидно, це не те що ви хотіли сказати. Але проблема в тому, що ви не продаєте, а просите. А бізнес не купує прохання. Він купує обґрунтування.
Тімлід не має поводитися як proxy. Його завдання — не просто передавати, а працювати як шлюз — API Gateway між двома світами, і перекладати біль команди мовою бізнесу. А бізнес розуміє тільки три речі: гроші, час і ризики.
Якщо ви не можете обґрунтувати рефакторинг без слова «чистий код» чи «краса» — ви не менеджер, а «сніжинка». Почніть роботу над техборгом з себе.
Алгоритм «продажу» рефакторингу
Щоб розмова перестала бути емоційною й почала працювати, потрібен простий протокол. Поки ви говорите «нам боляче» й «нам важко», це скарга, а не причина для змін.
Бізнес не реагує на емоції, він реагує на цифри. Тому важливо одразу переводити розмову в конкретику: що саме не так, скільки це коштує та що буде далі.
Такий підхід змінює вашу роль. Ви вже не скаржитесь, а пропонуєте рішення. І саме так «нам боляче» перетворюється на «ось вигідна пропозиція».
Крок 1. Опишіть проблему в термінах «гроші — час — ризики»
Починаючи розмову із замовником, забудьте фрази на кшталт «важко підтримувати», «прод впав» або тим більше «лайнокод». Є великий шанс, що саме ця людина колись цей код і приймала.
Одразу перекладайте на мову грошей, часу та ризиків.
Наприклад: «Через складність модуля кожна нова фіча займає на 40% більше часу. Це коштує компанії приблизно $2000 додаткових витрат щомісяця».
У цей момент ви починаєте говорити мовою, яку бізнес розуміє.
Крок 2. Покажіть, що буде, якщо нічого не змінювати
Бізнес не боїться самих проблем. Бізнес боїться їхнього погіршення.
Тому важливо показати динаміку.
Наприклад: «Якщо нічого не змінювати, через 3 місяці вартість змін подвоїться, терміни зростуть у 1,5 раза, а ризик падіння системи в пікові періоди стане критичним».
У цей момент ви переходите на мову продажів. Але продаєте не рефакторинг, а уникнення майбутніх втрат.
Крок 3. Запропонуйте мінімум два рішення
Якщо ви приходите з одним варіантом, це виглядає як ультиматум. І, найімовірніше, викличе опір. Тому важливо дати вибір.
Підготуйте щонайменше два варіанти: поступовий і кардинальний. Наприклад: поступове покращення або повний рефакторинг.
У цей момент це вже не ультиматум, а управління ризиками. Бізнес перестає захищатися й починає обирати.
Крок 4. Назвіть ціну входу
До кожного варіанту додайте конкретику: час і вартість. Наприклад:
«+20% до часу кожного завдання протягом кварталу (поступовий варіант), або повна зупинка розробки на один тиждень» (технічна пауза).
Це складний момент для багатьох, бо назвати реальну ціну страшно. Бізнесу вона, найімовірніше, не сподобається.
Крок 5. Покажіть ROI (окупність інвестицій)
І нарешті — найважливіше. Покажіть, що компанія отримає після рефакторингу. Наприклад:
«Після рефакторингу швидкість розробки зросте на 30%. Також знизиться залежність від конкретних розробників — модуль зможе підтримувати будь-хто в команді».
У цей момент ви продаєте не витрати, а інвестицію. І шанс отримати згоду різко зростає.
Але без цього рішення не буде.
Економіка кредиту: мова власника
Найпростіший спосіб пояснити технічний борг бізнесу — перестати говорити про код і почати говорити про гроші.
Опишіть техборг як кредит. Його колись узяли, щоби швидше випустити продукт. І це нормально. У більшості випадків це єдиний спосіб стартувати.
Будь-який кредит має дві частини: відсотки — це те, що ви платите щодня. Це баги, складність, повільна розробка, нерви команди. І тіло кредиту — власне, сам борг.
І ось ключова проблема: більшість команд роками платять лише відсотки й дивуються, чому нічого не змінюється. Точніше, змінюється, але в гірший бік.
Задача рефакторинга — не створити «чистий і красивий код». Вона в тому, щоб виплатити тіло кредиту й зупинити або хоча б суттєво зменшити постійний відтік ресурсів.
Коли ви пояснюєте це саме так, вас починають чути.
Висновок
Технічний борг — це нормальний стан будь-якого живого проєкту. Але ігнорувати його — це вже не технічна проблема, а управлінська помилка з фінансовими наслідками.
Хороший тімлід не скаржиться на борг, а керує ним: оцінює ризики, пропонує рішення й доводить їхню цінність.
У FoxmindEd, наприклад, ми вчимо тімлідів будувати цей «двосторонній API» між розробкою й бізнесом на реальних кейсах. Бо саме ця навичка перетворює інженера з витрати на партнера, який реально впливає на гроші.