Єгор Чучва працює на позиції Delivery Manager у Favbet Tech і є одним із ключових фахівців, які відповідають за запуск і реалізацію проєктів. Він розповідає: «Кожен новий старт у компанії – як підготовка до перегонів: ще до початку потрібно мати детальний план, правильно підібрати команду та чітко розуміти, куди рухатися».
Команда Favbet Tech розробляє технологічну інфраструктуру для онлайн-платформ. За роки роботи тут навчилися запускати проєкти так, щоб вони приносили результат навіть у найскладніших умовах.
У партнерському проєкті Єгор Чучва ділиться підходом компанії до старту й ведення проєктів, розказує кілька історій із життя компанії та дає поради тим, хто хоче уникнути форс-мажорів і затримок.
Зміст
Усе стартує із запиту від бізнес-партнера. Це може бути нова фішка для користувачів, оптимізація платформи чи адаптація. Але ми не просто беремо завдання та біжимо його виконувати.
Спочатку треба зрозуміти, яку проблему ми вирішуємо і для кого. Після отримання запиту бізнес-аналітики розбирають його на молекули. Вони з’ясовують, який біль або потребу користувача має закрити новий функціонал і як зробити так, щоб система працювала без сюрпризів.
Найважливіше – продумати всі сценарії використання. Якщо цього не зробити, на виході можна отримати продукт, що має хороший вигляд, але падає при першому ж реальному тесті.
Тривалість кожного з етапів підготовки до проєкту залежить від його масштабу. Маленький функціонал можна розібрати за тиждень, а щось глобальніше – це місяці роботи. Але підготовка – це не лише аналіз вимог. Ось кілька ключових етапів:
Іноді це можуть бути додаткові «розміри», наприклад, XS чи XXL.
Щоб описати, як ми готуємось до проєктів і ведемо їх, візьму як приклад запит від партнера з Європи.
З 1 січня в країні, де працює наш партнер, мала відбутись зміна валюти. Як член ЄС вона прощалася зі своєю національною валютою та повинна була перейти на євро, а ми мали перевести всю систему – від балансів до транзакцій – на нову рівно о 00:00 за місцевим часом. Партнерський сайт мав працювати ідеально, інакше могли виникнути проблеми з регуляторами та користувачами.
Не було жодного перехідного періоду, жодної можливості провести хоча б одну операцію у старій валюті після дедлайну. А ще був державний регулятор, який у реальному часі перевіряє кожну транзакцію та вимагає синхронізації зі своєю системою. Помилка могла спричинити великі штрафи, втрату довіри користувачів або навіть відключення платформи.
У нас є відділ бізнес-аналітиків, які разом із замовником з’ясовують усе до дрібниць. Ми не просто складаємо список необхідних кроків, а намагаємося зрозуміти, яку саме проблему це розв’зує.
Відповідно до цього метрики вже приходять на думку самі, залишається сформувати план розв’язання цієї проблеми – за допомогою якогось нового функціоналу чи оптимізації наявного коду, наприклад.
Якщо це бізнес-проблема, то порівнюємо відповідні бізнес-метрики до та після реалізації проєкту. Ці цифри, як правило, уже є в нас у базі даних. Залежно від того, на що ми хотіли повпливати, вони можуть бути різними – середній депозит, кількість реєстрацій, кількість клієнтів, що використали новий функціонал, тощо.
У кейсі зі зміною валюти була важливою і метрика часу, який треба витратити на перехід в ніч із 31 грудня на 1 січня. Тому при подібних міграціях ми завжди проводимо попередній «прогін» в окремому середовищі, щоб максимально точно спрогнозувати, скільки часу потрібно на всі процедури. Також дивимось на стабільність платформи після такого переходу, наявність необхідних звітів для регулятора в новій валюті та чи відповідає кількість транзакцій і сум умовам.
Ми пропрацьовуємо всі сценарії. Що буде, якщо користувач зробить депозит за секунду до опівночі? А якщо сервер регулятора «зависне»? Ми моделюємо ці потенційні ситуації, щоб система поводилася стабільно.
Щоб не роздувати беклог, команда ділить вимоги на дві категорії:
Такий підхід дозволяє спочатку запустити базову версію продукту, а потім допрацьовувати її за фідбеком користувачів. Він схожий на будівництво будинку: спочатку фундамент і стіни, а потім уже декор і меблі.
У проєкті з переходом на євро «критично необхідним» було перевести баланси і транзакції на євро. «Бажаним» стало інформаційне повідомлення на сайті й у мобільному застосунку, які попереджали користувачів про технічні роботи й недоступність платформи.
Команда – це не просто набір професіоналів, а пазл, який треба скласти. У Favbet Tech фахівців вибирають залежно від модулів, яких стосується проєкт, і специфіки партнера.
У кейсі зі зміною валюти у країні ми вибрали тих, хто вже знав локальні особливості й партнера. Також знадобились фахівці з баз даних (DBA) і команда, яка займається модулями збереження транзакцій, проведенням платежів та інтеграції з регулятором.
Але що, коли хтось раптом вибуває з команди? Якщо йде розробник, його обов’язки розподіляються між іншими. На такі випадки ми у Favbet Tech завжди готуємо універсальних фахівців. Для цього намагаємося робити максимально кросфункціональні команди та давати людям різноманітні завдання, в межах їхніх навичок, звісно. Такий фахівець постійно пізнає щось нове та розширює свою експертизу. І так більше шансів, що процес розробки не залежатиме від однієї людини.
А іноді варто йти на радикальні кроки. Для великих проєктів, які потребують ресурсів багатьох команд, ми створюємо «ударні групи»: беремо фахівців одночасно з різних команд і синхронізуємо їх в онлайні. Так було з оптимізацією платформи для нового партнера: замість двох спринтів усе зробили за п’ять днів. Дорого, але бізнес отримав результат раніше.
Тривалість проєкту залежить від його мети й зовнішніх факторів. Дрібні доопрацювання зазвичай займають два-три тижні. Середні проєкти, такі як оптимізація модуля платежів, – до двох місяців. А глобальні зміни, як у випадку переходу на євро, – півтора-два місяці. Є й довгожителі: наприклад, підтримка платформи для партнера може тривати роками, бо це передбачає постійну оптимізацію.
Усе залежить від масштабу, пріоритетів бізнесу та зовнішніх умов. У кейсі зі зміною валюти дедлайн диктувало законодавство. А буває, що проєкт затягується через зворотний зв’язок від користувачів: спочатку запускаємо базу, потім додаємо фішки. Наприклад, після переходу на євро ми ще місяць допрацьовували звіти за побажаннями партнера.
Ми продуктова компанія та маємо дуже гарні відносини з бізнес-замовниками. Іноді здається, що в нас замовники вже як частина команди. Вони без проблем можуть прийти на дейлі-мітинг команди для того, щоб послухати поточний стан справ або донести якийсь свій апдейт. Це допомагає швидко коригувати план і робить увесь процес прозорим.
Загалом ми робимо обов’язкову звітність за спринтом, а також регулярно узгоджуємо беклог завдань, які команда братиме на наступний етап. Щоб поліпшити процес розробки, відбуваються регулярні ретроспективи команди, куди також ми запрошуємо замовників.
Форс-мажори – це частина життя. Але підготовка і планування стають ключем до успіху. І абсолютно нормально, коли іноді на них витрачається більшість часу у проєкті. У кейсі з переходом на євро підготовка була левовою складовою успіху. У нас пішло три тижні на планування, але це врятувало від хаосу. Висновок: очікувано великий проєкт набагато краще, ніж «раптово» великий.
Не буду оригінальним, коли скажу, що для нас викликом і поштовхом для змін став ковід і початок повномасштабного вторгнення. Як не дивно, «завдяки» ковіду нам вдалося налагодити роботу команд у віддаленому режимі та мати постійний зв’язок з людьми, що згодом дуже допомогло.
Буває, що проєкт зупиняється через зовнішні фактори. Найчастіше це пов’язано зі змінами в законодавстві чи кон’юнктурі ринку в локації, для якої ми готуємо проєкт, або змінами у провайдера послуг у випадку інтеграцій. Ми намагаємося детально попередити такі випадки на етапі аналізу вимог – щоб кількість уже витраченого ресурсу на проєкт була якомога меншою. Але ми не можемо на 100% уникнути таких ситуацій. Іноді просто потрібно зупинити проєкт і зосередитися на чомусь актуальному.