Почему маркетплейс вместо интернет-магазина? Зачем аналитика?
Рынок веб-проектов расслоился на простые сайты (здесь балом правят Tilda, Wix и прочие Битрикс24.Сайты ) и ультра-сложные b2b-личные кабинеты дилерских сетей и маркетплейсы (площадки, размещающие товары партнеров, такие как OZON, Беру!, WildBerries). Такие проекты уникальны и в них по определению трудно использовать предыдущий опыт веб-разработки. Нельзя сделать маркетплейс с наскока, даже имея за плечами тысячу успешных интернет-магазинов.
Чтобы не оказаться у разбитого корыта проекта, все заинтересованные лица (в том числе и разработчики) должны сразу задать себе вопрос: понимаем ли мы, кто именно, что именно и как именно будет делать, чтобы проект был успешен?
Если нет ясного представления — нужно не в бой бросаться и не бюджеты со сроками согласовывать, а делать грамотное предпроектное исследование. Оно поможет увидеть главные подводные камни сложной новой разработки. Желательно, чтобы авторы этого исследования участвовали в дальнейшей разработке проекта. Да, мы снова говорим о том, что в ИНТЕРВОЛГЕ не только код пишут, но и решают проблемы бизнеса).
Специализация ИНТЕРВОЛГИ — вертикальная оцифровка фарм-бизнеса
ИНТЕРВОЛГА комплексно автоматизирует процессы в компаниях фармацевтической направленности
У нас за плечами около 20 проектов фарм-отрасли , и мы отлично понимаем особенности бизнеса.
Летом 2019 года крупная фарм-компания (дистрибьютор, производитель и обладатель собственной аптечной сети) обратилась к нам с идеей разработки интернет-магазина нового поколения — маркетплейса.
Вопросов было очень много, и в основном — не по технике. Это были организационные, маркетинговые, бизнес-вопросы. Мы решили начать с комплексного исследования и в августе 2019 года мы начали.
Мы решили описать место проекта в бизнесе Заказчика, связи с другими блоками, состояние конкурентов, архитектуру будущего проекта, дать рекомендации по разработке и разложить все по полочкам. Завершив исследование, мы решили рассказать, как его проводили и поделиться типовой структурой такого документа.
Мы считаем что любой нетривиальный проект должен начинаться с такого исследования. Нормально, если его делают 2 команды вместе — Заказчик и Интегратор.
Структура предпроектной аналитики
1. Цель проекта
Ради чего затевается проект? Зачастую это все, что есть на «нулевом» этапе работ. Должна быть измерима, достижима и понятна всем участникам, например «занять {сколько-то}% рынка онлайн-торговли {чем-то} в России к {какому-то} году». Цель может иметь промежуточные вехи, которые помогут заранее понять, попадает проект в ожидания или нет.
2. Цель документа
Зачем нужен этот документ? Понять, кто, что и как будет делать. По сути, цель документа: проработка плана достижения цели проекта.
3. Экономика
Кто кому и за что платит после старта проекта? Конечно же, нельзя сразу дать точный ответ на этот вопрос. Но примерная картина должна быть. В ходе работ над последующими разделами документа в экономическую модель нужно вносить правки и уточнения.
Представляя роли в проекте, можно представить и денежные потоки. В зависимости от глубины исследования можно только наметить потоки, оценить их или же посчитать конкретные значения в конце исследования.
4. Требования
От чего нельзя отказаться для достижения цели проекта? Например: работа сервиса в конкретных городах, бюджет на колл-центр, сколько сотрудников может нанять/выделить для управления? Следует обсудить и описать самое важное: технологическое окружение и интеграции (какие ИТ-системы задействованы в том или ином виде в работе нового проекта), логистика и пути товара. О цвете кнопок и поддерживаемой версии Chrome будет возможность подумать на этапе макетов и ТЗ, сейчас же основные требования — именно по бизнесу.
5. Целевая аудитория
Кто она и чего хочет? Хорошо, если у клиента есть доступ к Google Аналитикс / Яндекс.Метрике проекта похожей тематики. Если нет, то придется выполнить маркетинговое исследование конкурентов (см соответствующий раздел).
Начать анализ можно с сервиса Яндекс Wordstat. Он поможет понять сезонность запросов, а также что именно интересует людей в связи с тем или иным товаром. Например, с названием препарата «анальгин» чаще всего ищут «детям», «можно» и «инструкция», а вовсе не цену. Исходя из потребностей целевой аудитории чуть позже нужно будет продумывать функции и структуру сайта.
6. Конкуренты
Кто пытается достичь похожей цели на рынке? На этот вопрос ответит маркетолог компании-заказчика. Если у конкурентов запущены аналогичные проекты, их также стоит рассмотреть (но помнить про карго-культ и ни в коем случае не копировать чужие решения бездумно).
6.1 Маркетинговый анализ конкурентов
Честный способ получить реальные данные о посещаемости сайтов конкурентов (пусть и с погрешностью) — проект SimilarWeb . В отчете этого сервиса будут источники посещений, возраст, пол и др. — достаточные сведения для предварительного анализа трафика и понимания ЦА в общих чертах.
Эту работу должен проводить интернет-маркетолог.
6.2 Технический анализ конкурентов
Рекомендуется исследовать скорость загрузки, размер основных страниц конкурентов, баллы по Google PageSpeed Insights . Это даст представление о приемлемом уровне реализации схожих проектов.
Важные вопросы для проектов с большими данными:
- Есть ли сортировка? По каким полям?
- Есть ли фильтрация? По каким полям?
- Есть ли Geo IP и как устроена региональность?
- Какие браузеры и устройства поддерживаются версткой?
Дополнительно можно исследовать структуру сайта, чтобы получить приблизительное понятие, как устроены данные в других проектах.
Эту работу должен проводить разработчик.
7. Функции проекта
Кто и как будет взаимодействовать с проектом после старта? Результаты анализа конкурентов и потребностей ЦА удобно представить в виде диаграммы прецедентов (UML Use case). Ниже представлен фрагмент такой диаграммы для нашего клиента.
7.1 Роли
Какие стороны будут участвовать в проекте? На диаграмме видны основные роли участников проекта. На последующих этапах проектирования роли превращаются в пользователей, но не все и не всегда. Например, у администратора проекта может быть сразу несколько ролей.
Бывают технические роли, которые исполняет не какой-то конкретный человек, а веб-сервис или компания-партнер (платежные агенты, службы доставки, СМС-провайдеры, Яндекс.Маркет).
7.2 Действия
Какие действия будут доступны в проекте? Впоследствии они найдут свое отражение в структуре данных и карте сайта.
8. Данные
Какая информация нужна проекту для работы? Нужно вернуться на предыдущий этап, прочитать список всех действий в проекте и к каждому задать вопрос — что для этого нужно знать?
8.1 Сущности
Какие виды данных есть и как они связаны? Выделенные сущности удобно представить в виде ER-диаграммы (диаграммы «сущность-связь»). Это классический подготовительный этап при проектировании баз данных.
8.2 Источники данных
Откуда брать данные? Мало назвать сущности, требуется также решить, как данные будут попадать в проект и откуда. Откуда взять базу клиентов? Базу городов? E-mail’ы для первой рассылки? Следует заполнить таблицу.
8.3 Движение данных
Как будут распределены данные в проекте? Учитывая список сущностей и источники информации нужно представить схему движения данных в проекте. Для этого подойдет диаграмма развертывания (UML Deployment).
9. Карта сайта
Как должен быть устроен сайт чтобы отвечать требованиям ЦА? На этом этапе мы возвращаемся к пунктам исследования Целевая аудитория и Функции проекта и выводим на их основе первичную карту сайта.
ВАЖНО! При разработке ТЗ рекомендуется собрать семантическое ядро, и на его основе спроектировать финальную структуру сайта (в особенности каталога).
10. Технические решения
Какие технические решения стоят за каждым из разделов исследования? Теперь, когда функции и данные определены, можно ответить на технические вопросы. Например:
- Какие интеграции потребуются в проекте?
- Как обеспечить актуальность данных?
- Какие отчеты нужны на сайте?
- Применим ли умный фильтр?
- Как должна работать фича Х?
Универсальный список вопросов составить нельзя — они возникают в ходе исследования и зависят от специфики проекта.
11. Рекомендации по продвижению
Как правильно продвигать такой проект? Значительная часть предварительного исследования проводится маркетологом. Уже на этом этапе можно сделать глобальные выводы о стратегии продвижения: как делать контекст, как делать SEO (и надо ли)? Стоит ли размещать баннеры на сайте? Нужно ли мобильное приложение?
12. Риски
Какие риски есть в проекте и как ими управлять? На этом этапе выполняется отдельное исследование. Вспоминаем PMBOK:
- Идентификация рисков — определение перечня рисков.
- Качественный анализ рисков — расстановка приоритетов рисков.
- (Количественный анализ рисков — численный анализ эффекта рисков, пропускаем на предварительном исследовании)
- Планирование реагирования на риски — разработка вариантов реагирования
- Составление плана контроля рисков — определение регламента
Последовательно заполняются таблицы:
13. Этапы запуска
Как стартуем проект? Т.к. для простых проектов предварительное исследование не нужно, ответ очевиден: в несколько этапов. Проставив приоритеты функциям проекта нужно составить поэтапный план запуска.
14. Предварительная смета
Сколько же это будет стоить и когда результат? После завершения предварительного исследования все глобальные вопросы должны получить ответы. А раз есть план план запуска по этапам, можно дать предварительную оценку работ.
Заключение
Провести подобное исследование реально за 60-100 часов, но требуется комплексная работа разных специалистов: проектировщика, маркетолога и разработчика. У нас есть квалифицированные сотрудники и 15-летний опыт веб-разработки.
ИНТЕРВОЛГА имеет все возможности для анализа рынка, проектирования решения, веб-маркетинга и аналитики, а затем разработки и запуска проекта по e-commercе и автоматизации внутренних проектов. Задумали сложный проект? Ищете отраслевую экспертизу? Напишите нам: Фудтех , Фарма , Логистика .
Полезные ссылки:
• Разработка и доработка проектов на 1С-Битрикс.
• Настройка интеграции с 1С любой сложности.
• B2B-платформа для автоматизации оптовой торговли.
• Техническая поддержка сайтов.