Обновление Март 2020

Мы сделали подробную статью Как сделать платформу аукционного типа – со скринами демо и описанием как что работает.

Посмотреть демо товарного маркетплейса
Посмотреть демо аукциона (выбор подрядчика на проект)

Маркетплейс – это сложный интернет-проект. В одной из статей мы рассматривали Карту рисков для маркетплейса.

Один из способов уменьшения рисков – это точное следование порядку создания агрегаторов. Если у вас нет веской причины отклоняться от него, то лучше просто следовать этой практике.

Точное следование процессу упрощает проект

Итак, что же включает в себя порядок создания маркетплейса при веб-разработке с нуля:

  1. Концепция проекта. Это документ, описывающий общие положения относительно маркетплейса. Кто наш клиент? Как мы будем раскручивать маркетплейс? Чем мы отличаемся от других? Какие основные блоки маркетплейса? Ориентировочные параметры проекта (бюджет, сроки, объем). Более подробно концепцию проекта мы рассмотрим в будущих статьях.
  2. Грубая оценка проекта. На основании концепции вы можете попросить специалистов сделать грубую оценку проекта. На данном этапе невозможно дать точную оценку стоимости проекта. Поэтому не требуйте точности – просто поймите общие рамки проекта. Оценка должна делаться специализирующимися компаниями или специалистами, которые делали подобные проекты. Они дадут вам эту оценку на основании исторических данных. Также вы можете грубо оценить используя наш калькулятор стоимости портала. 
  3. Детализация первой версии проекта в виде технического задания (ТЗ). Найдите одного подрядчика под написание ТЗ. Рассматривайте этот этап как дополнительную проверку подрядчика. Уже на этом этапе будет понятно отношение подрядчика к делу и, в частности, к вашему проекту. Агрегатор должна быть детализирована до мелочей. Чем больше белых пятен останется, тем выше риски проекта. Также помните, что крупные структурные исправления стоят гораздо дороже чем, детальная проработка на уровне задания. Ваша задача – вместе с выбранным автором ТЗ заложить ядро будущей системы, которую можно будет развивать и совершенствовать.
  4. Детальная оценка по ТЗ. Декомпозируем всю систему на мелкие детали и каждую оцениваем отдельно в формате min-max в нормированных часах. Сделать это должен технический специалист, а не менеджер. В итоге вы получите ориентировочный бюджет. Лучше сразу считайте по max планке – будут дополнительные доработки, исправления ошибок, неучтенная сложность функционала. Программисты в оценке обычно используют оптимистичный подход, что все будет хорошо и они реализуют систему по намеченному плану. Но при этом обычно они не учитывают очень много нюансов: возможные проблемы производительности,  заказчик в ТЗ имел в виду что-то другое, ошибки проектирования в ТЗ, неучтенные дополнительные работы, например, настройка SSL на сервере и т.д.
  5. Разработка проекта по этапам. Разработка по этапам снижает риски и разработчика, и заказчика.  Заказчик получает больший контроль над проектом. Также есть возможность в некоторых случаях раньше дать первым пользователям поработать в системе, тем самым получить раннюю обратную связь, что хорошо для проекта. На этой стадии очень важно, чтобы заказчик не расслаблялся и не выпускал нити контроля из своих рук. ТЗ является по сути контрактом, который реализует разработчик. Но при этом понимание отдельных вопросов ТЗ может иметь разночтение, поэтому заказчик должен постоянно давать обратную связь по реализованным механизмам маркетплейса.
  6. Внедрение в эксплуатацию. Следующий шаг – это запуск маркетплейса в эксплуатацию. Существует ряд мер, которые необходимо выполнить, чтобы обезопасить себя от возможных проблем при запуске.

К ним относятся:

  • настройки сервера и окружения маркетплейса;
  • внешние сервисы;
  • общее тестирование;
  • тестирование производительности;
  • поисковая оптимизация;
  • система оповещения о проблемах.
  1. Сопровождение. На этом этапе разработка проекта не заканчивается, а только начинается. Проект должен постоянно развиваться и улучшаться. В любом случае будут находиться баги, будут возникать новые идеи как сделать удобнее и т.д. По сути процесс повторяется. Вы пишете новое мини ТЗ. Разработчики его выполняют по этапам и внедряют в рабочую систему.
  2. Продвижение маркетплейса. Продвижение можно делать параллельно разработке. Вы можете создавать семантическое ядро, готовить контент, искать первых лояльных пользователей, делать промо материалы, запускать группы в социальных сетях и т.д. Вам не нужно ждать завершения разработки, чтобы приступать к продвижению. Более того, об этом пункте лучше заранее подумать, т.к. в любом случае продвижение будет влиять на функции движка маркетплейса.

Начните с концепции проекта и постепенно двигайтесь по этапам, итеративно улучшая свою площадку.

Более подробно процесс создания маркетплейса и как сделать аукцион читайте в наших следующих статьях.

Также вы можете посмотреть информацию о нашем решении для маркетплейсов – готовый движок маркетплейса.