У нас было 120 процессов, 9 областей управления, более 100 авторов из 60 компаний, 3 ветки на каждый репозиторий и ещё по одной на каждую задачу, AI-агент, таск-трекер, толстый клиент редактора и три портала документации. Не то чтобы всё это нам было нужно, чтобы описать методологию управления в ИТ. Но когда однажды начинаешь собирать серьёзную базу знаний — возникает тенденция разогнаться так далеко, как только сможешь.

Единственное, что меня по-настоящему беспокоило — это конфликты слияния. Нет в мире ничего беспомощнее и безответственнее, чем методолог, пытающийся разобраться, что такое конфликт слияния. И я знал, что скоро мы в эту дрянь попадём.

Если вы когда-нибудь пробовали в одиночку причесать чужой Word-документ, в котором двадцать комментариев на полях и три уровня правок разными цветами — вы поймёте, с чего начнётся эта история. Только умножьте на 100 авторов из 60 компаний и 120 процессов. И добавьте ноль бюджета: всё это люди делают по вечерам, потому что им не всё равно, как будет выглядеть управление ИТ в стране.

Это не туториал и не обзор инструмента. Это история о том, как я полтора года уговаривал себя, что Wiki — нормальный выбор, потом ещё полгода уговаривал команду, что пора слезать. И как после переезда на Docs as Code половина того, чего я ждал, не случилась, а половина случилась не так. И почему мне всё равно нравится, что вышло.

Чтобы дальше было проще читать, расскажу коротко, кто все эти люди.

Вводные

• РИТМ — это «Рациональная ИТ-методология», открытая модель управления ИТ, которую сообщество российских профессионалов разрабатывает под крышей itSMF России. Когда ITIL, COBIT и TOGAF в один день стали для нас сложнодоступны, выяснилось, что у каждой команды в стране — свой жаргон, свой набор практик и своё представление, что такое продукт и услуга и какая между ними разница. Общий язык начал расползаться. РИТМ его собирает обратно: не копируя западные методологии, а адаптируя то лучшее, что в них было, под нашу реальность. Девять областей управления, от стратегии до постоянного совершенствования. Открытая лицензия. Сегодня в проекте больше 100 авторов из 60 с лишним компаний — Сбер, Газпромнефть, Норникель, Naumen, Softline, Яндекс и другие.

• Я в этой истории — Всеволод Шадрин, председатель itSMF России, архитектор РИТМ и руководитель AI-офиса в Naumen. Сотовую модель РИТМ придумал я, переезд, о котором будет дальше, организовывал тоже я. Так что предупреждаю сразу: я необъективен.

• Gramax — open-source платформа для документации по подходу Docs as Code. По сути — WYSIWYG-редактор поверх git: автор нажимает «Опубликовать», под капотом коммит и push. Ветки, история, merge requests, поддержка диаграмм через Mermaid, PlantUML и Draw.io. Соавтор этой статьи — Екатерина Павлова, CPO Gramax, и да, мы с ней в одной команде. Это не независимая рецензия, это рассказ людей, которые вместе вытаскивали эту миграцию.

• ЛК Аврора — это наш личный кабинет автора, собранный на базе ITSM 365. Там живут задачи документирования, ролевая модель и учёт вклада. Когда мы будем говорить «задача → ветка → MR → закрытие», задача в этой цепочке именно из Авроры.

Сначала была Wiki — и это было правильно

В конце 2023 года, когда РИТМ только начинался, нас было 16 человек и 9 процессов. Перед нами лежал выбор: ставить Wiki или сразу заходить в Docs as Code: заводить git, репозитории, пайплайны и объяснять каждому методологу, что такое feature-branch.

Мы выбрали Wiki. И, если бы я мог сейчас вернуться, я бы выбрал её снова.

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

Если у вас маленькая команда и одна аудитория документации — Wiki работает идеально. Проблемы начинаются ровно тогда, когда хотя бы одно из этих двух условий перестаёт быть правдой. У нас перестали быть оба.

Первая трещина: появилась вторая версия

До beta-версии в нашей жизни было два состояния документа: «черновик» и «актуальный». В beta внезапно появилось ещё одно: «то, что мы пишем» и «то, что мы уже показали». Первой пошла РИТМ.Активы.

В Wiki нужно было создать каталог, куда положить материалы для беты. Туда переносим, например, «Управление потребностями в ИТ-активах». Только тут же выясняется: процесс ссылается на десять других, а они лежат в закрытом разделе. Если перенести один — ссылки сломаются. Если скопировать — у нас теперь два документа с одинаковым именем и расходящейся жизнью. А ещё параллельно процесс надо дорабатывать, где это делать? В beta, поверх показанной версии? В копии? И куда вести ссылки из других процессов — на черновик или на причёсанную beta?

В Wiki вариантов два. Можно копировать страницы и героически следить за целостностью ссылок — но при 120 процессах это работа на отдельную должность. Можно переносить — но тогда единое хранилище области управления разваливается на «часть в разработке» и «часть в beta», и связь между ними держится на честном слове. Мы попробовали оба варианта. Оба ломались.

Вторая трещина: люди начали обходить инструмент

Дальше — то, что обычно никто не пишет в кейсах, потому что стыдно. Я расскажу, потому что иначе вся история не складывается.

Когда над одним процессом начинают работать три-пять человек одновременно, в Wiki происходят неприятные вещи. Комментарии пропадают при сохранении — не всегда, не у всех, но достаточно часто, чтобы перестать им доверять. Один автор перезаписывает правки другого, не подозревая об этом. Посмотреть, что изменилось между «вчера» и «сегодня», нельзя — есть только текущая версия. То, что для разработчика звучит как сюр, для редактора Wiki — норма жизни.

И дальше начинается самое смешное. Команды, устав от потерянных комментариев, начали оставлять их прямо в тексте. Курсивом, в скобках, с инициалами. Так надёжнее: текст-то Wiki не теряет, а вот объекты-комментарии — как повезёт. Параллельно в нескольких командах процесс согласования съехал в Word: кто-то выгружал страницу, рассылал по почте, собирал правки от пяти человек, потом руками переносил всё обратно в Wiki. И это не были люди, которые «не разобрались с инструментом». Это были люди, которые разобрались — и решили, что Word с почтой надёжнее.

Я в этот момент чувствовал то, что в моей профессии называется красивым словом «фрустрация», а в обычной жизни — беспомощностью. Потому что поддержка Wiki отвечала медленно, было непонятно, на каком этапе теряются комментарии, а ответственность перед командой я ощущал очень остро. Авторы РИТМ тратят на это нерабочее время. И если они тратят его на то, чтобы понять, в какой версии документа какие комментарии и кто их оставлял, — мы тратим их время на ерунду.

А потом случилась история, после которой я перестал думать «может, ещё подождём».

Осень 2025-го. Я пропустил счёт на оплату облачной Wiki. Просто проглядел письмо. Нам отрезали доступ. Не на запись — даже на чтение. Полтора года работы 100 авторов лежали по ту сторону логин-формы, и нормально экспортировать всё разом не получалось. Это длилось не дни, и я по-настоящему испугался. Я понял, что вся наша база знаний сейчас зависит от того, не пропустит ли один человек одно письмо.

Это была та самая последняя капля.

Решились на сложный процесс

Мы вернулись к Docs as Code — тому самому подходу, который двумя годами раньше отвергли как избыточный. Что изменилось? Только масштаб. На 100 авторах и 120 процессах цена «простого процесса» стала выше, чем цена «сложного». Wiki, которая казалась дешёвой, начала стоить нам конкретных потерянных часов и нервов.

Выбирали мы вдвоём с Максимом Демьяновым, CTO команды РИТМ и одновременно CTO в Naumen. Смотрели всё, что можно было посмотреть в России: разные Wiki — бесплатные и платные, Документерру, Teamly, Naumen MS. Confluence отпал по понятным причинам. Западное вообще отпало: нет VPN-устойчивых лицензий, нет легальной оплаты, дополнительные риски на длинной дистанции.

У нас было пять железных требований и одно мягкое:

• Несколько версий документа должны жить параллельно и не мешать друг другу: рабочая, согласованная и публичная.

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

• Контроль доступа на уровне версий: публичный, для itSMF, для авторов.

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

• Формат, дружественный к AI: plain text, никаких проприетарных бинарников. Я к этому отдельно вернусь — у нас на 2026 год запланирован LLM-ассистент поверх РИТМ, и без markdown в git это была бы боль.

А мягкое требование звучало так: инструмент должен скрывать сложность. Авторы РИТМ — методологи, не разработчики. Про git многие слышали, не все им пользовались. Если в редакторе видно слово «push», часть команды развернётся и уйдёт.

Мы выбрали Gramax + Аврору. Gramax — за условия, функциональные возможности и, главное, за команду. Аврору сделали на ITSM 365: знакомый стек, бесплатные лицензии и хостинг для itSMF, гибкая ролевая модель, low-code для собственной автоматизации. Jira отпала на старте: офлайн-only стек или пиратство — мимо.

Вы, конечно, заметили, что слово «команду» я выделил курсивом. Это не случайно. Главный вывод этой миграции я сделал не про продукт.

Главный поворот: команда поставщика — важнее инструмента

Я писал и переписывал этот абзац несколько раз, потому что он звучит как банальность из консалтинговой брошюры. И всё равно я его оставлю.

Когда Екатерина и команда Gramax начали приходить со своими предложениями — как структурировать репозитории (один репозиторий — это процесс? область управления? вообще что?), как сделать так, чтобы наша база знаний выглядела в Gramax классно, а не «как-нибудь» — я понял довольно простую вещь. Команда, которая знает свой продукт и хочет сделать хорошо — если не важнее самого продукта, то как минимум так же важна. Потому что продукт можно доработать. Gramax за время нашей миграции вырос — его реально доработали под нас, и он стал лучше. А вот «дорастить» команду со стороны вендора — почти невозможно. Если её там нет, нет и шанса.

Конкретно я это понял в двух точках. Первая — конференц-колл, на котором мы выбирали инструмент. Был я, Максим, и несколько команд разных продуктов. Мы тогда познакомились с Екатериной. После звонка я сказал Максиму: «Это самая адекватная команда из всех, кого мы посмотрели». Был интерес к нашей задаче — не «расскажите подробнее, мы потом подумаем», а нормальное разбирательство. Вторая — наш тимбилдинг летом. Я пригласил Катю. Хотел понять, как она вольётся, проникнется ли тем, что мы делаем. В рекрутинге это называется «культурный матч». Он случился. Я понял: с этими людьми можно работать вдолгую.

Сейчас, к слову, Екатерина вступила в команду авторов РИТМ и пишет два процесса. Мы пошли по стопроцентному варианту «вендор-партнёр».

• Вижу прогнозируемую пулю в комментариях: «А почему не стандартный git-flow, придумали новое».

• Ответ: схема была. Git-flow для документации — не бог весть какая инновация. Ценность была в команде, которая помогла вписать эту схему в нашу реальность 100 с лишним волонтёров. Без этого получилась бы красивая теория и третий брошенный инструмент.

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

Три ветки, три портала, одна реальность

Сегодня у каждого процесса РИТМ — отдельный git-репозиторий с тремя постоянными ветками. Это, наверное, лучше один раз показать, чем долго описывать:

Почему именно три? Потому что у нас именно три состояния работы. Есть пространство только для команды авторов — это private. Есть раннее пространство для членов itSMF — это beta. И есть то, что мы готовы показывать всему миру, — public. Так получилось три портала чтения.

Был ли соблазн добавить четвёртую — для отрасли, или для стартапов, или для финтеха? Архитектурно мы это предусмотрели: если когда-нибудь нужны будут отдельные «диалекты» РИТМ — для нефтехимии или для финтеха — это решится новой веткой. Просто пока такой потребности нет. Чаще, наоборот, просили поменьше.

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

Прежде чем рассказать про задачи, важная штука про git. private, beta, public живут параллельно и не мешают друг другу. Любая компания может клонировать репозиторий и получить корпоративный форк с сохранением связи с эталоном.

Как устроена работа: задача → ветка → MR → автозакрытие

Точка входа — Аврора. Автор приходит туда, создаёт задачу на документирование и заполняет три простые штуки: исходную ветку (чаще всего private), целевую ветку (если та же — будет временная ветка под задачу, если beta — это уже запрос «отрелизить») и согласующих, которыми может быть кто-то из команды авторов или Архсовет.

Форма создания задачи на документирование

Под капотом, как любит говорить Максим, никакой магии нет. Просто интеграция Авроры с git по REST API. Аврора создаёт ветку, но не сразу при создании задачи, а только когда автор первый раз открывает её в редакторе Gramax. Это специально — чтобы не мусорить ветками для задач, до которых никто никогда так и не дошёл. Имена веток — task-123 — придумал Максим. Уникальность уже обеспечена номером задачи, велосипед изобретать незачем: знаешь номер задачи — знаешь номер ветки, и наоборот.

Дальше автор работает в Gramax: правит markdown в визуальном редакторе, нажимает «Опубликовать» — под капотом сommit и push.

Визуальный редактор для авторов

Когда задача готова, переводит её в Авроре в статус «На согласование» — Аврора автоматически создаёт MR с указанными согласующими. Согласующий видит у себя на стартовой странице задачку, переходит в Gramax на ветку с MR, видит сам процесс. Может комментировать прямо в тексте. Может вносить мелкие правки. Видит сам MR с галочкой «Согласовано». А ещё — видит diff с любой версией. Можно по хардкору в виде сырого markdown, можно в виде уже размеченного документа. И, что важно для координации: видно, кто из согласующих сколько комментариев оставил и кто уже нажал «Согласовано».

Интерфейс согласования и комментирования

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

Интерфейс слияния

После мержа Gramax видит, что MR закрыт, дёргает Аврору по REST API, и задача в Авроре закрывается автоматически. Это нужно ради учёта вклада авторов через коммиты. Среднее время согласования — одна-две недели, в самом жёстком случае — три недели или месяц.

В Wiki, кстати, задачки почти не работали. То есть в продукте они формально были, но без покупки отдельного модуля даже фильтрации по спринтам, командам или процессам не было — был сплошной список, который я честно пытался освоить, но довольно быстро сдался. Поэтому переход в схему «единый flow: Аврора → задача → Gramax → MR → автозакрытие» оказался реальным апгрейдом.

От красивой схемы к гибридной

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

А потом ко мне пришёл Олег Скрынник — владелец РИТМ.Производство, одной из самых активных команд. И сказал, дословно: «Пожалуйста, можно мы больше никогда не будем работать с задачами, а просто все будем работать в private?» Парадокс в том, что Олег и его команда — те, кто в основной работе ближе всего к нормальному git-флоу. Видимо, на работе от этого устал, и тут попросил отдохнуть.

Что произошло на самом деле? Мы три недели подряд на статусах половину времени тратили на то, чтобы решить конфликты, объединить разные ветки одной задачи и собрать комментарии. Потому что люди путались с ветками. Они открывали процесс не через задачу, а через портал на чтение. Тыкали на плиточку — открывался процесс в той ветке, которую они смотрели в прошлый раз. Не факт, что нужно было её и редактировать. Они правили какую-то другую ветку и говорили: «Я там всё посмотрел, всё прокомментировал». Другой человек этого не видел. Или наоборот: «Я по всем комментариям отработал» — а кто-то комментарии оставлял в третьем месте, видит, что они без ответа, и обижается.

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

Мы пошли в сторону удобства. Сейчас у нас гибрид. Кому удобно через задачи — работают через задачи (например, «РИТМ.Операции», самая дисциплинированная команда — у них всё через задачи). Кому неудобно — работают как с классической базой знаний, только надо периодически делать pull/push. Всем членам команды РИТМ выдали права на редактирование всех процессов в private. Глоссарий — особняком: он один на всю команду, его согласовываем строго через задачи, чтобы не превратить в анархию.

Что меня в этом гибриде уравновешивает? Во-первых, люди вменяемые и понимают, что делают. Во-вторых — сам git. Это то, чего у нас никогда не было в Wiki:

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

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

Жизненный цикл: кто решает, что готово

Как вы уже поняли, рабочая версия для авторов — private. Дальше процесс идет в beta, а из beta в public.

Из private в beta:

Решение «выпускать в beta» принимает Архсовет — это четыре человека: Евгения Весницкая, Всеволод Шадрин, Илья Панкратов, Антон Боганов. После того, как команда авторов договорилась внутри своей области управления и передала на согласование в Архсовет.

В beta процесс должен «отлежаться»: мы собираем обратную связь от экспертов, выдерживаем паузу. Если ничего критичного — выпускаем.

Комментарии рецензентов из beta возвращаются в private несколькими путями. Если рецензент готов работать в Gramax — редактирует и комментирует напрямую, авторы видят. Если не готов — выгружаем в Word, там есть нормальная функция комментирования. Назад — не вручную: AI-агент распознаёт комментарии в Word, знает разметку Gramax и автоматически переносит правки в git. Но про агентов чуть ниже.

Из beta в public:

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

AI и его место

Я не просто так похвастался «медалькой» руководителя AI-офиса в Naumen. Я был бы не я, если бы не попытался автоматизировать рутину с помощью агентов.

Кейс 1. Вычитываем

Пока далеко не ушли от порядка выпуска версий процессов.

Перед выходом процесса из beta в public есть автоматизированный чек-лист — больше ста критериев на каждый из шести разделов процесса. Эти критерии теперь проверяет AI-агент: запускает процесс проверки готовности, выдаёт отчёт. Это не заменяет человеческую экспертную вычитку. Это грубый фильтр — связи между процессами, требования к форматированию, англицизмы, согласованность по ролям, терминам и объектам управления. Чтобы разгрузить экспертов и согласующих от проверки очевидного.

Напомню, что процессов у нас 120, а Архсовет — 4 человека. Такая автоматизация освободила нам около 2-4 часов на каждый процесс. Считаю, это крутой результат.

Кейс 2. Склеиваем развалившееся

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

Конкретный кейс — процесс «8.3 Анализ и проектирование», область управления «Производство продуктов и услуг». Было четыре разых ветки процесса, которые надо было свести в одну, причём так, чтобы не потерялись комментарии и не перезатёрлись чужие правки. Раньше я бы выделил под это пару вечеров, налил кофе и приготовился страдать.

Я подключил агента к git-хранилищу РИТМ. Я пользуюсь Claude Code, поэтому сделал скилл, который знает разметку Gramax — а это не классический markdown, у Gramax свои расширения для онлайн-комментариев. Дальше AI-агент спокойно зашёл в git, нашёл историю коммитов по веткам, сам сопоставил комментарии, нашёл потерянные по истории. Я работал в полуавтоматическом режиме: смотрел, что предлагает, корректировал.

Кейс 3. Пишем с нуля

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

Был черновик в Wiki. Был воркшоп — наш «Синхродень», где команды согласовывают входы-выходы-роли между процессами. Мы обсудили процесс под запись, я провёл исследование лучших практик — Agile, Scrum, SAFe. Транскрипцию и результаты отдал нашему AI-агенту, который знает принципы РИТМ и другие наши процессы. Он выдал первую черновую версию сразу в Gramax-разметке. После этого мы снова обсуждали под запись, снова отдавали транскрипцию в AI-агент, получали новую версию. Три итерации. Практически ничего не было написано руками — но три методолога погружались, вычитывали, обсуждали каждую итерацию. Это не нейрослоп. Это когда инструмент берёт на себя оформление и проверку соответствия стилю, а человек — содержание и смысл. И AI-агент сам себя контролировал по нашим критериям проверки процесса. Сейчас этот процесс ждёт выпуска в beta.

Ради таких сценариев (в том числе) и выбирался Docs as Code.

Как итог

Вот что я понял не сразу — и что мне теперь хочется записать одной фразой большими буквами на всех своих ноутбуках.

Три ветки не создают сложность. Они её проявляют.

В любой Wiki уже существуют несколько версий правды. Просто они не оформлены: черновики живут в голове автора, устаревшие страницы пылятся «надо бы обновить», копии разъехались по Word-файлам для согласования, скриншоты застряли в чатах, комментарии оставлены курсивом в тексте, потому что объекты-комментарии теряются. Wiki не показывает этого. Она делает вид, что правда одна.

Docs as Code не добавляет хаос. Он делает существующий рассинхрон видимым и управляемым.

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

Сложности авторов: ТОП-3

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

• BPMN и git плохо дружат. В Gramax есть Draw.io, и для типовых задач этого хватает. Но XML-диаграммы плохо мержатся, а нативной интеграции с BPMN-системами — то есть с системами, в которых процесс реально управляется схемой, а не просто отрисовывается, — пока нет. Костыль для тех, кто живёт в Бизнес-Студио, — экспорт в SVG. Не катастрофа, но и не то, чего хочется.

• Кривая обучения. Это нетиповой продукт, и большинство привыкло к Confluence или Wiki. Нужно ментально перестроиться: pull, push, commit, разные ветки. Дольше всех учились те, кто привык работать в Word и обмениваться файликами. Им и в Wiki было тяжело, и в Gramax тяжело — просто потому что дело не в инструменте, а в операционной модели работы с документами.

• Права доступа. В git нельзя дать доступ к отдельному файлу — только к репозиторию или ветке. Это fine-grained access control, которого в Confluence, например, из коробки больше. Мы его компенсировали через ветки и порталы, но это не то же самое.

Кто стал адвокатом подхода быстрее всех? Я. Причём, наверное, ещё до того, как мы реально мигрировали — я первым влюбился в Docs as Code. После меня — те, кто больше всего терял комментариев в Wiki и кому не нравился сам редактор Wiki. И самый медленный, «слоупочный» вопрос, который я регулярно слышал ещё через полгода после миграции, звучал так: «А в Wiki нам недоступно. Я смотрю в Wiki, там старая версия процесса». Через полгода. После миграции. Полгода!!!

Что в роадмапе и что болит сейчас

Болело раньше — отсутствие кросс-ссылок между репозиториями. Каждый процесс — отдельный репозиторий, и сослаться с одного процесса на другой автоматически было нельзя. Эту боль Gramax под наш запрос доработал. Сейчас работает.

Болит сейчас — комментирование без прав на редактирование. На порталах для чтения (beta, public) сейчас, чтобы оставить комментарий, нужно иметь права на редактирование. Хочется наоборот: читатель может комментировать, авторы это видят. Это доработка, которую мы ждём сильнее всех остальных (к лету-осени). И интеграция с BPMN-системами, не так горячо, но в списке.

Самое горячее в роадмапе на 2026-й — LLM-ассистент поверх РИТМ. И вот тут позвольте я приоткрою завесу.

РИТМ — это базис. Мы создаём его с пониманием, что какие-нибудь книжки толщиной с ITIL никто читать не будет. Даже отдельные регламенты процессов — никто не будет читать. Не то время, не то поколение работников. Поэтому нам нужен ассистент, который знает базу РИТМ и может, опираясь на неё, проконсультировать конкретного человека в его контексте. Подсказать, как описать процесс. Найти ближайший аналог. Указать на противоречие. Docs as Code даёт датасет, готовый к RAG из коробки.

На что не хватает рук или денег — на выверку схем процессов. Чтобы все диаграммы выглядели единообразно. У нас пишут волонтёры, и иногда это выглядит как «письмо из Простоквашино» — очень разные авторские стили. Хочется привести к одному визуальному языку, но это руки, которые пока заняты другим.

А мечта на три года звучит так:

Я хочу, чтобы РИТМ стал первой методологией, которая развивается по принципам open-source софта прямо в git.

Сейчас есть методологии, которые развиваются сообществом, но процесс предложения изменений в них непростой. Я хочу, чтобы обратная связь и улучшения могли быть оставлены сообществом методологов очень просто — pull request к процессу, обсуждение, мерж. И чтобы РИТМ стал стандартом де-факто в отрасли и заменил ушедшие западные методологии. На цели, как видите, не жалуюсь.

Если хочется попробовать у себя — минимальный пилот

Если эта история отозвалась — вот что я бы сделал на вашем месте, прежде чем разворачивать что-то большое.

Заведите git-репозиторий для одного вашего регламента. Создайте две ветки: рабочую и чистовую — это ваша минимальная «управляемая множественность», ради которой всё это начинается. Проведите первое ревью как merge request, с комментариями и утверждением. Напишите мне и я покажу, как это выглядит на масштабе, а архитектуру всей методологии можно посмотреть на публичной доске Miro — там сотовая модель РИТМ с девятью областями управления.

Если хочется попробовать инструменты руками — gram.ax можно скачать и сделать первое локальное хранилище за вечер; itsm365.com — это база, на которой собрана наша Аврора (можно запросить триал). И, конечно, я приглашаю в РИТМ ritm.digital. Если зацепит — пишите.

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

P.S. Ответ скептику

Главный комментарий, которого я под этой статьёй жду:

Ребята, да вы изобрели велосипед. Всё это уже было решено, всё это можно сделать другими инструментами, каким-то другим подходом

Можно. Нашу задачу можно было решить и не Docs as Code, а стандартной базой знаний. И ещё парой-тройкой способов. Но мы пошли тем путём, которым пошли. И, что важно, остались довольны.

Я делюсь не «единственно верным решением», а одним из возможных. Если у вас несколько версий документации, если вам надо итеративно организовать разработку с разной скоростью команд, если вы хотите плотно применять AI для поиска и проверки качества — посмотрите в сторону Docs as Code. В таких случаях он работает.

И ещё один комментарий, на который мне будет приятно ответить:

В чём, собственно, разница подхода Docs as Code и классического Confluence-подхода к базе знаний?

Разница — в готовности явно управлять несколькими правдами вместо одной.