RnD и новый транспорт: как создавать инновации на рынке шеринга

Сложности производства

В транспортном шеринге цикл RnD намного длиннее, чем в IT-разработке, поскольку многие элементы (например, датчики) нужно изготавливать физически. На практике это означает не только работу с производством, но и необходимость установить новый элемент на весь парк транспорта. 

Не говоря уже о том, что для замены все эти десятки тысяч нужно привезти в сервисный центр. 

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

Диалог с властями

В RnD-цикле шеринга между созданием гипотезы и ее тестированием появляется еще один этап — согласование с городскими администрациями. 

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

В первую очередь согласовывать нужно: 

• размещение парковочных мест, 
• скоростные ограничения
• запрещенные для проезда зоны. 

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

В частности, наше приложение дает пользователю подсказки, как правильно запарковать самокат. 

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

Быстро провалиться, быстро победить

В классическом RnD за этапом создания гипотез следует A/B-тестирование. Но если рынок и сам продукт находятся в фазе активного роста, стадия тестирования может выпадать из цикла.

В такие моменты зачастую важнее скорость разработки, поэтому A/B-тесты во многих случаев лучше заменить на методы fail fast и quick wins. Суть этого подхода в следующем:

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

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

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

Читайте по теме: «Самокаты — это карманное такси»: основатели Urent о тренде на кикшеринг в России, скандалах и новом законе

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

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

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

Уже после этого можно делать выводы, стоит ли использовать метод quick wins — или требуется полноценное тестирование.

Генерация идей

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

Остановимся подробнее на каждом из них. 

Аналитика

Основной источник новых идей для разработки — изучение продуктовых и бизнес-метрик. Так, сюда относятся:

1. частота поездок на единицу транспорта,
2. средняя выручка с клиента,
3. количество поездок одного пользователя за сезон.

Если какая-то из этих метрик проседает, нужно искать причину и способ это изменить. 

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

Читайте также: 

Подборка: разработчики технологий для умных городов

Почему Торонто отказался от проекта умного города, предложенного Alphabet

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

Пользовательский опыт

Второй важный источник идей для развития продукта — обратная связь от пользователей:

• глубинные интервью,
• количественные опросы,
• мониторинг отзывов.

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

Собственный пользовательский опыт

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

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

Резюме для стартапов

• Старайтесь минимизировать количество обновлений физической «начинки» транспортных средств: лучше сразу создать продукт максимально оснащенным технически.
• Оптимальный подход на нынешнем этапе развития рынка — fail fast/quick wins.
• Не тратьте время на A/B-тесты на этапе роста продукта: выбирайте оптимальное решение, тестируйте с клиентами и уже на практике смотрите, что можно улучшить.
• Все идеи должны быть согласованы с вашей собственной операционной командой, а те, что влияют на городское пространство — еще и с муниципальными властями.
• Обмен опытом между представителями регионов — хороший драйвер продукта.

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

Фото на обложке: Shutterstock / Akaberka