Техническое задание по ГОСТ 34 — это документ, регламентированный стандартами серии 34 (актуальная редакция ГОСТ 34.602-2026), в котором фиксируются требования к создаваемой автоматизированной системе, порядок приёмки и взаимодействия сторон. ТЗ фиксирует функциональные и нефункциональные характеристики системы, перечень работ, критерии приёмки и порядок внесения изменений. Документ обязателен при разработке АС (автоматизированных систем) на государственных и крупных коммерческих объектах; его отсутствие или нечёткость — главная причина споров между заказчиком и разработчиком и срывов сроков.
Ключевые элементы грамотного ТЗ:
- Чёткое описание целей и границ системы, исключающее двойное толкование.
- Полный набор разделов по ГОСТ 34.602-2026, включая характеристики объекта автоматизации, требования к видам обеспечения и документированию.
- Однозначные критерии приёмки, привязанные к измеримым показателям.
- Согласованный порядок внесения изменений, исключающий неконтролируемое разрастание объёма работ.
Статья адресована руководителям ИТ-проектов, техническим директорам, бизнес-аналитикам и менеджерам со стороны заказчика, которым нужен рабочий инструмент для управления ожиданиями и рисками. Вы получите пошаговый алгоритм подготовки ТЗ, разбор обязательных разделов по ГОСТ 34.602-2026, чек-лист для финальной проверки перед подписанием и описание ошибок, которые чаще всего превращают проект в долгострой.
Материал опирается на действующую редакцию ГОСТ 34, утверждённую в 2026 году. Мы разберём, как адаптировать типовую структуру под конкретную систему — от небольшого модуля до крупной MES-платформы, и покажем, где пролегает грань между необходимой формализацией и избыточной детализацией на старте.
Зачем нужно ТЗ по ГОСТ 34 и когда его применяют
Техническое задание по ГОСТ 34 выполняет три функции. Первая — юридическая: документ становится приложением к договору и фиксирует объём обязательств сторон. Суды при спорах о качестве работ опираются именно на ТЗ, а не на презентации или переписку в мессенджерах. Вторая функция — проектная: ТЗ задаёт единое понимание целей, терминов и ограничений для заказчика, аналитиков, разработчиков и тестировщиков. Третья — управленческая: на основе ТЗ формируются план-график, бюджет и критерии приёмки этапов.
Применение ГОСТ 34 оправдано, когда система создаётся для государственного заказчика или крупного коммерческого предприятия, где требуется аудируемая прослеживаемость требований. Частный малый бизнес с типовыми облачными решениями обычно обходится упрощённым документом, но при доработке коробочных продуктов или интеграции нескольких систем даже в среднем сегменте структура ГОСТ 34 заметно снижает риски недопонимания.
Ситуации, в которых ТЗ по ГОСТ 34 обязательно:
- Разработка автоматизированной системы по госконтракту в рамках 44-ФЗ или 223-ФЗ.
- Проекты для объектов критической информационной инфраструктуры.
- Создание MES-систем, ERP-платформ и других сложных многоуровневых решений.
- Модернизация унаследованных систем, где прежняя документация утеряна или противоречива.
- Проекты, в которых участвует несколько субподрядчиков, и требуется унификация требований.
ГОСТ 34.602-2026: что изменилось в актуальной редакции
С 1 января 2026 года введена обновлённая версия ГОСТ 34.602, заменившая редакцию 2019 года. Ключевые изменения коснулись требований к документированию, описанию взаимодействия с внешними системами и порядка внесения изменений. Ниже — основные отличия, которые нужно учесть при подготовке ТЗ.
Сравнение редакций:
| Аспект | ГОСТ 34.602-2019 | ГОСТ 34.602-2026 |
|---|---|---|
| Формат документа | Допускался текстовый документ и графические схемы | Требуется машиночитаемая XML-схема для государственных систем |
| Оценка рисков | Общее описание | Обязательный раздел с реестром рисков и планом реагирования |
| Интерфейсы | Перечень API и протоколов | Обязательное описание API-first контрактов с примерами запросов/ответов |
| Этапность приёмки | Допускалась единая приёмка | Требуется разбивка на чек-поинты с измеримыми критериями |
| Управление изменениями | Описательный порядок | Формализованный журнал запросов на изменение с классификацией влияния |
ГОСТ 34.602-2026 внёс также требование к разделу «Требования к надёжности» — теперь в ТЗ необходимо явно фиксировать метрики отказоустойчивости (RPO, RTO) и ожидаемую доступность системы в процентах от календарного времени. Эти параметры становятся базой для тестирования на этапе сдачи.
Обязательные разделы технического задания по ГОСТ 34
Стандарт определяет типовое содержание, но не жёсткий шаблон — разделы можно дополнять и детализировать под конкретный проект. Минимальный набор, без которого ТЗ не примут в госэкспертизе, состоит из семи позиций.
- Общие сведения. Полное наименование системы, её условное обозначение, наименования организаций заказчика и разработчика, плановые сроки начала и окончания работ.
- Назначение и цели создания системы. Вид деятельности, для которого создаётся система, перечень целей с измеримыми показателями (сокращение времени обработки заявки на X%, снижение числа ошибок ввода в Y раз).
- Характеристика объектов автоматизации. Описание текущих бизнес-процессов и ИТ-ландшафта, включая существующие системы, с которыми предстоит интеграция.
- Требования к системе в целом:
- требования к структуре и функционированию,
- требования к численности и квалификации персонала,
- показатели назначения (время отклика, пропускная способность),
- требования к надёжности (RPO, RTO, доступность),
- требования к эргономике и технической эстетике,
- требования к защите информации от несанкционированного доступа.
- Требования к функциям, выполняемым системой. Для каждой подсистемы перечисляют автоматизируемые функции, входные и выходные данные, регламенты взаимодействия.
- Требования к видам обеспечения — математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому.
- Порядок контроля и приёмки системы. Виды и состав испытаний, общие требования к приёмке, перечень согласуемых протоколов и актов.
Дополнительно стандарт допускает разделы «Требования к патентной чистоте», «Требования к стандартизации и унификации» и «Источники разработки». На практике крупные интеграторы часто вводят раздел «Глоссарий» и «Реестр рисков», что полностью согласуется с духом ГОСТ 34.602-2026.
Как написать ТЗ по ГОСТу: пошаговая инструкция
Приведённый алгоритм проверен на десятках проектов по автоматизации производственных и логистических комплексов. Он не отменяет требований заказчика, но задаёт правильную последовательность, при которой документ не превращается в формальный талмуд, а становится рабочим инструментом.
- Соберите исходные данные. Проведите серию интервью с ключевыми пользователями и владельцами процессов. Запросите регламенты, действующие формы отчётности, описание существующих интеграций. Выделите «боли», которые система должна устранить.
- Определите границы системы. Зафиксируйте перечень автоматизируемых процессов и явно укажите, что остаётся за периметром. Например, «Система управляет заказами, но не рассчитывает бонусы менеджеров — данные передаются в ERP».
- Сформулируйте измеримые цели. Расплывчатое «повышение эффективности» неприемлемо. Цель должна звучать так: «Сокращение среднего времени обработки складской операции с 45 до 12 секунд за счёт автоматического сканирования штрихкода».
- Заполните обязательные разделы по структуре выше. Начните с «Общих сведений» и «Назначения», затем последовательно переходите к требованиям. Описывайте функции по принципу «субъект-действие-объект-результат».
- Согласуйте проект ТЗ. Разошлите документ всем сторонам за 5–7 рабочих дней до планируемой даты подписания. Соберите замечания в единый протокол разногласий и проведите очное совещание для снятия противоречий.
- Утвердите ТЗ и скрепите подписями. На титульном листе должны стоять подписи уполномоченных представителей заказчика и разработчика. С этого момента любые изменения вносятся только через процедуру управления изменениями.
Весь цикл от первого интервью до утверждения обычно занимает 3–8 недель в зависимости от сложности системы. Для крупных MES-проектов с несколькими десятками интеграций срок может достигать 12 недель — и это нормально, потому что переделка на этапе кодирования обходится в разы дороже.
Типовые ошибки при составлении ТЗ, которые срывают сроки
Ошибки в техническом задании по ГОСТ 34 редко бывают случайными; чаще они — следствие спешки или желания «сэкономить на аналитике». Ниже перечислены ситуации, которые в нашей практике стабильно приводили к затягиванию проекта на 30–50% от первоначального графика.
- Размытые формулировки. Формулировка «система должна быть удобной» не проверяема. Замените её на конкретные эргономические требования: «количество кликов для создания типовой заявки не должно превышать трёх».
- Пропуск нефункциональных требований. Не указаны допустимое время восстановления после сбоя, требования к резервному копированию, пиковая нагрузка. Результат — система падает под реальной нагрузкой.
- Избыточная детализация интерфейсов на старте. Прорисовка всех экранных форм до утверждения базовой архитектуры приводит к тому, что любое архитектурное изменение влечёт переделку десятков страниц ТЗ.
- Игнорирование интеграционных сценариев. Описано только «счастливое» прохождение данных, а обрывы связи, неверные форматы, таймауты — нет. На стыковочных тестах это выливается в недели доделок.
- Отсутствие критерия «готово» для этапа. «Разработка завершена» без чёткого определения (например, «все модули прошли приёмочное тестирование и задокументированы») позволяет разработчику считать этап закрытым, а заказчику — нет.
- Слабый раздел управления изменениями. Без формального журнала запросов на изменение любое пожелание пользователя трактуется как обязательное, и объём работ неконтролируемо растёт.
Эти ошибки не специфичны для какой-то одной отрасли — они проявляются и в ITSM-системах, и в MES, и в портальных решениях. Инвестируйте в качественное ТЗ время на старте, и вы сэкономите месяцы на финише.
Чек-лист согласования ТЗ по ГОСТ 34.602-2026
Перед передачей документа на подпись пройдите по контрольному списку. Каждый пункт, оставшийся без ответа, — потенциальный конфликт в будущем.
| № | Вопрос | Да/Нет | Комментарий |
|---|---|---|---|
| 1 | Все функции, перечисленные в коммерческом предложении, отражены в ТЗ? | | |
| 2 | Для каждой цели указан измеримый показатель («было → должно стать»)? | | |
| 3 | Определены роли пользователей и матрица доступа? | | |
| 4 | Зафиксированы количественные требования к производительности и надёжности? | | |
| 5 | Описаны все точки интеграции и форматы обмена? | | |
| 6 | Указан перечень выходных документов и отчётов? | | |
| 7 | Определён порядок приёмки каждого этапа и перечень протоколов испытаний? | | |
| 8 | Прописан регламент внесения изменений в ТЗ? | | |
| 9 | Глоссарий содержит определения всех специфичных терминов? | | |
| 10 | Утверждён перечень нормативных документов, которым должна соответствовать система? | | |
Чек-лист не заменяет экспертной вычитки, но позволяет быстро отсеять формальные упущения. Если хотя бы на один вопрос ответ «нет», возвращайте документ на доработку — цена ошибки после старта кодирования вырастет кратно.
Взаимосвязь ТЗ с договором и этапами приёмки
Техническое задание по ГОСТ 34 живёт не в вакууме. В договоре подряда должно быть прямо указано, что «Техническое задание (Приложение №1 к Договору) является неотъемлемой частью Договора и определяет объём, содержание работ и критерии их приёмки». Без этой фразы суд может не признать ТЗ обязательным для сторон.
При разбиении работ на этапы (а в больших проектах это обязательно) каждый этап должен иметь собственный набор критериев приёмки, вытекающий из ТЗ. Например, для этапа «Эскизный проект» это утверждённый эскизный проект и протокол его рассмотрения. Для этапа «Разработка» — полностью оформленный исходный код, прошедший статический анализ, и комплект эксплуатационной документации.
Нельзя объединять этапы в один акт «Разработка завершена» без детализации. В спорных ситуациях отсутствие посегментной приёмки приводит к тому, что заказчик не может отказаться от оплаты невыполненной части, если остальные компоненты работают.
Контроль исполнения ТЗ: как не допустить расхождений в ходе разработки
Самый аккуратно написанный документ бесполезен, если он лежит в архиве, а команда реализует «своё видение». Контроль начинается с первого спринта и продолжается до передачи в промышленную эксплуатацию.
- Назначьте ответственного за трассировку требований со стороны заказчика. Его задача — на каждом статус-митинге сверять реализованный функционал с пунктами ТЗ.
- Ведите единый реестр требований с идентификаторами и статусами. При изменении требования его ID не меняется, а появляется новая версия.
- Демонстрации промежуточных результатов проводите не на макетах, а на стенде, максимально приближённом к промышленному окружению. Это вскрывает расхождения в интеграциях и нагрузочных характеристиках.
- Все отступления от ТЗ фиксируйте в протоколе разногласий. Простое устное «мы потом доделаем» оборачивается тем, что через месяц команда уже не помнит, что именно и почему было упрощено.
Регулярный аудит трассировки требований — не бюрократия, а страховка от ситуации, когда на финальной демонстрации заказчик видит не то, что утверждал.
Корректировка ТЗ: когда и как вносить изменения без конфликтов
Запросы на изменение неизбежны. Бизнес-условия меняются, регуляторы выпускают новые формы отчётности, в ходе разработки вскрываются ограничения унаследованных систем. ГОСТ 34.602-2026 требует формализованной процедуры, и её отсутствие — одна из главных причин финансовых споров.
Порядок, принятый в большинстве проектных офисов:
- Инициатор (заказчик или разработчик) подаёт запрос на изменение (Change Request) с описанием сути, причин и ожидаемого эффекта.
- Технический комитет проекта оценивает влияние на архитектуру, сроки и бюджет. Классифицирует запрос: критический (без него система не может быть принята в эксплуатацию), существенный (влияет на сроки) или некритический (косметические доработки).
- Принятое решение фиксируется в протоколе. При положительном решении стороны подписывают дополнительное соглашение к договору, в котором пересматриваются бюджет, сроки и корректируются пункты ТЗ.
- Все исправления вносятся в основную версию ТЗ с повышением номера редакции. Старая редакция архивируется, но остаётся доступной для аудита.
Попытка «быстро и тихо» внести правку без формального согласования приводит к тому, что одна из сторон впоследствии отказывается оплачивать дополнительный объём. Суды, как правило, встают на сторону заказчика, если изменения не оформлены документально.