Мобильных разработчиков часто спрашивают, сколько будет стоить реализовать ту или иную идею. Например, сделать аналог «Убер» или «Авито». При такой постановке вопроса трудно оценить предстоящие трудозатраты, что создает большой разброс цен у разных разработчиков и недоверие со стороны заказчика. Ещё одной проблемой является недостаточная проработка идеи. Зачастую заказчик видит общую концепцию приложения, но слабо представляет детали. Это приводит к лишним затратам на обсуждение и переписывание требований.
Эта статья адресована в первую очередь тем, кто задумался о заказе собственного приложения. В ней мы ответим на распространенные вопросы и дамим несколько советов, которые помогут вам проработать идею и не потратить лишнего.
Из этой статьи вы узнаете:
сколько стоит создать приложение по вашей идее;
из каких этапов состоит разработка;
как составить бриф и получить оценку без ТЗ;
нужно ли рисовать прототипы и как это лучше сделать;
стоит ли пользоваться конструкторами приложений;
нужно ли создавать под проект нативное приложение, или можно обойтись кроссплатформенным;
как спланировать сроки релиза, чтобы выпустить приложение вовремя.
У меня есть идея приложения. Сколько будет стоить разработка?
C ходу вам никто не скажет. Каждый более-менее крупный проект состоит из нескольких компонентов: самого приложения, сайта, базы данных, панели управления. Насколько затратным выйдет каждый компонент — зависит от ваших потребностей, уникальности задачи и специфики бизнеса.
Недавно мы разместили на бирже заказ на разработку клона «Убер». Одни исполнители просили 100 000 рублей, а другие — до 5 000 000.
Почему такой большой разброс цен?
Разные разработчики — разная стоимость часа работы.
Разные разработчики — разное понимание исходных требований.
Многие независимые разработчики оценивают проект, опираясь на личный опыт. Не факт, что ваше приложение будет похоже на то, что они уже делали.
Получить ориентировочную стоимость разработки можно и самостоятельно, с помощью специального калькулятора. Это не займет более трех минут вашего времени.
Из каких этапов состоит разработка?
Разработка приложений не ограничивается написанием кода. Вот что происходит после того, как ваша идея попадает в руки к разработчику:
Планирование и оценка — знакомство с документацией заказчика, составление плана работ.
Аналитика — выявление требований и способов их реализации.
Дизайн — отрисовка экранов, подготовка материалов для вёрстки, иконок, скриншотов для магазинов, создание интерактивных прототипов.
Разработка —верстка, разработка API, подключение (иногда интеграция со сторонними сервисами).
Тестирование — проверка всех возможных сценариев использования в различных условиях.
Релиз — публикация приложения в Apple App Store и Google Play.
Сопровождение — поддержка и развитие проекта после релиза.
Каждый этап требует времени и усилий. Если вам предлагают сделать приложение за 100 000 рублей без ТЗ – это повод насторожиться.
Когда я смогу узнать точную стоимость и сроки?
Как правило, точную оценку можно получить уже на этапе аналитики. К этому моменту ваша идея детализируется до конкретных требований, реализацию которых можно измерить в человеко-часах.
Проработка требований может занять от нескольких дней до нескольких недель, в зависимости от сложности проекта. Вы можете значительно ускорить этот процесс, если предоставите разработчику качественное ТЗ.
А можно как-нибудь без ТЗ?
Да, можно. Если вы хотите узнать нижний порог стоимости разработки, то ТЗ можно заменить на краткий бриф.
Бриф — это своего рода анкета для вас и разработчика. Он помогает лучше понять целесообразность идеи и определиться с функциями, которые должны быть в приложении.
В брифе необходимо проработать 4П: пользователей, проблемы, преимущества и прибыль.
Пользователи
Разные люди — разные потребности. От выбора целевой аудитории зависит то, каким должно быть приложение. Например:
В приложениях для пожилых людей используют большие кнопки и минимум настроек.
В приложениях для вызова такси часто встречаются дополнительные опции для пассажиров с детьми и домашними питомцами.
Проблемы
Если приложение не поможет пользователю решать его задачи, то он его, скорее всего, удалит.
Опишите конкретные ситуации, в которых ваше приложение будет полезно людям. Например:
«Заказать такси, когда забыл деньги»,
«Сравнить цены на пылесосы»,
«Найти кафе поблизости».
Преимущества
Чтобы «выстрелить», ваше приложение должно выгодно отличаться от аналогов. Как этого добиться:
Следует помнить, что магазины приложений в некоторых случаях берут внушительную комиссию за покупки пользователей, что может отразиться на сроках окупаемости проекта.
Бриф формирует общее видение проекта. В дальнейшем его можно использовать при составлении ТЗ с требованиями.
Старайтесь описывать требования, а не озвучивать. Так вам не придется по несколько раз пересказывать одно и то же. Если же вам легче формулировать мысли устно, воспользуйтесь голосовым вводом в Google Документах.
Нужно ли рисовать прототипы?
На ваше усмотрение. Прототипы помогают представить, как будут выглядеть экраны приложения. Если вы нарисуете их сами, то дизайнеру не придется придумывать всё с нуля. Он сможет глубже понять вашу идею и поможет развить её до окончательного варианта.
Создавать прототипы можно с помощью бесплатных сервисов или нарисовать от руки.
Список наиболее удобных решений для создания прототипов:
При создании прототипов ориентируйтесь на сценарии действий пользователя. Задавайте переходы между экранами, чтобы не упустить важных шагов.
Что ещё может повлиять на сроки оценки?
Могут возникнуть сложности при планировании интеграции. Например, если приложение должно обмениваться данными с внешним сервисом на Bitrix. Такие моменты сложно оценить, так как приходится постоянно взаимодействовать с командой на стороне клиента. Работа может стопориться просто из-за того, что разработчик всё утро ждал обратную связь от специалиста по CRM.
Создайте общее информационное пространство, в котором ваши специалисты будут отвечать на вопросы мобильных разработчиков. Например, с помощью Google Таблиц, Trello или других менеджеров задач. Собранную таким образом информацию потом можно использовать для доработки ТЗ.
Что лучше: нативное приложение или кроссплатформенное?
Кроссплатформенные приложения менее отзывчивы и не всегда корректно работают на обеих платформах. Если нужно быстро создать простое приложение (например, на основе сайта), то этот вариант вам подходит.
Нативные приложения могут по максимуму использовать возможности своих платформ и работать в офлайн. При этом дизайн приложения будет соответствовать тому, к чему привыкли пользователи Android или iOS. При нынешних тенденциях рынка данный вариант является предпочтительным.
Если ваш бюджет ограничен, закажите нативное приложение для одной платформы. Так вы получите минимально жизнеспособный продукт (MVP) c полным функционалом. С его помощью вы получите адекватную обратную связь от пользователей и поймете, нужно ли вкладывать в разработку для второй платформы.
Стоит ли использовать конструкторы приложений?
Конструкторы приложений предназначены для решения базовых задач бизнеса. Их главный плюс — возможность собрать и настроить приложение самостоятельно, экспериментируя с готовыми модулями. Если ваше приложение является типовым для своей ниши (делает то же, что и другие), вы можете собрать его с помощью конструктора. Если вам нужно что-то более специфичное, то этот вариант не подходит.
Стоит отметить, что большинство конструкторов — это франшизы. Фактически вы получаете доступ к приложению, который необходимо оплачивать. При этом некоторые недобросовестные владельцы франшизы оставляют за собой право менять условия сотрудничества или блокировать доступ клиента к личному кабинету.
Перед тем, как воспользоваться услугами конструктора, почитайте отзывы о приложениях, которые были созданы на его основе. Информация об успешных кейсах в портфолио не всегда соответствует реальному опыту использования.
Что если мое приложение должно быть готово к определенной дате?
Планируйте срок с запасом. К примеру в AppStore приложения проходят ревью, которое может занять более месяца. А повлиять на Apple нельзя.
Даты мероприятий, связанных с презентацией и продвижением приложения, назначайте после прохождения ревью.
Резюме
Одну и ту же идею можно оценить по-разному. Назвать точную стоимость и сроки разработки можно только после выявления и согласования требований.
Никогда не обсуждайте требования устно. Для правильной оценки у всех членов команды должна быть одинаковая информация, зафиксированная письменно.
Чтобы лучше донести свою идею для разработчика, можно составить бриф и нарисовать макеты экранов. В брифе нужно описать 4П: пользователей, проблемы (сценарии), преимущества и прибыль (способы монетизации) .
Чтобы не пришлось по несколько раз объяснять одно и то же — фиксируйте требования письменно.
Прототипы помогают проработать пользовательские сценарии и не упустить важных шагов. Если рисуете прототипы от руки, не забудьте показать логику перемещения между экранами (нажал здесь — перешел туда) .
Чтобы наладить коммуникации между разработчиками и вашими специалистами, ведите обсуждение в менеджерах задач.
Кроссплатформенные приложения подходят только для небольших и неприхотливых приложений. Во всех остальных случаях лучше выбрать нативную разработку.
Если ваш бюджет ограничен, создайте MVP-версию приложения для одной платформы, чтобы получить обратную связь от пользователей.
Конструкторы приложений подходят для решения типовых задач бизнеса. Для чего-то более специфичного лучше обратиться к студиям разработки.
Если ваше приложение должно быть готово к определенной дате, планируйте его выпуск хотя бы за месяц. Мероприятия по презентации и продвижению назначайте после ревью (особенно критично для iOS).
