Як ефективно запускати та вести нові проєкти? Етапи підготовки, кейси та поради від Favbet Tech

Єгор Чучва працює на позиції Delivery Manager у Favbet Tech і є одним із ключових фахівців, які відповідають за запуск і реалізацію проєктів. Він розповідає: «Кожен новий старт у компанії – як підготовка до перегонів: ще до початку потрібно мати детальний план, правильно підібрати команду та чітко розуміти, куди рухатися».

Команда Favbet Tech розробляє технологічну інфраструктуру для онлайн-платформ. За роки роботи тут навчилися запускати проєкти так, щоб вони приносили результат навіть у найскладніших умовах.

У партнерському проєкті Єгор Чучва ділиться підходом компанії до старту й ведення проєктів, розказує кілька історій із життя компанії та дає поради тим, хто хоче уникнути форс-мажорів і затримок.

Підготовка: етапи та рекомендації

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

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

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

Єгор Чучва

Delivery Manager

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

1. Валідуємо запит з менеджментом і даємо приблизний T-shirt-естімейт складності.
   
   Метод T-shirt-естімейт, або T-shirt sizing, дозволяє приблизно оцінити складність, обсяг роботи чи ресурсів, необхідних для виконання завдання. Замість того, щоб одразу давати детальну оцінку в годинах чи днях, команда на ранньому етапі аналізу визначає складність завдання в умовних «розмірах»:
   • S (Small) – маленьке, просте завдання, яке швидко виконується.
   • M (Medium) – середня складність, потребує помірних зусиль.
   • L (Large) – велике завдання, яке займе більше часу та ресурсів.
   • XL (Extra Large) — складний або масштабний проєкт.

   Іноді це можуть бути додаткові «розміри», наприклад, XS чи XXL.

2. Призначаємо проєктного менеджера й аналітика, які відповідатимуть за проєкт.
3. Узгоджуємо вимоги із замовником.
4. Формуємо технічну команду, план розробки і сфери відповідальності на кожному етапі.
5. Даємо фінальну оцінку і стартуємо.

Кейс: складнощі через перехід партнера на нову валюту

Щоб описати, як ми готуємось до проєктів і ведемо їх, візьму як приклад запит від партнера з Європи.

З 1 січня в країні, де працює наш партнер, мала відбутись зміна валюти. Як член ЄС вона прощалася зі своєю національною валютою та повинна була перейти на євро, а ми мали перевести всю систему – від балансів до транзакцій – на нову рівно о 00:00 за місцевим часом. Партнерський сайт мав працювати ідеально, інакше могли виникнути проблеми з регуляторами та користувачами.

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

Із чого почати роботу над проєктом

У нас є відділ бізнес-аналітиків, які разом із замовником з’ясовують усе до дрібниць. Ми не просто складаємо список необхідних кроків, а намагаємося зрозуміти, яку саме проблему це розв’зує.

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

Якщо це бізнес-проблема, то порівнюємо відповідні бізнес-метрики до та після реалізації проєкту. Ці цифри, як правило, уже є в нас у базі даних. Залежно від того, на що ми хотіли повпливати, вони можуть бути різними – середній депозит, кількість реєстрацій, кількість клієнтів, що використали новий функціонал, тощо.

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

Ми пропрацьовуємо всі сценарії. Що буде, якщо користувач зробить депозит за секунду до опівночі? А якщо сервер регулятора «зависне»? Ми моделюємо ці потенційні ситуації, щоб система поводилася стабільно.

Щоб не роздувати беклог, команда ділить вимоги на дві категорії:

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

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

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

Команда та розподіл завдань

Команда – це не просто набір професіоналів, а пазл, який треба скласти. У Favbet Tech фахівців вибирають залежно від модулів, яких стосується проєкт, і специфіки партнера.

Єгор Чучва

Delivery Manager

У кейсі зі зміною валюти у країні ми вибрали тих, хто вже знав локальні особливості й партнера. Також знадобились фахівці з баз даних (DBA) і команда, яка займається модулями збереження транзакцій, проведенням платежів та інтеграції з регулятором.

Але що, коли хтось раптом вибуває з команди? Якщо йде розробник, його обов’язки розподіляються між іншими. На такі випадки ми у Favbet Tech завжди готуємо універсальних фахівців. Для цього намагаємося робити максимально кросфункціональні команди та давати людям різноманітні завдання, в межах їхніх навичок, звісно. Такий фахівець постійно пізнає щось нове та розширює свою експертизу. І так більше шансів, що процес розробки не залежатиме від однієї людини.

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

Скільки живе проєкт

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

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

Як ми комунікуємо із замовником

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

Загалом ми робимо обов’язкову звітність за спринтом, а також регулярно узгоджуємо беклог завдань, які команда братиме на наступний етап. Щоб поліпшити процес розробки, відбуваються регулярні ретроспективи команди, куди також ми запрошуємо замовників.

Форс-мажори: як ми їх долаємо

Форс-мажори – це частина життя. Але підготовка і планування стають ключем до успіху. І абсолютно нормально, коли іноді на них витрачається більшість часу у проєкті. У кейсі з переходом на євро підготовка була левовою складовою успіху. У нас пішло три тижні на планування, але це врятувало від хаосу. Висновок: очікувано великий проєкт набагато краще, ніж «раптово» великий.

Не буду оригінальним, коли скажу, що для нас викликом і поштовхом для змін став ковід і початок повномасштабного вторгнення. Як не дивно, «завдяки» ковіду нам вдалося налагодити роботу команд у віддаленому режимі та мати постійний зв’язок з людьми, що згодом дуже допомогло.

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

5 порад компаніям, як виконувати проєкти без форс-мажорів і затримок

1. Плануйте ретельно. Час на підготовку надалі економить нерви та ресурси. Краще витратити тиждень на аналіз, ніж місяць – на виправлення.
2. Ставте головне запитання: навіщо? Команда, яка знає мету, пропонує ідеї і працює ефективніше.
3. Довіряйте цифрам. Метрики – ваш компас. У нас є дашборд, де я в будь-який момент можу побачити, що відбувається із проєктом. Поставте собі запитання: як рано ми зрозуміємо, що щось пішло не так? Чи є в нас метрика за останніми змінами в компанії чи команді? Чи можу я прямо зараз зрозуміти, що коїться із проєктом, якщо перейду лише за одним посиланням?
4. Будуйте команду.Команда – це вмотивовані люди з певним набором навичок, які здатні порозумітися між собою. Регулярні «один на один» допоможуть тримати руку на пульсі і вчасно зрозуміти зміни в мотивації людей та атмосферу в команді. Це дозволить не втрачати співробітників у розпал проєкту або приймати важливі рішення, попередньо підготувавши проєкт і команду до них.
5. Матриця ризиків – ваша страховка. Кожен проєкт – ризиковий. Рано чи пізно щось піде не так, але ви вже матимете план дій.