Мы собрали топ-7 ошибок, которые часто допускаются при разработке мобильного приложения или сайта для маркетплейса. Мы специально не сортируем их по рейтингу, так как в зависимости от типа проекта и подготовленности клиента влияние описанных моментов меняется. Постарайтесь избегать этих ошибок в своём проекте.
Первая версия — огромный «слон»
Бывает, что при разработке сайта или приложения с «нуля» ставится задача на проработку не 20 экранов, а 40, 50 и более. Из-за этого работы по запуску растягиваются на год вместо
Не проверяется бизнес-гипотеза
Этот момент вытекает из предыдущего. То есть маркетплейс разрабатывается только потому, что есть классная идея. Просто на Западе запустился такой же проект или вышла новая технология. Часто вообще не думают о каких-либо метриках успешности. Например, что будет, если за первый месяц приложением воспользуются 300 пользователей и они отправят 20 заявок? Этого достаточно для бизнеса или мало? Возможно, стоит заложить в бюджет запуска и расходы на маркетинг?
Читайте также: Как настроить маркетинг маркетплейса
Надежда на технологию, а не на бизнес-процесс
Когда делается клон Юду, но переписывается на новом модном языке (Дарт, например) и предполагается, что только за счёт этого сработает бизнес-модель. Не сработает. Если в вашем маркетплейсе нет ничего нового или ценного с точки зрения клиента, а есть только новые технологии — лучше забыть про эту идею, так как это будет дорого и бесперспективно.
Технология может помогать что-то делать дешевле, что-то быстрее, давать какую-то дополнительную ценность, то есть помогать вам заработать на том, на чём другие не зарабатывают. Но технология не может быть основой самого бизнес-процесса или монетизации. Основа монетизации должна исходить от выгоды вашего пользователя, который приносит вам деньги.
Читайте также: Что использовать при разработке сайта и приложения для маркетплейса
Экономия на разработчике
По нашему опыту, процентов 60 клиентов — это люди, которые один или несколько раз обожглись на фрилансерах. Экономия на разработчике приводила к тому, что он просто не справлялся с задачей в силу отсутствия опыта, поэтому нужно было либо много переделывать либо вообще разрабатывать заново. Желание сэкономить понятно, но скупой платит дважды.
Требования к MVP (минимально жизнеспособному продукту) как к лидерам рынка
Такое часто бывает с разработкой мессенджеров. Например, есть требование держать 10 млн онлайн-подключений, но при этом нет понимания, когда эти 10 млн пользователей будут, как они будут достигнуты, зачем вообще там 10 млн подключений онлайн, но требования всё равно выставляются. Исходя из них рассчитывается смета разработки и если нужно выдерживать высокие нагрузки, то стоимость будет минимум 3 млн рублей. А вот если бы задача была поставлена так, что в первый год меньше 100 тыс. пользователей онлайн, то разработка оценивалась бы в 10 раз дешевле.
Здесь важно соотносить собственные амбиции и возможности. Может быть имеет смысл сначала запустить MVP, который будет держать тысячу пользователей, а когда вы будете упираться в этот порог, сделать какой-то рефакторинг и внедрить технологии для высоких нагрузок. То есть не нужно бежать впереди паровоза и выставлять требования, которые не достижимы в перспективе ближайших нескольких месяцев. Иногда выгоднее поставить меньшие требования и менять их постепенно, чем сразу ставить завышенные и поплатиться за это бОльшим бюджетом.
Отсутствие выводов
Когда что-то создаётся, нужно понимать насколько хорошо или плохо идет процесс. Если плохо сделали, то почему? Если хорошо сделали, опять же, почему? Что нам помогло достичь такого результата? Неправильные выводы или, ещё хуже, их отсутствие приводит к тому, что разрабатывается функционал, который не нужен пользователям и делаются ненужные маркетинговые активности.
Смена команды в процессе разработки
Даже в ситуации, когда вы не согласны с чем-то, иногда проще немного доплатить разработчику, чтобы он довел проект до конца и уже потом принимать решение о смене команды. Очень часто новые разработчики говорят, что нужно делать заново либо откатываться до предыдущей ветки разработки. Такая смена «лошадей на переправе» гарантированно приведёт к удорожанию разработки.
