Скоростная разработка: кейс B2B-сервиса Headcount

Запросы с дедлайном «Нам нужно вчера!» мы получаем регулярно. Чтобы работать с такими заказами, надо отказываться от неважного и фокусироваться на главном. Как уложиться в жесткий дедлайн, не выгореть дотла и не загнать команду, рассказываем на примере разработки MVP для финансового стартапа Headcount.

Мы начали работать над стартапом Headcount 17 июня. Это B2B-сервис для перевода денег за работу подрядчикам по всему миру. Проект нужно было завершить к 24 августа — это Демо день в бизнес-инкубаторе Y Combinator. Событие считается одним из важнейших мероприятий для IT-стартапов. По представленным на нем проектам понимают, в каком направлении будет развиваться IT-индустрия в ближайшее время.

Основные конкуренты Headcount — Gusto.com, letsdeel.com, pilot.co. Все они используют Transferwise (сервис для транзакций), поэтому у них огромные комиссии для международных переводов. Headcount же на специальных условиях сотрудничает с крупным банком. Поэтому на комиссиях можно здорово сэкономить.

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

В обычной жизни на такой проект нам нужно не меньше трех месяцев. Браться за скоростную разработку платежной системы с такими сроками, рисками и без тестов — большая авантюра. Но Demo Day в бизнес-инкубаторе случается не каждый день да и отказаться от работы с Олдрином Клементом — автором проекта — у которого был опыт успешного запуска продукта в инкубаторе, мы не могли.

Основной проект Олдрина — jumpstart.com. Сервис помогает иностранным компаниям легально открывать бизнес в Америке. Проектом занимается удаленная команда, которая должна получать регулярную оплату. Большая личная боль заказчика — заторможенные переводы денег и высокая комиссия. Олдрин Клемент — не единственный, кто страдал от этого. Опрос знакомых бизнесменов в акселераторе показал: другие бизнесы тоже сталкиваются с этой проблемой при оплате работы своей команды.

Стартап напрашивался сам собой и убивал трех зайцев:

 — разрабатываем новый продукт и занимаем свободную нишу;

— апсейл для клиентов jumpstart.com и выход через новый продукт на модель recurring revenue, повышение LTV;

— еще раз засветиться в Y Combinator с новым проектом и закрепить имя серийного предпринимателя. Так будет легче получать инвестиции с каждым новым проектом.

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

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

При этом заказчик не был готов отказаться от мобильной версии сайта. Он знал, что в другом проекте — в jumpstart.com — 60 % транзакций делают на смартфонах. «‎Ты удивишься, но люди делают покупки в $4000 и открывают бизнес прямо в браузере в инстаграме», — говорил он.

Мы планировали использовать React на фронте, но заказчик убедил нас взять более привычный ему Next, Обычно мы задействуем его только если есть необходимость server side rendering’a. Заказчику нужен был Next.js, потому что он использован в Jumpstart. Работать с одинаковой технологией удобнее.

В работу взяли фичи первого приоритета: создание аккаунта, ручное заполнение рабочего времени, создание регулярных выплат сотрудникам, подключение банковского аккаунта и сами переводы.

Из-за сроков мы привлекли на проект пять разработчиков (обычно нам хватает трех, чтобы укладываться в 3 месяца). Мы отвечали только за скоростную разработку, которую распределили на двухнедельные спринты. На нулевом спринте наш тимлид сформировал архитектуру. После этого мы начали подключать остальных разработчиков.

Каждый день клиент проверял код и наши решения. У нас заказчиков с такой вовлеченностью и микроменеджментом раньше не было, но это объяснялось сжатыми сроками.

Самой сложной в проекте оказалась работа с API банка-партнера. API банк сделал совсем недавно, и оно было очень сырым: некоторые методы не работали. Пока мы разрабатывали свой сервис, находили баги в API. Например, нам не возвращалось поле ИНН для России или код банка для Бразилии.

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

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

Мы уложились в два месяца и зарелизили приложение. При этом команда работала по 8 часов в день, овертаймов удалось избежать. Этому во многом помог качественно выстроенный рабочий процесс: следование спринтам, детальное описание задач в Jira, Vercel для тестирования в реальном времени, автодеплои. Мы автоматизировали рутину скоростной разработки как могли. Для средних и крупных багов выделяли отдельное время и фиксили. Мелкие баги исправляли по ходу.