Процеси, люди та культура: як побудувати ефективне управління техборгом. Досвід FAVBET Tech

У FAVBET Tech був період, коли технічний борг одного з модулів системи почав серйозно впливати на процеси. А саме на швидкість виходу на ринок і те, скільки коштує контроль якості продукту. У відповідь на це в компанії провели внутрішній системний аудит, проаналізували ситуацію за правилом Парето й розробили комплексну стратегію погашення боргу.

Зараз процес управління техборгом у компанії максимально чіткий: на нього виділяється до 20% часу кожного спринта. У результаті графік погашення технічного боргу нагадує графік акцій на NASDAQ – із січня крива йде вниз. 

Як на це впливає не тільки виділений час, але й культура ownership і ШІ-інструменти, у партнерському матеріалі розповідає CTO FAVBET Tech Андрій Черниш.

Чому з’являється технічний борг і чи можна його уникнути

Ми є продуктовою компанією, яка націлена на постійне зростання, тому метрика time-to-market (TTM) для нас критично важлива, а темп можна назвати шаленим. Ми постійно випускаємо нові ігри, розширюємо функціональність, робимо інтеграції, промо, UX-експерименти та A/B-тести. Але хочемо не тільки залучати нових клієнтів (acquisition), а й утримувати чинних (retention). Тож якість продукту і його надійність не мають страждати.

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

Коли треба десь «зрізати кут», зробити workaround або швидко щось випустити, ми можемо на це піти, якщо:

• немає великого впливу рішення на користувачів;
• немає ризиків для системи;
• ми можемо це виправити в коротко- або середньостроковій перспективі – максимум через три місяці.

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

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

Таке рев’ю ми маємо на всіх етапах і всіх рівнях. Відловлюємо болючі точки та заносимо їх у беклог. Також аналізуємо та перевіряємо роботу ще на етапі планування: що саме розробник планує робити – які нові API, інтеграції, схеми для бази даних. Ми перевіряємо такі речі, перш ніж починаємо писати код. 

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

Тож головний висновок такий: уникнути технічного боргу неможливо, але варто його контролювати. З мого погляду, ми робимо це досить успішно. Графік роботи з нашим технічним боргом зараз дуже схожий на графік акцій на NASDAQ: із січня все йде вниз. Бувають піки, але тенденція йде на зниження.

Далі розкажу, як саме ми це робимо.

Процес управління технічним боргом у FAVBET Tech

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

Потім ми зробили комплексне оцінювання технічного боргу цільового модуля. У цьому нам допомогло правило Парето (принцип 80/20). Ми поставили найвищий пріоритет тим завданням, які дозволили б у найкоротший період отримати максимальні поліпшення за потрібними нам метриками: TTM, якість, надійність.

Подібне оцінювання тепер відбувається в кожній команді та в кожному сервісі на регулярній основі. Команди виділили 20% часу в кожному спринті для того, щоб працювати виключно над усуненням технічного боргу.

Наразі ми контролюємо свій борг, не допускаємо його різкого зростання, постійно працюємо над його зменшенням. Але прагматично: погашаємо в першу чергу той борг, що має прямий вплив на важливі бізнес-метрики та нефункціональний стан системи. 

До процесу управління технічним боргом входять такі ключові етапи:

1. Ідентифікація техборгу – коли свідомо зрізаємо кути, ми це документуємо і створюємо завдання. За це відповідальні девелопери, архітектори та менеджери.
2. Регулярний системний аудит. Проводиться не рідше, ніж раз на квартал. Містить аналіз сервісів і систем на предмет несвідомого технічного боргу. Відповідальні – архітектори.
3. Регулярний перегляд наявного боргу, його оцінювання і пріоритизація в беклозі команд – раз на кілька спринтів. Відповідальними є менеджери, девелопери.
4. Усунення технічного боргу – ми виділяємо приблизно 20% часу в кожному спринті для роботи над технічним боргом або технічними поліпшеннями. Займаються цим менеджери, девелопери.
5. Презентація бізнесу: раз на квартал ми презентуємо бізнесу досягнення з покращення технічного стану продукту із чіткими показниками – як він впливає на важливі бізнес-метрики. За це відповідають менеджери й архітектори.

Еволюційний підхід замість революцій

Революційні зміни – це не частина культури FAVBET Tech. Ми не практикуємо швидкі, необдумані рішення, коли все переписується з нуля. Замість різких революцій ми постійно еволюціонуємо. Це помітно як за нашими сервісами, так і за культурними підходами в командах.

Яскравим прикладом такого еволюційного підходу є робота з надто великими модулями системи. Коли один з наших сервісів став надто громіздким через накопичені компроміси й узяв на себе забагато контексту й комунікацій, ми не стали його повністю відкидати й переписувати з нуля. Натомість застосували strangler pattern – підхід, що нагадує ліану, яка поступово обвиває дерево.

Спершу створили проксі-рівень, через який ішли всі запити на наш умовний моноліт. А потім ітеративно розбили його на менші частини. У кожній ітерації при цьому зробили наступні кроки: 

1. Ідентифікували частину функціональності, яку хотіли винести з того моноліту, як-от модуль реєстрації користувача.
2. Створили нову версію цієї частини як окремий сервіс або компонент.
3. На проксі-рівні перемикнули трафік на новий сервіс або одразу, або поступово, частинами, щоб прогнати A/B-тест:
   a. спрямували частину трафіку до legacy;
   b. частину – до нового коду.
4. Після успішного переведення всього трафіку на новий сервіс видалили непотрібну частину коду зі старого сервісу.

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

Як ми виявляємо проблемний код

Manual detection

Найкраще свій код знає сам девелопер. Тому ми будуємо культуру ownership. Тобто розробники мають не просто писати код у вакуумі, а розуміти, де та за яких умов він працюватиме, для кого він пишеться. Відповідно, розробники бачать місця, які можна було б змінити, і логують їх. Працює принцип Іf it hurts, log it. Далі ці логування перевіряють менеджери й архітектори. 

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

Static analysis

Кожен код ми перевіряємо на відповідність стилю, вразливості, ефективність. Є купа інструментів, які допомагають зробити це автоматизовано, у тому числі ШІ. Ми найчастіше використовуємо:

• лінтери для перевірки код-стайлу;
• статичні аналізатори коду для виявлення вразливих, неефективних рішень та коду.
• OLAMA / LAMA CPP – власноруч підняті моделі для аналізу коду на основі open-source-рішень.

Розглядаємо впровадження AI-асистенту для розробників Cursor, а також інструмент для AI-based code review qodo.ai (ex-Codium). 

Security audit

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

Покриття тестами

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

Постійний моніторинг нефункціональних показників системи у продакшен

Проблеми у продакшен, які мають прямий вплив на користувачів – очевидний сигнал попрацювати над кодом.

Архітектурний системний аудит

У компанії за системний стан відповідають архітектори. Вони дивляться на систему з helicopter view – оцінюють її загальну взаємодію, цілісність і відсутність каскадних залежностей, які можуть призвести до масових збоїв. Якщо одна частина системи не витримує навантаження і тягне за собою інші, то це системна проблема. Щоб виявити її, використовують хаос-тестування – випадково вимикають частини системи, щоб зрозуміти, де можуть виникнути критичні збої, та усувають ці вразливі місця до появи проблем у продакшені.

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

Ключовим аспектом нашого підходу є комунікація з бізнесом. Ми будуємо її так, щоб бізнес максимально швидко отримував фідбек. Це так званий feedback loop: бізнес приходить з ідеєю → ми її опрацьовуємо → даємо фідбек → бізнес використовує цей фідбек для запуску наступного циклу.

У нас нема потреби «продавати» бізнесу завдання з погашення технічного боргу. Це тому, що наша комунікація зі стейкхолдерами максимально прозора. Ми вказуємо на ризики, які беремо на себе у випадку перекосу в бік TTM і виникнення техборгу, наголошуючи на вартісних змінах у майбутньому і плануємо такі зміни одразу. По суті, ми з бізнесом partners in crime.

Щоб це працювало ефективно, рекомендую наступні підходи:

1. Перекладайте розмову про борг на бізнес-мову, вказуйте як на ризики його існування, так і на позитивні зміни при його погашенні.
2. Показуйте зміни у важливих для бізнесу метриках у форматі «до та після».
3. Не просто виділяйте частину часу на виправлення технічного боргу, а аргументуйте, як це позитивно вплине на бізнес.
4. Залучайте продактів до обговорення технічного боргу, оцінок і пріоритетів для відповідних завдань.
5. При нагоді формулюйте «боргові» завдання як фічі, які вплинуть на бізнес-метрики.

Культура та люди в управлінні технічним боргом

Навіть найдосконаліші процеси управління технічним боргом не працюватимуть без правильної культури та відповідальних людей. Одним з найбільших викликів для нас є пошук і розвиток фахівців із продуктовим мисленням і культурою ownership.

Знайти професіоналів, які по-справжньому відчувають відповідальність за свою роботу, непросто. Попри численні layoffs у галузі та велику кількість доступних фахівців на ринку знайти тих, хто дійсно підходить нашій культурі і здатний мислити продуктово, залишається складним завданням.

Щоб розв’язати цю проблему, ми діємо в кількох напрямах:

1. Вдосконалюємо процес наймання, а саме суттєво переглянули процес пошуку й інтерв’ювання людей, щоб зменшити кількість помилок при набиранні команди та підвищити ефективність наймання.
2. Внутрішня мобільність – ми розуміємо, що іноді людина може не підходити для конкретного проєкту, але має цінні навички для іншої команди. Тому ми практикуємо обмін фахівцями між командами, щоб найкраще використовувати таланти.
3. Постійне зростання – активно інвестуємо в розвиток наших людей, створюємо гільдії за технологіями, де фахівці можуть обмінюватися знаннями й обговорювати цікаві їм теми.
4. Культурні зміни – постійно працюємо над культурою компанії, хоча це і непростий процес. Не всі легко сприймають такі зміни, адже вони часто вимагають виходу із зони комфорту й додаткових зусиль.

Висновки та поради: що робити командам, які працюють у проєктах, що швидко зростають

Ось кілька правил, які я хотів би виділити при роботі з техборгом:

1. Не жертвуйте основами архітектури із самого початку, інвестуйте час у потенційні точки розширення системи, особливо якщо вже є інформація про наступні фази. Але все ж таки не забувайте про принципи KISS (Keep it simple, stupid! – чим простіше, тим краще) та YAGNI (You aren’t gonna need it – не реалізуйте те, що не потрібно).
2. Визначте межу прийнятного технічного боргу на березі, у вас мають бути ліміти допустимості компромісів.
3. Інвестуйте в тестування на рівні вашого коду. Розробники мають не лише писати код, але й тестувати його та розуміти, як, де і ким він буде використовуватись.
4. Робіть review і пріоритизацію не лише фічових завданнь, але й технічних поліпшень, боргу – це те, що часто напряму впливає на бізнес-метрики.
5. Слідкуйте за балансом швидкості розробки та якості і стабільності вашого продукту.
6. Тримайте прозору комунікацію з бізнесом і продактами, давайте конструктивний фідбек. Ви всі хочете одного – успішності і прибутковості вашого продукту.