Мобильное приложение — это всегда крупная инвестиция, поэтому практически каждый заказчик в чем-нибудь да сомневается или даже высказывает опасения. В этом тексте собрали самые распространенные страхи клиентов и объясняем, что с ними делать.
Выбор неправильного технологического решения
Это часто происходит, когда компания, передающая разработку приложения на аутсорсинг, никогда раньше не имела дела с этим процессом или технологией. Однако на практике любое техническое решение, которым владеет команда разработчиков, может решить какую-то бизнес-задачу. Нативная, кроссплатформенная, веб-разработка – это несколько разных технических подходов, но они могут достигать одних и тех же целей и добиваться практически одинаковых результатов по качеству и характеристикам.
Что нужно сделать заказчику?
Обсудите требования к продукту с потенциальными исполнителями и сравните плюсы и минусы технологий, предлагаемых командой. Выбор технологического стека среди специалистов определяется либо историей начала работы и накоплением опыта, либо субъективным мнением о том, какое решение лучше. Кроссплатформенная разработка почти всегда так же хороша, как и нативная. В этой статье более подробно рассматриваются преимущества обоих вариантов.
Риск ошибиться с технологией, конечно, существует, но не стоит на нем зацикливаться. Это не имеет большого значения для классических проектов, не требующих высокой нагрузки или больших баз данных, или для специфических функций, которые обычно менее важны для стартапов и малых и средних предприятий. Если есть сомнения по техническим вопросам, рекомендуется собрать информацию от разных компаний, сравнить предложения и выбрать лучшую компанию. Если к проекту предъявляются особые требования, то, конечно, полезно иметь на стороне клиента специалиста, который хорошо знаком с этой технологией.
Отсутствие командной дисциплины
Вы можете заплатить за работу, а потом почувствовать, что не знаете и не понимаете, что будет дальше с разработкой. Или же, если вы не видите процесса, вы можете подумать, что его вообще не было. Это и про деньги—когда вам не понятно, как расходуется ваш бюджет, потому что слова из сметы не очень знакомы, и про доверие—когда кажется, что никто, кроме вас ваш продукт не знает. Спойлер: это так и одновременно не совсем так.
Что нужно сделать заказчику?
На этапе выбора подрядчика оцените его опыт на соответствующих проектах и отзывы тех, кто работал с командой. Кроме того, их портфолио не обязательно должно быть абсолютно идентичным вашему продукту. Достаточно выявить реализации схожей функциональности и понять, что команда знает, как работать на результат и как выводить проекты на рынок. Это снижает риск.
Поскольку проекты обычно поэтапные, неплохо бы определить формат промежуточных результатов и отчетов с подрядчиком на этапе заключения контракта. Такая практика меньше нервирует и позволяет постоянно отслеживать состояние дел.
Вам также следует проверить, как организован производственный процесс команды. Даже если сами специалисты сильны, если их работа не связана в единый цикл, результат не будет хорошим. Как правило, вы должны общаться с менеджером команды разработчиков (менеджером проекта, менеджером по работе с клиентами, в зависимости от студии). Если у вас есть вопросы, не стесняйтесь их задавать. Чем меньше таких недоразумений, тем лучше результаты, а добросовестные исполнители будут стремиться к продуктивному общению. Кроме того, это работает в обе стороны. У вашей команды могут быть неверные представления о вашем продукте или бизнесе, и вам необходимо ответить на них. Разработчики могут иметь опыт работы с подобными проектами и знать, какие механизмы, какие подходы и какие детали интерфейса будут лучше работать в вашем приложении, но детали вашей идеи, вашего бренда, вашего продукта и его характеристик – это клиентская экспертиза. Поэтому эффективный контроль над командой клиента формируется только тогда, когда они взаимно участвуют в разработке приложения.
Слив бюджета
Разработка приложений – это проект, который может стоить от нескольких сотен тысяч до нескольких миллионов рублей в среднем. Многие заказчики не готовы работать с командой в формате Time&Materials, где им платят за фактически потраченное на разработку время. Они предпочитают работать в формате Fix Price&Fix Time, где на ранней стадии оцениваются сроки и стоимость проекта, а также функциональность, которая будет реализована в его рамках. Даже при такой форме работы сохраняется опасение и риск того, что бюджет закончится. В некоторых случаях, по каким-либо причинам, смета проекта оказывается неверной, и проектную группу просят или ставят ультиматум о дополнительной оплате за неверную смету. Обеспечение безопасности контрактов и формулировок в них. Наша студия рекомендует разделить разработку на итерации и сделать систему управления максимально прозрачной. Так клиент сможет чаще видеть промежуточные результаты и соотносить затраты с полученными результатами. Также важно уже на этапе предпродажной подготовки оценить стоимость услуг экспертов и предварительные сметы и сравнить эти данные с рынком. Обычно следует остерегаться самых дешевых и самых дорогих предложений, но сметы, отличающиеся на 20% в одну сторону, с большей вероятностью будут соответствовать истинной стоимости проекта.
Что нужно сделать заказчику?
Подстраховаться договором и формулировками в нем. Мы в своей студии рекомендуем разбивать разработку на итерации и добиваться максимально прозрачной системы контроля. Так клиент сможет чаще видеть промежуточный результат и соотносить затраченные средства с полученным результатом. Кроме того, важно оценивать ставки специалистов и предварительные оценки еще на этапе пресейла и сравнивать данные с рынком. Самые дешевые и самые дорогие предложения по мобильной разработке должны обычно настораживать, а вот оценки, которые разнятся в пределах 20% в ту или иную сторону, скорее всего, соответствуют реальной стоимости проекта.
Медленная разработка и нарушение сроков
Сроки – это следующий вопрос после стоимости; если рассматривать его в контексте подхода FixPrice & FixTime, фиксация даты поставки является важным элементом. Разработка может идти медленно по ряду причин. Например, задержки возникают, когда один специалист работает над одной платформой, а не над несколькими параллельно. Студия может задействовать минимум ресурсов, что экономически выгодно для заказчика. Однако это приведет к более медленному внедрению функций. Другие компании оценивают трудозатраты нескольких специалистов, что повышает производительность, но также увеличивает бюджет проекта. Поэтому на этапе предпродажной подготовки обсудите, что важнее – стоимость или время.
Сроки выполнения могут быть поставлены под угрозу, если уровень знаний специалиста не соответствует задаче. Небольшие команды часто позволяют новичкам присоединяться к проекту без старшего сотрудника, чтобы сделать проект более экономически эффективным и обеспечить собственную выгоду. Нелишним будет уточнить у разработчиков уровень опыта сотрудников, которых они привлекают к проекту.
Зачастую сроки не соблюдаются из-за некорректной изначальной оценки (причин может быть множество), но эти риски, как правило, серьезная компания берет на себя и предлагает адекватные варианты решения клиенту.
Что нужно сделать заказчику?
Чтобы не случилось недопониманий по скорости разработки, не забыть обозначить дедлайн и зафиксировать его в договоре. Срыв сроков же регламентируется условиями договора. Мы в TEAM500 разбиваем проект на этапы и вводим штрафные санкции за просрочку сдачи промежуточных результатов и всего проекта. Они стимулируют компанию разработчика жестко соблюдать дедлайны, иначе последуют финансовые и репутационные потери.
Урон репутации бизнеса
Еще одна история о доверии – это страх, что клиенты получат продукт низкого качества, выпустят его, а бренд вместо роста доходов получит негативные отзывы пользователей. К сожалению, этот страх не всегда решает проблему, даже для самых высокопоставленных команд разработчиков. Качественные продукты и снижение репутационного риска – это сочетание здравой бизнес-идеи, хорошо продуманной стратегии и достойного исполнения. На стороне подрядчиков лежит ответственность за последнюю часть, и хотя они могут участвовать в первых двух элементах, помогая советами и делясь своим опытом, окончательное решение остается за владельцем продукта.
Что нужно сделать заказчику?
Прежде, чем идти за разработкой, провести аналитику рынка, понять свою целевую аудиторию, ее боли и проблемы, оценить конкурентов. Неделя сбора и изучения данных может сэкономить месяцы разработки, убрав из вашего проекта лишние функции, например, или вовсе в корне изменив подход к реализации.
После аналитического этапа, конечно, важно не прогадать с разработчиком, и об этом мы писали в отдельной статье, потому что деталей, на которые надо обратить внимание, намного больше, чем наиболее частых страхов.
Основной вывод: если вы чувствуете, что ваш продукт движется в неправильном направлении или что вы теряете связь со своей командой, разумно открыто обсудить проблему и, если необходимо, сменить разработчика. Конечно, новому внедренцу требуется время, чтобы научиться и погрузиться в материал, но это время может спасти репутацию вашего бизнеса и потери доходов в будущем. Мы с удовольствием беремся за проекты по доработке, чтобы найти оптимальное решение вашей проблемы. Мы всегда готовы помочь вам правильно оценить текущее состояние ваших услуг и вместе с вами подготовить план решения проблем и развития.
Узнай стоимость разработки мобильного приложения прямо сейчас!
