Как мы сократили time to market на 17%, не выжигая команду и не теряя в качестве

В стартапах на счету каждая секунда: чем быстрее выйдешь на рынок, тем больше шансов стать единорогом, а не очередной строчкой в списке таких амбициозных, но не взлетевших проектов. Но при этом скорость выхода на рынок не покроет критичные ошибки в коде и неюзабельный интерфейс. В этом кейсе расскажем, как мы сокращали time to market в разработке мобильных приложений для одного из первых BNPL-сервисов Подели.

Разделяй и оплачивай

По итогам 2024 года российский рынок BNPL-сервисов приблизился к отметке 300 млрд рублей. Если в 2022 доля оплат таким способом составляла 1% e-commerce, то в 2024 приближается к отметке 1,8 %. Популярность оплаты частями растёт, при этом  у подобных FinTech-решений ещё много пространства для развития

В этом кейсе мы, команда аутстаф-разработки SimbirSoft, вспоминаем, как в далёком 2022 помогали сервису Подели выходить на рынок, не теряя в качестве и не выжигая команду. Мы зашли в проект не с нуля: до нас над запуском работало две аутстаф-команды, которые справилась со сроками и запустили проект за 3 месяца. Но разработчики мобильного приложения не справились с дальнейшим развитием: тестированием ключевых фич, дизайном и кодом, который отвечал за бизнес-логику.

Наша работа над мобильным приложением началась в апреле 2022 года. Коллеги из Подели знали, что у нас большой опыт работы с банковскими приложениями и экспертиза в области кибербеза. За это время мы накопили стандарты безопасности и чек-листы, которые работали как часы.

Влетаем в проект

Часть задач ребята из Подели делали внутри. Например: 

1. Адаптация и расчёт графиков платежей: поскольку оплата покупки распределена на несколько периодов, сервис должен предоставлять клиенту возможность легко адаптировать график платежей. Например, чтобы платеж списывался после получения зарплаты, или использовались другие удобные для пользователя сценарии. 

2. Процессинг платежей и методы аутентификации: BNPL-сервис отличается от сервисов рассрочки и кредита, но его внутренняя структура не менее сложна, несмотря на видимую простоту. 

3. Скоринговые модели и отражение фрод-атак: подобные сервисы сопряжены с высокими рисками, в процессе разработки необходимо было предусмотреть меры по их снижению. В Подели этими задачами занимается команда по управлению рисками и отдельный модуль в программном комплексе.

Подели занимались архитектурой, бэклогом и разработкой своей части задач, а нам предстояло: 

1. Исправить баги во фронтенде мобильного приложения: разработчик, который работал над MVP до нас, завершил работу за 4 месяца. Ему пришлось жертвовать этапами тестирования, оперативно изменять дизайн и добавлять временные решения в код. Внешние изменения негативно влияли на внутреннюю бизнес-логику, это опасно для финансовых операций.

2. Наладить процесс взаимодействия с бэкендом и CRM без потери качества на стыках частей продукта.

3. Разработать киллер-фичи, идеи которых были сгенерены владельцами продукта Подели, и сделать его максимально удобным для клиента, чтобы отстроить сервис от конкурентов. 

И самое главное — сделать всё это быстро.

Стыковка команд

Когда Подели пришли к нам за помощью, над разными частями проекта продолжали работать другие команды: бэкенд, фронтенд, мобилка, CRM. 

Чтобы сонастроиться с остальными командами, работающими над проектом, нужно было много разговаривать и договариваться. Так, мы провели аудит кода и постарались договориться с остальными разработчиками о том, как будет выглядеть код, чтобы все понимали его одинаково. 

Мы внедрили:

1. процессы функционального и регрессионного тестирования

2. процесс подготовки и выпуска релизов

3. код-ревью

4. статический анализатор кода в обе платформы

5. процесс предварительной оценки фич для понимания попадания в ожидания бизнеса

6. возможность создавать фичи на базе действующей архитектуры

Кроме того, для сонастройки оперативно зашли в один сервис планирования задач, и это прошло практически безболезненно. И в целом смогли договориться о совместном планировании и движении по задачам. 

В gitflow процесс выстроили так: как только задачи проходили в ветке функциональное тестирование, ветка сливалась в develop, затем в ветки регресс и релиз. Пока шли регресс и релиз, мерджить другую ветку, готовую к релизу, было нельзя. Схема оказалась максимально рабочей. 

Отдельной работой был рефакторинг кода. Когда скорость разработки высокая, дедлайны горят, как будто бы некогда заниматься рефакторингом. Но предыдущий подрядчик уделял внимание чистоте и понятности кода во вторую очередь. И впоследствии эти недоработки сказались на времени выхода на рынок: внесение внешних изменений нарушало работу бэкенда, происходили сбои в приложении, а на исправление багов требовалось всё больше времени. Техдолг рос: проблемы накапливались, а решать их было некогда.

Могли мы обойтись без рефакторинга, если в целом всё работает? Да, но это влияет на долгосрочное развитие проекта. Тогда в будущем команда не смогла бы наращивать количество и качество фич, а Подели — удерживать позиции в топе BNPL-сервисов. Мы понимали задачи бизнеса и решили на старте инвестировать время в организацию и рефакторинг, чтобы нагнать потом. 

Кроме того, работу ускоряют новые подходы и фреймворки, которые мы внедряем в разработку. Например, с 2024 года используем JetpackCompose в Android-разработке и сокращаем время на написание кода.

Тише едешь, дальше будешь

Параллельно сонастройке с другими командами и рефакторингу продакты Подели генерировали идеи на развитие продукта: спецусловия за привязку карты, сторисы, редизайн. С релизами не спешили: time to market наращивали за счёт отработанного процесса проверки гипотез. После тестов выкатили новые фичи: 

1. Деление оплаты покупки на произвольное количество платежей

2. График платежей

3. История покупок

4. Список магазинов-партнеров

5. Привязка и отвязка карты в профиле

В релизах позже мы добавили:

1. Оплату покупки по QR-коду

2. Спецусловия при выпуске и привязке банковской карты 

3. Сдвиг ближайшего платежа на 14 дней

4. Перенос даты платежа на более удобный день

5. Возможность разделить остаток на 6-20 платежей

На этапе MVP в проекте внимание концентрировалось на базовых функциях. Позже акцент сместился на функции, которые облегчают взаимодействие пользователя с сервисом и делают его жизнь удобнее. 

За 2 года продакты проверили более 100 различных гипотез, не все из которых оказались успешными для пользователей. На проверку каждой функции уходило не более 20 дней. 

Погружаемся с космической скоростью

Всё шло нормально и по чек-листам до середины 2022 года. Начались ограничения в работе сторов мобильных приложений: разработчики столкнулись с ограничениями при загрузке приложений в сторы, а пользователи — при скачивании. Если приложение удалялось со смартфона, его нельзя было установить заново. 

Подели решили оперативно проработать веб-версию приложения, так как изначально в проекте был условный лендинг с урезанной функциональностью. В этом случае time to market как метрика горел как никогда. 

Команда из четырех инженеров, тимлида и двух тестеров, была собрана за 2 дня и запустила веб-версию за 2,5 месяца. Для ускорения использовали базу знаний по проекту и быстрый онбординг. Действующие разработчики тратили минимум времени на объяснения, не отвлекаясь от работы. А новые разработчики не ждали ответов от синьоров и тимлидов по две недели, а сразу включились в проект. После релиза мы сумели передать без остановки разработки эту фичу в команду Подели для дальнейшего развития.

Результат

Промежуточные результаты совместной работы за 2 года:

• Сокращение time to market на 17%

• Рост рейтинга приложения в сторах — с 3,6 до 4,4 (iOS), c 3,8 до 4,7 (Android)

• Подключены более 200 партнёров сервиса, предоставляющие 10 000 различных товаров и услуг 

Мы продолжаем работать с Подели и в ближайших релизах:

1. Персональные баннеры для клиентов: персональные предложения и кнопки ключевого действия согласно пути пользователя;

2. Возможность редактировать профиль 

3. «Общение» сервиса с пользователем: пуши, запрос отзыва, уведомления. 

Итого у нас получилось: с одной стороны — выведенный на рынок максимально быстро сервис для оплаты покупок частями. С другой стороны — стремительная разработка с учетом стыковки разных команд и сборка новой команды за считанные дни.

Когда вы заходите в разработку высокой скорости, нужно не только быть готовым делать быстро, но и подготовить инфраструктуру к этому: выстроенные процессы рефакторинга, тестирования и онбординга новых разработчиков – принципы работы аутстаф-команды SimbirSoft.