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

Цель проекта

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

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

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

Экономика

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

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

Требования

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

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

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

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

Конкуренты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роли

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

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

Действия

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

Данные

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

Сущности

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

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

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

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

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

Карта сайта

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

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

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

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

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

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

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

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

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

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

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

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

Риски

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

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

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

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

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

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

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

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

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