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

Выбор неверного технического решения

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

Что нужно сделать заказчику?

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

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

Нехватка контроля команды

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

Что нужно сделать заказчику?

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

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

Еще нужно уточнить, как у команды отлажены производственные процессы. Сами по себе специалисты могут быть сильными, но если их работа не связана в единый цикл, то результат будет плохим. Как правило, для этого налаживается связь с менеджером команды разработки (project-менеджер, аккаунт-менеджер, в разных студиях по-разному). Не бойтесь задавать ему любые вопросы о том, что вы чего-то не понимаете. Чем меньше этих недопониманий, тем лучше будет результат, и добросовестный исполнитель будет сам стремиться к продуктивной коммуникации.

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

Слив бюджета

Разработка приложения — это дорогостоящий проект, где суммы начинаются от сотен тысяч, а в среднем составляют несколько миллионов рублей . Многие заказчики не готовы работать с командами в формате Time&Materials, когда оплачиваются часы, фактически затраченные на разработку. Предпочитают работу в формате Fix Price& Fix Time, когда на начальном этапе очерчиваются сроки и стоимость проекта и функционал, который будет реализован в этих рамках. Даже при этом формате работы страх и риск слива бюджета остается. Существуют случаи, когда команда по какой-либо причине некорректно оценивает проект и впоследствии вынуждена просить или даже ультимативно требовать доплаты за те вещи, которые были оценены неверно.

Что нужно сделать заказчику?

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

Медленная разработка и срыв сроков

Сроки — это второй вопрос, который звучит после стоимости. Если рассуждать в контексте применения подхода FixPrice & FixTime, то фиксация дедлайна — неотъемлемая его часть. Разработка может идти медленно по разным причинам. Например, замедление процессов происходит когда над одной платформой работает один специалист, а не несколько — параллельно. Студия может заложить минимальные ресурсы, и это будет финансово выгоднее для заказчика. Однако тогда функционал реализуется дольше. Другие компании оценят трудозатраты нескольких специалистов, и это увеличит производительность, но при этом и бюджет проекта. Поэтому на этапе пресейла обговаривайте, что важнее: стоимость или сроки.

Другим сценарием, при котором сроки могут быть сорваны, является тот, когда уровень специалиста не соответствует задачам, которые он решает. Многие небольшие команды грешат этим: чтобы сохранить рентабельность проекта и выгодно реализовать его для себя, они сажают на проект начинающих специалистов, без участия старших коллег. Будет не лишним уточнить у разработчиков уровень опыта сотрудников, которых планируют привлекать к решению задач.

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

Что нужно сделать заказчику?

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

Урон репутации бизнеса

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

Что нужно сделать заказчику?

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

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

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