Перейти к основному содержимому

Методологии разработки государственных ИТ-систем

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Руководителю Аналитику Техническому писателю
Теория данных (раздел 3)

Миграции в релизе, ETL, конфиги сред — Пакетная работа, ETL, конфигурации. Карта — о разделе.

Методология государственных систем​

Общая теория SDLC, Agile, Scrum, Kanban и инженерных практик — в главе Жизненный цикл программного обеспечения. Здесь — как те же идеи сталкиваются с регуляторикой, контрактом и приёмкой в государственном секторе.

Почему методология государственных систем — отдельная дисциплина​

Разработка информационных систем в государственном секторе традиционно рассматривается через призму тех же инженерных практик, что применяются в коммерческой среде — waterfall, agile, devops, lean и прочие. Однако такой подход, хотя и полезен на уровне исполнителей и подрядных организаций, не учитывает фундаментального различия в природе задач, ценностей и ограничений, в рамках которых действует государственная информационная система (ГИС).

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

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

Отличие методологии как практики и методологии как регуляторной системы​

В коммерческой разработке, особенно в IT-стартапах или крупных технологических компаниях, методология понимается как набор внутренних практик, выбранных коллективом для повышения качества, скорости и предсказуемости результатов. Agile, Scrum, Kanban — это инструменты, которые организация может принять, адаптировать или отвергнуть без нарушения внешних норм. Эффективность такой методологии измеряется KPI — сроками вывода продукта, частотой релизов, удовлетворённостью клиентов, количеством багов и т.п.

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

Например, при разработке ГИС, финансируемой из бюджета, команда не может решить, что будет использовать Scrum вместо RUP, просто потому, что это "лучше работает". Выбор методологии должен быть отражён в техническом задании, согласован с заказчиком, и — что важнее — поддерживаться всей системой государственного контрактирования: от формирования плана-графика закупок до приёмки работ и прохождения аудита Счётной палаты.

Таким образом, методология в государственном секторе — это инструмент обеспечения соответствия. Соответствия:

Waterfall на бумаге и Agile у подрядчика

Заказчик часто живёт в поэтапной модели (ТЗ, экспертиза, акты).

Подрядчик внутри контракта может работать итеративно (спринты, CI).

Это не противоречие, если артефакты для приёмки собираются в нужные контрольные точки — см. блок про "два мира" ниже.

  • законодательству (в том числе законам о контрактной системе, защите персональных данных, безопасности информации);
  • нормативным актам (гостам, отраслевым стандартам, методическим указаниям Минцифры, ФСТЭК, ФСБ и пр.);
  • бюджетным процедурам (этапность финансирования, контроль КИК, утверждение лимитов);
  • отчётности (представление отчётов в Минфин, Минэкономразвития, надзорные органы);
  • внутренним регламентам (внутренние приказы руководства, положения о проектах, регламенты взаимодействия с подведомственными организациями).

Соответствие становится первичной целью. Оптимизация, если она возможна, осуществляется уже в рамках этих рамок.

Ограничения, задающие форму методологии​

Методологическая структура государственной системы формируется тремя основными типами ограничений.

Юридическое ограничение​

Законодательство задаёт базовые рамки жизненного цикла информационной системы. Федеральные законы, указы Президента, постановления Правительства, приказы федеральных органов исполнительной власти — все они содержат обязательные требования к этапам создания, эксплуатации и ликвидации ГИС. Особенно важно:

  • Федеральный закон № 149-ФЗ "Об информации, информационных технологиях и о защите информации" — определяет классификацию информационных систем и основы их защиты;
  • Федеральный закон № 152-ФЗ "О персональных данных" — требует реализации специфических мер безопасности и документирования обработки;
  • Постановление Правительства № 1030 и приказы Минцифры — регулируют стадии создания ГИС: от формирования концепции до ввода в промышленную эксплуатацию;
  • Федеральный закон № 44-ФЗ "О контрактной системе" — устанавливает правила заключения, исполнения и приёмки контрактов на ИТ-услуги.

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

В результате жизненный цикл ГИС становится строго поэтапным, поскольку каждый этап должен быть подтверждён документально — концепция — распоряжением руководителя, ТЗ — утверждённым документом с грифом "Для служебного пользования" или выше, проектная документация — экспертизой, акты приёмки — подписями уполномоченных лиц. Промежуточные итерации, "быстрые релизы" или "минимально жизнеспособные продукты" (MVP), характерные для Agile, не просто не поощряются — они невозможны в рамках такой системы. MVP не может быть представлен в отчёт Минфину как результат использования бюджетных средств без соответствующего технического обоснования и согласования.

MVP в госконтракте

Термин MVP в Agile — "минимум ценности для проверки гипотезы".

В контракте 44-ФЗ обычно фиксируют этапы и результаты (прототип, пилот, очередь ввода), а не "полуфабрикат без приёмки".

Итерации у подрядчика возможны, если каждый платёжный рубеж закрыт актом по ТЗ.

Отчётность и проверки как управляющий фактор​

В коммерческой среде отчётность направлена на внутреннюю координацию (стендапы, демонстрации, ретроспективы) или на внешнего клиента (презентации, бета-версии). В государственной системе отчётность служит иной цели — подтверждению правомерности расходования бюджетных средств и соблюдения регламентов.

Структура отчётности в ГИС многозвенна и жёстко регламентирована. Например:

  • ежеквартально — отчёты в Минфин по исполнению плана закупок;
  • поэтапно — акты приёмки выполненных работ по контракту;
  • ежегодно — отчёт о состоянии информационно-телекоммуникационной инфраструктуры;
  • после ввода в эксплуатацию — информация в Реестр государственных информационных систем (РГИС);
  • по требованию — документы для проверок Счётной палаты, прокуратуры, органов внутреннего финансового контроля.

Каждый из этих отчётов строится вокруг соответствия формальным критериям. Например, в акте приёмки работ не будет указано: "реализована функция автоподстановки адреса". Там будет: "в соответствии с п. 4.2.1 ТЗ приложение обеспечивает интеграцию с ФИАС по протоколу HTTP/JSON в режиме синхронного запроса, с соблюдением требований к уровню защищённости согласно п. 4 приказа ФСТЭК № 21".

Это делает процесс разработки документоцентричным. Документ не является продуктом разработки — он её условием. Прежде чем код будет написан, должен быть согласован и утверждён текст ТЗ. Прежде чем система будет запущена, должен пройти аудит ИБ, выдан паспорт безопасности, оформлен акт ввода в эксплуатацию.

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

Человеческий фактор​

Следует чётко разграничить два субъекта в процессе создания ГИС:

  • Подрядчики (исполнители) — ИТ-компании, студии, консалтинговые фирмы. Для них характерно применение современных методологий — Scrum, Kanban, DevOps-практик, CI/CD. Их интерес — сдать проект в срок, в рамках бюджета, с минимальными рисками переработок. Они гибки, адаптивны, готовы к изменениям — в пределах контракта.
  • Заказчики (государственные структуры) — министерства, ведомства, региональные органы власти. Для них характерен консерватизм, основанный на системных рисках. Один неудачный проект может привести к проверке, увольнению, уголовному делу. Поэтому выбор в пользу "проверенного", "традиционного", "как в прошлый раз" — это рациональная стратегия снижения личной и институциональной ответственности.

Консерватизм проявляется в:

  • предпочтении текстовых, бумажных (или PDF-форматных) документов перед интерактивными бэклогами;
  • требовании полного, детального ТЗ до начала разработки — чтобы исключить "движение цели" и обвинения в неисполнении обязательств;
  • жёсткой привязке к ГОСТам, даже если они устарели, — потому что ссылка на ГОСТ является аргументом в споре с проверяющими;
  • избегании "нестандартных" решений: open source без поддержки российской компании, облачных решений вне Государственной информационной системы (ГИС) или за пределами "Облачного реестра Минцифры";
  • склонности к монолитным архитектурам из-за простоты описания и сопровождения в отчётах.

Это адаптация к среде, где ключевой метрикой успеха является не качество продукта, а отсутствие претензий.

Два мира: подрядчик и заказчик

Внутри команды подрядчика — Scrum, Kanban, CI/CD, короткие циклы.

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

Жизненный цикл ГИС​

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

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

Рассмотрим типовую последовательность (на основе Постановления Правительства РФ № 1030 и приказов Минцифры, но с акцентом на практическую логику, а не формальное перечисление):

Инициация и обоснование​

Этап начинается с политического или административного решения — указа, поручения Президента или Правительства, распоряжения руководителя ведомства, включения в государственную программу.

Ключевым документом здесь является концепция создания (развития) системы. Она не содержит технических решений, но обосновывает:

  • общественную потребность (например, "снижение времени оформления пособий с 30 до 3 суток");
  • соответствие национальным проектам или стратегиям цифровой трансформации;
  • оценку рисков — репутационных, правовых, бюджетных ("возможность проверки Счётной палатой при несоблюдении требований 152-ФЗ");
  • предварительную архитектуру взаимодействия с другими ГИС (ЕПГУ, ЕГАИС, СМЭВ и др.);
  • оценку совокупной стоимости владения (TCO), включая разработку, 5–10 лет эксплуатации, лицензирование, аудиты, модернизацию.

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

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

Формирование технического задания (ТЗ)​

В коммерческой среде ТЗ — это инструмент передачи видения продукта от заказчика к исполнителю. В государственной практике ТЗ — это юридический акт, который:

  • фиксирует объём обязательств подрядчика;
  • служит основанием для оплаты по контракту;
  • используется при проверке — сравнение итогового результата с пунктами ТЗ является стандартной процедурой.

Поэтому ТЗ в ГИС — это формализованное описание с привязкой к нормативам. Например:

"Система должна обеспечивать хранение персональных данных граждан в соответствии с требованиями п. 16 Положения о составе и порядке ведения журналов учёта операций, установленного приказом ФСТЭК России от 11.02.2013 № 21".

"Интерфейс обмена с ЕСИА осуществляется посредством защищённого канала связи, реализованного в соответствии с требованиями Методических рекомендаций по организации защищённого взаимодействия ГИС, утверждённых приказом Минцифры России от 17.07.2020 № 378".

ТЗ согласуется с ИТ-департаментом, юридической службой, службой защиты информации, финансовым управлением — потому что каждый раздел создаёт риски для соответствующей службы.

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

Проектирование​

На этапе проектирования подрядчик создаёт архитектуру, прототипы, и полный комплект проектной документации в соответствии с ГОСТ 34.601–90 и ГОСТ 19.102–77.

Сюда входят:

  • технический проект (ТП) — описание архитектуры, платформ, протоколов, схем интеграции;
  • рабочая документация — спецификации программных модулей, баз данных, интерфейсов;
  • программа и методика испытаний (ПМИ) — детальный план проверок, согласованный с заказчиком;
  • паспорт системы — обобщающий документ для регистрации в РГИС.

Каждый из этих документов проходит внутреннюю экспертизу (внутри подрядчика), затем — независимую экспертизу (в аккредитованной организации), и только после этого — приёмочную комиссию со стороны заказчика.

Экспертиза — проверка соответствия нормативным актам. Например:

  • есть ли в ТП ссылка на класс защиты информации по ФСТЭК?
  • учтены ли требования к отказоустойчивости из приказа Минцифры № 531?
  • предусмотрен ли резервный центр обработки данных (ЦОД)?

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

Реализация и тестирование​

В условиях waterfall-подхода, доминирующего в госконтрактах, реализация и тестирование строго разнесены во времени и по ответственности.

Подрядчик пишет код, но не имеет права проводить приёмочные испытания. Тестирование делится на три уровня:

  1. Внутреннее тестирование — проводится подрядчиком (unit-, интеграционное, нагрузочное). Результат — отчёт, который не является основанием для оплаты.
  2. Независимое тестирование — проводится аккредитованной тестовой лабораторией по утверждённой ПМИ. Результат — акт, включающий перечень несоответствий ("замечаний"). Их устранение — за счёт подрядчика.
  3. Приёмочные испытания — проводятся заказчиком, часто с участием реальных пользователей (например, сотрудников МФЦ). Здесь проверяется соответствие бизнес-процессам. Например — "Может ли сотрудник подать заявку на пособие за 5 минут?" — даже если интерфейс с технической точки зрения работает корректно, но не соответствует регламенту работы учреждения, испытания не пройдены.

Приёмочные испытания — финальная точка. Если система не прошла — контракт не закрывается, деньги не перечисляются, проект "зависает". Нет механизма "выпустим в бету, доработаем по фидбэку". Есть только "принято" или "не принято".

Ввод в эксплуатацию и регистрация​

Успешное прохождение приёмочных испытаний не означает, что система начинает работать. Необходимо:

  • издать приказ о вводе в промышленную эксплуатацию;
  • зарегистрировать систему в Реестре ГИС (РГИС) — с указанием класса защищённости, ответственного лица, подключённых внешних систем;
  • провести обучение пользователей и подготовить регламенты эксплуатации;
  • назначить ответственного за ИБ и провести инструктаж по локальным нормативным актам;
  • внести систему в план-график мероприятий по обеспечению безопасности (на 1 год вперёд).

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

Эксплуатация и сопровождение​

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

Регламент сопровождения — обязательный документ, включающий:

  • график проведения работ (например — "проверка логов — ежедневно", "резервное копирование — каждые 4 часа", "аудит журналов ИБ — ежемесячно");
  • перечень инцидентов и реакция на них ("утечка персональных данных → немедленное информирование Роскомнадзора в течение 24 часов");
  • процедуры модернизации — которые, опять же, требуют нового ТЗ, новой экспертизы и нового контракта.

Автоматизация развёртывания (CI/CD), hotfix’ы без согласования, A/B-тестирование — всё это запрещено регламентами безопасности информации. Любое изменение в промышленной системе должно быть оформлено как "внесение изменений в программную документацию" и согласовано. Практика показывает: внедрение корректирующего патча может занять от 10 до 30 рабочих дней — из-за согласований.

Где Agile всё же возможен (без нарушения рамок)​

Полноценный "релиз в production каждый спринт" в промышленной ГИС часто недоступен без отдельного согласования. Но это не запрещает итеративность внутри контракта:

  • Пилот / опытная эксплуатация на ограниченном контуре пользователей — до приказа о промышленной эксплуатации.
  • Исследование и прототип на этапе концепции или ТЗ (макеты, нагрузочный стенд) — как обоснование решений, а не как "MVP в отчёте Минфину".
  • Scrum у подрядчика при waterfall-приёмке заказчиком — спринты, CI, автотесты — с внешней отчётностью по ГОСТ и актам этапов.

Формулировки в ТЗ: плохо / хорошо

Плохо (непроверяемо при приёмке)Хорошо (проверяемо, со ссылкой на норму)
"Сделать удобный интерфейс""Время заполнения формы заявления — не более 5 минут при типовом сценарии из п. 3.2 регламента"
"Быстрая интеграция с реестром""Запрос статуса по REST, таймаут 3 с, при недоступности — код ошибки X и запись в журнал по п. 4 приказа ФСТЭК № 21"

Внутренний процесс подрядчика → внешний документ для приёмки

Внутри команды (можно)Для заказчика и проверки (нужно)
Ветки Git, pull request, code reviewОписание конфигурации в ТП, журнал версий
Отчёт CI о прогоне тестовПрограмма и методика испытаний (ПМИ), протоколы испытаний
Демо на dev/stage каждую неделюАкт этапа / приёмочные испытания по утверждённому графику

Нормативная основа​

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

Например, ГОСТ 34 ("Автоматизированные системы") давно устарел с технической точки зрения. Он не учитывает облачные технологии, микросервисы, CI/CD, контейнеризацию. И всё же он остаётся ключевым документом в госконтрактах — потому что ссылка на ГОСТ 34 в ТЗ позволяет заказчику сказать проверяющему: "Мы действовали в соответствии с действующим стандартом". Отсутствие такой ссылки — повод для критики.

Аналогично — ГОСТ Р ИСО/МЭК 12207 (жизненный цикл ПО). Он формально принят, но на практике применяется фрагментарно — лишь те разделы, которые требуются для составления нужных документов (например, "Ведомость документов"). Процессы вроде "управления конфигурацией" или "валидации" зачастую сводятся к подписанию бумажных журналов, а не к использованию Git и автоматических тестов.

Более того, в последние годы наблюдается дублирование и расслоение нормативной базы:

  • Минцифры России выпускает методические рекомендации (например, "Требования к архитектуре ГИС");
  • ФСТЭК — приказы по защите информации (№ 21, № 31, № 17);
  • ФСБ — собственные требования к криптографической защите;
  • Роскомнадзор — указания по персональным данным;
  • Минфин — требования к бюджетному учёту ИТ-расходов.

Эти документы не всегда согласованы. Например, Минцифры может рекомендовать использовать open-source решения, а ФСТЭК требовать наличия поддержки от российской компании-разработчика. Подрядчик вынужден искать компромисс, но окончательное решение принимает заказчик — исходя из того, какой орган имеет больше полномочий в случае проверки.

Таким образом, "методология" в ГИС — это практика балансирования между противоречивыми требованиями, где техническое решение всегда вторично по отношению к способности его обосновать ссылкой на нормативный акт.

Архитектура ответственности​

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

Рассмотрим ключевые роли — как зоны юридической и административной ответственности.

Заказчик (инициатор и владелец)​

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

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

Он отвечает за:

  • корректность формулировок в концепции и ТЗ с точки зрения ведомственных задач;
  • своевременное информирование вышестоящего руководства о рисках (например, срыв срока — за 3 месяца);
  • согласование всех отступлений от норм (например, использование СУБД, не включённой в Единый реестр российских программ);
  • подписание актов — как акт возложения ответственности — "Я, как заказчик, подтверждаю, что требования выполнены в объёме, достаточном для приёмки".

Заказчик не может самостоятельно изменить приоритеты в ходе проекта. Даже если он лично убедился, что функция А важнее функции Б, он не вправе перераспределить объём работ — это требует изменения контракта, согласованного с юридической службой и финансовым управлением. Его полномочия — интерпретировать существующие требования, но не вводить новые.

Технический надзор (Технадзор)​

Роль, не имеющая прямого аналога в коммерческой разработке. Технадзор — это независимый контролёр со стороны заказчика, часто оформлен как отдельный контракт с другой организацией (например, с ФГУП или аккредитованным институтом).

Его функция — фиксировать несоответствия. Он проверяет:

  • соблюдение сроков (по графику-"диаграмме Ганта", утверждённому в контракте);
  • соответствие промежуточных документов (ТП, ПМИ) требованиям ТЗ;
  • наличие подписей в журналах (например, журнале входного контроля образцов);
  • полноту отчётности (например, "есть ли акт внутреннего тестирования от 15.03.2025?").

Технадзор не оценивает, "хорошая" ли архитектура. Он проверяет, описана ли она в документе и соответствует ли описание формальным требованиям.

Конфликт между подрядчиком и технадзором — обычная ситуация. Подрядчик считает, что система работает; технадзор требует, чтобы в ТП был отдельный раздел "Описание отказоустойчивости в соответствии с п. 5.2 приказа Минцифры № 531". Без этого раздела — задержка приёмки. Такой конфликт разрешается административным решением заказчика: "Включить раздел" или "Получить письменное согласование от Минцифры на отступление".

Экспертная организация​

Обычно это аккредитованная лаборатория, имеющая лицензию ФСТЭК или Минцифры на проведение экспертизы.

Её роль — валидация соответствия нормам. Экспертиза проектной документации — это проверка по чек-листу:

  • указан ли класс защиты информации (КЗИ)?
  • есть ли описание мероприятий по защите от НСД?
  • учтены ли требования к аутентификации по приказу ФСТЭК № 31?

Если в документе всё есть — экспертиза пройдена. Если чего-то нет — выдаётся "заключение с замечаниями". Устранение замечаний — за счёт подрядчика, и срок на это фиксируется (обычно 10–15 рабочих дней). Превышение срока — основание для штрафных санкций.

Примечательно: экспертная организация не несёт ответственности за последствия внедрения. Она подтверждает только соответствие документа на момент проверки. Если через год выяснится, что система уязвима — виноваты заказчик (не обеспечил сопровождение) и подрядчик (некачественно реализовал), но не эксперт.

Подрядчик (исполнитель)​

Это единственный участник, чья ответственность — техническая. Но и она ограничена рамками контракта.

Подрядчик отвечает за:

  • выполнение работ в объёме, сроках и качестве, указанных в ТЗ и контракте;
  • предоставление полного комплекта документов (кода, отчётов, журналов, паспортов);
  • устранение замечаний экспертизы и технадзора в установленные сроки.

Он не отвечает за:

  • целесообразность системы (это — заказчик);
  • корректность ТЗ (если ТЗ требует реализовать невозможное — подрядчик может оспорить это в досудебном порядке, но не обязан это делать по умолчанию);
  • последующую эксплуатацию (если в контракте не прописано сопровождение).

Существует важный нюанс: подрядчик часто работает "в рамках двух миров". Внутри своей команды он может использовать Scrum, GitLab CI, автоматизированное тестирование — но финальный отчёт должен быть оформлен в соответствии с ГОСТ 19.502–78 ("Программа и методика испытаний"), с титульными листами, штампами, подписями руководителя и главного инженера.

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

Логика управления в корпоративной и государственной среде​

Ниже — анализ глубинных различий в логике принятия решений, которые делают прямой перенос практик (например, "внедрим Scrum в госпроект") обречённым на провал.

Цель проекта​

  • Корпоративная среда — максимизация ценности для пользователя/бизнеса при заданных ограничениях (время, бюджет, ресурсы). Успех измеряется метриками — рост конверсии, снижение времени обработки заявки, NPS.
  • Государственная среда: минимизация рисков ответственности при выполнении публичной функции. Успех измеряется — отсутствием проверок, своевременной сдачей отчётов, регистрацией в РГИС, подписанием всех актов.

Отсюда — различие в отношении к неопределённости. В корпоративной среде неопределённость — повод для экспериментов (MVP, A/B-тесты). В государственной — повод для дополнительных согласований и страховочных документов.

Управление изменениями​

  • Корпоративная среда: изменения — норма. Бэклог динамичен, приоритеты пересматриваются еженедельно. Даже в рамках waterfall допускаются формальные запросы на изменение (change request) с оценкой impact’а.
  • Государственная среда: изменения — исключение, требующее юридического оформления. Любое отклонение от ТЗ рассматривается как нарушение контракта, если не оформлено как дополнительное соглашение. Процедура внесения изменений может включать:
    • подготовку обоснования (почему изменение необходимо);
    • проведение новой экспертизы (если затрагиваются защищённые компоненты);
    • согласование с вышестоящим органом (если сумма превышает лимит);
    • корректировку плана-графика закупок.

Поэтому заказчики часто предпочитают "доделать по старому ТЗ, даже если это не нужно", чем запускать процедуру изменения. Это не нерационально — это рационально в контексте минимизации административных издержек.

Оценка неудачи​

  • Корпоративная среда: неудача = продукт не решает задачу. Реакция — анализ причин, pivot, закрытие проекта. Провал — возможность научиться.
  • Государственная среда: неудача = факт нарушения процедуры. Реакция — поиск виновного, проверка, доклад вышестоящему руководству, восстановление процесса. Провал — угроза карьере.

Пример — система работает, но при приёмке выяснилось, что в ПМИ не указан один тест-кейс по безопасности. Подрядчик готов доработать за 1 день. Но формально — приёмка не пройдена. Заказчик не может подписать акт, даже если система функционирует. Потому что подписание = признание соответствия, а его нет. Риск для заказчика (административная ответственность) выше, чем выгода от запуска системы.

Роль документации​

  • Корпоративная среда: документация — средство передачи знаний. Допускается "документация как код" (README, Swagger, Confluence), живые диаграммы, видеозаписи демо.
  • Государственная среда: документация — доказательная база. Требуется:
    • бумажная (или PDF с ЭЦП) форма;
    • титульные листы с грифами ("Для служебного пользования");
    • подписи уполномоченных лиц (с расшифровкой ФИО и должности);
    • нумерация страниц, регистрационные номера, штампы.

Даже если система написана на Rust с полным покрытием тестами, без утверждённого ТЗ и акта приёмки она юридически не существует.

Рекомендации​

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

Ниже — проверенные подходы, позволяющие сохранить техническое качество без нарушения рамок.

Разделяйте внутренние и внешние процессы​

  • Внутри команды подрядчика используйте любые современные практики — CI/CD, code review, TDD — но не афишируйте их в отчётах.
  • Финальные документы (ТП, ПМИ, отчёты) оформляйте в соответствии с ГОСТ — но используйте их как обёртку для современной реализации. Например, в ТП можно написать: "Система построена по микросервисной архитектуре" — и далее описать её в терминах "подсистем" и "взаимодействующих модулей", как того требует ГОСТ 34.

Переводите технические решения на язык нормативов​

Не говорите: "Мы используем Kubernetes для оркестрации". Говорите:

"Развертывание и масштабирование компонентов системы осуществляется с применением программно-аппаратных средств, обеспечивающих выполнение требований п. 5.4 приказа Минцифры № 531 (отказоустойчивость не ниже 99,9%)".

Это не "приукрашивание" — это адаптация языка под аудиторию. Проверяющий не обязан понимать Kubernetes, но обязан убедиться, что требования выполнены.

Управляйте ожиданиями заказчика заранее​

На этапе проработки ТЗ чётко разделяйте:

  • то, что обязательно по закону (например, шифрование персональных данных);
  • то, что обязательно по контракту (например, наличие бумажного журнала входного контроля);
  • то, что можно оптимизировать (например, формат отчёта — Excel или PDF, если контракт не уточняет).

Предлагайте заказчику "технические компромиссы":

"Мы можем выполнить требование о резервном копировании каждые 4 часа, но технически это реализуется через автоматизированный скрипт с логированием в SIEM-систему. При этом журнал резервного копирования будет формироваться в PDF-формате и подписываться ЭЦП ежедневно — как того требует регламент".

Инвестируйте в "документальную инженерию"​

Выделите в команде роль технического писателя / нормативного инженера — человека, который:

  • знает ГОСТы и приказы на уровне ссылок;
  • умеет переводить архитектурные решения в формат "требование → реализация → подтверждение";
  • готовит документы так, чтобы они прошли экспертизу с первого раза.

Это снижает риски простоев на этапе согласования и экономит больше времени, чем оптимизация CI/CD-пайплайна.

Типовые ошибки в госпроектах и способы профилактики​

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

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

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

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

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

Как сочетать гибкость и формальные этапы​

Госпроекту подходит двухконтурная организация работ:

  • Внутренний контур подрядчика
    Короткие итерации, демо, автотесты, CI, быстрая обратная связь.

  • Внешний контур заказчика
    Этапы, акты, экспертиза, документы по ГОСТ и ведомственным регламентам.

Связка контуров строится через промежуточные артефакты:

  • к каждой контрольной точке готовится пакет доказательств по требованиям ТЗ;
  • внутренние инкременты агрегируются в формально проверяемые результаты этапа;
  • риски фиксируются заранее, чтобы изменение контракта запускалось до критического дедлайна.

Так команда сохраняет инженерную скорость внутри и юридическую устойчивость снаружи.

Полезный маршрут по энциклопедии​

Эта глава лучше усваивается в связке с соседними статьями:

Содержание