Сергей Легчеков поделился своим опытом по извлечению требований, который он получил, работая в стартапе над запуском сервиса пассажирских перевозок.

Основные проблемы стартапа

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

 

Приступив к работе, он столкнулся с рядом проблем:

• Выявление категории заинтересованных лиц и соблюдение баланса между ними. Данный сервис ориентирован на две категории пользователей: пассажиры, которые хотят попасть из точки А в точку Б, и водители, которые хотят получить заказы на поездки и зарабатывать деньги. Обе категории зависимы друг от друга. Другими словами, если пассажир не может получить автомобиль для поездки, у него пропадет интерес к приложению, так как основная цель “уехать” не будет удовлетворена, а долгое ожидание — не то, на что он рассчитывал. Также и с водителем — если он сейчас свободен, но заказов не получает, это вынудит его искать другой сервис, где его услуги будут востребованы.

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

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

Стартап vs Uber

Чтобы понять, в чем бизнес видел преимущество своего сервиса, Сергей рассказал, как работают большинство водителей в сервисе пассажирских перевозок. Они обращаются в транспортную компанию, которая имеет все лицензии на перевозки и контракт с сервисом-агрегатором, так как оформление своего ИП в этой сфере и получение всевозможных документов и разрешений отнимает очень много сил и времени.  Транспортная компания при таком сотрудничестве получает около 75% стоимости поездки, а водитель — только половину этой суммы, что очень мало с учетом всех издержек на топливо, содержание автомобиля и т.д.

У стартапа уже была действующая транспортная компания с лицензией на пассажирские перевозки, и при запуске своего сервиса они могли бы получать 100% стоимости поездки, что давало преимущество платить больше водителям.

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

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

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

Старт проекта по всему вышеописанному был совсем нетипичным. Начинать нужно было “завтра” и с минимальным жизнеспособным продуктом.

Анализ стейкхолдеров и наблюдение за процессом

Пришла пора для работы Сергея как бизнес-аналитика. Представленная документация сводилась к минимальному описанию функциональности водителя и пассажира.

Водителей, в свою очередь, проинструктировали, как установить приложение, и попросили быть онлайн в день старта.

Для привлечения пассажиров были сделаны массовые емейл и СМС рассылки за день до старта. Нужно сказать, что в первый день приложение установили около 800 пользователей. С коммерческой точки зрения старт был достаточно успешным, более 200 заказов в первый день. Но было и много звонков как от водителей, так и от пассажиров с просьбой о помощи. У некоторых водителей не получалось начать поездку в системе, у других — закончить поездку, были пассажиры, у которых было недостаточно средств на карте, чтобы расплатиться за поездку, а водителю в этот момент просто отображалась кнопка “Сообщить о проблеме”, ведущая на почтовый клиент. Несколько пользователей просто не смогли войти в ситему.

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

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

• Встреча с водителями.

• Встреча с разработчиками используемой системы.

• Погружение представителей бизнеса в мир управления проектами.

• Убеждение бизнеса в том, что такого минимально жизнеспособного продукта не достаточно для рынка конкурентов и  нужны новые функции.

• Разработка решения для предупреждения попыток мошенничества.

Сергей организовал встречу с водителями, на которую пришли около 100 человек, чтобы собрать требования и помочь в разработке необходимого функционала. Однако она не увенчалась должным успехом, общий язык было найти трудно, и можно было только догадываться о том, что имеют в виду люди, работая “за рулем”.

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

The happy end или причины провала

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

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

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

Причины провала:

• Отсутствие исследований, фаз дискавери и анализа, сбора требований, чтобы понимать, куда двигаться дальше.

• Недостаточность функционала для конкуренции на рынке.

• Низкий бюджет.

• Неопытность водителей в информационных технологиях.

 

Совет от Сергея: “Всегда проводите фазу дискавери, особенно если есть проблемы в бизнес-требованиях. Не бойтесь вовлекаться в любые процессы, которые происходят на проекте. Общайтесь со своими заинтересованными лицами”.

 

Вопросы и ответы:

Какая контрактная модель была на этом проекте? 

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

Uber знал, что у него растет конкурент?

Да, на сайт стартапа была подключена аналитика. IP адреса совпадали с одним из офисов Uber. Uber присматривался к тому, как работает система. Есть предположение, что представители компании пользовались сервисом как пассажиры. В итоге пришли к тому, чтобы выкупить сервис.

Какие техники использовали для извлечения пользовательских требований?

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

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

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

Основатели что-то для себя вынесли за потраченные деньги?

Поняли, как работает проект в целом, а особенно, проект, связанный с информационными технологиями. У них был свой путь, свое мировоззрение, как заработать на сервисе.

Какие самые важные активности вы бы запланировали для дискавери фазы, если бы она случилась на этом проекте?

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

На ваш взгляд, были ли какие то решения, которые могли создать преимущество вашему сервису перед Uber?

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

Автор: Величкевич Екатерина