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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Маркетплейс — это стартап, который потребует много сил и (чаще всего) средств. И если бизнес-модель нерабочая, то чем раньше предприниматель это поймёт, тем лучше. Сначала делают 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. Прямой контакт с программистом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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