Доверие вместо контроля: как в 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), который будет постоянно обновляться и давать больше вариантов и возможностей для развития.

Кстати, с внедрением AI-инструментов у нас появляются и новые роли. Например, раньше не было Data Annotators, а теперь есть. Это тоже одно из направлений, которое может заинтересовать сотрудников — и мы будем рады это предложить.

Вывод

Мы не ищем универсальных решений — мы адаптируем методологии под конкретные продукты и команды. И хотя вызовы остаются — нехватка кадров, необходимость баланса между структурой и гибкостью, поиск оптимальных путей развития для каждого специалиста — именно индивидуальный подход, доверие и открытая коммуникация позволяют нам двигаться вперёд.