Сколько времени занимает разработка приложения

Короткий ответ: пилотная версия с ограниченным составом — обычно 1–2 месяца, полноценный продукт с несколькими платформами и интеграциями — от 3–4 месяцев и дольше; любая точная цифра до проработки состава — гадание. На срок сильнее всего влияют не технологии, а три вещи: состав функций, число интеграций и скорость решений заказчика. Ниже — раскладка по этапам, факторы-множители и причины срывов.

Сначала договоримся о честности: студия, называющая точный срок до состава работ, либо называет срок под свой шаблон (вы получите шаблон, а не продукт), либо планирует признание «случились обстоятельства» в середине проекта. Мы фиксируем сроки после продуктовой проработки, когда известен состав первой версии, — и дальше отвечаем за них по этапам.

Раскладка по этапам

Типовой проект делится на пять этапов, и разработка — лишь один из них:

• Продуктовая проработка — сценарии, состав первой версии, оценка: обычно 1–2 недели. Этот этап экономит месяцы: каждая отсечённая здесь функция — минус недели в разработке.
• Прототип и дизайн — экраны, сценарии, визуальный стиль: 2–4 недели в зависимости от числа экранов и сложности дизайн-системы.
• Разработка — самый длинный этап: от 3–4 недель для пилотного состава до нескольких месяцев для полноценного продукта с интеграциями.
• Тестирование и стабилизация — 1–2 недели: реальные устройства, сценарии ошибок, оплата, нагрузка.
• Публикация — подготовка материалов и прохождение модерации магазинов: закладывайте от нескольких дней до пары недель; подробности — в руководствах по Google Play и App Store.

Что влияет на срок сильнее всего

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

Второй — интеграции. Приложение без внешних связей предсказуемо; каждая интеграция добавляет зависимость от чужой системы: её API, её лимиты, её поддержка. Учётная система без документированного API способна съесть недели на исследование. Третий — число платформ: iOS + Android + веб — это три контура тестирования и публикации, даже при кроссплатформенной разработке; выбор обсуждаем в статье о нативной и кроссплатформенной разработке.

Три главные причины срыва сроков

Медленные решения заказчика. Каждое «подумаем неделю» на согласовании экрана — неделя к проекту. Назначьте одного ответственного с правом решений — это самая дешёвая страховка сроков.

Рост состава в процессе. «А давайте ещё» без переноса дедлайна — математическое противоречие. Правило здорового проекта: новая функция либо меняется на срок, либо уезжает в следующую версию.

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

Как сократить срок честно

Работают четыре приёма: урезать состав первой версии до проверяющей гипотезы; использовать готовые проверенные модули там, где они есть (у нас — механики записи, подписок, платежей, кабинетов); параллелить подготовку контента заказчиком с разработкой; и готовить публикацию заранее — аккаунты разработчика и документы собираются параллельно с кодом, а не после него. Именно за счёт модульной сборки наши пилоты обычно занимают 30–45 дней — но это оценка для конкретного состава, а не обещание «любого приложения за месяц».

Не работают: «поставить больше разработчиков» (после определённого порога они замедляют друг друга), «пропустить тестирование» (переносит его на пользователей и отзывы) и «начать кодить без прототипа» (переделки дороже проектирования). Если срок критичен — скажите об этом на старте: под дедлайн собирается другой состав продукта, а не тот же «но быстрее».

Частые вопросы