Рубрики:

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

Прочтёте за 5 мин.

Как адекватно оценить сроки, бюджет на разработку и квалификацию подрядчика

IT-инструменты, которые использует Виктор Черногоров

  • Tagline
  • Slack
  • Facebook, Вконтакте

Разработка мобильного приложения - довольно сложная услуга, требующая не только финансовых инвестиций, но и вовлечения заказчика почти во все процессы. Как понять, что разработчик потянет проект? Как оценить его квалификацию? Как контролировать качество и сроки? Директор по развитию питерской компании MobilUp Владимир Черногоров рассказал о наиболее распространенных причинах провалов разработки приложений и о том, как этих ошибок можно избежать.

Досье

Виктор Черногоров, директор по развитию компании  MobileUp (разработка мобильных приложений). Образование: Санкт-Петербургский государственный университет экономики и финансов (ФИНЭК). MobilUp входит в топ-10 мобильных разработчиков России по версии «Рейтинга Рунета», среди её клиентов – МТС, Tutu.ru, «Тинькофф», «Рив Гош» и другие известные бренды.

Виктор Черногоров

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

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

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

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

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

  • Смотрите на факты. Если у компании портфолио «не очень», а сейлз говорит, что они всё сделают на высшем уровне - возможно, у них крутой менеджер по продажам, но не команда. (О том, как оценивать работы в портфолио - читайте ниже).

Причина вторая: недостаточная квалификация подрядчика

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

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

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

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

  • Скачайте и протестируйте приложения. Рекомендую не просто запустить, а попробовать выполнить сценарии использования. Особое внимание уделите нестандартным сценариям. Например, работе без или с плохим интернетом. 

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

  • Сильные разработчики часто делятся опытом и знаниями: выступают на конференциях, пишут статьи, «шарят» наработки в github. Поинтересуйтесь вкладом компании в отрасль. 

  • Заключите договор не на весь проект, а на часть. Если сроки будут сорваны или качество будет хромать, можно с минимальными потерями переключиться на другую компанию.

Причина третья: заявлены неадекватные сроки

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

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

  • согласование и подписание договора - 1 неделя;
  • сбор требований на разработку и написание ТЗ - 2-3 недели + время на согласование;
  • проектирование интерфейса - 1-2 недели + время на согласование;
  • дизайн - 1-2 недели + время на согласование;
  • разработка - 1 месяц;
  • тестирование и отладка - 1 неделя + время на тестирование заказчиком;
  • загрузка приложений в App Store и Google Play - 1-2 дня, если все пройдёт гладко.
  • Итого (от идеи до воплощения проекта) - минимум 2,5 месяца.
Часть этих этапов могут быть параллельны, но редко бывает быстрее. И учитывайте, что если сегодня вы договорились, не факт, что уже завтра начнётся разработка. Когда компания востребованная, сотрудники не сидят без дела и приступить к работе смогут, когда закончат текущие задачи. У топовых компаний этот срок иногда занимает несколько месяцев. 

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

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

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

Причина четвёртая: неправильно рассчитан бюджет

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

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

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

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

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

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

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

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

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

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

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

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

1. Описывают проект завуалировано (это «супер-пупер-ноу-хау»), но хотят хотя бы примерную оценку сроков и стоимости с погрешностью не более 20-30%. 

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

3. Просят сделать для них клон Uber, Instagram, Prisma или Pokemon Go. Обычно просят точную оценку: «У вас же есть пример. Нужен точно такой же продукт, но под нашим брендом».

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

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

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

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

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

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

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

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

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

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

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

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

Источник: Cossa.ru.

MobileApp 

Читайте также:

Пять причин, по которым «Яндекс» не хочет «видеть» ваш сайт.
Фальшивые отзывы: как предприниматели обманывают клиентов.
Как увеличить конверсию с помощью онлайн-консультанта.

20 сентября 2016

Комментарии

0
  • Прокомментируйте первым.

  • Задайте вопрос
    по автоматизации бизнеса

    Наши эксперты ответят на вопросы по автоматизации бизнеса


    Задать вопрос
    Ваш вопрос отправлен

    Ваш вопрос

    Введите Имя
    Введите E-mail
    Отправить Очистить
Возможно, вас заинтересуют другие наши материалы
Загрузить ещё
Идёт загрузка материалов