Особенности разработки ИТ-продуктов, проданных на этапе концепта: кейс логистического B2B-сервиса Cargo

Александр Шульгин, управляющий партнёр Purrweb, на примере приложения по организации доставки Cargo рассказывает, с какими проблемами сталкивается команда, когда разработка продукта начинается после подписания договора с клиентом, и как с этими проблемами справиться.

Кто из стартаперов не мечтал о том, чтобы получить первых клиентов еще до релиза приложения или сервиса? Кажется, что это гораздо надежнее и перспективнее, чем запускаться в условиях неопределенности, однако все не так однозначно. Например, в B2B-сегменте подобная стратегия требует очень грамотного управления продуктом, в противном случае есть риск не оправдать ожидания клиента.

За границей продажа ИТ-продуктов на ранних стадиях — распространенная история. Если стартапер нащупал боль рынка и готов предложить действительно хорошее решение, у него есть все шансы получить первого заказчика еще до написания первой строчки кода. Не только инвесторы готовы вкладываться в перспективные ИТ-решения, но и клиенты, ведь у покупки продуктов на этапе концептов много преимуществ. Главное из них — возможность получить кастомный сервис за минимальную стоимость.

Продажа еще не готового приложения происходит с помощью дизайн-концептов и кликабельных прототипов, которые демонстрируют эффективное решение боли рынка. Однако как и инвесторы, клиенты не готовы рисковать и ждать годами релиза, поэтому они купят только те сервисы, которые через 2-4 месяца будут как минимум стабильно работающими MVP (Minimum viable product).

Наш кейс начался с того, что стартапер Gurpreet Jajj из Арабских Эмиратов обратился в Purrweb за дизайн-концептом для ИТ-сервиса, который оптимизирует логистику в малом и среднем бизнесе, например, в интернет-магазинах, ресторанах, прачечных. Сервис должен был стать приложением-шаблоном (White Label), которое органично интегрируется в бизнес-процессы клиентов, делая доставку по городу прозрачной и эффективной.

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

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

Для работы по сценарию «вначале продажа — потом продукт» необходимо грамотное планирование и расстановка приоритетов. Причем приоритеты важнее, потому что даже идеальное планирование не спасает от ситуаций, когда заказчик в середине спринта приходит с новыми идеями и «хотелками». Двигать сроки нельзя, игнорировать пожелания — тоже не вариант.

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

Основной флоу в «Cargo» выглядел следующим образом. Курьер приезжает на склад, открывает приложение и начинает работу, отметив свой статус. Второй экран — список посылок, которые надо сегодня доставить. Курьер находит их на складе, затем сканирует бар-код или вводит его вручную: эта процедура означает, что посылка теперь находится под ответственностью курьера. Как только все посылки собраны, курьер получает маршрутный лист, в котором получатели рассортированы максимально удобным образом. Поскольку доставщики чаще всего передвигаются по городу на машине, мы интегрировали в приложение навигатор. Когда курьер вручает посылку адресату, ее опять надо просканировать, и после этого можно ехать в следующую точку.

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

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

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

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

Чтобы оптимизировать наше взаимодействие с командой бэкенд-программистов, мы решили работать по принципу frontend driven development. Так как главное преимущество нашего приложения — пользовательские сценарии, вначале мы делали клиентскую часть, и только потом серверную. Именно мы решали, когда и какие запросы отдавать на сервер, и определяли структуру ответа.

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

При дизайне интерфейсов приложений формата White Label надо учитывать, что сервис должен легко мимикрировать под любой брендинг. Фактически приложение White Label — это шаблон приложения, но данный факт не должен сказывается на дизайне, более того, сжатые сроки — не повод жертвовать визуальной составляющей. Чтобы интерфейсы не выглядели, как заготовка, а само приложение было живым и ярким, мы много внимания уделили деталям. Например, даже неинформативный полупустой экран «Отсутствие заданий» мы сделали гармоничным и сбалансированным за счет аккуратной иконки.

Есть и другие нюансы при работе с приложениями White Label: они касаются цветовой гаммы. Традиционное решение — продумать систему из основных и дополнительных цветов, которые будут меняться на фирменные цвета из брендбука клиента.

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

При сжатых сроках нет времени и возможности покрывать код тестами, поэтому к тестированию нужно подойти максимально ответственно.

В нашем случае основная сложность опять же заключалась в навигаторе: для его проверки тестировщикам пришлось не раз выбираться из офиса и гулять по окрестностям. Чтобы избежать багов, мы выделили на эту задачу дополнительные ресурсы и в целом потратили больше времени, чем обычно. Но все равно меньше, чем на написание тестов.

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

Для попадания в дедлайны и обеспечения стабильной работы приложения, крайне важна скорость исправления багов. Именно поэтому весь фронтенд мы решили делать на React Native: несмотря на предубеждения, этому фреймворку практически нет равных в создании кроссплатформенных приложений с красивыми адаптивными интерфейсами в кратчайшие сроки.

К React Native много претензий со стороны разработчиков из-за ряда сложностей с поддержкой библиотек и зависимостей. Однако мы давно работаем с этим фреймворком и научились справляться с его ограничениями и недостатками. В данном случае для навигатора мы использовали готовую открытую библиотеку MapBox, которая после небольшой отладки стала четко и стабильно работать.

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

Наш MVP пережил испытание масштабированием: выбранный технологический стек (React Native, Realm, Mapbox) позволил успешно развивать сразу несколько версий приложения. А сам сервис стал популярным решением, которое сейчас предлагается в рамках линейки продуктов IT-компании Illuminate Software Solutions.

#разработка #стартапы #дизайн #приложения