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