Как создать маркетплейс: технический ликбез

Денис Гордиенко, руководитель Bright Mobile, — о том, что нужно знать основателям при создании маркетплейса.

В закладки

Предприниматели сильны в своих идеях, но часто не имеют технических знаний в разработке сайтов и приложений. Из-за этого возникают трудности на всех этапах развития маркетплейса. В рамках обучающего курса m-p.academy провёл вебинар по базовым вопросам при создании маркетплейсов.

Принцип первой версии

Первая версия приложения выполняет главную задачу процесса. В этой версии может не быть красивого дизайна или каких-то функций, удобных, но не принципиальных для основной идеи. Первая версия решает задачу, для которой пользователь скачивает приложение или заходит на сайт. Если говорить по-простому, то MVP — это тест, стоит ли дальше развивать тему или такая идея никому не интересна.

1. Правило 20 экранов

Если при проектировании в приложении получилось больше 20 экранов, то скорее всего, вы внесли в проект больше функций, чем это необходимо на первом этапе. Это не тотальное правило, но повод основательно задуматься.

Например, для доски объявлений нужны пять основных экранов:

  • Регистрация и авторизация.
  • Профиль.
  • Лента объявлений.
  • Создание объявлений.
  • Просмотр объявлений.

И дополнительные экраны, такие как переписка пользователей или уведомления, — уже опциональная вещь. Лучше сделать пять экранов и услышать от пользователей требования расширить функциональность, чем сделать 50 и после запуска понять, что 30 из них никому не нужны. Детальнее о таком подходе можно почитать в Lean Startup.

2. Максимальный срок разработки — два месяца

Если уходит больше, это значит, что проект слишком большой (смотри первый пункт). Либо задержки идут со стороны автора проекта: одобрение технического задания, проверка приложения, принятие актов и тому подобное. Обычно это происходит, если есть основной бизнес и остаётся только пара часов на стартап.

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

У стартапов перед лидерами рынка только одно преимущество — скорость. Стартап может быстро внедрять изменения. Если растягивать этап разработки, то можно лишиться единственного преимущества.

3. Гипотезы для проверки и средства измерения

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

Важный момент, на который обращают внимание инвесторы, — сходимость юнит-экономики. Если объяснять дилетантски, то экономика сходится, если на каждый вложенный в маркетинг рубль сервис зарабатывает больше одного рубля. Более глубоко можно почитать здесь.

Если гипотеза реализуется, то благодаря чему? Часто бывает, что основатель думает, что пользователям нужна одна функциональность, а приложение выстреливает совсем по другой причине. Как пример — YouDo, который начинался как сервис шуточных заданий. Здесь нужно не навязывать то, что было задумано ранее, а подхватить волну спроса.

Понять, из скольки экранов будет состоять приложение, сколько времени уйдёт на его разработку, и проверить часть гипотез можно ещё до создания приложения или сайта.

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

4. Что, если «нет»?

Маркетплейс — это стартап, который потребует много сил и (чаще всего) средств. И если бизнес-модель нерабочая, то чем раньше предприниматель это поймёт, тем лучше. Сначала делают MVP-версию: если «взлетит» — добавляют функции, которые необходимы пользователям, и развивают проект дальше.

Сама суть MVP в том, что если идея находит свой отклик, то вы попадаете в счастливое число 2% стартаперов, у которых получилось (речь не о «единорогах», а о выходе на стабильный бизнес). Если нет, то потратите меньше денег, чем могли бы.

Стек технологий: сайт

В большинстве случаев на первые несколько лет используется стандартный для веба стек: PHP + mySQL на какой-нибудь популярной CMS.

Для маркетплейсов сейчас есть готовые решения от «1С-Битрикс» (доски объявлений), Wordpress (доски и товарные маркетплейсы), CS-Cart (товарные маркетплейсы). Здесь важно оценить, во сколько вам обойдётся доработка под себя. Рекомендовал бы самостоятельно выбрать решение и уже на FL или в студиях оценить именно доработки под вашу идею. Это позволит существенно сократить бюджет на старте.

Если кажется, что ни одно готовое решение вам не подходит, нужно вернуться к первому пункту — можно ли упростить ваш проект? История о том, что ваша идея настолько уникальна, что нет даже примерных аналогов, вызывает больше вопросов, чем уверенности. Скорее всего, подобные проекты уже были, но что-то пошло не так. Вопрос в том, что именно и учли ли вы это у себя.

Стек технологий: приложения

По приложениям на рынке сформировалось три принципиальных подхода:

  • Нативная разработка.
  • PWA, webview.
  • Кроссплатформенная разработка.

Натив — это написание приложения с нуля, отдельно под iOS, отдельно под Android на родных Swift, Objective-C и Java. Чаще всего нативщики хвастаются скоростью работы и реализацией любой мыслимой функциональности, начиная от игры, заканчивая простеньким бизнес-приложением.

В целом они правы, но, само собой, 99% успеха в прямых руках программиста (помните, сколько грузилось приложение «Сбербанка» полгода назад?). Цена, соответствующая возможностям технологии.

PWA — мобильный сайт, на который можно перейти не из браузера, а при нажатии на иконку, как и в приложении. Webview — мобильный сайт, обёрнутый в приложение-контейнер. Стек самый дешёвый из всех трёх, так как вы покупаете веб-разработчика, которых на рынке очень много.

Ограничений в технологии достаточно много. Очень не многие могут грамотно работать с push (а в PWA — это не на всех устройствах возможно), GPS страдает, скорость загрузки зависит от соединения с сервером. Технология подойдёт для простеньких приложений, где нет большой нагрузки на сервер и само устройство.

Кроссплатформа — это когда приложение разрабатывается в одном стеке, а потом уже компилируется под iOS и под Android. Благодаря этому экономится время (работает один программист, а не два, как в нативе), что отражается на стоимости.

Из минусов я вижу ограничения по анимации и 3D-объектам. На мой взгляд, такое решение идеально подходит для бизнес-проектов, но не подойдёт для игр и подобных «тяжёлых» приложений с VR и AR.

Процесс разработки маркетплейса

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

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

Суть их сводится к тому, что команда имеет общее понимание, что она реализует, а в процессе реализации:

  • Ставится задача на неделю.
  • Выполняется.
  • Отчёт перед оунером.
  • Возвращаемся к первому пункту — и так по кругу, пока проект не будет полностью готов.

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

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

Поддержка и развитие после запуска

Затраты на программиста — постоянные, как и на маркетинг. Рынок развивается постоянно, и вам придётся регулярно делать обновления, доработки.

Работу программиста оплачивают двумя способами:

  • За фактические затраченные часы (время и материал).

Программист взял задание, сделал, сказал вам, сколько часов потратил, вы оплатили.

  • За выполненную доработку.

Программист говорит вам фиксированную стоимость, и неважно, сколько времени займёт по факту.

В итоге, всё сводится к управлению риском «что, если не уложился в оценку?». В первом случае — риск на вас, и вы оплачиваете фактическое время. Можно сэкономить, если программист сделал всё быстрее оценки, но и дополнительно оплатить, если не уложился.

Во втором — цена фиксированная, но, как правило, выше оценки по ТМ. Если программист реально оценивает задачу в десять часов, он назовёт тринадцать (на всякий случай). Это не хорошо и не плохо — он тоже управляет своими рисками. Важно ответить себе на вопрос, что для вас выгоднее — заплатить меньше или зафиксировать бюджет, который не изменится.

Выбор команды

Есть три варианта, куда обратиться:

  1. Фрилансеры. Обитают на FL.
  2. Студии. Наиболее адекватный «Рейтинг Рунета».
  3. In-house-разработка. Тогда прямая дорога на HH.

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

Фрилансеры

  1. Дёшево.
  2. Прямой контакт с программистом.

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

Кроме того, нужно иметь ввиду важный нюанс. Человеку должно быть выгодно работать с вами. В ином случае — он найдёт себе другого заказчика, с которым будет комфортнее работать.

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

Тем не менее нужно обязательно просить исходники. Чтобы в случае конфликтных ситуации можно было обратиться к другому программисту даже с условиями частичного рефакторинга. Но чаще всего выгоднее помириться с автором кода.

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

Студии

  • Дорого.
  • Риск неадекватного ПМа.

ПМ — это человек, который курирует создание вашего приложения в студии. В его задачах — говорить вам о том, как идёт разработка, о возникших проблемах, предлагать решения. Бывают менеджеры, которые не хотят конфликтов с заказчиками и при проблемной ситуации до последнего умалчивают об этом.

Не предупреждают заказчиков о возможных сдвигах сроков, удорожании разработки и так далее. Всё это выливается в непрогнозируемые проблемы уже у вашего стартапа. На мой взгляд, честность и профпригодность ПМа в большинстве случаев даже более важна, чем квалификация программиста.

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

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

У студии помимо вас есть ещё другие заказчики. И в приоритете будут те, кто быстро отвечает, вовремя производит оплату, вовлечён в процесс. Грубо говоря, когда административный ресурс студии задействован по-минимуму, а производственный — работает на полную.

In house

  • Очень дорого.
  • Зато свои.

Иногда у основателей появляется ложное ощущение, что собственный программист выйдет дешевле. Это основано на том, что нормального программиста можно купить на рынке за 80 тысяч рублей в мес (500 рублей в час), а студии за тот же час просят минимум 1200 рублей (оборзели?). Однако не учитывается ряд важных деталей, которые в эту стоимость заложены.

Вам необходимо будет придумывать, как грузить программистов, чтобы не было простоя. То есть если задач нет и программист простаивает, то зарплата всё равно капает. Это отражается и в мотивации. Налоговая нагрузка также на вас, если всё вбелую, то +33%.

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

Подбор новых, отпуска, как и риски за простой — тоже проблемы, появляющиеся из-за прямого найма.

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

Заключение

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

  1. Быстро проверять идеи с фрилансерами и получать подтверждение гипотезы рынком.
  2. Делать основательную версию со студией и развивать до стабильной выручки.
  3. Переходить в in house, когда есть выручка с проекта и стоит вопрос об инвестициях и масштабируемом экспоненциальном росте.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 17, "likes": 19, "favorites": 163, "is_advertisement": false, "subsite_label": "life", "id": 79466, "is_wide": false, "is_ugc": true, "date": "Tue, 20 Aug 2019 17:17:38 +0300", "is_special": false }
0
{ "id": 79466, "author_id": 127886, "diff_limit": 1000, "urls": {"diff":"\/comments\/79466\/get","add":"\/comments\/79466\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/79466"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199123, "last_count_and_date": null }
17 комментариев
Популярные
По порядку
Написать комментарий...
8

Ребзя, пилите MVP на Тильде за 1 день, рекламу на второй, новый проект на 3-ий )

Ответить
0

Хороший совет. Конкретно в статье не стал писать, т.к. речь о маркетплейсах. В тишьду вендоров не получится прикрепить. Если только ей общий спрос измерить

Ответить
1

Для маркет-плейсов на этапе MVP, тоже подходит, для парку 10-ов товаров подойдёт. Через форму - "Оставить заявку", под товаром.

Ответить
2

А что вы имеете ввиду под термином "маркетплейс"?

Ответить
2

Система, где сводятся две роли пользователей, со взаимными интересами. Чаще всего выделяют три типа:

1. Товарный маркетплейс. Продавцы через площадку выкладывают товар, покуматели заказывают всё в едином интерфейсе. Примеры - Яндекс.Маркет, Озон, Вайлдбериз

2. Доски объявлений. Одни пользователи размещают объявления о продаже или каком-то событии, а вторые пишут напрямую. Примеры - Авито, Юла

3. Маркетплейсы услуг. Заказчики услуг пишут заявку что им нужно, исполнители откликаются, предлагая свои услуги, заказчик выбирает кто больше нравится. Примеры - fl.ru, youdo, Профи.ру

Ответить
1

Имеет ввиду поиск новых клиентов на vc с помощью простыни текста.

Ответить
2

Хорошо написано, без воды, спасибо.

Скажите, а вот решения от 1С-Битрикс, которые вы упомянули, это полноценные отдельные продукты, которые передаются в виде кода покупателям, или это нужно быть как-то связанным с битриксом и что-то куда-то интегрировать?

И, пользуясь случаем, еще один вопрос: на Ваш взгляд, каковы основные преимущества решений подобных битриксу, которые стоят десятки тысяч рублей, перед теми же решениями от wordpress, которые либо бесплатные либо значительно дешевле? Будет интересно узнать мнение эксперта.

P.S. Я намеренно не провожу аналогию с решениями вашей компании, потому что у вас все-таки мобильные приложения(если я правильно понял), а не сайты.

Ответить
1

Спасибо за высокую оценку :) По Вашим вопросам:

1. Это передаётся с открытым кодом. Т.е. на маркетплейсе битрикса покупается понравившийся шаблон с редакцией CMS и вы получаете исходники, которые ставите себе на хостинг и используете на своё усмотрение.

2. Главное преимущество Битрикса - есть с кого спросить :) Если у вас что-то сломалось, то можно напрячь поддержку Битрикса, либо через них достать нерадивого партнёра. Если сайт собирал фрилансер на вордпрессе, то гарантий никаких. Ну и лично мне в Битиркс нравится архитектура. Свой прошлый стартап делали с ядром на Битриксе, но это вкусовщина, нужно ориентироваться на программиста, которого берёте в команду, если он сторонник WP, то кнутом не заставишь делать на Битриксе.

3. Да, мы занимаемся приложениями для маркетплейсов. Сайты тоже делаем, но только в качестве комплексного договора (вместе с приложением) и только при нестандартных требованиях к проекту, где обычный php+mySQL+CMS не удовлетворяют.

Ответить
1

Большое спасибо

Ответить
1

Добрый.
А есть вариант оценить и дать консультацию по существующему маркетплейсу? Консультация в плане развития глазами специалистов?

Ответить
0

Автор, mvp - это не про магазин на вордпресс или битрикс.

Ответить
2

Почему? Здесь MVP это Minimum Viable Product.

Ответить
2

Более того, MVP часто делают на каком-то готовом решении, а если выстрелит, то пилят кастом.

Ответить
0

Зависит от идеи. Если идея - новая логистическая система с космической скоростью доставки, например, электроники, то достаточно запилить за неделю сайт на любом шаблоне магазина, заполнить контентом и добавить калькулятор нашей чудо-доставки, чтоб проверить готовы ли клиенты платить космические деньги за космическую доставку. Пускаем 10 тыс посетителей трафика и считаем конверсию.

Чем это не MVP?

Ответить

Комментарий удален

{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ] { "page_type": "default" }