Главное Свежее Вакансии Образование
Выбор редакции:
😼
Выбор
редакции
1 561 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Владелец продукта: почему без него так плохо. Часть 2

Epic fail! Oh no! Работа на проектах разработки всегда сопряжена с рисками провала, недостижения целей, полного разочарования в продукте, команде и в себе. Попробуем понять, как не допустить провала проекта.

Описание проекта



Целевая аудитория и пользователи продукта — точка отсчета для успешности проекта

Итак, на одном из проектов я участвовала в качестве менеджера разработки со стороны исполнителя. Заказчик занимался оптовой продажей автозапчастей, у него была крупная сеть поставок по всей стране, специализированные магазины и пара интернет-магазинов. Все вполне успешно. Заказчик решил, что время пришло и пора запилить свой маркетплейс с деталями и поставщиками, лучше чем у Яндекса и Емекса.

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

Структура сервиса


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

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


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


Основной сценарий работы выглядел примерно следующим образом:

  1. Автовладелец обнаруживает проблему — необходимость приобрести деталь.
  2. На сайте или в мобильном приложении вводит поисковый запрос.
  3. В поисковой выдаче получает различные предложения от продавцов, отсортированных по рейтингу, цене, близости.
  4. Автовладелец оставляет заказ на приобретение детали (бронирует ее), приезжает в нужный магазин, совершает покупку.

Бизнес-модель


Суть бизнес-модели сводилась к получению комиссии за совершенные сделки, то есть предполагалось монетизировать сервис за счет отчислений от продавцов товаров и поставщиков услуг. Основным УТП для покупателей была обширная сеть поставщиков, включая магазинчики «дяди вани» за углом. Поставщикам и продавцам предлагалась привлеченная рекламой аудитория потенциальных покупателей.

Разработка и запуск


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

Однако, проект так и не был запущен. Вообще. Не было даже ни альфа, ни бета релиза.

* * *

Как думаете, что именно произошло? Пишите в комментариях.

Stay tuned.

Первую часть истории можно прочитать в этой статье.

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.