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

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

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

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

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

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

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

В большинстве случаев на первые несколько лет используется стандартный для веба стек: 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.

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

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

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

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

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

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

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

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