6.02. Методология государственных систем
Почему методология государственных систем — отдельная дисциплина
Разработка информационных систем в государственном секторе традиционно рассматривается через призму тех же инженерных практик, что применяются в коммерческой среде: waterfall, agile, devops, lean и прочие. Однако такой подход, хотя и полезен на уровне исполнителей и подрядных организаций, не учитывает фундаментального различия в природе задач, ценностей и ограничений, в рамках которых действует государственная информационная система (ГИС).
Государственная система — это элемент публичной инфраструктуры, инструмент реализации публичной политики, средство обеспечения прав граждан, механизм контроля и отчётности перед обществом. В силу этой природы ГИС существуют ради стабильности, предсказуемости, конституционной легитимности и обеспечения интересов неопределённо широкого круга пользователей — от физических лиц до органов власти всех уровней.
Поэтому методология разработки и сопровождения ГИС не может быть сведена к выбору шаблона жизненного цикла или набора практик управления задачами. Она представляет собой многоуровневую систему координации, объединяющую технические, управленческие, юридические, административные и финансовые процедуры. Она не сводится к одному документу или стандарту — она формируется практикой, регуляторными требованиями и традициями государственного управления.
1. Отличие «методологии как практики» и «методологии как регуляторной системы»
В коммерческой разработке, особенно в IT-стартапах или крупных технологических компаниях, методология понимается как набор внутренних практик, выбранных коллективом для повышения качества, скорости и предсказуемости результатов. Agile, Scrum, Kanban — это инструменты, которые организация может принять, адаптировать или отвергнуть без нарушения внешних норм. Эффективность такой методологии измеряется KPI: сроками вывода продукта, частотой релизов, удовлетворённостью клиентов, количеством багов и т.п.
В государственном секторе методология — это, прежде всего, система внешних обязательств. Она навязывается сверху, техническими, юридическими, финансовыми и административными механизмами.
Например, при разработке ГИС, финансируемой из бюджета, команда не может решить, что будет использовать Scrum вместо RUP, просто потому, что это «лучше работает». Выбор методологии должен быть отражён в техническом задании, согласован с заказчиком, и — что важнее — поддерживаться всей системой государственного контрактирования: от формирования плана-графика закупок до приёмки работ и прохождения аудита Счётной палаты.
Таким образом, методология в государственном секторе — это инструмент обеспечения соответствия. Соответствия:
- законодательству (в том числе законам о контрактной системе, защите персональных данных, безопасности информации);
- нормативным актам (гостам, отраслевым стандартам, методическим указаниям Минцифры, ФСТЭК, ФСБ и пр.);
- бюджетным процедурам (этапность финансирования, контроль КИК, утверждение лимитов);
- отчётности (представление отчётов в Минфин, Минэкономразвития, надзорные органы);
- внутренним регламентам (внутренние приказы руководства, положения о проектах, регламенты взаимодействия с подведомственными организациями).
Соответствие становится первичной целью. Оптимизация, если она возможна, осуществляется уже в рамках этих рамок.
2. Ограничения, задающие форму методологии
Методологическая структура государственной системы формируется тремя основными типами ограничений.
2.1. Юридическое ограничение
Законодательство задаёт базовые рамки жизненного цикла информационной системы. Федеральные законы, указы Президента, постановления Правительства, приказы федеральных органов исполнительной власти — все они содержат обязательные требования к этапам создания, эксплуатации и ликвидации ГИС. Особенно важно:
- Федеральный закон № 149-ФЗ «Об информации, информационных технологиях и о защите информации» — определяет классификацию информационных систем и основы их защиты;
- Федеральный закон № 152-ФЗ «О персональных данных» — требует реализации специфических мер безопасности и документирования обработки;
- Постановление Правительства № 1030 и приказы Минцифры — регулируют стадии создания ГИС: от формирования концепции до ввода в промышленную эксплуатацию;
- Федеральный закон № 44-ФЗ «О контрактной системе» — устанавливает правила заключения, исполнения и приёмки контрактов на ИТ-услуги.
Эти нормы не являются рекомендациями. Нарушение хотя бы одного из пунктов может привести к блокировке системы, возврату бюджетных средств, административной ответственности и даже уголовному преследованию должностных лиц.
В результате жизненный цикл ГИС становится строго поэтапным, поскольку каждый этап должен быть подтверждён документально: концепция — распоряжением руководителя, ТЗ — утверждённым документом с грифом «Для служебного пользования» или выше, проектная документация — экспертизой, акты приёмки — подписями уполномоченных лиц. Промежуточные итерации, «быстрые релизы» или «минимально жизнеспособные продукты» (MVP), характерные для Agile, не просто не поощряются — они невозможны в рамках такой системы. MVP не может быть представлен в отчёт Минфину как результат использования бюджетных средств без соответствующего технического обоснования и согласования.
2.2. Отчётность и проверки как управляющий фактор
В коммерческой среде отчётность направлена на внутреннюю координацию (стендапы, демонстрации, ретроспективы) или на внешнего клиента (презентации, бета-версии). В государственной системе отчётность служит иной цели — подтверждению правомерности расходования бюджетных средств и соблюдения регламентов.
Структура отчётности в ГИС многозвенна и жёстко регламентирована. Например:
- ежеквартально — отчёты в Минфин по исполнению плана закупок;
- поэтапно — акты приёмки выполненных работ по контракту;
- ежегодно — отчёт о состоянии информационно-телекоммуникационной инфраструктуры;
- после ввода в эксплуатацию — информация в Реестр государственных информационных систем (РГИС);
- по требованию — документы для проверок Счётной палаты, прокуратуры, органов внутреннего финансового контроля.
Каждый из этих отчётов строится вокруг соответствия формальным критериям. Например, в акте приёмки работ не будет указано: «реализована функция автоподстановки адреса». Там будет: «в соответствии с п. 4.2.1 ТЗ приложение обеспечивает интеграцию с ФИАС по протоколу HTTP/JSON в режиме синхронного запроса, с соблюдением требований к уровню защищённости согласно п. 4 приказа ФСТЭК № 21».
Это делает процесс разработки документоцентричным. Документ не является продуктом разработки — он её условием. Прежде чем код будет написан, должен быть согласован и утверждён текст ТЗ. Прежде чем система будет запущена, должен пройти аудит ИБ, выдан паспорт безопасности, оформлен акт ввода в эксплуатацию.
Отсюда возникает специфическая роль «проектного офиса» или «управления проектами» в государственной структуре: его задача — обеспечить прохождение всех контрольных точек. Успешный менеджер государственного ИТ-проекта — это тот, кто умеет вовремя собрать подписи, подготовить пакет на экспертизу и согласовать отступления от норм в установленном порядке.
2.3. Человеческий фактор
Следует чётко разграничить два субъекта в процессе создания ГИС:
- Подрядчики (исполнители) — ИТ-компании, студии, консалтинговые фирмы. Для них характерно применение современных методологий: Scrum, Kanban, DevOps-практик, CI/CD. Их интерес — сдать проект в срок, в рамках бюджета, с минимальными рисками переработок. Они гибки, адаптивны, готовы к изменениям — в пределах контракта.
- Заказчики (государственные структуры) — министерства, ведомства, региональные органы власти. Для них характерен консерватизм, основанный на системных рисках. Один неудачный проект может привести к проверке, увольнению, уголовному делу. Поэтому выбор в пользу «проверенного», «традиционного», «как в прошлый раз» — это рациональная стратегия снижения личной и институциональной ответственности.
Консерватизм проявляется в:
- предпочтении текстовых, бумажных (или PDF-форматных) документов перед интерактивными бэклогами;
- требовании полного, детального ТЗ до начала разработки — чтобы исключить «движение цели» и обвинения в неисполнении обязательств;
- жёсткой привязке к ГОСТам, даже если они устарели, — потому что ссылка на ГОСТ является аргументом в споре с проверяющими;
- избегании «нестандартных» решений: open source без поддержки российской компании, облачных решений вне Государственной информационной системы (ГИС) или за пределами «Облачного реестра Минцифры»;
- склонности к монолитным архитектурам из-за простоты описания и сопровождения в отчётах.
Это адаптация к среде, где ключевой метрикой успеха является не качество продукта, а отсутствие претензий.
3. Жизненный цикл ГИС
В учебниках по управлению проектами жизненный цикл программного обеспечения часто изображается в виде линейной или итеративной схемы: требования → проектирование → реализация → тестирование → внедрение. В случае государственной информационной системы такая модель оказывается неприменимой. Вернее, она может существовать внутри контракта с подрядчиком, но не отражает реальной логики проекта на уровне заказчика.
Для государственной структуры жизненный цикл — это цепочка юридически значимых событий, каждое из которых открывает доступ к следующему этапу финансирования, разрешает действие или снимает ответственность.
Рассмотрим типовую последовательность (на основе Постановления Правительства РФ № 1030 и приказов Минцифры, но с акцентом на практическую логику, а не формальное перечисление):
3.1. Инициация и обоснование
Этап начинается с политического или административного решения — указа, поручения Президента или Правительства, распоряжения руководителя ведомства, включения в государственную программу.
Ключевым документом здесь является концепция создания (развития) системы. Она не содержит технических решений, но обосновывает:
- общественную потребность (например, «снижение времени оформления пособий с 30 до 3 суток»);
- соответствие национальным проектам или стратегиям цифровой трансформации;
- оценку рисков — репутационных, правовых, бюджетных («возможность проверки Счётной палатой при несоблюдении требований 152-ФЗ»);
- предварительную архитектуру взаимодействия с другими ГИС (ЕПГУ, ЕГАИС, СМЭВ и др.);
- оценку совокупной стоимости владения (TCO), включая разработку, 5–10 лет эксплуатации, лицензирование, аудиты, модернизацию.
Концепция утверждается приказом руководителя и становится основанием для включения расходов в проект бюджета на следующий трёхлетний период.
Обратите внимание: уже на этом этапе формируется документ-обязательство, а не техническая гипотеза. Изменить концепцию после утверждения возможно, но только через повторное согласование — с теми же бюрократическими издержками, что и при первоначальном утверждении.
3.2. Формирование технического задания (ТЗ)
В коммерческой среде ТЗ — это инструмент передачи видения продукта от заказчика к исполнителю. В государственной практике ТЗ — это юридический акт, который:
- фиксирует объём обязательств подрядчика;
- служит основанием для оплаты по контракту;
- используется при проверке — сравнение итогового результата с пунктами ТЗ является стандартной процедурой.
Поэтому ТЗ в ГИС — это формализованное описание с привязкой к нормативам. Например:
«Система должна обеспечивать хранение персональных данных граждан в соответствии с требованиями п. 16 Положения о составе и порядке ведения журналов учёта операций, установленного приказом ФСТЭК России от 11.02.2013 № 21».
«Интерфейс обмена с ЕСИА осуществляется посредством защищённого канала связи, реализованного в соответствии с требованиями Методических рекомендаций по организации защищённого взаимодействия ГИС, утверждённых приказом Минцифры России от 17.07.2020 № 378».
ТЗ согласуется с ИТ-департаментом, юридической службой, службой защиты информации, финансовым управлением — потому что каждый раздел создаёт риски для соответствующей службы.
Изменение ТЗ после заключения контракта возможно, но регулируется отдельной процедурой — внесением изменений в контракт, требующей новой экспертизы и, часто, дополнительного согласования с вышестоящим органом. На практике это означает, что даже незначительная корректировка (например, добавление одного поля в форму) может занять от двух недель до двух месяцев.
3.3. Проектирование
На этапе проектирования подрядчик создаёт архитектуру, прототипы, и полный комплект проектной документации в соответствии с ГОСТ 34.601–90 и ГОСТ 19.102–77.
Сюда входят:
- технический проект (ТП) — описание архитектуры, платформ, протоколов, схем интеграции;
- рабочая документация — спецификации программных модулей, баз данных, интерфейсов;
- программа и методика испытаний (ПМИ) — детальный план проверок, согласованный с заказчиком;
- паспорт системы — обобщающий документ для регистрации в РГИС.
Каждый из этих документов проходит внутреннюю экспертизу (внутри подрядчика), затем — независимую экспертизу (в аккредитованной организации), и только после этого — приёмочную комиссию со стороны заказчика.
Экспертиза — проверка соответствия нормативным актам. Например:
- есть ли в ТП ссылка на класс защиты информации по ФСТЭК?
- учтены ли требования к отказоустойчивости из приказа Минцифры № 531?
- предусмотрен ли резервный центр обработки данных (ЦОД)?
Технические решения могут быть неоптимальными — но если они «по ГОСТу», система проходит. И наоборот: изящная, современная архитектура может быть отклонена, если в документе нет формальной ссылки на нужный пункт приказа.
3.4. Реализация и тестирование
В условиях waterfall-подхода, доминирующего в госконтрактах, реализация и тестирование строго разнесены во времени и по ответственности.
Подрядчик пишет код, но не имеет права проводить приёмочные испытания. Тестирование делится на три уровня:
- Внутреннее тестирование — проводится подрядчиком (unit-, интеграционное, нагрузочное). Результат — отчёт, который не является основанием для оплаты.
- Независимое тестирование — проводится аккредитованной тестовой лабораторией по утверждённой ПМИ. Результат — акт, включающий перечень несоответствий («замечаний»). Их устранение — за счёт подрядчика.
- Приёмочные испытания — проводятся заказчиком, часто с участием реальных пользователей (например, сотрудников МФЦ). Здесь проверяется соответствие бизнес-процессам. Например: «Может ли сотрудник подать заявку на пособие за 5 минут?» — даже если интерфейс с технической точки зрения работает корректно, но не соответствует регламенту работы учреждения, испытания не пройдены.
Приёмочные испытания — финальная точка. Если система не прошла — контракт не закрывается, деньги не перечисляются, проект «зависает». Нет механизма «выпустим в бету, доработаем по фидбэку». Есть только «принято» или «не принято».
3.5. Ввод в эксплуатацию и регистрация
Успешное прохождение приёмочных испытаний не означает, что система начинает работать. Необходимо:
- издать приказ о вводе в промышленную эксплуатацию;
- зарегистрировать систему в Реестре ГИС (РГИС) — с указанием класса защищённости, ответственного лица, подключённых внешних систем;
- провести обучение пользователей и подготовить регламенты эксплуатации;
- назначить ответственного за ИБ и провести инструктаж по локальным нормативным актам;
- внести систему в план-график мероприятий по обеспечению безопасности (на 1 год вперёд).
Только после выполнения всех этих шагов система считается юридически функционирующей. До этого момента её использование — нарушение.
3.6. Эксплуатация и сопровождение
В коммерческой среде эксплуатация — это непрерывный цикл мониторинга, сбора фидбэка, патчей и релизов. В государственной системе — это исполнение утверждённого регламента.
Регламент сопровождения — обязательный документ, включающий:
- график проведения работ (например: «проверка логов — ежедневно», «резервное копирование — каждые 4 часа», «аудит журналов ИБ — ежемесячно»);
- перечень инцидентов и реакция на них («утечка персональных данных → немедленное информирование Роскомнадзора в течение 24 часов»);
- процедуры модернизации — которые, опять же, требуют нового ТЗ, новой экспертизы и нового контракта.
Автоматизация развёртывания (CI/CD), hotfix’ы без согласования, A/B-тестирование — всё это запрещено регламентами безопасности информации. Любое изменение в промышленной системе должно быть оформлено как «внесение изменений в программную документацию» и согласовано. Практика показывает: внедрение корректирующего патча может занять от 10 до 30 рабочих дней — из-за согласований.
4. Нормативная основа
Говоря о ГОСТах и отраслевых стандартах, важно понимать: их функция в государственной системе — обеспечение юридической защиты.
Например, ГОСТ 34 («Автоматизированные системы») давно устарел с технической точки зрения. Он не учитывает облачные технологии, микросервисы, CI/CD, контейнеризацию. И всё же он остаётся ключевым документом в госконтрактах — потому что ссылка на ГОСТ 34 в ТЗ позволяет заказчику сказать проверяющему: «Мы действовали в соответствии с действующим стандартом». Отсутствие такой ссылки — повод для критики.
Аналогично — ГОСТ Р ИСО/МЭК 12207 (жизненный цикл ПО). Он формально принят, но на практике применяется фрагментарно: лишь те разделы, которые требуются для составления нужных документов (например, «Ведомость документов»). Процессы вроде «управления конфигурацией» или «валидации» зачастую сводятся к подписанию бумажных журналов, а не к использованию Git и автоматических тестов.
Более того, в последние годы наблюдается дублирование и расслоение нормативной базы:
- Минцифры России выпускает методические рекомендации (например, «Требования к архитектуре ГИС»);
- ФСТЭК — приказы по защите информации (№ 21, № 31, № 17);
- ФСБ — собственные требования к криптографической защите;
- Роскомнадзор — указания по персональным данным;
- Минфин — требования к бюджетному учёту ИТ-расходов.
Эти документы не всегда согласованы. Например, Минцифры может рекомендовать использовать open-source решения, а ФСТЭК требовать наличия поддержки от российской компании-разработчика. Подрядчик вынужден искать компромисс, но окончательное решение принимает заказчик — исходя из того, какой орган имеет больше полномочий в случае проверки.
Таким образом, «методология» в ГИС — это практика балансирования между противоречивыми требованиями, где техническое решение всегда вторично по отношению к способности его обосновать ссылкой на нормативный акт.
5. Архитектура ответственности
В коммерческом проекте ответственность, как правило, линейна и подчинена логике результата: продукт-менеджер отвечает за ценность, техлид — за качество, scrum-мастер — за процессы. В государственной системе ответственность размазана, дублирована и смещена в сторону формальных ролей, закреплённых в контракте и приказах. Это не недостаток — это механизм распределения рисков в условиях высокой персональной ответственности.
Рассмотрим ключевые роли — как зоны юридической и административной ответственности.
5.1. Заказчик (инициатор и владелец)
Это не «клиент» в коммерческом смысле. Это публичное лицо, несущее персональную ответственность за целесообразность расходования бюджетных средств.
Типичный заказчик — руководитель департамента цифрового развития министерства или главный специалист по ИТ в ведомстве. Его главная задача — доказать, что она была необходима, создана по правилам и не привела к нарушениям.
Он отвечает за:
- корректность формулировок в концепции и ТЗ с точки зрения ведомственных задач;
- своевременное информирование вышестоящего руководства о рисках (например, срыв срока — за 3 месяца);
- согласование всех отступлений от норм (например, использование СУБД, не включённой в Единый реестр российских программ);
- подписание актов — как акт возложения ответственности: «Я, как заказчик, подтверждаю, что требования выполнены в объёме, достаточном для приёмки».
Заказчик не может самостоятельно изменить приоритеты в ходе проекта. Даже если он лично убедился, что функция А важнее функции Б, он не вправе перераспределить объём работ — это требует изменения контракта, согласованного с юридической службой и финансовым управлением. Его полномочия — интерпретировать существующие требования, но не вводить новые.
5.2. Технический надзор (Технадзор)
Роль, не имеющая прямого аналога в коммерческой разработке. Технадзор — это независимый контролёр со стороны заказчика, часто оформлен как отдельный контракт с другой организацией (например, с ФГУП или аккредитованным институтом).
Его функция — фиксировать несоответствия. Он проверяет:
- соблюдение сроков (по графику-«диаграмме Ганта», утверждённому в контракте);
- соответствие промежуточных документов (ТП, ПМИ) требованиям ТЗ;
- наличие подписей в журналах (например, журнале входного контроля образцов);
- полноту отчётности (например, «есть ли акт внутреннего тестирования от 15.03.2025?»).
Технадзор не оценивает, «хорошая» ли архитектура. Он проверяет, описана ли она в документе и соответствует ли описание формальным требованиям.
Конфликт между подрядчиком и технадзором — обычная ситуация. Подрядчик считает, что система работает; технадзор требует, чтобы в ТП был отдельный раздел «Описание отказоустойчивости в соответствии с п. 5.2 приказа Минцифры № 531». Без этого раздела — задержка приёмки. Такой конфликт разрешается административным решением заказчика: «Включить раздел» или «Получить письменное согласование от Минцифры на отступление».
5.3. Экспертная организация
Обычно это аккредитованная лаборатория, имеющая лицензию ФСТЭК или Минцифры на проведение экспертизы.
Её роль — валидация соответствия нормам. Экспертиза проектной документации — это проверка по чек-листу:
- указан ли класс защиты информации (КЗИ)?
- есть ли описание мероприятий по защите от НСД?
- учтены ли требования к аутентификации по приказу ФСТЭК № 31?
Если в документе всё есть — экспертиза пройдена. Если чего-то нет — выдаётся «заключение с замечаниями». Устранение замечаний — за счёт подрядчика, и срок на это фиксируется (обычно 10–15 рабочих дней). Превышение срока — основание для штрафных санкций.
Примечательно: экспертная организация не несёт ответственности за последствия внедрения. Она подтверждает только соответствие документа на момент проверки. Если через год выяснится, что система уязвима — виноваты заказчик (не обеспечил сопровождение) и подрядчик (некачественно реализовал), но не эксперт.
5.4. Подрядчик (исполнитель)
Это единственный участник, чья ответственность — техническая. Но и она ограничена рамками контракта.
Подрядчик отвечает за:
- выполнение работ в объёме, сроках и качестве, указанных в ТЗ и контракте;
- предоставление полного комплекта документов (кода, отчётов, журналов, паспортов);
- устранение замечаний экспертизы и технадзора в установленные сроки.
Он не отвечает за:
- целесообразность системы (это — заказчик);
- корректность ТЗ (если ТЗ требует реализовать невозможное — подрядчик может оспорить это в досудебном порядке, но не обязан это делать по умолчанию);
- последующую эксплуатацию (если в контракте не прописано сопровождение).
Существует важный нюанс: подрядчик часто работает «в рамках двух миров». Внутри своей команды он может использовать Scrum, GitLab CI, автоматизированное тестирование — но финальный отчёт должен быть оформлен в соответствии с ГОСТ 19.502–78 («Программа и методика испытаний»), с титульными листами, штампами, подписями руководителя и главного инженера.
Это разделение внутренней эффективности и внешней легитимности. Качество продукта обеспечивается современными практиками. Юридическая защита — формальными документами.
6. Логика управления в корпоративной и государственной среде
Ниже — анализ глубинных различий в логике принятия решений, которые делают прямой перенос практик (например, «внедрим Scrum в госпроект») обречённым на провал.
6.1. Цель проекта
- Корпоративная среда: максимизация ценности для пользователя/бизнеса при заданных ограничениях (время, бюджет, ресурсы). Успех измеряется метриками: рост конверсии, снижение времени обработки заявки, NPS.
- Государственная среда: минимизация рисков ответственности при выполнении публичной функции. Успех измеряется: отсутствием проверок, своевременной сдачей отчётов, регистрацией в РГИС, подписанием всех актов.
Отсюда — различие в отношении к неопределённости. В корпоративной среде неопределённость — повод для экспериментов (MVP, A/B-тесты). В государственной — повод для дополнительных согласований и страховочных документов.
6.2. Управление изменениями
- Корпоративная среда: изменения — норма. Бэклог динамичен, приоритеты пересматриваются еженедельно. Даже в рамках waterfall допускаются формальные запросы на изменение (change request) с оценкой impact’а.
- Государственная среда: изменения — исключение, требующее юридического оформления. Любое отклонение от ТЗ рассматривается как нарушение контракта, если не оформлено как дополнительное соглашение. Процедура внесения изменений может включать:
- подготовку обоснования (почему изменение необходимо);
- проведение новой экспертизы (если затрагиваются защищённые компоненты);
- согласование с вышестоящим органом (если сумма превышает лимит);
- корректировку плана-графика закупок.
Поэтому заказчики часто предпочитают «доделать по старому ТЗ, даже если это не нужно», чем запускать процедуру изменения. Это не нерационально — это рационально в контексте минимизации административных издержек.
6.3. Оценка неудачи
- Корпоративная среда: неудача = продукт не решает задачу. Реакция: анализ причин, pivot, закрытие проекта. Провал — возможность научиться.
- Государственная среда: неудача = факт нарушения процедуры. Реакция: поиск виновного, проверка, доклад вышестоящему руководству, восстановление процесса. Провал — угроза карьере.
Пример: система работает, но при приёмке выяснилось, что в ПМИ не указан один тест-кейс по безопасности. Подрядчик готов доработать за 1 день. Но формально — приёмка не пройдена. Заказчик не может подписать акт, даже если система функционирует. Потому что подписание = признание соответствия, а его нет. Риск для заказчика (административная ответственность) выше, чем выгода от запуска системы.
6.4. Роль документации
- Корпоративная среда: документация — средство передачи знаний. Допускается «документация как код» (README, Swagger, Confluence), живые диаграммы, видеозаписи демо.
- Государственная среда: документация — доказательная база. Требуется:
- бумажная (или PDF с ЭЦП) форма;
- титульные листы с грифами («Для служебного пользования»);
- подписи уполномоченных лиц (с расшифровкой ФИО и должности);
- нумерация страниц, регистрационные номера, штампы.
Даже если система написана на Rust с полным покрытием тестами, без утверждённого ТЗ и акта приёмки она юридически не существует.
7. Практические рекомендации
Специалист, вовлечённый в госпроект, сталкивается с конфликтом: с одной стороны — требования инженерной культуры (гибкость, итеративность, автоматизация), с другой — требования регуляторной среды (формализм, поэтапность, документооборот).
Ниже — проверенные подходы, позволяющие сохранить техническое качество без нарушения рамок.
7.1. Разделяйте внутренние и внешние процессы
- Внутри команды подрядчика используйте любые современные практики: CI/CD, code review, TDD — но не афишируйте их в отчётах.
- Финальные документы (ТП, ПМИ, отчёты) оформляйте в соответствии с ГОСТ — но используйте их как обёртку для современной реализации. Например, в ТП можно написать: «Система построена по микросервисной архитектуре» — и далее описать её в терминах «подсистем» и «взаимодействующих модулей», как того требует ГОСТ 34.
7.2. Переводите технические решения на язык нормативов
Не говорите: «Мы используем Kubernetes для оркестрации». Говорите:
«Развертывание и масштабирование компонентов системы осуществляется с применением программно-аппаратных средств, обеспечивающих выполнение требований п. 5.4 приказа Минцифры № 531 (отказоустойчивость не ниже 99,9%)».
Это не «приукрашивание» — это адаптация языка под аудиторию. Проверяющий не обязан понимать Kubernetes, но обязан убедиться, что требования выполнены.
7.3. Управляйте ожиданиями заказчика заранее
На этапе проработки ТЗ чётко разделяйте:
- то, что обязательно по закону (например, шифрование персональных данных);
- то, что обязательно по контракту (например, наличие бумажного журнала входного контроля);
- то, что можно оптимизировать (например, формат отчёта — Excel или PDF, если контракт не уточняет).
Предлагайте заказчику «технические компромиссы»:
«Мы можем выполнить требование о резервном копировании каждые 4 часа, но технически это реализуется через автоматизированный скрипт с логированием в SIEM-систему. При этом журнал резервного копирования будет формироваться в PDF-формате и подписываться ЭЦП ежедневно — как того требует регламент».
7.4. Инвестируйте в «документальную инженерию»
Выделите в команде роль технического писателя / нормативного инженера — человека, который:
- знает ГОСТы и приказы на уровне ссылок;
- умеет переводить архитектурные решения в формат «требование → реализация → подтверждение»;
- готовит документы так, чтобы они прошли экспертизу с первого раза.
Это снижает риски простоев на этапе согласования и экономит больше времени, чем оптимизация CI/CD-пайплайна.