Конец большого ТЗ: почему цифровые системы нужно проектировать иначе

1. Почему длинное ТЗ устаревает раньше, чем система выходит в эксплуатацию

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

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

Для заказчика эта проблема особенно заметна. С 2025 года реализуется национальный проект «Экономика данных и цифровая трансформация государства», цель которого связана с цифровой трансформацией государственного и муниципального управления, экономики и социальной сферы. Минцифры указывает, что в паспорт нацпроекта включены 12 показателей.² Одновременно обновленная Национальная стратегия развития ИИ до 2030 года закрепляет задачи внедрения ИИ в отраслях экономики и социальной сферы, развитие доверенных технологий и технологический суверенитет.³

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

Большое ТЗ ломается в пяти точках.

• Первая — процессы. После обследования меняются маршруты согласования, полномочия подразделений, KPI и операционные роли.
• Вторая — данные. Выясняется, что справочники не синхронизированы, мастер-данные не определены, дубли и пропуски мешают автоматизации.
• Третья — интеграции. На старте известны одни системы, к середине проекта появляются новые программные интерфейсы, витрины, шины, требования к обмену.
• Четвертая — безопасность. Уточняются модели доступа, классы защищенности, требования к журналированию и аттестации.
• Пятая — импортонезависимость. Выбор СУБД, ОС, средств виртуализации, система бизнес-аналитики, управление бизнес-процессами, интеграционная шина или компонентов ускоренной разработки на визуальных конструкторах становится архитектурным ограничением, а не закупочной формальностью.

2. Как большие языковые модели меняют экономику аналитики и проектирования

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

Уже сегодня инструменты разработка с поддержкой ИИ официально позиционируются как средства помощи в генерации кода, подсказках по программным интерфейсам и фреймворкам, подготовке запросов к базам данных и создании тестов. Документация GitHub Copilot указывает, что инструмент может помогать с генерацией предложений для программных интерфейсов, фреймворков, запросов к базам данных и описания инфраструктуры в виде кода; отдельная документация описывает применение чат Copilot для генерации модульных тестов.¹⁵ Microsoft описывает Copilot в Azure SQL как инструмент на базе больших языковых моделей, анализирующий контекст базы данных и помогающий получать объяснения и предложения по запросам.¹⁵ Google описывает Gemini помощник разработчика как помощника на базе ИИ для разработки, развертывания и эксплуатации приложений на протяжении жизненного цикла ПО.¹⁵

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

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

Поэтому зрелая позиция звучит так: Большие языковые модели ускоряют производство вариантов, но не принимают архитектурных решений. Управление ИИ должно учитывать риски достоверности, безопасности, конфиденциальности, человеческого контроля и цепочки поставки. NIST в профиле по генеративному ИИ рассматривает управление рисками генеративного ИИ как расширение рамки управления рисками ИИ, а перечень OWASP Top 10 для приложений на базе больших языковых моделей выделяет отдельные классы угроз, включая внедрение вредоносных инструкций в запрос, раскрытие чувствительной информации, уязвимости цепочки поставки и отказ модели из-за перегрузки.^{12 13}

3. Что должно прийти на смену большому ТЗ

На смену большому ТЗ должна прийти не «свобода без документов», а живая спецификация. Это управляемый набор артефактов, который обновляется вместе с проектом и связывает бизнес-цели, данные, требования, интерфейсы, тесты и приемку.

Живая спецификация включает семь элементов.

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

Это не противоречит инженерной дисциплине. Международный стандарт ISO/IEC/IEEE 29148 описывает процессы инженерии требований для систем и программных продуктов на протяжении жизненного цикла, а IEEE 29148 прямо указывает на итеративное и рекурсивное применение процессов требований.¹⁴

Главное изменение — в объекте управления. В старой модели управленец контролировал документ: есть ТЗ, есть приложение, есть акт. В новой модели он контролирует связность: требование связано с целью, цель — с процессом, процесс — с данными, данные — с интерфейсом, интерфейс — с тестом, тест — с приемкой, приемка — с метрикой эффекта.

Большое ТЗ не исчезает. Оно перестает быть единственным центром управления проектом.

4. Как сохранить управляемость без бюрократического перегруза

Самая частая ошибка — противопоставить большое ТЗ и гибкую разработку. В действительности проблема не в объеме документа, а в отсутствии управляемого цикла изменений. Гибкая модель без архитектуры быстро превращается в хаос: требования расползаются, подрядчик становится единственным носителем знания, приемка спорная, документация отстает, ИБ подключается слишком поздно.

Управляемость строится на нескольких механизмах.

Архитектурный комитет. Он не должен быть церемонией ради протокола. Его задача — принимать решения о платформенном ядре, данных, интеграциях, безопасности, импортонезависимом стеке, отклонениях от стандартов и техническом долге. В составе должны быть владелец бизнес-результата, ИТ-директор и директор по цифровой трансформации, архитектор, ИБ, владелец данных, представитель эксплуатации и закупочного блока.

Реестр требований и матрица трассируемости требований. Каждое требование должно иметь происхождение и связь с тестом. Если требование не связано с бизнес-целью, владельцем и критерием приемки, оно не управляется. Если тест не связан с требованием, приемка становится субъективной.

Приемочные критерии. Приемочные критерии должны формулироваться до разработки. Не «система должна обеспечивать удобный поиск», а «пользователь с ролью X находит запись по трем параметрам за N секунд, видит только разрешенные поля, действие логируется, результат выгружается в утвержденном формате».

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

Контроль безопасности и данных с первого этапа. Для государственных информационных систем, КИИ и систем с персональными данными требования ИБ нельзя добавлять в конце. ФСТЭК предъявляет требования по защите информации в ГИС, по защите персональных данных и по безопасности значимых объектов КИИ; в частности, требования к системе защиты информации ГИС включаются в техническое задание на создание системы.¹¹

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

5. Практическая модель для заказчика

Для бизнеса и госсектора нужна модель, которая совместима с российской регуляторной и технологической реальностью: импортонезависимость, защищенные контуры, персональные данные, КИИ, ГИС, реестр российского ПО, ГосТех, ГосОблако, закупочные процедуры и ограниченный кадровый ресурс.

Реестр российского и евразийского ПО содержит перечни ПО, происхождение которого подтверждено; Минцифры описывает реестры как перечни доверенного программного обеспечения, созданного российскими разработчиками или разработчиками из дружественных стран.⁶ Указ Президента №166 устанавливает меры по обеспечению технологической независимости и безопасности критической информационной инфраструктуры.⁷ Для операторов персональных данных Роскомнадзор указывает обязанности, включая уведомление, политику обработки, выполнение требований 152-ФЗ и обработку персональных данных с использованием баз данных на территории РФ при сборе данных, в том числе через интернет.¹⁰

В госсекторе добавляется платформенный контур. Минцифры описывает «ГосТех» как облачное платформенное решение для федеральных и региональных органов власти. Правительство в мае 2026 года сообщало, что свыше 25 регионов уже протестировали типовые облачные решения, доступные на единой цифровой платформе «ГосТех».⁴ ГосОблако, по данным Минцифры, начало функционировать вне рамок эксперимента с 1 января 2025 года.⁵

Отсюда вытекает практическая схема проекта.

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

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

Этап 2. Архитектурная рамка

Фиксируются принципы: где находится платформа, какие классы данных обрабатываются, какие компоненты допустимы, как строятся интеграции, какие требования ИБ обязательны, что входит в платформенное ядро, а что — в прикладные модули.

Этап 3. Прототип

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

Этап 4. минимально рабочий релиз

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

Этап 5. Платформенное ядро

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

Этап 6. Прикладные модули

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

Этап 7. Эксплуатация и развитие

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

Метрики успеха

Риски и ограничения новой модели

Заключение

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

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

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

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

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