Вопросы и ответы

Как понять реальные сроки разработки цифрового сервиса до подписания договора

Автор и проверка: Алексей Воронов, редакционный координатор ormobil.com · Факты, документы, риски и применимость · Обновлено: 02 сентября 2025 г.

Реальные сроки разработки цифрового сервиса можно понять до договора, если проверять не обещание «сделаем за месяц», а состав работ, готовность ТЗ, команду, зависимости и порядок согласований. Попросите подрядчика дать

Критерии выбора

Что считать реальным сроком разработки

Реальный срок — это не только время программиста за кодом. В него входят:

• уточнение требований;

• проектирование сценариев пользователя;

• дизайн интерфейсов;

• разработка backend и frontend или мобильного приложения;

• интеграции с внешними сервисами;

• тестирование;

• исправление ошибок;

• приемка заказчиком;

• публикация, релиз или передача в эксплуатацию;

• гарантийная стабилизация после запуска.

Например, если подрядчик говорит: «MVP личного кабинета сделаем за 4 недели», нужно уточнить, что именно входит в эти 4 недели. Если туда не включены согласование макетов, подключение платежей, тестирование на устройствах и исправление критичных ошибок, фактический запуск может занять 6–10 недель.

Какие документы нужно запросить до договора

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

| Документ | Что проверять | Почему важно для сроков |

|---|---|---|

| Техническое задание или brief | Есть ли роли пользователей, сценарии, ограничения, интеграции | Без ТЗ сроки почти всегда приблизительные |

| Смета | Разбивка по этапам, часам, ставкам, допущениям | Видно, где срок может вырасти |

| Календарный план | Даты начала и окончания этапов, контрольные точки | Помогает отличить план от устного обещания |

| Договор | Ответственность, приемка, гарантия, порядок изменений | Защищает от бесконечного переноса запуска |

| Спецификация интеграций | API, доступы, внешние подрядчики, тестовые среды | Интеграции часто задерживают проект |

| Регламент правок | Количество итераций, сроки реакции сторон | Устные правки ломают график |

| План поддержки | Что происходит после релиза | Запуск без поддержки повышает риск простоев |

Минимальный срок на нормальную предпроектную оценку обычно составляет 3–7 рабочих дней. Если сложный сервис оценивают «за час» без вопросов к бизнес-логике, это повод насторожиться.

Какие сроки выглядят правдоподобно

Точные сроки зависят от состава функций, команды и готовности материалов. Но для первичной проверки можно ориентироваться на такие диапазоны:

| Тип цифрового сервиса | Примерный срок при готовом ТЗ | Что может увеличить срок |

|---|---:|---|

| Лендинг с формами и простой админкой | 2–4 недели | Нестандартная анимация, интеграции, много правок |

| Корпоративный сайт с каталогом | 1,5–3 месяца | Импорт данных, фильтры, роли редакторов |

| MVP мобильного приложения | 2–4 месяца | iOS/Android одновременно, offline-режим, пуши |

| Личный кабинет клиента | 2–5 месяцев | Авторизация, платежи, статусы заказов, CRM |

| B2B-портал или сервис с ролями | 4–8 месяцев | Сложные права доступа, API, нагрузка, безопасность |

| Маркетплейс или SaaS-платформа | 6–12 месяцев и более | Много ролей, биллинг, модерация, аналитика |

Если вам обещают разработать сложный сервис с личным кабинетом, платежами, уведомлениями и интеграцией с CRM за 2–3 недели, нужно попросить детализацию: возможно, речь идет только о прототипе, шаблонной версии или части функциональности.

---

Таблица проверки

Как проверить срок до подписания договора

| Проверка | Хороший признак | Рискованный признак |

|---|---|---|

| Подрядчик задает вопросы | Уточняет роли, сценарии, данные, интеграции, ограничения | Сразу называет срок без погружения |

| Есть декомпозиция | Работы разбиты на этапы и задачи | В смете одна строка: «разработка сервиса» |

| Указаны зависимости | Доступы, API, контент, согласования вынесены отдельно | Все зависит «от команды подрядчика» |

| Есть буфер | В плане заложены тестирование и исправления | Релиз стоит сразу после завершения разработки |

| Описана приемка | Понятно, кто и как принимает этапы | Приемка «по факту готовности» |

| Прописаны правки | Есть лимит итераций и сроки реакции | Правки устные и без фиксации |

| Есть гарантия | Указан срок гарантийной поддержки, например 14–30 дней | После релиза поддержка не предусмотрена |

| Показано портфолио | Есть похожие проекты и подтвержденные кейсы | Только общие слова и красивые презентации |

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

---

Сравнение вариантов

Вариант 1. Быстрая оценка «по описанию»

Подходит, если вы только выбираете подрядчика и хотите понять порядок бюджета и сроков.

Что можно получить:

• примерный диапазон сроков;

• вилку бюджета;

• список ключевых рисков;

• предположение по составу команды.

Минусы:

• точность низкая;

• много допущений;

• подрядчик может занизить срок, чтобы выиграть переговоры.

Пример: вы описываете сервис как «мобильное приложение для записи клиентов». По такой формулировке один подрядчик может оценить 1,5 месяца, другой — 5 месяцев. Разница объясняется деталями: нужна ли онлайн-оплата, личный кабинет, расписание специалистов, push-уведомления, интеграция с CRM, модерация и аналитика.

Вариант 2. Предпроектное обследование

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

Обычно включает:

• интервью с владельцем продукта;

• карту пользовательских ролей;

• описание ключевых сценариев;

• список интеграций;

• оценку MVP;

• календарный план;

• технические ограничения;

• рекомендации по этапам запуска.

Практический ориентир: предпроектная оценка может занимать от 3–7 рабочих дней для небольшого сервиса до 2–4 недель для сложной платформы с несколькими ролями и внешними системами.

Такой этап помогает не переплачивать за лишние функции и не начинать разработку с размытым объемом работ.

Вариант 3. Договор на MVP с фиксированным объемом

Подходит, если нужно быстро проверить гипотезу и не строить сразу «полную версию».

Что фиксировать:

• список функций первой версии;

• что не входит в MVP;

• критерии готовности;

• сроки этапов;

• формат тестирования;

• правила добавления новых задач.

Например, вместо «сделать маркетплейс» можно зафиксировать MVP: регистрация продавца, карточка товара, каталог, заявка покупателя, админская модерация. Оплату, рейтинг, чат, аналитику и доставку можно вынести во второй этап. Это делает срок более управляемым.

Вариант 4. Срочная разработка

Иногда бизнесу нужен запуск к выставке, тендеру, сезонной продаже или внутренней дате. Срочный вариант возможен, но он должен быть честно описан.

Что меняется при срочном запуске:

• увеличивается стоимость из-за расширенной команды;

• часть функций переносится после релиза;

• растет риск технического долга;

• нужна быстрая приемка со стороны заказчика;

• нельзя бесконечно менять требования.

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

---

Что изменилось сейчас и что проверять особенно внимательно

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

Поэтому до договора важно проверять не только «сколько пишем код», но и:

• готовы ли доступы к внешним сервисам;

• есть ли актуальная API-документация;

• кто отвечает за тестовую среду;

• кто предоставляет контент и данные;

• кто принимает решения по дизайну;

• нужно ли проходить модерацию в App Store или Google Play;

• есть ли требования к персональным данным и безопасности;

• кто оплачивает лицензии, серверы и сторонние сервисы.

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

---

Когда предложенный срок не подходит

Срок стоит считать ненадежным, если:

• нет технического задания;

• нет списка функций;

• не указано, что входит и не входит в работу;

• сроки названы устно;

• смета не разбита на этапы;

• не описаны правки;

• нет ответственности за задержки;

• не указаны зависимости от заказчика;

• гарантия отсутствует;

• поддержка после запуска не предусмотрена.

Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов или отсутствие поддержки. В цифровом проекте это может означать, что дизайн передали не в том формате, API не готов, платежный модуль требует дополнительной настройки, а исправление ошибок после релиза внезапно считается отдельной платной работой.

Что может пойти не так

1. Срок был рассчитан без интеграций

Подрядчик оценил интерфейс и базовую логику, но не учел CRM, оплату, SMS, email-рассылку или складскую систему.

2. ТЗ заменили перепиской в мессенджере

В итоге каждая сторона по-своему понимает объем работ.

3. Правки не ограничены

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

4. Заказчик задерживает материалы

Нет текстов, изображений, доступов, тестовых данных или ответственного за приемку.

5. Не заложено тестирование

Формально разработка завершена, но сервис нестабилен и запуск переносится.

6. Не определены права на результат

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

---

1. Техническое задание

• Есть ли описание целей сервиса?

• Перечислены ли роли пользователей?

• Описаны ли основные сценарии?

• Указаны ли ограничения и исключения?

• Есть ли список функций MVP?

• Отдельно ли указано, что не входит в первый релиз?

2. Сроки

• Есть ли календарный план?

• Разбиты ли сроки по этапам?

• Есть ли дата начала и дата релиза?

• Указаны ли сроки согласований со стороны заказчика?

• Заложены ли тестирование и исправления?

• Есть ли буфер на риски?

3. Смета

• Есть ли базовая, оптимальная и срочная смета?

• Понятна ли стоимость каждого этапа?

• Указаны ли ставки или трудозатраты?

• Видно ли, что считается дополнительной работой?

• Прописана ли стоимость переделки?

• Отдельно ли указаны лицензии, серверы, внешние сервисы?

4. Команда

• Кто будет менеджером проекта?

• Кто отвечает за аналитику?

• Кто делает дизайн?

• Кто разрабатывает backend и frontend?

• Кто тестирует?

• Кто отвечает за релиз и поддержку?

5. Правки и приемка

• Сколько итераций правок включено?

• Как фиксируются изменения?

• Через какой канал принимаются задачи?

• Какой срок реакции у заказчика и подрядчика?

• Что считается завершенным этапом?

• Что делать, если требования изменились?

6. Гарантия и поддержка

• Есть ли гарантийный период?

• Что считается гарантийным случаем?

• Сколько стоит поддержка после гарантии?

• Кто следит за сервером?

• Кто исправляет ошибки после запуска?

• Как быстро реагируют на критичные сбои?

---

Пример правильного запроса подрядчику

Чтобы получить честную оценку, можно направить подрядчику такой запрос:

> Нужна оценка сроков и бюджета разработки цифрового сервиса. Просим подготовить 3 варианта: базовый, оптимальный и срочный. Отдельно указать сроки первичной оценки 3–7 рабочих дней, состав команды, этапы, риски, гарантию, стоимость переделки, порядок правок, поддержку после запуска и список данных, которые нужны от нас до старта.

К запросу полезно приложить:

• краткое описание продукта;

• список нужных функций;

• примеры похожих сервисов;

• предполагаемые роли пользователей;

• требования к мобильной версии или приложениям;

• список интеграций;

• желаемую дату запуска;

• ограничения по бюджету;

• текущие материалы: дизайн, брендбук, API, базы данных, документы.

Так подрядчик сможет оценить не абстрактный «сервис», а конкретный объем работ.

---

Контекстные материалы, которые стоит подготовить

Для более точной оценки сроков полезно заранее собрать внутренний пакет:

• бизнес-цель сервиса;

• описание аудитории;

• список обязательных функций;

• список функций «можно позже»;

• требования к безопасности;

• требования к хранению данных;

• доступы к текущим системам;

• контакты ответственных сотрудников;

• примеры интерфейсов, которые вам нравятся;

• критерии успешного запуска.

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

---

Можно ли понять точный срок до подписания договора?

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

Почему разные подрядчики называют разные сроки?

Они могут по-разному понимать объем работ. Один считает только разработку интерфейса, другой включает аналитику, дизайн, backend, тестирование, интеграции и релиз. Поэтому сравнивать нужно не финальную дату, а состав работ в смете.

Что важнее для проверки: цена или срок?

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

Сколько времени занимает оценка проекта?

Для небольшого цифрового сервиса первичная оценка обычно занимает 3–7 рабочих дней. Для сложной платформы, мобильного приложения с несколькими ролями или проекта с интеграциями может потребоваться 2–4 недели предпроектного обследования.

Нужно ли платить за предпроектную аналитику?

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

Что делать, если подрядчик обещает очень быстро?

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

Как зафиксировать срок в договоре?

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

Что обязательно должно быть в смете?

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

Как понять, что срок занижен?

Признаки: нет ТЗ, нет этапов, нет тестирования, не учтены интеграции, не указаны зависимости от заказчика, отсутствует гарантия, а все правки обещают «по ходу». В таком случае фактический срок почти наверняка вырастет.

Какой самый безопасный подход?

Начать с фиксированного MVP, согласовать список функций первой версии и вынести дополнительные идеи в следующий этап. Так проще контролировать сроки, бюджет и качество запуска.