О себе

Всем привет. Меня зовут Никита, я руковожу командой Цикл-ОН. Мы уже более 5 лет ведем проекты по заказной разработке ПО и, как и многие, сталкиваемся с необходимостью разработки не только качественного кода, но и документацию на продукты. В нашей нише особенность, что заказчики живут в парадигме ГОСТа. Я бы здесь хотел оставить небольшую заметку о нашем опыте — как то, что для начаиналось как откровенное мучение превратилось сначала в умную идеологию, а по итогу в самостоятельное решение для подготовки документации — Платформа «ГОСТ‑ОН».

С чего все началось

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

Думали - наймем техписа, и дело в шляпе

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

Начало экспериментов - Confluence, макросы Word, Google Docs, MarkDown

Очевидно, что требовалось новое решение, которое бы сразу решало несколько задач:

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

  • преднастройка стилей форматирования документа

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

Устроили всесоюзные смотрины основных продуктов и пришли к таким результатам:

Параметр

Word c макросами

Confluence

Google Docs

Синхронизация версия

Не решает. WordOnline,когда еще был в России, как-то пытался решить задачу, но сейчас совсем тупиковая ветвь

Решается, версионирования по пользователям тоже работает

Лучший вариант - полный синхрон, управление правами

Преднастройка стилей

Лучший вариант

По умолчанию не решается. Отдельными костылями решалось, но не настолько продвинуто как требует ГОСТ (рамки, тонкости выравнивания тексты, колонтитуты и т.д.)

Сложные элементы форматирования "слетают" при конвертации в Word. Заказчика всегда просил Word смотреть.

Уход от копипаста

Функционал "полей" частично решал задачу, но UI не позволяет держать общую рамку и связь полей по всем документами

Макрос Include Page может решать эту задачу, но рушит на сложных элементах: мультиатрибутивные элементы описания и др.

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

Вердикт

Лучший вариант из плохих альтернатив

Можно было бы использовать, если бы не нюансы оформления документов по ГОСТ

Если документов мало и форматирование не критично - можно рассмотреть

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

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

Умная идеология - Каждый элемент описания ПО является информационной сущностью

Мы пришли к принципу переменных. Каждый элемент описания является информационным объектом

1. Атомарные поля

Простые поля типа «название системы», «заказчик», «исполнитель»

2. Списки

Плоские и вложенные перечисления. Например, «Внешние ИС, с которыми взаимодействует система» или «Документы-основания для разработки».

3. Изображения

Схемы, скриншоты, диаграммы. Скажем, «Компонентная схема», «Структурная схема» или отдельная папка - «Скриншоты для руководства администратора».

4. Объекты

Самый сложный тип переменных — сложные сущности с множеством атрибутов. Например, «Модуль» с вложенными «Функциями», которые связаны с «Экранными формами».

Вскоре под эту парадигму стали придумывать способы хранения и работы с этими сущностями. Проект шел под кодовым наименованием "ГОСТ-ОН". Так в итоге и назвали продукт.

Рождение ГОСТ-ОНа

В итоге мы пришли к некой форме IDE работы с документами. Но мы пошли дальше классического Docs-as-Code. Мы взяли привычный всем MarkDown, добавили мощный Python-ный шаблонизатор Jinja2, который бы работал с переменными и создали генератор документов, который позволяет учесть специфику российских ГОСТов и при этом сохранить гибкость для учета особых требований, возникающих на каждом проекте.

В итоге у нас родился триптих-вид рабочего места:

  • слева - панель переменные

  • по середине - основная рабочая зона с MD-редаткором, поддерживающим синатксис шаблонизации текста на базе Jinja2 (что это такое - лучше ознакомиться отдельно в руководстве)

  • справа - HTML-превью документа с возможностью экспорта в DOCX, PDF, HTML, MD.

Текстовый редактор ГОСТ-ОН
Текстовый редактор ГОСТ-ОН

Что принципиально поменялось

Время на форматирование практически сведено к нулю

В Платформе сразу живут правильные стили Word для каждого типа документа по ГОСТ. Хотите сменить Times New Roman на GOST Type A по ГОСТ 2 – делаем в один клик. Хочшеь с рамкой, хочешь без - все тоже настраивается.

Пример сгенерированного документа, открытого в Word
Пример сгенерированного документа, открытого в Word

Единый источники правды - хранятся не документы, а описания

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

Полное наименование системы: {{ full_is_name }}

Краткое наименование системы: {{ short_is_name }}

Исполнитель: {{ developer }}

И самый кайф: поменял один раз описание, это сразу транслируется на все документы, содержащие это описание.

У документации есть своя архитектура

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

Пример отображения структуры элементов описания информационной системы
Пример отображения структуры элементов описания информационной системы

Лучшие кейсы

Несколько житейских примеров из практики

Заказчик попросил поменять регистрационный номер ИС

Это такая особенность нумерации документов и их версий по ГОСТ 34.201.

Раньше: меняем колонтитутлы и титульные листы по ВСЕХ документах.
Стало: поменяли описание переменной {{ reg_number }} - все документы актуализированы.

Заказчик попросил поменять формат описания 146 методик испытаний ПО

ПМИ всегда одна из трудоемких задач для документации на систему, тем более что формат описания проверок всегда исходит от практики заказчика - ГОСТ жестко не регламентирует.

Раньше: 95% времени уходит на переформатирование таблиц в Word, нежели на проверку методик и их выпноление.

Стало: изменение 5 строк в редакторе для изменения вложенного цикла.

Что-то на будущее

Надеюсь, заметка была полезна. Есть еще много аспектов, которые возможно смогу раскрыть в будущем:

  • формы слов (падежи)

  • маленькие прелести (автонумерация рисунков и таблиц)

  • ИИ-агент

  • совместный режим и режим ревью

  • интеграция с облачным хранилищем файлов

  • перевод документации из ГОСТ в интерактивную веб-версию

Буду рад любой обратной связи!

Комментарии (11)


  1. TimurZhoraev
    14.03.2026 20:48

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


    1. NikitaOsokin_ON Автор
      14.03.2026 20:48

      В любом случае пришли, что некая парадигма IDE оптимальна. Здесь еще надол учитывать порог входа для работы с такими инстурментами, особенно если задача перевести на них хардкорных гост-техписателей. Поэтому вопрос GUI тоже очень важным, чтобы была интуитивность в работе. В принципе то, к чему мы пришли не заключена в рамки только ГОСТ-документации. Можно задать любой типовой набор стилей Word и в бой!)


  1. jvw
    14.03.2026 20:48

    Интересная штука. Хотел потыкать, но у вас регистрация только по приглашениям. Судя по описанию и скринам интерфейса (здесь и у вас на сайте), я бы сказал, вашей системе недостаёт векторного поиска. Полезная штука, когда документации много и коррелирует с вашими планами - я имею в виду ИИ помощника (RAG)


    1. orchanin
      14.03.2026 20:48

      А куда вы хотели потыкать? У меня не получилось найти следы самого сервиса в профиле автора и статье.


      1. jvw
        14.03.2026 20:48

        я по названию нагуглил https://gost-on.ru/


        1. orchanin
          14.03.2026 20:48

          Слона то я и не заметил)


    1. NikitaOsokin_ON Автор
      14.03.2026 20:48

      Напишите мне сообщение, я с удовольствием предоставлю демо-доступ)


  1. d3d12
    14.03.2026 20:48

    Я наверно очевидность скажу - но не проще сюда ИИшку прикрутить, она все и поменяет.


    1. NikitaOsokin_ON Автор
      14.03.2026 20:48

      В случае массивной документации если просто " в лоб" просить ИИ решить задачу, то упирались в 2 ограничения: лимит контекстного окна и большой расход токенов (несколько сотен тысяч). Поэтому в принципе видим сервис как инструмент качественного структурирования промпта и способ экономии токенов, так большой расход токенов на "выходе" еще терпим, но то что нужно давать много контекста, это сильно "засоряет" общение с LLM. Даже векторная база через RAG с ходу все эти вопросы не решает. Отдельным материалом еще расскажу про это)


  1. GorkyUser
    14.03.2026 20:48

    Молодцы, конечно, но есть же такие развитые технологии как Docbook и DITA и есть XML-редакторы их поддерживающие, например, oXygen XML Editor. Поддерживается:
    1. Принцип единого источника. Документ в Oxygen можно собирать из "кирпичиков" – из разных текстов, хранящихся в других файлах.
    2. Профилирование. Блоки данных можно помечать специальными атрибутами, которые отвечают за публикацию документа в той или иной интерпретации. Перед публикацией отмечается нужная интерпретация и какие-то блоки печатаются, а какие-то, не относящиеся к этой интерпретации, игнорируются.
    3. Отделение оформления от содержания. Писатель работает только с содержанием и разметкой. Стили форматирования элементов разметки прописаны в других файлах и после настройки не меняются.
    4. Многоформатность. Публикация возможно в различные форматы (PDF, Word, HTML...).
    Самое сложное будет, особенно с необходимостью писать по ГОСТу настроить стили в п.3. А потом все идет как по маслу.


    1. NikitaOsokin_ON Автор
      14.03.2026 20:48

      Именно в случае ГОСТа самым тяжелым оказалось решить вопрос правильного рендеринга DOCX и из него впоследствии PDF. Вся ГОСТ с документация с "рамками" это прям оформительская боль, так как это оформляется в логике Word как колонтитул, далее используются разные форматы колотитулов для титульного листа, оглавления и основной части + элементы переменных внутри колонтитулов. То есть все что мы пробовали приводила к получению полуфабрикатных документов, которые все равно приходилось дополнительно форматировать руками. Надеюс в отдельной статье чуть больше технической деталей опишу, как мы в итог это решили + еще заложили вариативность, что можно свободно менять форматирование при генерации (например в ГОСТе 2 шрифта допустимы: Times New Roman и GOST).

      И еще нам стало очень удобно подключать ИИ-ассистента, когда это свое решение, то больше есть поле для экспериментов с этим. В перспектие дойдем до своего MCP.