Короткий ответ: сколько делают приложение
Универсального срока нет, но есть понятные ориентиры. Чем меньше функций в первой версии и чем меньше внешних систем, тем быстрее приложение попадает к пользователям.
Ниже — ориентиры по типам проектов. Это не обещание для любого проекта, а порядок величин, от которого удобно отталкиваться при планировании.
Важно понимать разницу между «приложение готово» и «приложение доступно пользователям». Между этими моментами — тестирование на реальных устройствах, подготовка страниц в магазинах и проверка модераторами.
| Тип проекта | Что внутри | Ориентир по срокам |
|---|---|---|
| Простой MVP | Информация, услуги, заявка, уведомления | около 2 недель |
| Бизнес-приложение | Личный кабинет, каталог или запись, оплата, CRM или 1С | от нескольких недель, зависит от интеграций |
| Сложный сервис | Несколько ролей, подписки, много интеграций, высокая нагрузка | от нескольких месяцев, поэтапно |
К сроку разработки стоит добавить время на модерацию в магазинах приложений — о ней ниже.
Из каких этапов складывается срок
Любой проект проходит одни и те же этапы. Разница лишь в том, сколько времени занимает каждый из них.
- Обсуждение и оценка. Уточняем цель, роли пользователей, список функций и интеграций, фиксируем состав первой версии.
- Прототип и дизайн. Собираем структуру экранов, затем отрисовываем интерфейс в фирменном стиле.
- Разработка клиентской части. Приложение для iOS и Android: экраны, логика, работа с сервером.
- Серверная часть и админ-панель. База данных, API, управление контентом и заказами.
- Интеграции. CRM, 1С, платёжные сервисы, онлайн-касса, мессенджеры.
- Тестирование. Проверяем сценарии на разных устройствах и версиях ОС, исправляем ошибки.
- Публикация. Готовим описание, скриншоты, политику конфиденциальности и отправляем на проверку в App Store, Google Play и RuStore.
Часть этапов идёт параллельно. Например, серверную часть можно начинать, пока согласуется дизайн, а материалы для магазинов — готовить во время тестирования.
Что сильнее всего влияет на сроки
Объём экранов важен, но чаще срок «съедают» не они, а логика и внешние зависимости.
- Количество ролей. Приложение только для клиента делается быстрее, чем связка «клиент — курьер — администратор».
- Интеграции. Работа с CRM, 1С или кассой зависит от качества их API и от того, как быстро выданы доступы и документация.
- Оплата и чеки. Подключение платёжного провайдера требует договора и проверки со стороны сервиса, а это время, на которое команда разработки не влияет.
- Уникальный дизайн и анимации. Нестандартные элементы интерфейса требуют больше времени на отрисовку и реализацию.
- Скорость согласований. Если ответ на вопрос приходит через неделю, проект стоит неделю.
- Изменения по ходу. Новые функции посреди спринта сдвигают сроки сильнее, чем кажется.
Сроки по модулям: что добавляет время
Каждый модуль добавляет к проекту не только стоимость, но и время. Мы не даём точные дни на модуль в отрыве от проекта: одна и та же интеграция с CRM может занять пару дней или пару недель в зависимости от системы на вашей стороне.
Ориентироваться можно так: модули без внешних систем (авторизация, личный кабинет, push-уведомления, каталог) обычно предсказуемы. Модули с внешними сторонами (оплата, онлайн-касса, 1С, Госуслуги) зависят от скорости подключения и проверок на стороне партнёров. Их лучше запускать как можно раньше.
Набор модулей и ориентировочную стоимость удобно собрать в калькуляторе — это заодно поможет понять, что войдёт в первую версию, а что во вторую.
Как запустить MVP быстрее
Быстрый запуск — это прежде всего правильно урезанная первая версия. Задача MVP — проверить, будут ли клиенты пользоваться приложением, а не реализовать всё задуманное.
Оставьте один основной сценарий: заказ, запись, получение бонусов. Используйте готовые компоненты интерфейса, а сложные функции вроде подписок или чата перенесите во второй этап.
Подготовьте материалы до старта: логотип, тексты, фотографии, список услуг или товаров, доступы к CRM. Назначьте одного человека, который принимает решения со стороны бизнеса. Быстрые согласования экономят не меньше времени, чем работа команды разработки.
Публикация и модерация в магазинах
Готовое приложение ещё нужно опубликовать. В России важно размещать его в трёх магазинах: App Store, Google Play и RuStore. У каждого своя проверка, и закладывать время на неё нужно заранее.
Обычно проверка занимает от нескольких часов до нескольких дней. Если у модераторов есть замечания — например, к описанию, политике конфиденциальности или работе тестового аккаунта, — приложение нужно доработать и отправить повторно.
Отдельно стоит заложить время на аккаунты разработчика. Регистрация и проверка аккаунта, особенно для организации, может занять дни, а для российских компаний с App Store и Google Play есть сложности с оплатой взносов. Лучше заняться этим в самом начале проекта, а не за день до релиза.
Как мы планируем сроки и держим их
Срок, названный «на глаз», почти всегда оказывается неверным. Поэтому мы планируем проект от состава функций, а не от желаемой даты релиза, и сразу показываем, какие задачи зависят от нас, а какие — от вас и от внешних сервисов.
Если дата запуска жёсткая — например, приложение нужно к открытию нового филиала или к сезону, — мы идём от обратного: определяем, какой объём реально успеть, и переносим остальное во второй этап. Это честнее, чем обещать всё и сдвигать релиз.
- Фиксируем состав первой версии письменно, чтобы все понимали, что входит в срок.
- Разбиваем работу на короткие этапы и показываем промежуточный результат — экраны, сборки для тестирования.
- Заранее составляем список того, что нужно от заказчика: материалы, доступы, договоры с платёжными сервисами.
- Запускаем «долгие» внешние процессы в первые дни: регистрацию аккаунтов, подключение эквайринга и кассы.
- Новые идеи по ходу проекта записываем в бэклог следующей версии, если они не критичны для запуска.
Такой подход не делает разработку мгновенной, но делает её предсказуемой: вы заранее знаете, что и когда получите.
Что чаще всего задерживает релиз
Большинство задержек предсказуемы, и их можно избежать, если знать о них заранее: нет доступов к CRM или 1С, не подписан договор с платёжным сервисом, не готовы тексты и фото, не зарегистрированы аккаунты разработчика, состав функций меняется по ходу работы.
Мы стараемся выявить такие риски на этапе оценки и сразу составить план: что нужно от вас, к какому сроку и что будет, если этот срок сдвинется.
Что происходит после релиза
Релиз — это не конец работы, а начало жизни приложения. Первые недели после запуска важно смотреть аналитику, собирать отзывы и быстро исправлять мелкие недочёты.
Дальше приложение развивается итерациями: каждая новая версия добавляет функции, которые действительно нужны пользователям. Мы сопровождаем приложения после запуска — обновляем под новые версии iOS и Android и помогаем с публикацией обновлений.
Планируя сроки, учитывайте и этот этап: обновления тоже проходят модерацию в магазинах, поэтому крупные изменения лучше выпускать по заранее согласованному графику, а не в последний момент перед акцией или сезоном.