«Сколько по времени?» — второй вопрос после стоимости. Ответ «зависит от проекта» правдив, но бесполезен. В этой статье — конкретные сроки для разных типов приложений, что на них влияет и как не допустить срыва дедлайнов.
Реальные сроки по типам проектов
| Тип приложения | Подготовка | Разработка | Тестирование + релиз | Итого |
|---|---|---|---|---|
| Простое (каталог, формы, push) | 3–4 нед. | 6–8 нед. | 1–2 нед. | 2,5–3,5 мес. |
| Среднее (e-commerce, оплата, лояльность) | 4–6 нед. | 8–14 нед. | 2–3 нед. | 3,5–5,5 мес. |
| Сложное (маркетплейс, геолокация, чат, курьеры) | 6–8 нед. | 14–24 нед. | 3–4 нед. | 5,5–9 мес. |
Это сроки для кроссплатформенной разработки на Flutter (iOS + Android одновременно). Нативная разработка для двух платформ параллельно занимает примерно столько же календарного времени, но требует вдвое больше человеко-часов.
Что влияет на сроки
Качество подготовки
Проект с готовым прототипом, утверждённым дизайном и детальным ТЗ запускается в разработку за дни. Проект, где «мы пока не определились с функционалом», буксует неделями на этапе согласований. Подготовка экономит время, а не тратит его.
Скорость согласований
Самая частая причина срыва сроков — не разработчики, а заказчик. Макет на согласовании неделю, ТЗ обсуждается месяц, промежуточные результаты ревьюятся по 5 дней. Каждый день простоя на согласовании — день к сроку проекта.
Совет: выделите ответственного человека с полномочиями принимать решения. Если каждый макет должен утвердить совет директоров — проект затянется вдвое.
Изменения в процессе
«А давайте добавим ещё чат» на середине разработки — это не доработка, а новая задача, которая сдвигает сроки на 2–4 недели. Изменения неизбежны, но каждое нужно оценивать по влиянию на сроки и бюджет.
Интеграции
Подключение внешних систем (платёжные провайдеры, CRM, ERP, сервисы доставки) часто занимает больше времени, чем ожидается. Причины: устаревшая документация API, баги на стороне провайдера, долгое получение доступов и тестовых аккаунтов.
Модерация сторов
App Store модерирует 1–3 дня, иногда дольше. Первая публикация часто отклоняется — нужно время на исправления и повторную подачу. Закладывайте 1–2 недели на модерацию.
Как ускорить без потери качества
Начинайте с MVP. 10 функций вместо 50 — в 3–4 раза быстрее. Остальное добавите итерациями после запуска.
Параллельте подготовку и разработку. Пока дизайнер рисует вторую половину экранов, разработчик может начать с первой. Это требует хорошего управления, но сокращает сроки на 15–20%.
Быстро принимайте решения. SLA на согласование: 1–2 рабочих дня на макеты, 3–5 дней на крупные решения. Зафиксируйте это в начале проекта.
Не меняйте scope в процессе. Записывайте идеи в бэклог для следующих итераций. Текущий спринт — текущий scope.
Почему «быстрее» не значит «лучше»
Сжатие сроков ниже разумного минимума приводит к предсказуемым последствиям:
- Технический долг — код, который работает, но написан «на коленке». Его придётся переписывать.
- Баги в продакшене — недостаточное тестирование = проблемы у реальных пользователей.
- Выгорание команды — работа в аврале не может длиться долго без потери качества.
Правильный подход: определить реалистичные сроки, заложить 15–20% буфер на непредвиденные ситуации и придерживаться плана.
Итоги
MVP мобильного приложения — 2,5–5,5 месяцев. Сложный продукт — до 9 месяцев. Главные факторы, влияющие на сроки: объём функционала, скорость согласований и стабильность требований. Лучший способ уложиться в сроки — качественная подготовка и дисциплина в принятии решений.
Хотите узнать сроки для вашего проекта? Опишите задачу — дадим обоснованную оценку с разбивкой по этапам.
