“Ти знаєш, який у нас тех. борг?” – питання, яке одного разу чує кожен продакт і ситуація, в яку потрапляє кожен продукт. Розберемося сьогодні, чому до певного моменту в цьому нічого страшного, що трапляється, коли він настає, і як мінімізувати ймовірність такого настання.
Технічний борг – накопичені в технічному боці продукту невірні програмні рішення (у вигляді кривого коду та архітектури), які можуть вам дуже завадити в подальшому розвитку та масштабуванні продукту, обмеживши ваші можливості з розширення користувацького функціоналу.
Зазвичай, команда розробки дотримується побудованої раніше логіки/архітектури коду і підлаштовує під неї і подальшу розробку. Таким чином, побудоване коли-небудь нашвидкуруч криве рішення, зі зростанням продукту/бази, починає обростати великими зв’язками й умовами, які будуються на кривому рішенні.
І якщо його будують на кволій архітектурі та логіці, то, за теорією ймовірності, одного разу все почне працювати НЕ ЯК ПОТРІБНО, а як… дозволяють обмежені можливості (ще й спадаючі).
Для вимірювання тех. боргу немає чіткої метрики, але гадаю, що відсотки, які накопичуються за таким боргом, пропорційні відсотку недалекоглядності продакту і його розробників.
Я для себе виділяю три види тех. боргу:
Допустимий або усвідомлений борг
Коли обсяг тех. заборгованості ще ні на що не впливає і його можна досить швидко ліквідувати протягом допустимого для команди/бізнесу періоду часу, яка ще усвідомлює.
Це ідеальний і збалансований вид боргу, коли команда розуміє і пам’ятає, що поточні милиці зроблені для пришвидшення розробки, і нічого нового та масштабного надбудовувати НАД такими милицями не можна.
Наростаючий тех. борг
Виникає, коли команда все ж таки починає розвиток функціоналу продукту й архітектури на працюючих милицях, підлаштовуючи нові рішення під особливості цих милиць, відмовляючись від більш ефективних технічних рішень.
Обсяг заборгованості вже починає позначатися на реалізованих варіантах тех. рішень, поки що у вигляді фраз “саме так зробити ___ не вийде, тому що в нас ___, але можемо зробити по іншому”.
І так, це робиться, працює, але технічно рішення сильно прив’язане до тієї самої початкової милиці. Далі вже дві, три… п’ятнадцять користувацьких фіч (коду), надбудованих над кривим рішенням, жорстко прив’язані до нього і ⇒ обмежені на рівні функціональних можливостей коду ⇒ обмежують UX/UI-механіки ⇒ обмежують продукт.
Уже на цій стадії потрібно замислитися над майбутнім і тверезо оцінити можливі ризики (писав про ризики тут), і якщо поточний статус розвитку продукту і плани на найближче майбутнє дають змогу взяти 1-2-3 місяці на рефакторинг, то, найімовірніше, це потрібно зробити.
Критичний або безповоротний борг
Те, до чого, зрештою, одного разу і можна прийти. Обсяг заборгованості вже такий, що беклог частіше забарвлений у червоний колір баг-репортів, а кожен новий рядок фікс-коду породжує ще Х2 рядка (у найкращому разі) або упускає систему вже на новій помилці, яка виникла, у все тій же кривій логіці коду, що розрісся з роками.
Це, насправді, бич більшої частини великих IT-продуктів, де підтримка поточної працездатності коду починає забирати практично весь час команди розробки.
Подивіться на Skype, Google, Facebook. Їхні ключові продукти генерують гроші, але… стоять у розвитку на місці. Вони гальмують, у них іноді миготять елементи з дизайну 2000-х, вони не гнучкі, у них немає API з однієї простої причини – у пріоритеті підтримка поточної працездатності та рефакторинг коду й інтерфейсів, що швидко старіють. Думаю, що, напевно, через цей самий фактор вони купують молоді стартапи, техборг яких ще вкрай малий, і їх легше поглинути, вбудувавши у свою і без того складну систему.
Поради щодо зменшення технічного боргу
Якщо серйозних боргів немає, то завдання продакта – утримувати себе, продукт і команду в рамках усвідомленого технічного боргу, об’єктивно розуміючи, коли ті чи інші милиці доречні, корисні й допомагають виграти вам і продукту час, а коли стануть бомбою відкладеної дії.
Думай на майбутнє
Продакт-менеджер як ніхто інший повинен розуміти, що з себе представляє продукт як поточне і можливе рішення користувацької проблеми.
Думай про гнучкість його застосування користувачами, аналізуй контекст, у якому вони використовують продукт, і не бійся думати про те, для чого ще вони можуть його застосувати (загальні та приватні user cases). Розуміння цих речей покаже тобі всі можливі зв’язки між твоїм продуктом і проблемами та діями користувачів, що існують або можуть з’явитися в майбутньому.
Повідомляй команді про майбутнє
Фраза, яку має використовувати кожен продукт-менеджер у постановці завдань для команди розробки на нові фічі в продукті:
Розробити з урахуванням _____.
Працює просто – якщо ви ставите завдання на розробку нової фічі і ви, як PM, розумієте, що вона за механікою пов’язана або може бути в найближчому часі пов’язана з іншими (і, можливо, навіть з будь-якими очікуваними фічами в продукті), то не полінуйтеся зайвий раз звернути увагу ваших розробників на це.
У такий спосіб ви знизите ймовірність того, що вони запилять щось суворо за завданням, що працюватиме зараз, але потенційно погано з майбутніми розробками, які ще у вас у голові/далеких сторіс.
Дружи з тим, хто відповідає за архітектуру і логіку
Тому що це саме та людина, яка і буде відповідати за те, як в кінцевому рахунку буде реалізована фіча або тимчасова милиця.
Проговори з нею мовою користувацьких кейсів про те, як має працювати фіча/милиця зараз/в ідеалі/в майбутньому. Зрозумій, що розробники працюють не з живими людьми, а бездушним кодом, який підпорядкований правилам математики, а не користувацьких емоцій. Пояснюючи на конкретних прикладах, ти малюєш у своїй та їхній голові яснішу картину, яка далі і втілюється в користувацьких механіках і, як наслідок, красивішу і зрозумілішу всім логіку коду.
Документуйте користувацьку логіку і код
За замовчуванням це має робитися в сторіс, але дуже часто дрібні деталі описуються саме в складових тасках, які часто губляться разом з описаною логікою, тому не лінуйся ще раз прописувати в сторіс усю логіку роботи фічі, переконавшись, що всі учасники вірно трактували терміни, а також порядок та глибину користувацьких дій в рамках цього завдання.
Три головних НІ, щоб не збирати тех. борг:
- не збирати милиці;
- не забувати своєчасно позбуватися їх;
- не починати до цього будь-які серйозні інтеграції та розробку.
Що робити якщо вже встряли?
- Визнайте хворобу.
Усе як у медицині – якщо хвороба заважає жити і розвиватися, то потрібно визнати факт хвороби і погодитися на її подальше лікування. В ідеальному світі – усунення боргу це гарний привід заново переглянути і поліпшити процеси, за якими працює продукт.
Доведеться посилено попітніти з СТО і командою за розробкою повноцінного плану дій, який можна умовно розбити на такі етапи:
Ставимо цілі за заборгованостями: “Скоротити час завантаження сторінки пошуку до 1 секунди → Чекаємо зростання корис. дій”, “Рефакторинг для запуску API (складова з двох сторіс) → 10 підключених до API клієнтів”, “Переїзд на на Laravel 8.0 → Оновлення моделі платної передплати до Freemium зі зростанням обороту на 20%”.
Документування. Насамперед (і найголовніше), потрібно зібрати реальну картину з архітектурою і логікою того, що ви з командою вирішили оптимізувати. Доведеться карбувати код, попутно перевіряючи його роботу на продакшені, згадуючи на практиці “а як у нас все працює ___”. Раджу описувати це як повноцінні користувацькі міні-кейси, щоб у новій версії їх можна було швидше знайти, відтворити і перевірити.
- Аналітика.
Зібравши всю інфу і прогнавши її на кейсах, дивимося заново/з нуля на свій продукт як на кінцевий інструмент для користувача, вивчаючи його слабкі сторони, аналізуючи можливі причини та їхній зв’язок між собою і пропонуючи варіанти щодо поліпшення виявлених проблемних місць.
- Планування.
Переосмислюємо інфу, вибираємо нові підходящі варіанти без конфліктів із чимось, оновлюючи сторіс і механіку роботи фічі/коду.
- Реалізація.
Окремі спринти, переформована команда, окрема гілка – гадаю, програмісти і без нас знають що і як там робити.
- Тести та перевірка.
Без них нікуди і тут знову знадобляться міні-кейси з пункту №2. Дивимося старі механіки, знаходимо, проганяємо, порівнюємо з новими.
- Пост-аналітика.
Дивимося в цифри і метрики з №1, порівнюємо з власними відчуттями. Якщо щось не так, починаємо з №4.
Повторюся, що багато етапів і моментів пов’язані саме з хлопцями з команди розроблення, яким більше видніше, як планувати і проводити рефакторинг коду. Завдання продакту – дати якомога більше інформації про те, як застосовується і може застосовуватися користувачами ваш продукт.
Думаю, що дотримуючись прозорості та діалогу з командою, обговорюючи зрозумілою мовою конкретні призначені для користувача механіки, будь-якій команді цілком до снаги стримувати свій тех. обов’язок у межах допустимих лімітів.
