120 процессов, девять областей управления и больше 100 авторов из 60 с лишним компаний оказались для Wiki той самой нагрузкой, после которой «простой инструмент» внезапно становится дорогим. Проект РИТМ, открытая «Рациональная ИТ-методология» под эгидой itSMF России, перевёл свою базу знаний на Docs as Code и Git, потому что старая схема перестала выдерживать ни параллельную работу, ни выпуск сразу нескольких версий документов.
Об этой миграции сообщает Habr / Менеджмент в блоге Gramax. Речь идёт не о косметической замене редактора, а о перестройке процесса для большой распределённой команды: в проекте участвуют специалисты из Сбера, «Газпромнефти», «Норникеля», Softline, «Яндекса» и других компаний, а сами материалы пишутся в значительной степени на энтузиазме, вечерами, без отдельного инфраструктурного бюджета. В такой модели любой сбой в инструменте быстро превращается в потерянные часы десятков людей.
Парадокс в том, что на старте Wiki была вполне разумным выбором. В конце 2023 года у РИТМ было 16 участников и девять процессов. При таком масштабе не было смысла строить тяжёлую систему с репозиториями, ветками и объяснениями методологам, зачем им feature-branch и merge request. Wiki давала ровно то, что нужно молодой инициативе: один источник правды, быстрый вход, минимум инфраструктуры. Проблемы начались позже, когда проект вырос и у документов появилось больше одного состояния.
Ключевой перелом случился с появлением beta-версий. До этого у команды фактически было два режима: черновик и актуальная публикация. Потом добавилось третье состояние: то, что ещё дорабатывается, и то, что уже нужно показывать ограниченной аудитории. В Wiki такая логика быстро расползается. Если переносить процесс в отдельный раздел для беты, ломаются ссылки на связанные материалы. Если копировать страницы, появляются дубликаты с разъезжающейся историей правок. А когда процессов уже 120, следить за целостностью ссылок вручную можно только при очень сильной любви к боли.
Ещё неприятнее выглядела повседневная совместная работа. По описанию автора кейса, при одновременном редактировании тремя-пятью участниками комментарии в Wiki могли пропадать, один автор мог перезаписать изменения другого, а нормального сравнения версий между «вчера» и «сегодня» не было. В результате команды начали обходить сам инструмент. Комментарии стали оставлять прямо в тексте, курсивом и в скобках, чтобы их хотя бы не потерять. Часть согласований переехала обратно в Word и почту: страницу выгружали, собирали правки по письмам и потом вручную заносили всё назад. Для документационного контура это худший сигнал из возможных: пользователи уже не спорят с системой, а просто строят параллельную инфраструктуру у неё за спиной.
Окончательно иллюзии добила история осени 2025 года, когда проект временно потерял доступ к облачной Wiki из-за пропущенного счёта на оплату. Не только на запись, но и на чтение. Для базы знаний, в которую полтора года вкладывались более 100 авторов, это уже не бытовая накладка, а напоминание о зависимости от одной платёжки и одного человека, который мог не заметить письмо. После этого команда вернулась к тому варианту, который раньше считала избыточным, и выбрала Docs as Code на базе Gramax.
Новая схема устроена ближе к разработке, чем к классической корпоративной документации. У каждого процесса теперь отдельный git-репозиторий и три постоянные ветки: private для рабочей версии команды авторов, beta для согласованного, но ещё не публичного варианта, и public для релиза, который виден всем. Поверх этого работает цепочка «задача - ветка - merge request - закрытие». Задачи живут в личном кабинете автора «Аврора», который собран на базе ITSM 365; ветка под задачу создаётся не заранее, а в момент первого открытия в Gramax, чтобы не плодить мусор. Сам Gramax здесь выступает как визуальный редактор поверх Git: автор правит markdown в WYSIWYG-интерфейсе, нажимает «Опубликовать», а commit и push происходят под капотом. Для методологов это важная деталь: Git остаётся в системе, но не становится обязательным предметом для ежедневной борьбы.
Важно и то, что переезд не представлен как история про мгновенное счастье после внедрения модного подхода. Часть ожиданий у команды не сбылась, а часть проблем приехала в новом виде. Например, Gramax пришлось дорабатывать под автоматические ссылки между отдельными репозиториями процессов. По словам авторов, одной из самых нужных функций остаётся комментирование на порталах чтения без прав на редактирование: сейчас, чтобы оставить замечание к версии beta или public, пользователю всё ещё нужны редакторские права. В планах также интеграция с BPMN-системами, а самым горячим пунктом дорожной карты на 2026 год назван LLM-ассистент поверх корпуса РИТМ.
Для русскоязычной IT-аудитории эта история интересна не только как кейс про документацию. Она хорошо показывает, где заканчивается магия «давайте возьмём что попроще». Пока команда маленькая, Wiki действительно быстрее и дешевле. Но когда появляются версии, сложные связи между артефактами, много авторов и необходимость прозрачного согласования, цена простоты начинает расти быстрее, чем цена формального процесса. В этом смысле миграция РИТМ выглядит не как спор Wiki против Git, а как вполне взрослый вопрос архитектуры знаний: в какой момент документация перестаёт быть набором страниц и становится полноценной системой разработки контента.