job9087
Учитель
- Регистрация
- 19 Окт 2018
- Сообщения
- 26,110
- Тема Автор
- #1
7 причин провалов при заказной разработке мобильного приложения
Мобильная разработка — сложная услуга, которая требует денежных вложений и времени заказчика. Как понять, что разработчик потянет проект? Как правильно построить сотрудничество, сделать качественное приложение с первого раза?
Назовем 7 распространённых ситуаций, результатом которых становятся неоправданные надежды заказчика. Но всего этого можно избежать, если заранее учитывать некоторые нюансы построения взаимоотношений с подрядчиком.
Причина неудачи #1: Менеджер по продажам завышает ожидания и обещает золотые горы
Первый, с кем знакомится клиент — это менеджер по продажам (сейлз). Он — лицо компании-разработчика на этапе выбора подрядчика.
Главная мотивация сейлза — продажи. Чем больше контрактов и чем они дороже, тем больше его бонус.
Сейлзам каждый день приходится общаться с множеством потенциальных клиентов, единицы которых превращаются в заказчиков. Поэтому они часто занижают стоимость и завышают перспективы будущего проекта. Так легче продать.
- Что стоит учитывать:
Живое общение и воодушевление сейлза — это здо́рово, но лучше познакомьтесь с человеком, который будет руководить разработкой. У него наверняка более реалистичные взгляды на проект, сроки и стоимость.
И смотрите на факты. Если у компании портфолио не очень, а сейлз говорит, что они всё сделают на высшем уровне — возможно, у них крутой менеджер по продажам, а не команда. (Как оценивать работы в портфолио — читайте ниже.)
Причина неудачи #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: Незнание собственного продукта
Заказчики:
- Описывают проект завуалировано, так как это «супер-пупер ноу-хау», но хотят хотя бы примерную оценку сроков и стоимости с погрешностью не более 20-30%.
- Хотят всего и побольше. Например, соцсеть с возможностью обмена фото и видео, поиском достопримечательностей на карте, построением маршрута до них, аудиоэкскурсией, возможностью заказа такси, интеграцией с умными часами и геймификацией для удержания пользователей.
- Просят сделать для них клон Uber, Instagram, Prisma или Pokemon Go. Обычно просят точную оценку: «У вас же есть пример. Нужен точно такой же продукт, но под нашим брендом».
Факт: не бывает двух одинаковых приложений!
Для точной оценки нужны подробные материалы (ТЗ, мокапы экранов). Чем меньше вводных, тем ниже точность оценки.
Совет
Если ваша идея хороша и вам нужно мобильное приложение, распишите хотя бы кратко: что умеет, зачем нужно пользователю, что будет делать и как вы планируете зарабатывать на нём. Такой документ займет минимум 2-3 страницы, но даже это поможет вам чётче сформулировать идею, а разработчикам — более точно оценить проект на этапе пресейла.
Причина неудачи #7: Неиспользование экспертизы подрядчика
Иногда заказчик забывает о конечном потребителе и руководствуется интуицией, собственным вкусом или советами друзей. Такие решения могут обернуться полным провалом, если вовремя не остановиться.
Простой совет
Посоветуйтесь с подрядчиком. Студия, как правило, видела сотни проектов и тысячи экранов, набила шишки и исправляла кучу багов. Цель студии — взаимная выгода: заказчик получает работающий продукт, который приносит ему прибыль, а студия — деньги за разработку, хороший проект для портфолио и, вероятно, контракт на дальнейшую поддержку приложения (как было сказано выше — приложению, которым люди действительно пользуются, нужны доработки и обновления).
Заключение: как получить то, что нужно?
Для разработки качественного продукта и заказчик, и исполнитель должны работать как слаженная команда. Это значит, что вы должны найти нужных исполнителей и придерживаться простых правил «игры».
В самом начале:
- определитесь, что за проект вы хотите сделать, кто его ЦА, как на нём зарабатывать;
- опишите проект и постарайтесь выделить MVP;
- определите, какой исполнитель вам нужен. Выберите два из трёх параметров: дёшево, быстро, качественно.
При выборе исполнителя:
- ориентируйтесь на портфолио и отзывы;
- опыт и техническую экспертизу;
- состав команды и мнение/отношение к проекту.
Начиная работу:
- согласуйте периодичность и формат отчетов;
- выделите время на общение с исполнителем или назначьте того, кто будет курировать разработку;
- не стремитесь сделать максимум функционала за минимум времени и минимум денег. Во всём должен быть баланс;
- ещё лучше, если вы начнете с реализации части функционала, чтобы понять, насколько вам комфортно работать вместе;
- помните о возможных дополнительных тратах;
- помните, что бюджет и сроки зависят и от вас.
После запуска проекта:
- следите за цифрами и показателями;
- прислушивайтесь к мнению пользователей;
- стройте гипотезы, изучайте конкурентов. На основе этого совершенствуйте продукт;
- помните, что загрузка приложения в магазины — это только начало!
Для кого-то это покажется очевидным. Но практика показывает, что многие заказчики мобильных приложений плохо представляют, как будет строиться работа с подрядчиком.
Мобильная разработка — сложная услуга, которая требует денежных вложений и времени заказчика. Как понять, что разработчик потянет проект? Как правильно построить сотрудничество, сделать качественное приложение с первого раза?
Назовем 7 распространённых ситуаций, результатом которых становятся неоправданные надежды заказчика. Но всего этого можно избежать, если заранее учитывать некоторые нюансы построения взаимоотношений с подрядчиком.
Причина неудачи #1: Менеджер по продажам завышает ожидания и обещает золотые горы
Первый, с кем знакомится клиент — это менеджер по продажам (сейлз). Он — лицо компании-разработчика на этапе выбора подрядчика.
Главная мотивация сейлза — продажи. Чем больше контрактов и чем они дороже, тем больше его бонус.
Сейлзам каждый день приходится общаться с множеством потенциальных клиентов, единицы которых превращаются в заказчиков. Поэтому они часто занижают стоимость и завышают перспективы будущего проекта. Так легче продать.
- Что стоит учитывать:
Живое общение и воодушевление сейлза — это здо́рово, но лучше познакомьтесь с человеком, который будет руководить разработкой. У него наверняка более реалистичные взгляды на проект, сроки и стоимость.
И смотрите на факты. Если у компании портфолио не очень, а сейлз говорит, что они всё сделают на высшем уровне — возможно, у них крутой менеджер по продажам, а не команда. (Как оценивать работы в портфолио — читайте ниже.)
Причина неудачи #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: Незнание собственного продукта
Заказчики:
- Описывают проект завуалировано, так как это «супер-пупер ноу-хау», но хотят хотя бы примерную оценку сроков и стоимости с погрешностью не более 20-30%.
- Хотят всего и побольше. Например, соцсеть с возможностью обмена фото и видео, поиском достопримечательностей на карте, построением маршрута до них, аудиоэкскурсией, возможностью заказа такси, интеграцией с умными часами и геймификацией для удержания пользователей.
- Просят сделать для них клон Uber, Instagram, Prisma или Pokemon Go. Обычно просят точную оценку: «У вас же есть пример. Нужен точно такой же продукт, но под нашим брендом».
Факт: не бывает двух одинаковых приложений!
Для точной оценки нужны подробные материалы (ТЗ, мокапы экранов). Чем меньше вводных, тем ниже точность оценки.
Совет
Если ваша идея хороша и вам нужно мобильное приложение, распишите хотя бы кратко: что умеет, зачем нужно пользователю, что будет делать и как вы планируете зарабатывать на нём. Такой документ займет минимум 2-3 страницы, но даже это поможет вам чётче сформулировать идею, а разработчикам — более точно оценить проект на этапе пресейла.
Причина неудачи #7: Неиспользование экспертизы подрядчика
Иногда заказчик забывает о конечном потребителе и руководствуется интуицией, собственным вкусом или советами друзей. Такие решения могут обернуться полным провалом, если вовремя не остановиться.
Простой совет
Посоветуйтесь с подрядчиком. Студия, как правило, видела сотни проектов и тысячи экранов, набила шишки и исправляла кучу багов. Цель студии — взаимная выгода: заказчик получает работающий продукт, который приносит ему прибыль, а студия — деньги за разработку, хороший проект для портфолио и, вероятно, контракт на дальнейшую поддержку приложения (как было сказано выше — приложению, которым люди действительно пользуются, нужны доработки и обновления).
Заключение: как получить то, что нужно?
Для разработки качественного продукта и заказчик, и исполнитель должны работать как слаженная команда. Это значит, что вы должны найти нужных исполнителей и придерживаться простых правил «игры».
В самом начале:
- определитесь, что за проект вы хотите сделать, кто его ЦА, как на нём зарабатывать;
- опишите проект и постарайтесь выделить MVP;
- определите, какой исполнитель вам нужен. Выберите два из трёх параметров: дёшево, быстро, качественно.
При выборе исполнителя:
- ориентируйтесь на портфолио и отзывы;
- опыт и техническую экспертизу;
- состав команды и мнение/отношение к проекту.
Начиная работу:
- согласуйте периодичность и формат отчетов;
- выделите время на общение с исполнителем или назначьте того, кто будет курировать разработку;
- не стремитесь сделать максимум функционала за минимум времени и минимум денег. Во всём должен быть баланс;
- ещё лучше, если вы начнете с реализации части функционала, чтобы понять, насколько вам комфортно работать вместе;
- помните о возможных дополнительных тратах;
- помните, что бюджет и сроки зависят и от вас.
После запуска проекта:
- следите за цифрами и показателями;
- прислушивайтесь к мнению пользователей;
- стройте гипотезы, изучайте конкурентов. На основе этого совершенствуйте продукт;
- помните, что загрузка приложения в магазины — это только начало!
Для кого-то это покажется очевидным. Но практика показывает, что многие заказчики мобильных приложений плохо представляют, как будет строиться работа с подрядчиком.
