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

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

https://rb.ru/opinion/mobile-2017/
Мобильная разработка — сложная услуга, которая требует денежных вложений и времени заказчика. Как понять, что разработчик потянет проект? Как правильно построить сотрудничество, сделать качественное приложение с первого раза?

Я назову 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;
    • определите, какой исполнитель вам нужен. Выберите два из трёх параметров: дёшево, быстро, качественно.


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

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


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

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


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

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

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