Довіра замість контролю: як у FAVBET Tech керують командою та мотивують її

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

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

Як ми в FAVBET Tech формуємо команди

Я обіймаю посаду CBDO від початку 2025. До того понад три роки був Head of Delivery. 

Забезпечити delivery – значить, упевнитись, що продукт, який ми розробили, повністю відповідає очікуванням кінцевого клієнта та розв’язує його проблему. Тому команда Head of Delivery присутня на кожному етапі розробки: від моменту, коли ідея тільки з’явилася, до її формування спочатку в задачу, а потім набір коду та безпосередньо продукт чи фічу.

Віталій Сілаєв

CBDO у FAVBET Tech

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

Розуміння не тільки що, а й навіщо – надзвичайно важливе для того, щоб люди відчували себе причетними до бізнесу та мали мотивацію створювати щось для його розвитку. У FAVBET Tech працює близько 400 людей. Тому в керівників є два шляхи: впроваджувати системи контролю та «важкі» процеси або довіряти. Ми вибираємо другий.

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

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

Водночас ми ніколи не формуємо команди з більш ніж 10 фахівців. Це стандартне правило в Agile-практиках, і нам воно підходить. Якщо людей більше, починає губитися інформація з їхніх комунікацій. А якщо почати ці комунікації документувати, це сповільнить процеси. Тож вибираємо гнучкість і маленькі команди.

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

1. Усі необхідні ролі та люди в командах, які можуть перетворити ідею в реальність. 
2. Залученість команди до процесу розвитку продукту, фідбеків клієнтів, аналітики продукту.
3. Можливість впроваджувати свої ідеї, повʼязані з поліпшенням як технічних питань, так і самого продукту.

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

Різні методології під різні команди і проєкти

У більшості випадків вибір методології залежить від стадії проєкту:

• Інколи на початку потрібен Waterfall – просто пройти задачі крок за кроком.
• Коли проєкт швидко розвивається та потрібні такі самі швидкі фідбеки від клієнтів і продакт-оунерів, гарно спрацьовує Agile і Scrum.
• На фінальних стадіях, коли вже відбувся запуск нового продукту й потрібно швидко  пофіксити всі звернення клієнтів, які були на старті, можна використати Kanban.

Може бути і якась експериментальна методологія. Наприклад, два роки тому ми створили окремий R&D-підрозділ, щоб пропрацьовувати там гіпотези та ідеї, які виникають у продакт-менеджерів. Якби для нього ми використовували жорсткий структурний підхід, то вперлися б у чітке розподілення ролей, а для експериментів треба ініціативніші команди. Тож ми дали їм цю свободу, і за два роки змогли запустити вісім нових продуктів.

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

Ще один виклик у тому, що над нашим основним продуктом працює найбільша кількість команд – понад 30. Їх треба синхронізувати таким чином, щоб їхні задачі не повторювались і 2–3 групи банально не робили те саме. Для цього впровадили механіки SAFe (Scaled Agile Framework). Долучали спеціальних консультантів і проводили корпоративне навчання.

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

Як наймаємо та будуємо відносини зі тиммейтами

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

1. Наймати людей з відповідними софт-скілами.
2. Правильно будувати відносини з тими, хто вже працює в компанії.

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

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

Також ми сформували команду People Partners, яка допомагає нам комунікувати й чути фідбеки.

У нас є декілька каналів комунікації:

• Зустрічі one-to-one. Регулярно проходять для кожного фахівця з його менеджером.
• PDP (Personal Development Plan) та Performance Review. Хоча ця активність більше про постановку цілей, її обовʼязковим пунктом є фідбеки. Зараз працюємо над тим, щоб співробітник у режимі реального часу міг бачити як обробляють його відгуки і пропозиції.
• Активність на рівні команд (ретроспективи та дейлі). На ретроспективах дивляться більш широко, на дейлі – більш точково: в обох випадках учасники команд можуть поділитися тим, що пішло не так і чи потрібна допомога.
• Ретроспективи на рівні всіх команд компанії. Відбуваються кожні три місяці після планування – дивимося, чи добре спрацювало минуле планування, яких команд не вистачає, де потрібні структурні зміни, де краще проробити задачі, виділити пріоритети тощо.
• Опитування. Це й анкети про рівень задоволеності роботи в компанії, і 360, й інші HR-опитування.

Тільки запитати людей про проблеми – недостатньо. Треба прищеплювати культуру фідбеків. Тому що спочатку відповіді на наші HR-опитування виглядали схоже: усіх усе влаштовувало. І це, звичайно, не давало ніякої інформації. Але коли люди побачили перші розв’язані питання (що базувались навіть на невеликій кількості запитів на поліпшення), вони зрозуміли, що це ефективний інструмент змін, і почали надавати відкритий фідбек.

Що впливає на мотивацію співробітників

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

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

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

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

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

3 основні виклики управління командою

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

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

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

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

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

Наприклад, сапорт хоче стати розробником. Ми відкриті до цього і готові допомагати, але таку підтримку неможливо масштабувати без career path, який буде постійно up-to-date давати більше можливостей вибору і варіантів розвитку співробітникам.

До речі, із впровадженням ШІ-інструментів у нас з’являються й нові ролі. Наприклад, раніше не було Data Annotators, а зараз є. Відповідно, це один з напрямів, які хтось може захотіти спробувати, і ми їм це запропонуємо.

Висновок

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