Недавно CNews опубликовал ежегодный обзор «Рынок ИТ: итоги 2025». Один из его главных выводов — российский ИТ-рынок переходит от срочного импортозамещения к более осознанному выбору: заказчики оценивают уже не только происхождение решения и наличие основных функций, но также его устойчивость, безопасность, возможности интеграции и экономический результат.
В системах документации происходит примерно то же самое.
Несколько лет назад перед российскими компаниями стояла срочная задача: отказаться от зарубежных систем, сохранить документацию и не остановить работу команд и поддержку клиентов. Кто-то перенёс материалы в российскую базу знаний, кто-то — в Git и статический генератор, кто-то собрал собственное решение из нескольких инструментов. Во многих случаях главная задача была выполнена: страницы сохранились, доступ к ним восстановили, публикацию запустили.
Теперь компании оценивают уже не сам факт перехода, а качество получившейся системы:
- успевает ли документация за развитием продукта;
- можно ли поддерживать несколько версий без копирования;
- сколько ручной работы осталось вокруг публикации;
- могут ли в работе участвовать не только технические писатели;
- готова ли документация стать надёжным источником для искусственного интеллекта.
И здесь выясняется, что перенести контент гораздо проще, чем перенести весь процесс работы с ним.
Первая волна решала другую задачу
Решения, принятые в условиях срочного импортозамещения, не стоит оценивать по сегодняшним требованиям.
На первом этапе было важно:
- сохранить критические материалы;
- обеспечить доступ сотрудников и клиентов;
- снизить зависимость от иностранного поставщика;
- восстановить публикацию в ограниченные сроки.
При таких вводных компании закономерно выбирали самый быстрый рабочий вариант. Если документы удалось выгрузить, разместить в новой системе и снова опубликовать, проект можно было считать успешным.
Ограничения проявились позже, когда объём документации вырос, появились новые версии продуктов, изменились требования безопасности, а в работе стало участвовать больше подразделений.
Временные решения постепенно превратились в постоянную архитектуру.
Перенесли страницы, но не всегда сохранили процесс
У миграции документации есть несколько уровней.
На первом переносятся сами файлы. На втором — тексты, изображения, ссылки и структура разделов. Обычно именно на этом этапе миграцию считают завершённой.
Но в профессиональной системе документация состоит не только из страниц. В ней могут использоваться:
- общие фрагменты текста;
- переменные;
- условные блоки;
- несколько версий продукта;
- разные публикации для разных аудиторий;
- согласование и рецензирование;
- права доступа;
- автоматическая сборка.
Если эти механизмы не удалось сохранить, внешне успешная миграция быстро начинает создавать дополнительную работу.
Например, общая инструкция, которая раньше хранилась в одном месте, после переноса превращается в десять независимых копий. Исправление нужно вручную вносить во все версии, а со временем тексты начинают расходиться.
Другой распространённый сценарий — документация в Git со сложной системой сборки. Пока проект небольшой, всё работает нормально. При росте объёма появляются долгие сборки, нестабильные тесты, конфликты зависимостей и большое количество собственных скриптов.
В итоге команда тратит всё больше времени не на содержание документации, а на обслуживание способа её публикации.
Есть несколько признаков, что проблема стала системной:
- версии ведутся копированием;
- одно изменение приходится повторять в нескольких местах;
- публикация зависит от отдельных специалистов;
- сотрудники снова используют Word, PDF, Wiki и Git параллельно;
- сборка крупной документации занимает неприемлемо много времени;
- ручные обходные действия стали обычной частью процесса.
Формально система существует. Фактически единый контур снова распался.
При миграции проще всего проверить, открываются ли страницы и сохранились ли изображения. Гораздо сложнее заметить, что вместе с прежней системой исчезли переиспользование, версии и привычный порядок работы. Эти потери начинают по-настоящему мешать не сразу, а через год или два, когда растут объём документации и количество продуктов.
Разработка ускорилась, документация — не всегда
За последние годы создание программного обеспечения заметно ускорилось. Автоматизация и инструменты искусственного интеллекта позволяют быстрее делать прототипы, писать код и выпускать изменения.
Но готовый код ещё не означает, что пользователь получил ценность.
После разработки остаются:
- приёмка;
- обновление инструкций;
- обучение поддержки;
- сообщение об изменениях клиентам;
- внедрение новой возможности в реальную работу.
Функция может уже присутствовать в продукте, но пользователи не знают, зачем она нужна, не могут найти инструкцию или не понимают, подходит ли она для их задачи.
В этот момент документация становится одним из ограничений развития продукта.
Она должна объяснять не только расположение кнопок, но и пользовательский сценарий:
- когда применять функцию;
- какую задачу она решает;
- что нужно подготовить;
- какой результат должен получиться;
- какие существуют ограничения.
Меняется и состав участников. Знание о продукте распределено между разработчиками, руководителями продукта, аналитиками, поддержкой, внедрением и техническими писателями.
При этом у всех разные рабочие инструменты. Разработчику удобен Git, руководителю продукта — задачи и сценарии, поддержке — быстрые исправления, техническому писателю — структурированный контент, версии и переиспользование.
Поэтому недостаточно просто открыть всем доступ к одной базе знаний. Нужен управляемый процесс, в котором разные специалисты могут вносить свой вклад, а структура и качество документации остаются под контролем.
Роль технического писателя при этом не исчезает. Она смещается от единственного автора к архитектору контента, редактору и владельцу качества документации.
Искусственный интеллект повышает требования к источникам
Сегодня многие компании хотят подключить к документации интеллектуальный поиск или помощника, который отвечает на вопросы пользователей.
На демонстрации это выглядит просто: система получает запрос, находит подходящие материалы и формирует связный ответ.
В реальной базе знаний могут одновременно находиться:
- инструкции для разных версий;
- устаревшие страницы;
- дубли;
- противоречащие друг другу сведения;
- материалы с разными уровнями доступа.
Искусственный интеллект не исправляет эти проблемы. Он только формирует на их основе убедительно звучащий ответ.
Если документация устарела, ответ тоже будет устаревшим. Если существуют несколько противоречивых версий, результат становится непредсказуемым. Если права доступа настроены неправильно, помощник может раскрыть пользователю закрытую информацию.
Поэтому для работы с искусственным интеллектом нужны:
- единый управляемый источник;
- понятное разделение версий;
- актуальный статус материалов;
- корректные права доступа;
- возможность проверить первоисточник;
- история изменений;
- контроль публикации.
Кроме ответов на вопросы, искусственный интеллект может помогать готовить черновики, искать затронутые изменениями разделы и обновлять документацию после изменений в продукте.
Но чем больше действий ему передаётся, тем важнее становится контроль над данными и операциями, к которым он получает доступ.
Не каждая проблема требует новой миграции
Когда команда недовольна документацией, проще всего обвинить систему. Но новая платформа не исправит отсутствие ответственного, несогласованный процесс или привычку обновлять инструкции через месяц после выпуска функции.
Перед выбором нового решения стоит понять, где именно находится проблема.
Проблема в процессе
Признаки:
- никто не отвечает за актуальность;
- информация о продуктовых изменениях приходит слишком поздно;
- документация не входит в критерии готовности выпуска;
- роли участников не определены.
В этом случае сначала нужно менять правила работы.
Проблема во внедрении
Признаки:
- старая структура была перенесена без пересмотра;
- права настроены неправильно;
- разные команды работают по разным правилам;
- сотрудники не используют доступные возможности системы;
- временные решения после миграции так и не были пересмотрены.
Здесь может помочь аудит и перенастройка существующего решения.
Проблема в архитектуре системы
Признаки:
- версии создаются копированием;
- общие фрагменты нельзя переиспользовать;
- публикация зависит от множества самописных компонентов;
- нет удобного способа участия для нетехнических специалистов;
- невозможно корректно разграничить доступ для интеллектуального помощника;
- стоимость резко растёт вместе с количеством читателей;
- ограничения постоянно компенсируются ручной работой.
В таком случае уже имеет смысл рассматривать другую платформу или другой класс решений.
Что проверить в своей системе
Для первоначальной диагностики достаточно ответить на несколько вопросов:
- Выходит ли документация одновременно с обновлением продукта?
- Можно ли изменить общую информацию один раз, а не исправлять множество копий?
- Поддерживаются ли разные версии без полного дублирования?
- Могут ли разные подразделения участвовать в одном процессе?
- Понятно ли, кто отвечает за актуальность материалов?
- Остаётся ли публикация стабильной при росте объёма?
- Соответствует ли система требованиям ИТ и информационной безопасности?
- Можно ли безопасно использовать документацию как источник для искусственного интеллекта?
- Не компенсирует ли команда ограничения платформы постоянными ручными действиями?
Один отрицательный ответ ещё не означает, что пора переезжать. Но если одни и те же проблемы повторяются в разных продуктах, версиях и подразделениях, речь, вероятно, идёт уже не о локальном неудобстве.
Вторая волна импортозамещения — не про то, чтобы снова всё перенести. Сначала нужно определить, где находится ограничение: в рабочих процессах, в неудачном внедрении или в архитектуре самой системы. Только после этого можно понять, действительно ли компании нужна новая платформа.
Следующий этап — зрелость процесса
Первая волна импортозамещения отвечала на вопрос:
Как сохранить документацию и продолжить работу без зарубежного поставщика?
Теперь вопрос звучит иначе:
Как построить процесс, который успевает за продуктом и может развиваться следующие несколько лет?
Для этого уже недостаточно просто хранить страницы в российской системе.
Документация должна:
- обновляться вместе с продуктом;
- поддерживать несколько версий и аудиторий;
- позволять переиспользовать общую информацию;
- объединять работу разных подразделений;
- снижать нагрузку на поддержку;
- помогать пользователям осваивать новые возможности;
- безопасно использоваться в системах искусственного интеллекта.
В Документерре мы развиваем платформу именно с учётом этих задач: поддерживаем переиспользование и условный контент, совместную работу разных ролей, интеграции и контролируемое подключение инструментов искусственного интеллекта.
Но начинать оценку текущей системы стоит не со списка функций и не с новой сравнительной таблицы.
Сначала нужно понять, где именно возникло ограничение: в процессе, внедрении или архитектуре.
Первичная миграция была в первую очередь про технологическую независимость. Следующий этап — про зрелость.
ЧаВо
Первая волна решала задачу физического переноса: перенести документы, восстановить доступ, не остановить публикацию. Вторая волна оценивает не сам факт переноса, а качество получившегося процесса — успевает ли документация за продуктом, можно ли поддерживать версии без копирования, сколько ручной работы осталось вокруг публикации.
Стоит разделить три уровня: процесс (никто не отвечает за актуальность, роли не определены), внедрение (старая структура перенесена без пересмотра, права настроены неправильно) и архитектуру (версии создаются копированием, публикация зависит от самописных компонентов). Проблемы первых двух уровней решаются пересмотром правил и аудитом. Проблема на уровне архитектуры обычно требует другой платформы.
Не обязательно. Один отрицательный ответ на диагностические вопросы ещё не повод для переезда. Сигнал появляется, когда одни и те же проблемы повторяются в разных продуктах, версиях и подразделениях — тогда речь уже не о локальном неудобстве.
Единый управляемый источник, понятное разделение версий, актуальный статус материалов, корректные права доступа и возможность проверить первоисточник. Без этого ИИ не решает проблемы устаревшей или противоречивой документации — он их усиливает, потому что формирует убедительный ответ на основе того, что есть, даже если это ошибка или закрытая информация.
Платформа поддерживает переиспользование контента и условный контент, совместную работу разных ролей и контролируемое подключение инструментов ИИ — то есть закрывает именно архитектурный уровень зрелости, о котором речь в статье.
