В первой части мы рассмотрели, что необходимо продумать до обращения к разработчикам для составления продуманного техзадания, то есть для экономии времени и средств на будущую работу с приложением. Как можно сократить расходы при создании и запуске приложения, разберем в этой статье.
Использовать готовые решения
Этот вариант подходит всем, кому не требуется дорогая эксклюзивная разработка под множество сложных условий и требований. Ускорить и удешевить создание и поддержку приложения помогут:
- Конструкторы. Это едва ли не самый простой вариант запуска приложения. При желании можно даже не обращаться к специалистам, а сделать все самостоятельно. Конечно, это шаблоны, но для несложных проектов и они могут быть хороши.
- Дизайн-системы. Это могут быть не только гайдлайны (правила и рекомендации) для Android и iOS, но и готовые библиотеки с иконками, значками, блоками и прочим (UI-киты). Уникального дизайна не получится, но он не всегда и нужен. Когда важнее интуитивное освоение приложения, стоит воспользоваться готовыми наработками.
- Банкинг и другие сервисы. Когда можно подключить SaaS-платформу, стоит пользоваться такой возможностью. Во-первых, это сокращает время на разработку. Во-вторых, удешевляет ее, поскольку внедрение сложных и безопасных систем оплаты обойдется дороже, чем тариф стороннего сервиса. Да и пользователи будут больше доверять знакомому логотипу платежной системы.
- Мессенджеры и боты. В продолжение темы — это тоже можно не создавать «с нуля», а интегрировать. Если, конечно, такие функции вообще нужны.
- Бэкенд. Серверную архитектуру можно развернуть в облачном сервисе. Или, если это позволительно, организовать хранение данных на устройстве пользователя. Все это, разумеется, дешевле, чем поддерживать собственные сервера.
Не будем говорить про такие инструменты, как Google Формы или Таблицы, которые тоже можно «прикрутить» к приложению для экономии на разработке. Суть в том, чтобы выбирать надежные сторонние сервисы везде, где это допустимо с точки зрения безопасности и удобства пользователей.
Заранее подумать о продвижении
Да, еще до запуска приложения (и даже до обращения в агентство) стоит разработать маркетинговую стратегию. Это нужно, чтобы:
- заложить бюджет на рекламу;
- анонсировать приложение для получения первых пользователей;
- иметь план продвижения после запуска и понимание расходов на его воплощение в жизнь.
Об этом нередко забывают, а в результате не знают, что делать с приложением и как уговаривать людей его устанавливать. И получается, что деньги потрачены зря.
Правильно выбрать разработчика
Итак, назначение, функциональность и пожелания по экономии на разработке определены. Теперь нужно грамотно договориться с разработчиками, чтобы получить ожидаемый результат и никого не обидеть. Выбирая исполнителя по коммерческим предложениям и беседам, стоит обратить внимание на такие вопросы:
- Что входит в стоимость из КП. Может случиться, что менеджеры не посчитали оплату аналитики и подготовки техзадания специалистами агентства. Или наоборот, заложили в стоимость пока не нужные функции или интеграции. В таких случаях лучше попросить перерасчет под заданные условия.
- Специалисты в штате и на аутсорсе. Нельзя сказать, какое соотношение идеально — все зависит от профессионализма, а не от места работы. Но если у агентства много фрилансеров, есть вероятность задержки сроков. Впрочем, штатные специалисты тоже могут ошибаться. И поэтому важен следующий пункт.
- Модель оплаты. Обычно на выбор есть два варианта: фиксированная помесячная (или за весь проект) или почасовая. Вторая модель может оказаться выгоднее в целом, поскольку предполагает возможность сокращения сроков и гибкой реакции на их срыв. При фиксированной оплате в стоимость будут заложены риски, и сроки должны быть точно соблюдены. Что выбирать, зависит от сложности разработки и расчетов для конкретной ситуации. Но обратить внимание стоит на оба варианта.
- Нативная или кроссплатформенная разработка. В первом случае приложения создаются именно под указанные ОС. Во втором они должны работать на всем и сразу, что может приводить к сбоям, но позволяет быстрее и порой дешевле охватить широкую аудиторию. Если точно решено, на каких платформах будет запущено приложение, принять решение будет проще.
- Возможность поэтапного запуска. В первой части мы говорили о том, что часть функций можно внедрять постепенно. А значит, нужно и самим определить порядок действий, и договориться о нем с разработчиками. Важно обсудить с ними все детали, чтобы в процессе работы не обнаружились проблемы с добавлением нового и работой старого.
- Стоимость поддержки. После запуска приложение нужно обслуживать, даже когда не предполагается его дорабатывать. Как минимум, необходимо следить за обновлениями ОС и прошивок. Удобнее всего доверить поддержку разработчикам, и стоит заранее узнать, во сколько это обойдется. Чтобы сэкономить, можно выбрать почасовую оплату вместо абонентской и обращаться только по необходимости. Разумеется, если сбои не критичны.
Это основные вопросы, которые желательно обсудить до заключения договора. Разработчиков много, и наверняка удастся найти «своего».
Выпустить MVP и получить обратную связь
То есть не тратить время на создание полноценной версии, а выпустить «минимально работающий продукт» и узнать мнение о нем. «Фишки» можно внедрять постепенно, по мере необходимости и уже получая прибыль от приложения.
К слову, после выпуска MVP может оказаться, что приложение не востребовано. В такой ситуации утешением станут сэкономленные деньги, время и нервы.
На чем нельзя экономить?
Как видно, есть достаточно способов сократить расходы — готовые инструменты, поэтапный запуск, условия договора с агентством. Но есть пункты, экономия на которых недопустима и приводит к серьезным расходам в будущем:
- ТЗ и прототип. В первой части этого материала мы говорили о важности тщательной проработки сценариев взаимодействия с приложением. И на это действительно необходимо потратиться: переделки из-за ошибок или недопонимания затянут процесс разработки и приведут к лишним расходам.
- Качество кода. Конечно, заказчику сложно это проверить, поэтому речь идет скорее о выборе достойного доверия разработчика. Хотя четкое ТЗ помогает избегать создания «костылей» в процессе создания и доработки приложения. А если код хорошо написан, не будет проблем ни с работой приложения, ни с переходом к другому специалисту.
- Тестирование. Техническое тестирование обязательно, и оно должно быть тщательно выполнено специалистами агентства. Но необходимо проверить приложение «вживую», на его целевой аудитории. Это может быть сплит-тестирование или приглашение посмотреть бета-версию — любой доступный вариант подойдет для получения обратной связи.
- Удобство и безопасность для пользователей. Если приложение запрашивает доступ ко всему, что есть на устройстве, медленно работает, сбоит и другими способами раздражает людей, пользоваться им не будут. А в случае утечки данных, перестанут обращаться и в саму компанию.
Баланс качества и стоимости приложения возможен. Нужно только серьезно отнестись к разработке, и есть шансы, что новый «супер-апп» завоюет свою аудиторию.
