Кейс CRM-платформы «Модус»: уходим из Confluence в Docs as Code
Всем привет, я Катя, развиваю Gramax. Недавно мы поговорили с командой CRM-платформы «Модус» от ИТ-холдинга Т1 о переходе из Confluence в Docs as Code.
На Хабре уже вышла подробная версия этой истории, а здесь хочу оставить более короткий разбор: в чем была продуктовая боль, почему одного Git оказалось бы мало и какую роль в переходе сыграл Gramax.
Если совсем кратко: команде нужно было перестать собирать документацию отдельным ручным процессом после релиза. Документация должна была версионироваться вместе с продуктом, поставляться рядом с ним и оставаться доступной для авторов, которые не живут каждый день в IDE.
Контекст
«Модус» от ИТ-холдинга Т1— платформа для автоматизации бизнес-процессов взаимодействия с клиентами. У продукта есть регулярные релизы, несколько крупных бизнес-модулей и пользовательская документация, которую получают заказчики и партнеры: руководства пользователя, руководства администратора, инструкции, технические материалы.
Основные авторы пользовательской документации — аналитики. Именно они лучше всех знают сценарии, ограничения и поведение системы. Но старый процесс был завязан на Confluence и последующую ручную сборку материалов.
На практике это выглядело так:
Продукт поставляется отдельно
Документация живет отдельно
Под нужного заказчика нужно выгрузить правильные страницы
Затем собрать комплект, проверить версию и привести материалы к нужному виду
Пока продукт один и релизов немного, с этим можно жить. Но когда у разных клиентов разные версии платформы, база знаний без нормальной релизной модели быстро превращается в место, где сложно ответить на простой вопрос: «а как это работало именно в той версии?»
Почему Confluence перестал закрывать задачу
Главная проблема была не в том, что Confluence неудобен как редактор. Наоборот, многие команды любят его именно за низкий порог входа. Проблема была в другом: документация оказалась отделена от жизненного цикла продукта.
Если у одного клиента 27-й релиз, у другого 28-й, а у третьего уже 31-й, актуальная страница в базе знаний не всегда помогает. Нужен срез документации под конкретную версию. И желательно не в виде воспоминаний команды, а как воспроизводимый процесс.
Команде нужно было:
Хранить документацию в Git
Вести ее в ветках и релизах
Ревьюить изменения
Собирать портал вместе с поставкой продукта
Сохранять единые шаблоны руководств
Не заставлять аналитиков становиться разработчиками
Последний пункт оказался ключевым. Docs as Code хорошо звучит для разработчиков: Markdown, Git, merge request, история изменений. Но для аналитика это может выглядеть как набор лишних технических препятствий между мыслью и текстом.
Где в этой схеме появился Gramax
Команда смотрела разные варианты и довольно быстро столкнулась с типичной проблемой Docs as Code: технически все правильно, но автору неудобно. Нужно понимать структуру папок, пути к картинкам, синтаксис таблиц, правила ссылок и еще несколько вещей, которые не относятся к содержанию руководства.
Gramax подошел как визуальный слой поверх Git и Markdown.
Для автора это редактор, где можно создавать разделы и статьи, вставлять изображения, работать с таблицами и видеть структуру документации. Для процесса это все еще Markdown-файлы в репозитории, с историей изменений, ветками и возможностью встроиться в релизный цикл.
В этом и был основной смысл внедрения: не заменить Git чем-то более простым, а сделать Git-процесс доступным для тех, кто пишет пользовательскую документацию.
Разработчики и архитекторы при этом не теряют привычный способ работы. Кто хочет, может редактировать Markdown в VS Code или другом инструменте. Gramax не закрывает данные в собственном формате: источник остается открытым и переносимым.
Что изменилось в процессе
После перехода документация стала ближе к продуктовой поставке. Пользовательские материалы больше не нужно собирать как отдельный артефакт вручную из разрозненных страниц. Они лежат в репозитории, проходят ревью, попадают в нужную ветку и могут поставляться вместе с продуктом.
Это не отменило методологическую работу. При миграции пришлось пересмотреть структуру, отделить пользовательские материалы от внутренних, привести руководства к единым шаблонам, обновить скриншоты и убрать устаревшее.
Но в этом был полезный эффект: переезд стал не просто переносом из одного инструмента в другой, а ревизией документации. Когда материалы начинают жить рядом с релизом, становится сложнее откладывать качество «на потом».
Почему низкий порог входа важнее, чем кажется
В Docs as Code часто обсуждают Git, CI/CD, статические генераторы и формат хранения. Все это важно. Но если документацию пишут аналитики, продакты, консультанты или специалисты поддержки, успех внедрения упирается не только в архитектуру.
Люди должны иметь возможность быстро внести правку, добавить страницу, обновить картинку и не бояться сломать репозиторий.
Поэтому Gramax оказался не просто редактором Markdown. Он стал способом подключить нетехнических авторов к инженерному процессу без ощущения, что они попали на чужую территорию.
Это особенно важно для компаний, где документация не принадлежит одной выделенной команде технических писателей. Если знания распределены между аналитиками, разработчиками, архитекторами и поддержкой, инструмент должен выдерживать разные привычки работы.
Что команда получила
Коротко результат можно описать так: документация перестала быть отдельным ручным хвостом после релиза.
Что изменилось на практике:
Появилась версионность. Документацию можно привязать к конкретной версии продукта, а не только к текущему состоянию страницы.
Сократилась ручная сборка. Сбор всего комплекта занимал примерно 40 часов. Сейчас по документации платформы время на передачу сократилось примерно в 2 раза. Когда все модули переедут в Docs as Code, команда ожидает сокращение примерно до 4 часов на весь процесс.
Портал стал актуальным источником. Поддержке и пользователям проще искать ответы на едином актуальном портале.
Авторы не выпали из процесса. Аналитики получили визуальный инструмент, а технические участники сохранили привычный Git-подход.
Появилась база для дальнейшей автоматизации. Markdown в Git проще проверять, обрабатывать, публиковать и использовать как корпус знаний для поиска и ИИ-сценариев.
Последний пункт для нас особенно важен. ИИ плохо работает поверх хаотичной базы знаний: где-то Word-файлы, где-то страницы в вики, где-то устаревшие копии и внутренние ссылки. Когда документация хранится в едином формате, имеет историю изменений и связана с релизами, поверх нее уже можно строить более надежный поиск, проверки и агентные сценарии.
Что важно вынести из этого кейса
Переход в Docs as Code — это не только Markdown и Git. Это смена статуса документации.
В старой модели документация часто существует как сопровождающий материал: ее собирают после, отправляют отдельно, обновляют по необходимости. В новой модели она становится частью продуктовой цепочки. Релиз, документация, ревью и поставка начинают двигаться в одном процессе.
Но чтобы эта модель заработала, недостаточно сказать команде: «теперь все пишем в Git». Нужен вход для разных авторов. Нужны шаблоны, понятная структура, ревью и инструмент, который не заставляет человека думать о синтаксисе каждый раз, когда он хочет описать пользовательский сценарий.
Для «Модус» Gramax стал именно таким мостом: между Confluence и Git, между аналитиками и Docs as Code, между удобным редактированием и инженерной версионностью.