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

Виктор Черногоров
Директор по развитию MobileUp

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

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

Первый, с кем знакомится клиент — это менеджер по продажам (сейлз). Он — лицо компании-разработчика на этапе выбора подрядчика.
Главная мотивация сейлза — продажи. Чем больше контрактов и чем они дороже, тем больше его бонус.
Сейлзам каждый день приходится общаться с множеством потенциальных клиентов, единицы которых превращаются в заказчиков. Поэтому они часто занижают стоимость и завышают перспективы будущего проекта. Так легче продать.
Что стоит учитывать
Живое общение и воодушевление сейлза — это здо́рово, но лучше познакомьтесь с человеком, который будет руководить разработкой. У него наверняка более реалистичные взгляды на проект, сроки и стоимость.
Причина неудачи #2
Недостаточная техническая экспертиза подрядчика
Больной вопрос для многих заказчиков: как понять, что эти ребята потянут уровень проекта и не придется через год переписывать всё с нуля? Как узнать, что «под капотом»?

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

По опыту, минимальный срок разработки проекта будет складывается из следующих пунктов:
    1
    Cогласование и подписание договора — 1 неделя.
    2
    Cбор требований на разработку и написание ТЗ — 2-3 недели + время на согласование.
    3
    Проектирование интерфейса — 1-2 недели + время на согласование.
    4
    Разработка приложения — 1 месяц.
    5
    Тестирование и отладка — 1 неделя + время на тестирование заказчиком.
    6
    Загрузка приложений в 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.ru
    Если материал вам понравился, расскажите о нем друзьям. Спасибо!
    Читайте также:
    Один раз в месяц мы присылаем статьи на почту