Почему сроки в ТЗ не берутся из воздуха
В коммерческой разработке срок — результат переговоров, в закупке — юридический факт: он попадает в контракт, за просрочку начисляется пени 1/300 ключевой ставки за каждый день (ст. 34 44-ФЗ и ПП № 1042, разбор — в «Штрафы и пени по 44-ФЗ для ИТ»). При этом заказчики нередко ставят срок от даты финансирования, а не от трудоёмкости, а поставщики соглашаются, чтобы выиграть. Результат предсказуем: срыв этапов, споры на приёмке, штрафы. Правильный порядок обратный: сначала трудоёмкость и этапность, потом календарь, и только потом — цена контракта.
Каркас: стадии по ГОСТ 34.601-90
Отечественный стандарт ГОСТ 34.601-90 описывает полный жизненный цикл создания автоматизированной системы восемью стадиями: формирование требований к АС, разработка концепции, техническое задание, эскизный проект, технический проект, рабочая документация, ввод в действие, сопровождение. Стандарт прямо допускает объединять и исключать стадии — «делать все восемь» ради бюрократии не нужно, но каждая строка вашего календаря должна быть одной из этих стадий.
Для закупок ПО это даёт два практических следствия. Первое: срок в контракте — это не «дата, когда сайт заработает», а последовательность стадий с датами, у каждой стадии свой результат и своя приёмка. Второе: если заказчик требует «ввод в действие» за срок, в который физически не выполняются даже ТЗ и технический проект, — это видно сразу и это повод для запроса разъяснений (как читать извещение целиком — в пошаговом разборе извещения).
| Стадия ГОСТ 34.601-90 | Результат стадии | Кто критичен для срока |
|---|---|---|
| Формирование требований, концепция | отчёт об обследовании, концепция АС | доступ заказчика к процессам и данным |
| Техническое задание | утверждённое ТЗ (по ГОСТ 34.602-89) | скорость согласований заказчика |
| Эскизный и технический проект | архитектура, спецификации, план работ | команда поставщика |
| Рабочая документация | программа и базы данных, документация | команда поставщика |
| Ввод в действие | испытания, опытная эксплуатация, ввод | оба участника |
| Сопровождение | гарантийная поддержка | режим по контракту |
Испытания закладываются в срок, а не «потом»
ГОСТ 34.603-92 закрепляет виды испытаний автоматизированных систем: предварительные испытания, опытная эксплуатация, приёмочные испытания. Каждое — с комплектом документов: программы и методики испытаний, протоколы, акты. На практике именно этот блок съедает от четверти до половины календарного срока, потому что привязан к людям заказчика: назначить комиссию, подготовить стенд, собрать протоколы. В ТЗ сроки испытаний прописываются явно: сколько дней на предварительные, сколько на опытную эксплуатацию (обычно недели, а не дни — если объём системы большой), сколько на устранение замечаний. Этапы и акты приёмки по 44-ФЗ разобраны в «Приёмка ПО: этапы и акты».
Переводим требования в часы
Трудоёмкость считается от требований ТЗ, а не «по ощущению команды». Рабочий алгоритм:
- Декомпозиция: каждое функциональное требование разбивается на задачи аналитика, дизайнера, разработчиков, тестировщика — до размера, оцениваемого в часах.
- Оценка с диапазоном: каждой задаче — оптимистичная и пессимистичная оценка; для закупки берётся консервативная, потому что контракт не резиновый.
- Календарование: часы делятся на доступную пропускную способность команды с учётом занятости людей на других проектах — 1 000 часов разработки не равны месяцу, если на проекте два разработчика не на полном дне.
- Внешние зависимости: время на интеграции со смежными системами заказчика, закупку лицензий и доступов, импорт данных — считаются отдельно, потому что управляются не вами.
Для пересчёта в деньги годятся рыночные ставки ИТ-разработки по ролям 2 800–3 800 ₽/час (наш прайс-бук по 236 закрытым ИТ-лотам, контекст — в прайс-листе рынка разработки ПО 2026): трудоёмкость в часах одновременно проверяет и срок, и цену — если часы × ставка превышают НМЦК, закупка не сходится до подачи заявки, а не после победы.
Буферы: чей риск — того и время
Классическая ошибка поставщика — планировать идеальный мир. В календарь закладываются:
- буфер на согласования — каждая экспертиза документа заказчиком берётся с запасом; циклы «отправил — правки — снова отправил» умножают срок документации;
- буфер на данные — если обучающая выборка, справочники или исторические данные готовит заказчик, его задержка не должна становиться вашей просрочкой (для ИИ-систем этот риск главный — см. ТЗ на ИИ-систему);
- буфер на испытания — повторные прогоны после устранения замечаний;
- буфер на регресс — фиксы, найденные на поздних стадиях, всегда дороже.
Юридическая упаковка буферов — формулировки в проекте контракта о приостановке срока на период согласований или непредоставления данных заказчиком; если таких условий нет, спор о просрочке решается не в вашу пользу. Что можно менять в проекте контракта после победы — в разборе протокола разногласий.
Чек-лист срока перед подачей заявки
- Все этапы календаря названы стадиями ГОСТ 34.601-90 или ссылками на них.
- На испытания (ГОСТ 34.603-92) отведено явное время с учётом комиссий заказчика.
- Трудоёмкость посчитана декомпозицией требований, а не «по опыту похожего проекта».
- Внешние зависимости заказчика выделены и имеют даты или дедлайны в контракте.
- Буферы включены в срок, а не «поймем по ходу».
- Срок в извещении ≥ суммы этапов; иначе — запрос разъяснений или отказ от участия.
Что мы предлагаем
ООО «НЬЮ-ССТ» выполняет госзаказы на разработку ПО и знает цену каждой неделе планирования. Пришлите ТЗ или ссылку на закупку на sales@vyshka.cloud — бесплатно, за 1 рабочий день вернём расчёт: этапы по ГОСТ 34, трудоёмкость в часах, календарь с буферами и вердикт о реальности сроков. Составление ТЗ под закупку — в услуге «Бизнес-аналитика и ТЗ», чем MVP отличается от промышленной системы и почему сроки различаются в разы — в ответе «Чем отличается MVP от промышленной системы».