Организация маркетплейса

В нашей предыдущей публикации обсуждалось, что такое маркетплейс и его архитектура, также была упомянута it-инфраструктура. Сегодня речь пойдёт о организации проекта с нуля, текст будет более тезисным и распланированным. Материал полезен для того, кто уже пользуется маркетплейсом, или задумывался о создании маркетплейса — например, для нужд организации. Основным автором текста является мой коллега — Анатолий Ерофеев.

Цель проекта

Ради чего затевается проект? Зачастую это все, что есть на «нулевом» этапе работ. Должна быть измерима, достижима и понятна всем участникам, например «занять {сколько-то}% рынка онлайн-торговли {чем-то} в России к {какому-то} году». Цель может иметь промежуточные вехи, которые помогут заранее понять, попадает проект в ожидания или нет.

Цель документа

Зачем нужен этот документ? Понять, кто, что и как будет делать. По сути, цель документа: проработка плана достижения цели проекта.

Экономика

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

i-n5aebafpybz6p_3kpejaulsza.gif

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

v5ubxecfbkl-qwoq_ib4q6ehutu.png

Требования

От чего нельзя отказаться для достижения цели проекта? Например: работа сервиса в конкретных городах, бюджет на колл-центр, сколько сотрудников может нанять/выделить для управления? Следует обсудить и описать самое важное: технологическое окружение и интеграции (какие ИТ-системы задействованы в том или ином виде в работе нового проекта), логистика и пути товара. О цвете кнопок и поддерживаемой версии Chrome будет возможность подумать на этапе макетов и ТЗ, сейчас же основные требования — именно по бизнесу.

Целевая аудитория

Кто она и чего хочет? Хорошо, если у клиента есть доступ к Google Analytics / Яндекс.Метрике проекта похожей тематики. Если нет, то придется выполнить маркетинговое исследование конкурентов (см соответствующий раздел).

Начать анализ можно с сервиса Яндекс Wordstat. Он поможет понять сезонность запросов, а также что именно интересует людей в связи с тем или иным товаром. Например, с названием препарата «анальгин» чаще всего ищут «детям», «можно» и «инструкция», а вовсе не цену. Исходя из потребностей целевой аудитории чуть позже нужно будет продумывать функции и структуру сайта.

Конкуренты

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

hl9k5rullbk1syzrp4gnb66p5ny.gif

Маркетинговый анализ конкурентов

Честный способ получить реальные данные о посещаемости сайтов конкурентов (пусть и с погрешностью) — проект SimilarWeb. В отчете этого сервиса будут источники посещений, возраст, пол и др. — достаточные сведения для предварительного анализа трафика и понимания ЦА в общих чертах. 

Эту работу должен проводить интернет-маркетолог.

Технический анализ конкурентов

Рекомендуется исследовать скорость загрузки, размер основных страниц конкурентов, баллы по Google PageSpeed Insights. Это даст представление о приемлемом уровне реализации схожих проектов.

Важные вопросы для проектов с большими данными:

  1. Есть ли сортировка? По каким полям?

  2. Есть ли фильтрация? По каким полям?

  3. Есть ли Geo IP и как устроена региональность?

  4. Какие браузеры и устройства поддерживаются версткой?

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

Эту работу должен проводить разработчик.

Функции проекта

Кто и как будет взаимодействовать с проектом после старта? Результаты анализа конкурентов и потребностей ЦА удобно представить в виде диаграммы прецедентов (UML Use case). Ниже представлен фрагмент такой диаграммы для нашего клиента.

kbktouxj5zr1vq603n5zfqm4ciu.png

Роли

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

Бывают технические роли, которые исполняет не какой-то конкретный человек, а веб-сервис или компания-партнер (платежные агенты, службы доставки, СМС-провайдеры, Яндекс.Маркет).

Действия

Какие действия будут доступны в проекте? Впоследствии они найдут свое отражение в структуре данных и карте сайта.

Данные

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

Сущности

Какие виды данных есть и как они связаны? Выделенные сущности удобно представить в виде ER-диаграммы (диаграммы «сущность-связь»). Это классический подготовительный этап при проектировании баз данных.

zfqxn8hy5t7nadxoegp5omfkuru.png

Источники данных

Откуда брать данные? Мало назвать сущности, требуется также решить, как данные будут попадать в проект и откуда. Откуда взять базу клиентов? Базу городов? E-mail«ы для первой рассылки? Следует заполнить таблицу.

Вид данных

Источник

Способ ввода

Город

База ФИАС

Интеграция

Пользователь

Старый сайт

Вручную через импорт CSV (телефон, почта, логин)

Движение данных

Как будут распределены данные в проекте? Учитывая список сущностей и источники информации нужно представить схему движения данных в проекте. Для этого подойдет диаграмма развертывания (UML Deployment).

Карта сайта

Как должен быть устроен сайт, чтобы отвечать требованиям ЦА? На этом этапе мы возвращаемся к пунктам исследования Целевая аудитория и Функции проекта и выводим на их основе первичную карту сайта.

ВАЖНО! При разработке ТЗ рекомендуется собрать семантическое ядро, и на его основе спроектировать финальную структуру сайта (в особенности каталога).

Технические решения

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

  • Какие интеграции потребуются в проекте?

  • Как обеспечить актуальность данных?

  • Какие отчеты нужны на сайте?

  • Применим ли умный фильтр?

  • Как должна работать фича Х?

i5jfj2whbuwageo729flqg7mzx8.gif

Универсальный список вопросов составить нельзя — они возникают в ходе исследования и зависят от специфики проекта.

Рекомендации по продвижению

Как правильно продвигать такой проект? Значительная часть предварительного исследования проводится маркетологом. Уже на этом этапе можно сделать глобальные выводы о стратегии продвижения: как делать контекст, как делать SEO (и надо ли)?   Стоит ли размещать баннеры на сайте? Нужно ли мобильное приложение?

Риски

Какие риски есть в проекте и как ими управлять? На этом этапе выполняется отдельное исследование. Вспоминаем PMBOK:

  1. Идентификация рисков — определение перечня рисков.

  2. Качественный анализ рисков — расстановка приоритетов рисков.

  3. (Количественный анализ рисков — численный анализ эффекта рисков, пропускаем на предварительном исследовании)

  4. Планирование реагирования на риски — разработка вариантов реагирования

  5. Составление плана контроля рисков — определение регламента

Этапы запуска

Как стартуем проект? Т.к. для простых проектов предварительное исследование не нужно, ответ очевиден: в несколько этапов. Проставив приоритеты функциям проекта нужно составить поэтапный план запуска.

tltzy9n-xzrsdeevvtvkf93ecxw.gif

Спасибо за внимание, будем рады комментариям.

© Habrahabr.ru