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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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