Є і буде завжди: як працювати з невизначеністю? Досвід у FAVBET Tech

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

«Зміни є і будуть постійно – це життя. І аналітик працює із цим на професійному рівні. Головне завдання аналітика – зменшення невизначеності», – пояснює Head of Product Management у FAVBET Tech Захар Христич.

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

Звідки береться невизначеність і хто її створює

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

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

При цьому бізнес дивиться на ініціативу через фінансову призму. Якщо фіча не дає прибутку або не сприяє зростанню, реалізовувати її немає сенсу.

Саме прибуток – головний фільтр. Бізнес-аналітик може запропонувати два варіанти реалізації:

• Один швидкий, але закриє потребу умовно на 90%.
• Другий повний, але значно дорожчий.

Часто вибирають перший варіант. Так ми мінімізуємо ризик, бо робимо швидко й одразу бачимо результат (тобто перевіряємо гіпотезу).

З іншого боку стоїть IT, тобто технічні фахівці. Вони так само мають свій вплив на фінальну форму вимог. Архітектори, девелопери або QA можуть подивитися на рішення і сказати: «Можна простіше» або «Це зробити неможливо, бо зачіпає критичні залежності». Іноді технічна команда пропонує взагалі інший підхід, який змінює початкову логіку реалізації. 

Процес реалізації ініціатив: чому зміни можливі на будь-якому етапі

У FAVBET Tech ми працюємо за SAFe (Scaled Agile Framework). У ньому є дві ключові одиниці планування:

1. Тримісячний продуктовий інкремент (PI).
2. Двотижневі спринти всередині нього.

Для прикладу: на кожен PI на команду з 20 аналітиків заходить близько 500 завдань, і ще приблизно 150 додаються вже у процесі. Ініціативи можуть бути різні за обсягом і складністю. Як-от це може бути розгортання нового партнера з усіма інтеграціями або створення нової воронки реєстрації, яка змінює логіку роботи на всіх платформах і вимагає синхронної роботи кількох команд.

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

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

Але навіть якщо рішення погоджене, зміни можуть з’явитися на будь-якому з цих етапів.

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

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

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

Як ми ухвалюємо рішення і тримаємо зміни під контролем

Головне – не факт змін, а те, як ми на них реагуємо.

Прийняття рішень завжди починається з оцінювання впливу. Ми дивимось:

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

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

 

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

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

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

Інструменти, підходи і практики для роботи з невизначеністю

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

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

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

Ще одна практика – обмеження на тривалість аналізу однієї задачі. Вона з’явилася після одного кейсу, що боляче по нас вдарив. Ми мали перенести legacy-систему в новий backoffice. Завдання здавалося нескладним: замінити інтерфейс, залишивши наявні API. Аналіз оцінили в 40 годин.

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

Ми також регулярно проводимо ретро, особливо після проблемних кейсів. Розбираємо, що пішло не так, на якому етапі, що можна було зробити інакше. Висновки обов’язково фіксуємо письмово.

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

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