Сколько времени и денег требует мобильное приложение — по этапам и со скрытыми расходами
Вы задаёте один и тот же вопрос трём подрядчикам: «Нужно мобильное приложение, сколько это будет стоить и сколько займёт времени?» От одного приходит цифра в 3000 манат, от другого — 12000, третий вообще уходит от ответа: «Давайте сначала встретимся». Вы пытаетесь сравнить эти числа, но на самом деле сравнивать нечего — потому что ни один из них не задал вам одинаковых вопросов до того, как назвать сумму.
Проблема не в самом бюджете, а в допущениях, которые стоят за предложением. Один подрядчик представляет себе простое приложение-визитку, другой — целую систему с оплатой, уведомлениями и админ-панелью, и никто из них об этом не говорит вслух. Ниже — куда на самом деле уходят время и деньги, какой вопрос меняет цену, и какие повторяющиеся расходы никто не называет заранее.
Вопрос не «сколько», а «что именно»
«Мобильное приложение» — не один продукт, этим словом называют всё подряд, от визитки до банковского приложения. Поэтому первый вопрос — не о цене, а об объёме:
- Приложение работает само по себе или общается с сервером? Показ статичной информации и запись каждой операции в базу — совершенно разная по объёму работа.
- Есть ли вход пользователя? Регистрация, восстановление пароля, вход через соцсеть — каждое из этого отдельный модуль.
- Есть ли оплата? Интеграция карточной оплаты требует не только кода, но и открытия счёта и процедуры подтверждения.
- Отправляются ли уведомления? Push-уведомление выглядит простой функцией, но за ней стоит отдельная инфраструктура.
Любая цена, названная без ответа на эти вопросы, — не предложение, а догадка. Разделение того, что действительно нужно на старте (MVP — минимально работающая версия), от того, что можно добавить позже, делает реальными и бюджет, и срок.
Куда уходит время
Проект проходит через четыре этапа, и у каждого своя длительность.
Разработка концепции и дизайн
Сначала прописывается список функций и путь пользователя по экранам — какая кнопка куда ведёт, какой экран идёт после какого. Если этот этап проходят наспех, результат потом переделывают уже во время разработки — а это всегда дороже, чем спланировать правильно с первого раза.
Разработка
Здесь параллельно идут две работы: видимый интерфейс и то, что стоит за ним — серверная часть с данными пользователей, заказами, логикой уведомлений. Если интерфейс для iOS и Android пишется отдельно, эта работа удваивается — поэтому выбор платформы напрямую влияет на бюджет (об этом ниже).
Тестирование и проверка магазином
Готовое приложение — ещё не конец работы. Сначала его проверяют на реальных телефонах, в реальных условиях сети (в симуляторе всё всегда работает идеально). Затем оно отправляется в App Store и Google Play — у каждого свой этап проверки, и это превращает дату запуска в переменную, которая не полностью в ваших руках. Причина отказа часто вовсе не техническая — например, просто отсутствует страница политики конфиденциальности.
Нативная разработка или один код на обе платформы
Приложение, написанное отдельно для iOS и Android (нативно), полностью соответствует правилам каждой платформы и работает быстрее, но это два отдельных кода — каждое изменение делается дважды. Решение с одной кодовой базой на обе платформы (кроссплатформенное) снижает и время, и бюджет, особенно на этапе MVP. Выбор зависит не от числа экранов, а от того, насколько сложные функции устройства нужны приложению — камера, датчики, работа без интернета, — и решать это нужно на этапе концепции, а не после начала разработки.
Скрытая строка: расходы, которые повторяются каждый год
Большинство предложений называют одну сумму — за разработку. Но расходы продолжаются и после публикации приложения в магазине, и об этом обычно не говорят заранее:
- Apple Developer Program — чтобы разместить приложение в App Store и держать его там, платится 99 долларов США в год, согласно официальной странице регистрации Apple.
- Google Play — на стороне Android иначе: согласно
Мобильное приложение — не здание, которое строится один раз и остаётся стоять. Это живой продукт с ежегодной платой за существование.
Эти строки — не крупные суммы, но им нужно место в бюджетной таблице. Бизнес, который планирует только стоимость разработки и забывает о них, через год работы приложения в магазине получает «неожиданный» счёт.
Кто отвечает за приложение после запуска
Проект не заканчивается в день публикации в магазине — начинается новый этап. В первые месяцы реальные пользователи находят ошибки там, где их не видно в симуляторе: на конкретной модели телефона, при конкретном качестве связи. Кто ведёт этот этап, должно быть прописано заранее:
- Исправление ошибок — за сколько дней рассматривается сообщённая пользователем проблема, и кто за это отвечает.
- Совместимость при обновлении ОС — когда iOS или Android выпускают новую версию, кто проверяет, что приложение продолжает работать.
- Мелкие изменения — обновление текста, цены, изображения считается новым проектом или частью месячной поддержки.
Если эти три пункта не прописаны в предложении, при первой же проблеме можно услышать «это не входило в нашу часть» — и тогда поиск нового подрядчика начинается с изучения чужого кода с нуля.
Как читать предложение подрядчика
В следующий раз, получив предложение, спросите о трёх вещах: точно ли прописан объём (какие экраны, какие функции входят), сколько времени занимает каждый этап, и на чьё имя оформляется взнос магазину и кто платит за сервер. Любая цифра без ответа на эти три вопроса не годится для сравнения.
Если хотите вместе прояснить объём своего проекта, посмотрите, как мы ведём проекты мобильных приложений — аккаунты открываются на ваше имя, а код с первого дня остаётся вашей собственностью.
