Не допустите 6 ошибок, которые делают 80% заказчиков мобильной разработки – советы от HandsApp

Исходя из опыта нашей команды, около 60% компаний впервые заказывают мобильную разработку. Штатные ИТ-специалисты и вовсе есть едва ли у каждого пятого заказчика.

Такие «новички» нередко нарываются на недобросовестные компании, которые оказывают некачественные услуги. Например – выдают MVP за полноценное предложение (с соответствующим прайсом).

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

№ 1. Разработка «с нуля под ключ»

«Под ключ» – это маркетинговое клише. Некоторые студии мобильной разработки используют его в своей рекламе, и тем самым – вводят клиента в заблуждение. И вот почему.

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

№ 2. Выбор команды

При выборе подрядчика есть два весомых фактора.

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

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

Два этих фактора в ближайшей перспективе приведут к появлению большого количества студий, в которых работают вчерашние ученики, которыми руководит точно такой же «джун».

Какое приложение может сделать команда новичков, которая не имеет представления о процессе и опыта коммуникации с заказчиком (де факто – работает без проджекта) – остается только гадать.

№ 3. Перегруженный функционал.

Здесь можно выделить две распространенные ошибки:

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

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

Избежать этих ошибок на старте довольно просто, если следовать по пути разработки минимальных продуктов.

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

№ 4. Приложение «для себя»

Я долго думал, как наиболее полно раскрыть этот фактор, не углубляясь при этом в глубины маркетинга. И решил сделать это с помощью аналогии.

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

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

Затем вы полностью убираете из пиццы мясо, потому что вы его не едите. А курьеров нанимаете только пеших, потому что автокурьеры вредят экологии.Через месяц такой бизнес закроется. Потому что целевой аудитории нужны вежливые, а не рыжие. Она хочет сытную еду за оптимальный прайс и доставку горячей, а не безвредной для экологии пиццы.

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

№ 5. Игнорирование различий между ОС Android и iOS – это разные операционные системы, с массой индивидуальных особенностей.

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

Кнопки.

Львиная доля Android-устройств имеют кнопки. Все последние модели Iphone напротив, выпускаются без кнопок.

Модерация сторов.

Приложение, которое без проблем прошло модерацию GooglePlay, может провалиться при модерации в Appstore, и наоборот.

Разница в разработке.

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

Даже если разработка ведется только под одну операционную систему (чаще всего это Android) опытная команда быстрее пройдет модерацию сторов и допустит меньше ошибок в разработке. Это позволит существенно сэкономить время на запуск.

Что касается iOS-разработки, моя команда использует свой, авторский подход, о котором я рассказывал в этой статье.

№ 6. Агрессивный маркетинг и монетизация

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

В ходе разработки и на ранних этапах запуска не стоит агрессивно «тыкать» в пользователя баннерами при каждом нажатии и присылать push-уведомления дважды в день. Дайте приложению «прижиться» на рабочем экране.

Чек-лист: как заказать разработку и избежать большинства ошибок

Теперь поговорим о том, как избежать этих и многих других ошибок:

Ознакомьтесь с теорией. Для этого не нужно штудировать специальную литературу (или Хабр), о мобильной разработке. Есть много «адаптированных», статей, где простым языком рассказываются азы и принципы.

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

Составьте четкое и подробное ТЗ. Речь идет не о технических компетенциях, а о задачах и целях: какое количество пользователей вы рассчитываете привлечь, планируете ли расширять функционал в будущем, какую проблему компании должна решать программа.

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

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

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