Организация маркетплейса
В нашей предыдущей публикации обсуждалось, что такое маркетплейс и его архитектура, также была упомянута it-инфраструктура. Сегодня речь пойдёт о организации проекта с нуля, текст будет более тезисным и распланированным. Материал полезен для того, кто уже пользуется маркетплейсом, или задумывался о создании маркетплейса — например, для нужд организации. Основным автором текста является мой коллега — Анатолий Ерофеев.
Цель проекта
Ради чего затевается проект? Зачастую это все, что есть на «нулевом» этапе работ. Должна быть измерима, достижима и понятна всем участникам, например «занять {сколько-то}% рынка онлайн-торговли {чем-то} в России к {какому-то} году». Цель может иметь промежуточные вехи, которые помогут заранее понять, попадает проект в ожидания или нет.
Цель документа
Зачем нужен этот документ? Понять, кто, что и как будет делать. По сути, цель документа: проработка плана достижения цели проекта.
Экономика
Кто кому и за что платит после старта проекта? Конечно же, нельзя сразу дать точный ответ на этот вопрос. Но примерная картина должна быть. В ходе работ над последующими разделами документа в экономическую модель нужно вносить правки и уточнения.
Представляя роли в проекте, можно представить и денежные потоки. В зависимости от глубины исследования можно только наметить потоки, оценить их или же посчитать конкретные значения в конце исследования.
Требования
От чего нельзя отказаться для достижения цели проекта? Например: работа сервиса в конкретных городах, бюджет на колл-центр, сколько сотрудников может нанять/выделить для управления? Следует обсудить и описать самое важное: технологическое окружение и интеграции (какие ИТ-системы задействованы в том или ином виде в работе нового проекта), логистика и пути товара. О цвете кнопок и поддерживаемой версии Chrome будет возможность подумать на этапе макетов и ТЗ, сейчас же основные требования — именно по бизнесу.
Целевая аудитория
Кто она и чего хочет? Хорошо, если у клиента есть доступ к Google Analytics / Яндекс.Метрике проекта похожей тематики. Если нет, то придется выполнить маркетинговое исследование конкурентов (см соответствующий раздел).
Начать анализ можно с сервиса Яндекс Wordstat. Он поможет понять сезонность запросов, а также что именно интересует людей в связи с тем или иным товаром. Например, с названием препарата «анальгин» чаще всего ищут «детям», «можно» и «инструкция», а вовсе не цену. Исходя из потребностей целевой аудитории чуть позже нужно будет продумывать функции и структуру сайта.
Конкуренты
Кто пытается достичь похожей цели на рынке? На этот вопрос ответит маркетолог компании-заказчика. Если у конкурентов запущены аналогичные проекты, их также стоит рассмотреть (но помнить про карго-культ и ни в коем случае не копировать чужие решения бездумно).
Маркетинговый анализ конкурентов
Честный способ получить реальные данные о посещаемости сайтов конкурентов (пусть и с погрешностью) — проект SimilarWeb. В отчете этого сервиса будут источники посещений, возраст, пол и др. — достаточные сведения для предварительного анализа трафика и понимания ЦА в общих чертах.
Эту работу должен проводить интернет-маркетолог.
Технический анализ конкурентов
Рекомендуется исследовать скорость загрузки, размер основных страниц конкурентов, баллы по Google PageSpeed Insights. Это даст представление о приемлемом уровне реализации схожих проектов.
Важные вопросы для проектов с большими данными:
Есть ли сортировка? По каким полям?
Есть ли фильтрация? По каким полям?
Есть ли Geo IP и как устроена региональность?
Какие браузеры и устройства поддерживаются версткой?
Дополнительно можно исследовать структуру сайта, чтобы получить приблизительное понятие, как устроены данные в других проектах.
Эту работу должен проводить разработчик.
Функции проекта
Кто и как будет взаимодействовать с проектом после старта? Результаты анализа конкурентов и потребностей ЦА удобно представить в виде диаграммы прецедентов (UML Use case). Ниже представлен фрагмент такой диаграммы для нашего клиента.
Роли
Какие стороны будут участвовать в проекте? На диаграмме видны основные роли участников проекта. На последующих этапах проектирования роли превращаются в пользователей, но не все и не всегда. Например, у администратора проекта может быть сразу несколько ролей.
Бывают технические роли, которые исполняет не какой-то конкретный человек, а веб-сервис или компания-партнер (платежные агенты, службы доставки, СМС-провайдеры, Яндекс.Маркет).
Действия
Какие действия будут доступны в проекте? Впоследствии они найдут свое отражение в структуре данных и карте сайта.
Данные
Какая информация нужна проекту для работы? Нужно вернуться на предыдущий этап, прочитать список всех действий в проекте и к каждому задать вопрос — что для этого нужно знать?
Сущности
Какие виды данных есть и как они связаны? Выделенные сущности удобно представить в виде ER-диаграммы (диаграммы «сущность-связь»). Это классический подготовительный этап при проектировании баз данных.
Источники данных
Откуда брать данные? Мало назвать сущности, требуется также решить, как данные будут попадать в проект и откуда. Откуда взять базу клиентов? Базу городов? E-mail«ы для первой рассылки? Следует заполнить таблицу.
Вид данных | Источник | Способ ввода |
Город | База ФИАС | Интеграция |
Пользователь | Старый сайт | Вручную через импорт CSV (телефон, почта, логин) |
Движение данных
Как будут распределены данные в проекте? Учитывая список сущностей и источники информации нужно представить схему движения данных в проекте. Для этого подойдет диаграмма развертывания (UML Deployment).
Карта сайта
Как должен быть устроен сайт, чтобы отвечать требованиям ЦА? На этом этапе мы возвращаемся к пунктам исследования Целевая аудитория и Функции проекта и выводим на их основе первичную карту сайта.
ВАЖНО! При разработке ТЗ рекомендуется собрать семантическое ядро, и на его основе спроектировать финальную структуру сайта (в особенности каталога).
Технические решения
Какие технические решения стоят за каждым из разделов исследования? Теперь, когда функции и данные определены, можно ответить на технические вопросы. Например:
Какие интеграции потребуются в проекте?
Как обеспечить актуальность данных?
Какие отчеты нужны на сайте?
Применим ли умный фильтр?
Как должна работать фича Х?
Универсальный список вопросов составить нельзя — они возникают в ходе исследования и зависят от специфики проекта.
Рекомендации по продвижению
Как правильно продвигать такой проект? Значительная часть предварительного исследования проводится маркетологом. Уже на этом этапе можно сделать глобальные выводы о стратегии продвижения: как делать контекст, как делать SEO (и надо ли)? Стоит ли размещать баннеры на сайте? Нужно ли мобильное приложение?
Риски
Какие риски есть в проекте и как ими управлять? На этом этапе выполняется отдельное исследование. Вспоминаем PMBOK:
Идентификация рисков — определение перечня рисков.
Качественный анализ рисков — расстановка приоритетов рисков.
(Количественный анализ рисков — численный анализ эффекта рисков, пропускаем на предварительном исследовании)
Планирование реагирования на риски — разработка вариантов реагирования
Составление плана контроля рисков — определение регламента
Этапы запуска
Как стартуем проект? Т.к. для простых проектов предварительное исследование не нужно, ответ очевиден: в несколько этапов. Проставив приоритеты функциям проекта нужно составить поэтапный план запуска.
Спасибо за внимание, будем рады комментариям.
