7 причин провалов при заказной разработке мобильного приложения

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

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

Причина неудачи #1: Менеджер по продажам завышает ожидания и обещает золотые горы

Первый, с кем знакомится клиент — это менеджер по продажам (сейлз). Он — лицо компании-разработчика на этапе выбора подрядчика.

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

Главная мотивация сейлза — продажи. Чем больше контрактов и чем они дороже, тем больше его бонус.

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

Что стоит учитывать

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

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

Причина неудачи #2: Недостаточная техническая экспертиза подрядчика

Больной вопрос для многих заказчиков: как понять, что эти ребята потянут уровень проекта и не придется через год переписывать всё с нуля? Как узнать, что «под капотом»?

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

Что стоит учитывать

1. Посмотрите работы подрядчика. Удобство приложений, уровень дизайна, отзывы в «сторах» и историю обновлений.
2. Скачайте и протестируйте приложения. Рекомендую не просто запустить, а попробовать выполнить сценарии использования. Особое внимание уделите нестандартным сценариям. Например, работе без или с плохим интернетом.
3. Изучайте последние выпущенные приложения. Многим компаниям на заре мобильной разработки повезло поработать с крупными брендами, но это было давно. Узнайте, что из себя представляет компания сейчас.
4. Сильные разработчики часто делятся опытом и знаниями: выступают на конференциях, пишут статьи, «шарят» наработки в github. Поинтересуйтесь вкладом компании в отрасль.
5. «Не кладите все яйца в одну корзину». Заключите договор не на весь проект, а на малую часть. Если сроки будут сорваны или качество будет хромать, можно с минимальными потерями переключиться на другую компанию.

Причина неудачи #3: Обозначены неадекватные сроки

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

Большинство компаний добавляет в оценку буфер — время на согласование и отладку или рисковый бюджет.

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

• согласование и подписание договора — 1 неделя;
• сбор требований на разработку и написание ТЗ — 2-3 недели + время на согласование;
• проектирование интерфейса — 1-2 недели + время на согласование;
• дизайн — 1-2 недели + время на согласование;
• разработка — 1 месяц;
• тестирование и отладка — 1 неделя + время на тестирование заказчиком.
• загрузка приложений в App Store и Google Play — 1-2 дня, если все пройдёт гладко.

ИТОГО (от идеи до воплощения проекта) — минимум 2,5 месяца.

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

Что стоит учитывать

Смотрите реально на сроки выполнения и используйте стратегию MVP (Minimum Viable Product): начните с минимального функционала.

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

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

Причина неудачи #4: Неправильно рассчитан бюджет

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

Не могу вспомнить ни один успешный продукт, который не выпустил хотя бы десяток обновлений.

Что стоит учитывать

Держите в голове, что вам понадобится дополнительный бюджет на развитие и продвижение. Лучше упростите идею до минимума и реализуйте (про MVP я уже говорил). Сосредоточьтесь на основном функционале, остальное вам подскажут пользователи. А после релиза развивайте исходя из данных аналитики и отзывов аудитории.

Причина неудачи #5: Изначально бесполезный проект

Бессмысленные проекты могут принести деньги, но их нельзя положить в портфолио. Опытные студии не берутся за них. Доработок не будет, так как проект умрёт при старте, а команда проекта будет противиться делать то, что никому, кроме заказчика, не нужно. Самые упёртые и талантливые разработчики могут даже уволиться, ещё и команду прихватить, только бы не заниматься тем, что откровенно не нравится. Плохие проекты демотивируют.

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

(Но это не значит, что другие разработчики не позарятся на ваши деньги без каких-либо обсуждений.)

Что стоит учитывать

Совет стартапам

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

Совет работающему бизнесу

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

Совет для всех

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

Причина неудачи #6: Незнание собственного продукта

Классические примеры лидов, которые к нам часто приходят:

1. Описывают проект завуалировано, так как это «супер-пупер ноу-хау», но хотят хотя бы примерную оценку сроков и стоимости с погрешностью не более 20-30%.
2. Хотят всего и побольше. Например, соцсеть с возможностью обмена фото и видео, поиском достопримечательностей на карте, построением маршрута до них, аудиоэкскурсией, возможностью заказа такси, интеграцией с умными часами и геймификацией для удержания пользователей.
3. Просят сделать для них клон Uber, Instagram, Prisma или Pokemon Go. Обычно просят точную оценку: «У вас же есть пример. Нужен точно такой же продукт, но под нашим брендом».

Факт: не бывает двух одинаковых приложений!

Для точной оценки нужны подробные материалы (ТЗ, мокапы экранов). Чем меньше вводных, тем ниже точность оценки.

Совет

Если ваша идея хороша и вам нужно мобильное приложение, распишите хотя бы кратко: что умеет, зачем нужно пользователю, что будет делать и как вы планируете зарабатывать на нём. Такой документ займет минимум 2-3 страницы, но даже это поможет вам чётче сформулировать идею, а разработчикам — более точно оценить проект на этапе пресейла.

Причина неудачи #7: Неиспользование экспертизы подрядчика

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

Простой совет

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

Заключение: как получить то, что нужно?

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

В самом начале:

• определитесь, что за проект вы хотите сделать, кто его ЦА, как на нём зарабатывать;
• опишите проект и постарайтесь выделить MVP;
• определите, какой исполнитель вам нужен. Выберите два из трёх параметров: дёшево, быстро, качественно.

При выборе исполнителя:

• ориентируйтесь на портфолио и отзывы;
• опыт и техническую экспертизу;
• состав команды и мнение/отношение к проекту.

Начиная работу:

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

После запуска проекта:

• следите за цифрами и показателями;
• прислушивайтесь к мнению пользователей;
• стройте гипотезы, изучайте конкурентов. На основе этого совершенствуйте продукт;
• помните, что загрузка приложения в магазины — это только начало!

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

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