Мобильное приложение: сколько стоит и как сделать? Полный гайд

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

Привет! Меня зовут Глеб Федоренко, я основатель Galt Agency – мы создаём мобильные приложения под ключ для других бизнесов (в портфолио разные проекты: от e-com и fashion до логистики в Европе).

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

В этой статье я максимально подробно поделюсь своим опытом и попытаюсь помочь вам определиться со стратегией, если вы решили делать мобильное приложение.

Обычно процесс создания приложения состоит из пяти стадий: от идеи до запуска. Каждую из них можно контролировать самому или делегировать специалистам.

Идея, анализ рынка, бизнес-модель

Первое, о чём стоит задуматься, — нужно ли это приложение вообще. Точно ли нельзя обойтись мобильной версией сайта?

Ваши действия зависят от стадии бизнеса. Если вы делаете приложение для работающего бизнеса, и оно поможет вам масштабироваться – вопрос отпадает.

Если делаете стартап, перед стартом работ нужно сделать три шага:

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

Разберём на банальном примере. Все люди периодически хотят есть, а значит есть вечная проблема — где взять еду. Её решают несколько типов приложений: доставки продуктов из нескольких магазинов, собственные приложения доставки крупных супермаркетов, доставки готовой еды из ряда заведений и собственные приложения у крупных кафе и ресторанов. Ещё недавно на этом рынке была проблема — всё везли слишком долго, от 45 минут. Её решило известное приложение доставки продуктов за 15 минут с названием двухколёсного транспорта. И это выстрелило!

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

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

Требования к продукту

Идея есть, осталось продумать реализацию. На этом этапе стоит задать себе пять важных вопросов:

• Что приложение должно делать — собирать данные из разных источников и ранжировать их, оформлять и оплачивать заказы, обрабатывать фотографии или что-то ещё. Иными словами, зачем пользователь скачает приложение, и что он должен получить.
• Как на нём зарабатывать — например, брать деньги с кого-то за размещение в нём товаров или рекламы, продавать с его помощью собственные товары, сделать скачивание платным или внедрить механику подписки.
• Кто будет им пользоваться — понять портрет клиента, чтобы разработать приложение, которое попадет в его "боли", будет выглядеть привычно и удобно для него.
• Сколько людей будет им пользоваться – пара сотен человек или сотни тысяч человек. Понятно, что предсказать сразу, выстрелит приложение или нет, вряд ли получится. Но примерно определиться с масштабом всё же нужно ещё до разработки – чтобы построить правильную архитектуру (фундамент для деревянной дачи не выдержит небоскреб, а строить для дачи фундамент небоскреба – неоправданно дорого)
• Как им управлять — что должно быть в админской версии приложения, что в нём можно будет менять, а что нет. Этот вопрос стоит особого внимания, если до этого с приложениями дел не имели. Ведь приложение не статично, в нём придётся что-то менять, например, цены или ассортимент. Чем проще админка — тем легче управлять, но меньше вариантов для внесения изменений.

Ответы на эти вопросы по сути станут краткой версией технического задания — ТЗ, на разработку приложения. Именно это нужно рассказать тому, кто будет его создавать. Иначе высок риск получить совсем не то, что хотелось. Переделывать будет дорого и долго — мало кто готов взяться исправить чужую работу.

Создание прототипа

Прототип — это визуализация будущего приложения: от схем и набросков к интерактивной модели. На этом этапе нужно чётко понимать:

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

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

В прототипировании есть три важных этапа:

UX дизайн/wireframe’инг — это создание прототипа приложения в виде схем и набросков экранов.

Например, регистрация — авторизация — первые действия — заполнение профиля — оформление заказа — покупка — отслеживание заказа — написание отзыва.

Каждый шаг пользователя — это отдельный экран или wireframe.

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

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

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

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

Интерактивный прототип — важная часть, которую многие пропускают, по сути – анимированные макеты.

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

Разработка

На этапе разработки важно разделить два понятия — frontend и backend. Запомнить легко:

• frontend — то, что спереди, то есть взаимодействует с пользователем;
• backend — то, что сзади, изнутри, то есть серверная часть приложения.

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

• будет приложение тормозить или нет;
• выдержит нужное число пользователей или зависнет;
• насколько безопасно получится хранить данные;

Если приложение работает плохо, пользователю будет безразлична его красота и удобный интерфейс. Он уйдёт к конкурентам, и будет прав: никто не хочет вечно ждать загрузку или в сотый раз за день вводить пароль.

Разработка архитектуры приложения включает выбор используемых технологий, построение базы данных, API (через него приложение взаимодействует с сервером), интеграции CRM, CMS и много других технических нюансов. Если вы это не знаете — лучше даже не пытаться разобраться самому, а довериться профессионалу. И надеяться, что он выберет современные и надёжные инструменты, а иначе — проблемы в работе приложения заставят вас начать разработку с нуля или отдать его на доработку. Научить вас разбираться в архитектуре приложений за одну статью мы не можем. А вот создать для вас приложение — можем.

Помимо архитектуры, необходимо разработать оболочку приложения. Варианта два:

• кроссплатформенное решение — один код, который работает на разных операционных системах (iOS, Android, MacOS, Windows);
• нативное приложение — разрабатывается под конкретную операционную систему.

Первый вариант — универсальный, современный, позволяет сэкономить около 35% ресурсов на разработке (если вы запускаете iOS и Android), а также предоставить одинаковый пользовательский опыт на всех платформах.

Второй вариант позволяет добиться максимальной производительности, но расходы на разработку и поддержку будут существенно выше (т.к. над созданием работают несколько команд разработчиков, одна под каждую ОС).

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

Запуск

Приложение готово, пора запускать! Так думают многие, но работает это по-другому. Сначала его нужно протестировать.

Тестирование проводится в два этапа:

Пользовательское тестирование

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

Нагрузочное тестирование

• выдерживает ли приложение имитацию большого потока пользователей;
• выдерживает ли приложение имитацию атаки;

Эту работу обычно выполняют QA-специалисты (quality assurance, контроль качества).

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

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

К кому обратиться за разработкой приложения — зависит от того, насколько вы сами в этом разбираетесь и готовы контролировать каждый этап.

Фриланс

Фрилансеры – самый недорогой и самый проблемный вариант.

С фрилансерами всегда есть риски:

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

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

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

Своя команда

Ещё один вариант — собрать свою команду в штат. Понадобится хотя бы 2 разработчика (frontend и backend), дизайнер и менеджер проекта. Здесь есть свои подводные камни:

• Придётся провести не одно собеседование самому и всё равно разобраться в разработке или нанять рекрутера.
• Подбор людей займёт немало времени.
• Стоит сразу подумать, что потом делать с командой. Ведь им придётся платить зарплату и придумывать задачи.
• Это дороже, чем команда фрилансеров.

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

Аутсорс

Оптимальный вариант — обратиться в агентство, где разработку приложения полностью возьмут на себя. Все этапы — от анализа рынка до запуска, проведут специалисты. А ещё будут сопровождать проект после релиза, научат вас администрировать приложение и не сорвут сроки. По крайне мере, в агентстве Galt мы делаем именно так.

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

Цена зависит от того, какая команда будет работать над приложением. Есть три варианта:

• Фриланс – самый доступный, хоть и проблемный вариант (нюансы работы описали выше). В любом случае придется отдать минимум несколько сотен тысяч.
• Своя команда — по самым скромным подсчетам, от 600 тыс. в месяц (минимум два разработчика, дизайнер, менеджер) и несколько месяцев работы. По опыту, реальные расходы будут выше.
• Агентство — золотая середина. Относительно недешево, но выгоднее содержания своей команды, комплексно, в срок и голова ни о чём не болит: проект сделают под ключ и помогут с дальнейшей поддержкой.

От чтения статьи до готового приложения всего один шаг — заполните бриф, мы составим для вас смету и оперативно начнём работу.

Кто уже имел опыт с разработкой собственного приложения — удачный или нет, пишите в комментариях, обсудим 👇