Техническое задание по ГОСТ 34: как составить документ, который примут и заказчик, и разработчик

Техническое задание по ГОСТ 34 — это документ, регламентированный стандартами серии 34 (актуальная редакция ГОСТ 34.602-2020), в котором фиксируются требования к создаваемой автоматизированной системе, порядок приёмки и взаимодействия сторон. ТЗ фиксирует функциональные и нефункциональные характеристики системы, перечень работ, критерии приёмки и порядок внесения изменений. Документ обязателен при разработке АС (автоматизированных систем) на государственных и крупных коммерческих объектах; его отсутствие или нечёткость — главная причина споров между заказчиком и разработчиком и срывов сроков.

Ключевые элементы грамотного ТЗ:

• Чёткое описание целей и границ системы, исключающее двойное толкование.
• Полный набор разделов по ГОСТ 34.602-2020, включая характеристики объекта автоматизации, требования к видам обеспечения и документированию.
• Однозначные критерии приёмки, привязанные к измеримым показателям.
• Согласованный порядок внесения изменений, исключающий неконтролируемое разрастание объёма работ.

Статья адресована руководителям ИТ-проектов, техническим директорам, бизнес-аналитикам и менеджерам со стороны заказчика, которым нужен рабочий инструмент для управления ожиданиями и рисками. Вы получите пошаговый алгоритм подготовки ТЗ, разбор обязательных разделов по ГОСТ 34.602-2020, чек-лист для финальной проверки перед подписанием и описание ошибок, которые чаще всего превращают проект в долгострой.

Материал опирается на действующую редакцию ГОСТ 34, утверждённую в 2026 году. Мы разберём, как адаптировать типовую структуру под конкретную систему — от небольшого модуля до крупной MES-платформы, и покажем, где пролегает грань между необходимой формализацией и избыточной детализацией на старте.

Зачем нужно ТЗ по ГОСТ 34 и когда его применяют

Техническое задание по ГОСТ 34 выполняет три функции. Первая — юридическая: документ становится приложением к договору и фиксирует объём обязательств сторон. Суды при спорах о качестве работ опираются именно на ТЗ, а не на презентации или переписку в мессенджерах. Вторая функция — проектная: ТЗ задаёт единое понимание целей, терминов и ограничений для заказчика, аналитиков, разработчиков и тестировщиков. Третья — управленческая: на основе ТЗ формируются план-график, бюджет и критерии приёмки этапов.

Применение ГОСТ 34 оправдано, когда система создаётся для государственного заказчика или крупного коммерческого предприятия, где требуется аудируемая прослеживаемость требований. Частный малый бизнес с типовыми облачными решениями обычно обходится упрощённым документом, но при доработке коробочных продуктов или интеграции нескольких систем даже в среднем сегменте структура ГОСТ 34 заметно снижает риски недопонимания.

Ситуации, в которых ТЗ по ГОСТ 34 обязательно:

• Разработка автоматизированной системы по госконтракту в рамках 44-ФЗ или 223-ФЗ.
• Проекты для объектов критической информационной инфраструктуры.
• Создание MES-систем, ERP-платформ и других сложных многоуровневых решений.
• Модернизация унаследованных систем, где прежняя документация утеряна или противоречива.
• Проекты, в которых участвует несколько субподрядчиков, и требуется унификация требований.

ГОСТ 34.602-2020: какая редакция действует сейчас

Действующая редакция стандарта на техническое задание — ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Она пришла на смену давнему ГОСТ 34.602-89 и сохранила преемственность структуры ТЗ, уточнив формулировки разделов и приведя терминологию к современной серии стандартов на АС.

Что стоит учитывать при работе по актуальной редакции:

Стандарт задаёт минимально необходимый каркас. Крупные заказчики и интеграторы часто дополняют ТЗ разделами «Глоссарий», «Реестр рисков» и измеримыми критериями приёмки по этапам — это не противоречит ГОСТ 34.602-2020 и снижает риск споров при сдаче.

Обязательные разделы технического задания по ГОСТ 34

Стандарт определяет типовое содержание, но не жёсткий шаблон — разделы можно дополнять и детализировать под конкретный проект. Минимальный набор, без которого ТЗ не примут в госэкспертизе, состоит из семи позиций.

1. Общие сведения. Полное наименование системы, её условное обозначение, наименования организаций заказчика и разработчика, плановые сроки начала и окончания работ.
2. Назначение и цели создания системы. Вид деятельности, для которого создаётся система, перечень целей с измеримыми показателями (сокращение времени обработки заявки на X%, снижение числа ошибок ввода в Y раз).
3. Характеристика объектов автоматизации. Описание текущих бизнес-процессов и ИТ-ландшафта, включая существующие системы, с которыми предстоит интеграция.
4. Требования к системе в целом:

• требования к структуре и функционированию,
• требования к численности и квалификации персонала,
• показатели назначения (время отклика, пропускная способность),
• требования к надёжности (RPO, RTO, доступность),
• требования к эргономике и технической эстетике,
• требования к защите информации от несанкционированного доступа.

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

Дополнительно стандарт допускает разделы «Требования к патентной чистоте», «Требования к стандартизации и унификации» и «Источники разработки». На практике крупные интеграторы часто вводят раздел «Глоссарий» и «Реестр рисков», что полностью согласуется с духом ГОСТ 34.602-2020.

Как написать ТЗ по ГОСТу: пошаговая инструкция

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

1. Соберите исходные данные. Проведите серию интервью с ключевыми пользователями и владельцами процессов. Запросите регламенты, действующие формы отчётности, описание существующих интеграций. Выделите «боли», которые система должна устранить.
2. Определите границы системы. Зафиксируйте перечень автоматизируемых процессов и явно укажите, что остаётся за периметром. Например, «Система управляет заказами, но не рассчитывает бонусы менеджеров — данные передаются в ERP».
3. Сформулируйте измеримые цели. Расплывчатое «повышение эффективности» неприемлемо. Цель должна звучать так: «Сокращение среднего времени обработки складской операции с 45 до 12 секунд за счёт автоматического сканирования штрихкода».
4. Заполните обязательные разделы по структуре выше. Начните с «Общих сведений» и «Назначения», затем последовательно переходите к требованиям. Описывайте функции по принципу «субъект-действие-объект-результат».
5. Согласуйте проект ТЗ. Разошлите документ всем сторонам за 5–7 рабочих дней до планируемой даты подписания. Соберите замечания в единый протокол разногласий и проведите очное совещание для снятия противоречий.
6. Утвердите ТЗ и скрепите подписями. На титульном листе должны стоять подписи уполномоченных представителей заказчика и разработчика. С этого момента любые изменения вносятся только через процедуру управления изменениями.

Весь цикл от первого интервью до утверждения обычно занимает 3–8 недель в зависимости от сложности системы. Для крупных MES-проектов с несколькими десятками интеграций срок может достигать 12 недель — и это нормально, потому что переделка на этапе кодирования обходится в разы дороже.

Типовые ошибки при составлении ТЗ, которые срывают сроки

Ошибки в техническом задании по ГОСТ 34 редко бывают случайными; чаще они — следствие спешки или желания «сэкономить на аналитике». Ниже перечислены ситуации, которые в нашей практике стабильно приводили к затягиванию проекта на 30–50% от первоначального графика.

• Размытые формулировки. Формулировка «система должна быть удобной» не проверяема. Замените её на конкретные эргономические требования: «количество кликов для создания типовой заявки не должно превышать трёх».
• Пропуск нефункциональных требований. Не указаны допустимое время восстановления после сбоя, требования к резервному копированию, пиковая нагрузка. Результат — система падает под реальной нагрузкой.
• Избыточная детализация интерфейсов на старте. Прорисовка всех экранных форм до утверждения базовой архитектуры приводит к тому, что любое архитектурное изменение влечёт переделку десятков страниц ТЗ.
• Игнорирование интеграционных сценариев. Описано только «счастливое» прохождение данных, а обрывы связи, неверные форматы, таймауты — нет. На стыковочных тестах это выливается в недели доделок.
• Отсутствие критерия «готово» для этапа. «Разработка завершена» без чёткого определения (например, «все модули прошли приёмочное тестирование и задокументированы») позволяет разработчику считать этап закрытым, а заказчику — нет.
• Слабый раздел управления изменениями. Без формального журнала запросов на изменение любое пожелание пользователя трактуется как обязательное, и объём работ неконтролируемо растёт.

Эти ошибки не специфичны для какой-то одной отрасли — они проявляются и в ITSM-системах, и в MES, и в портальных решениях. Инвестируйте в качественное ТЗ время на старте, и вы сэкономите месяцы на финише.

Чек-лист согласования ТЗ по ГОСТ 34.602-2020

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

Чек-лист не заменяет экспертной вычитки, но позволяет быстро отсеять формальные упущения. Если хотя бы на один вопрос ответ «нет», возвращайте документ на доработку — цена ошибки после старта кодирования вырастет кратно.

Взаимосвязь ТЗ с договором и этапами приёмки

Техническое задание по ГОСТ 34 живёт не в вакууме. В договоре подряда должно быть прямо указано, что «Техническое задание (Приложение №1 к Договору) является неотъемлемой частью Договора и определяет объём, содержание работ и критерии их приёмки». Без этой фразы суд может не признать ТЗ обязательным для сторон.

При разбиении работ на этапы (а в больших проектах это обязательно) каждый этап должен иметь собственный набор критериев приёмки, вытекающий из ТЗ. Например, для этапа «Эскизный проект» это утверждённый эскизный проект и протокол его рассмотрения. Для этапа «Разработка» — полностью оформленный исходный код, прошедший статический анализ, и комплект эксплуатационной документации.

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

Контроль исполнения ТЗ: как не допустить расхождений в ходе разработки

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

• Назначьте ответственного за трассировку требований со стороны заказчика. Его задача — на каждом статус-митинге сверять реализованный функционал с пунктами ТЗ.
• Ведите единый реестр требований с идентификаторами и статусами. При изменении требования его ID не меняется, а появляется новая версия.
• Демонстрации промежуточных результатов проводите не на макетах, а на стенде, максимально приближённом к промышленному окружению. Это вскрывает расхождения в интеграциях и нагрузочных характеристиках.
• Все отступления от ТЗ фиксируйте в протоколе разногласий. Простое устное «мы потом доделаем» оборачивается тем, что через месяц команда уже не помнит, что именно и почему было упрощено.

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

Корректировка ТЗ: когда и как вносить изменения без конфликтов

Запросы на изменение неизбежны. Бизнес-условия меняются, регуляторы выпускают новые формы отчётности, в ходе разработки вскрываются ограничения унаследованных систем. ГОСТ 34.602-2020 требует формализованной процедуры, и её отсутствие — одна из главных причин финансовых споров.

Порядок, принятый в большинстве проектных офисов:

1. Инициатор (заказчик или разработчик) подаёт запрос на изменение (Change Request) с описанием сути, причин и ожидаемого эффекта.
2. Технический комитет проекта оценивает влияние на архитектуру, сроки и бюджет. Классифицирует запрос: критический (без него система не может быть принята в эксплуатацию), существенный (влияет на сроки) или некритический (косметические доработки).
3. Принятое решение фиксируется в протоколе. При положительном решении стороны подписывают дополнительное соглашение к договору, в котором пересматриваются бюджет, сроки и корректируются пункты ТЗ.
4. Все исправления вносятся в основную версию ТЗ с повышением номера редакции. Старая редакция архивируется, но остаётся доступной для аудита.

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

Читайте также

• Наши услуги: команды, аутстаффинг и разработка под задачу