Сколько длится разработка приложения: этапы и сроки

Срок разработки зависит от объёма задачи. Telegram-бот или небольшая автоматизация обычно занимает от одной до нескольких недель, первая рабочая версия ИИ-агента — несколько недель, отдельное приложение для iOS, Android, macOS, Windows или веба — от нескольких месяцев. Точный срок можно назвать только после разбора задачи, а первую пользу продукт приносит раньше, если выпускать его частями.

Почему нельзя назвать срок, не разобрав задачу

Вопрос «сколько длится разработка приложения» похож на вопрос «сколько длится ремонт». Ответ зависит от того, что именно строим: один экран с формой заявки и продукт с личным кабинетом, оплатой, ролями сотрудников и версиями для пяти платформ отличаются по объёму в разы.

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

Ниже — ориентиры, которые помогают заранее понять порядок сроков. Это не обещание, а точка отсчёта для разговора.

Ориентиры по срокам: таблица

В таблице — типичные виды проектов, ориентир по сроку и то, что сильнее всего влияет на итоговую цифру. Ориентиры взяты со страницы разработки ПО JEEKSSHIRE 24 и описывают обычный случай.

Обратите внимание на формулировку для ИИ-агента: речь о первой рабочей версии. Агента обычно запускают на ограниченном круге задач, проверяют ответы и только потом расширяют. Подробнее об этом — в разборе ИИ-агент для бизнеса: что это и как внедрить.

Этапы разработки ПО и что происходит на каждом

Разработка — это не один длинный отрезок «пишем код», а несколько этапов с понятным результатом в конце каждого. Так их видит заказчик:

1. Разбор задачи. Смотрим, что мешает бизнесу сегодня, где теряются деньги и время и какой результат считается успехом.
2. Решение и оценка. Предлагаем самое простое решение, которое даёт нужный результат, и раскладываем его на части, которые можно показать и проверить по отдельности. Здесь появляется срок.
3. Сборка по частям. Вы видите работающие куски по ходу дела, а не одну сдачу в конце, и можете менять приоритеты между частями.
4. Проверка и релиз. Сборка, линт и тесты проходят до выкатки. Если проверки не пройдены, релиза нет, каким бы срочным он ни был.
5. Наблюдение и развитие. Настраиваем оповещения о сбоях и резервные копии, чтобы о проблеме узнавали вы от команды, а не от клиентов.

Где уходит больше всего времени

Больше всего календарного времени занимает сборка по частям — это основной объём работы. Но на сроки сильнее всего влияют первые два этапа: если на разборе задача сформулирована точно, сборка идёт без переделок. Если разбор пропустили, время возвращается позже — в виде правок уже готовых экранов.

Проверка и релиз кажутся коротким шагом, но экономить на них опасно: ошибка, найденная до выкатки, исправляется за часы, а ошибка у живых пользователей стоит доверия.

Из чего складываются сроки разработки мобильного приложения

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

• Платформы. iOS и Android, а иногда ещё macOS, Windows и веб. Одна кодовая база экономит время там, где это уместно, а родная сборка нужна там, где важна скорость работы.
• Серверная часть. Учётные записи, хранение данных, уведомления, обмен с вашими системами.
• Платежи и подписки. Подключение оплаты, возвратов и сверок, где деньги считаются на сервере, а клиенту показывается результат.
• Языки интерфейса. Если продукт выходит на несколько рынков, тексты отделяют от кода с самого начала, а для арабского интерфейс зеркалится справа налево.
• Личный кабинет и админка. Права доступа, роли сотрудников, журнал действий.
• Публикация в магазинах. Подготовка сборок, описаний и материалов для App Store и Google Play.

Каждый пункт можно отложить на следующий релиз, если он не нужен для главного сценария. Именно так сокращается путь до первой версии.

Публикация в App Store и Google Play — часть работы

Частая ошибка в планировании — считать, что приложение готово, когда готов код. На деле между последней правкой и появлением приложения в магазине есть отдельный этап.

• Подготовка аккаунтов разработчика и подписи сборок.
• Описание, скриншоты, политика конфиденциальности и ответы на вопросы магазина о данных пользователей.
• Проверка приложения со стороны Apple и Google. Её срок не зависит от разработчика, а приложение могут вернуть с замечаниями, которые нужно исправить.
• Для настольных приложений — установщик, подпись, нотаризация и автообновление.

Этот этап стоит закладывать в план сразу. В JEEKSSHIRE 24 публикация в магазинах приложений входит в работу, а не остаётся заказчику как отдельная задача.

Что удлиняет сроки

Большая часть сдвигов связана не с программированием, а с организацией работы. Самые частые причины:

• Размытая задача. Если не ясно, какой результат считается успехом, команда строит догадки, а потом переделывает.
• Новые требования посреди сборки. Каждое «а давайте ещё добавим» сдвигает срок, если не отложить его на следующий релиз.
• Долгие согласования. Неделя ожидания ответа по экрану — это неделя к сроку, даже если работа в этот момент не шла.
• Доступы и данные. Интеграция стоит на месте, пока нет доступа к CRM, складу или почте, а грязные данные приходится чистить.
• Желание выпустить всё сразу. Продукт без единого релиза до финала копит риски: ошибки и неверные решения обнаруживаются поздно.
• Чужой код без описания. Если продукт уже писали другие, сначала нужно прочитать код и понять, что происходит на самом деле.

Как заранее снять первую причину, разобрано в гайде как подготовить ТЗ на разработку. Готовое ТЗ не обязательно, но ясное описание задачи экономит время на всех следующих этапах.

Как ускорить разработку без потери качества

Ускорять можно за счёт объёма и порядка работы, но не за счёт проверок. Пропущенные тесты не сокращают проект, а переносят его время на исправление ошибок у пользователей.

Начать с MVP

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

Выпускать частями

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

Выбирать простое решение

Меньше кода — меньше рисков. Простое решение быстрее строить, быстрее проверять и проще держать в проде. Иногда это значит взять готовый инструмент вместо разработки с нуля — об этом выборе есть разбор заказная разработка или готовое решение.

Быстро отвечать и назначить одного ответственного

Когда со стороны заказчика есть человек, который принимает решения и отвечает в течение дня, проект не простаивает в ожидании согласований.

Как понять, что проект закончен

Срок разработки заканчивается не на последней строке кода, а на приёмке. На выходе заказчик получает работающий продукт в проде, исходный код и права на него, описание того, как продукт устроен и как его выпускать, настроенные оповещения о сбоях и резервные копии.

Дальше продукт живёт: обновления, исправления и развитие идут по договорённости о сопровождении. Что проверить при приёмке и что должно быть передано, разобрано в гайде как принять проект.

Как получить оценку срока для своей задачи

Чтобы разговор о сроках был предметным, подготовьте короткое описание:

• Что сейчас мешает и где теряются время или деньги.
• Какой результат будет считаться успехом.
• Кто будет пользоваться продуктом: клиенты, сотрудники или и те и другие.
• С какими системами нужна связь: CRM, склад, почта, мессенджеры.
• Желаемый срок и что из задуманного нужно в первую очередь.

Опишите задачу своими словами в форме заявки на странице разработки. После разбора команда JEEKSSHIRE 24 вернётся с оценкой и планом по шагам: что войдёт в первую версию и что — в следующие релизы.

Discovery: что это за этап и что получает заказчик

Discovery (дискавери, этап исследования) — это разбор задачи до начала сборки. Его цель — не написать код, а убрать главные неизвестные: что именно строим, для кого, с какими системами продукт связан и где риски. Чем больше неизвестных снято на старте, тем меньше переделок и сдвигов срока потом.

На выходе этапа у заказчика должны быть конкретные материалы, а не только ощущение, что «всё обсудили»:

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

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

Agile, спринты или водопад: как модель работы влияет на сроки

Модель работы определяет, когда вы видите результат и насколько легко менять план.

Водопад (waterfall)

Всё планируется заранее: требования, дизайн, разработка, тестирование и сдача идут по очереди. Модель подходит для небольших задач с неизменным объёмом. Риск в том, что результат виден только в конце, и ошибка в понимании задачи обнаруживается слишком поздно.

Гибкий подход (Agile) и спринты

Работа идёт короткими циклами — спринтами. В конце каждого команда показывает работающую часть, а приоритеты следующего цикла уточняются по результату. Общий срок при этом тоже планируется, но план корректируется по фактам, а не по прогнозам.

На практике для заказной разработки часто выбирают середину: общий план и оценка по частям, а внутри — короткие циклы с показом результата. Так мы и работаем: вы видите работающие куски по ходу дела и можете менять приоритеты. Если первую версию нужно выпустить как можно раньше, этот подход удобно сочетать с разработкой MVP.