30 дней из жизни архитектора контента: проверяем теорию практикой

Всем привет!

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

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

Изменение структуры контента в базе

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

Посоветовавшись на совещании архитекторов, мы решили, что пора разрешить несколько уровней вложенности папок в базе. Сортировка по наименованию раздела и типу статьи (например: раздел-статья, раздел-инструкция, FAQ, release notes) позволила увидеть повторяющийся контент и настроить заимствования. На это мы потратили около одной недели, пересмотрев вручную более 30 тысяч разделов.

Кроме того, мы создали отдельные папки для новых разделов и договорились, что архитекторы будут регулярно их сортировать — раз в полгода-год. Это позволит авторам сэкономить время на этапе подготовки и сосредоточиться на смысле текста, а не на вопросах классификации.

Регулярные проверки контента

Review Workflow

Review Workflow — это автоматизированный процесс проверки, комментирования и согласования технического контента экспертами. Главная задача этого процесса вычитки — связать технических писателей с профильными специалистами (редакторами, тестировщиками, аналитиками, разработчиками, продуктовыми менеджерами) без бесконечной пересылки файлов по электронной почте и обмена комментариями в тикетах.

Раз в год мы обновляем workflow, чтобы сделать процесс вычитки максимально прозрачным и избавить команду от лишней ручной работы. По окончании работ над очередным улучшением сценария мы описали изменения в базе знаний. Теперь уведомления стали гораздо информативнее: сотрудники сразу видят горящие дедлайны и комментарии, а важные файлы можно прикрепить прямо к письму, не теряя контекст обсуждения. Мы также серьезно исправили подсчет статистики: система учитывает только нужные разделы и игнорирует те разделы, которые одобрил их автор, чтобы отчеты о покрытии контента вычиткой не искажали реальную картину. Все изменения в комплексе экономят время команды и значительно снижают риск ошибок при передаче задач.

Всего было проведено около 25 улучшений, на которые ушло чуть больше двух недель работы. На обновление инструкций в базе знаний, на их проверку, на подготовку демо для авторов и ее проведение ушло около трех рабочих дней.

Проверка использования переменных в тексте разделов

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

Чтобы авторы не забывали использовать переменные, мы разработали воркфлоу, позволяющий автоматически создавать задачи на обработку разделов документов, в которых явно указывается название продукта или компании вместо использования переменных.

Работы по созданию воркфлоу заняли 16 часов. В результате при первом прогоне было обнаружено около 928 разделов документов, в которых названия продуктов и компании были написаны вручную. Ежемесячно при повторном запуске этого workflow создается от 5 до 20 задач на авторов на исправление контента.

Настройка публикации

Новые типы документов

В Positive Technologies помимо публичного портала help.ptsecurity.com работает внутренний портал, доступный только сотрудникам. Это портал — единая точка входа для загрузки документации по продуктам. 

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

В это месяце мы добавили в систему девять новых типов документов. На настройку каждого типа ушло от 5 до 10 минут.

Сейчас на внутреннем портале доступно около 5000 документов на разных языках.

Переменные

В нашей системе управления контентом переменная представляет собой динамический текстовый объект, который создается один раз и централизованно подставляется в текст или графику. При публикации документа система автоматически заменяет имя переменной на конкретное значение в зависимости от выбранного варианта продукта. Значения переменных хранятся в специальных таблицах. Каждая строка такой таблицы обычно соответствует определенному варианту продукта (версии, конфигурации), а столбцы — переменным.

Мы используем переменные в тексте, чтобы гарантировать единообразие наименований (например, продуктов, модулей, компонентов) во всех материалах, а также чтобы обновлять данные в одном месте, а не править каждый документ отдельно. Это экономит команде несколько часов ручной работы в тех релизах, где требуется изменить названия. А еще это позволяет нам повысить процент повторного использования текста, что в свою очередь снижает трудозатраты на редактуру и перевод.

В рассматриваемый нами период в переменные с именами продуктов и названиями компании мы добавили несколько новых значений. Значения переведены на все языки, на которых у нас есть справочный контент. Всего за месяц мы выполнили 4 такие задачи, потратив в среднем на каждую по 45 минут.

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

Управление жизненным циклом контента

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

Таксономия

Таксономия в нашей CMS представляет собой иерархию метаданных для классификации, фильтрации и поиска контента. В контексте мастер-проектов таксономия обеспечивает автоматическое исключение нерелевантных блоков в процессе публикации. Например, данный подход применяется при генерации EULA, где доля переиспользуемого текста составляет около 97%, а вариативная часть — не более 3%. 

Версионная таксономия позволяет четко разграничивать актуальные материалы и устаревшие версии, чтобы пользователи не запутались в обновлениях. За месяц было выполнено 11 задач на добавление такой таксономии. 

На создание каждого элемента таксономии у архитектора контента уходит не более пяти минут, при этом автор экономит часы на подготовке контента к свежему релизу продукта.

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

Регулярные архитекторские проверки

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

Администрирование

Управление пользователями и их правами

За месяц в систему мы добавили несколько новых пользователей: предоставили лицензии, назначили группы пользователей, и соответственно выдали права на различные объекты в нашей системе документирования.

Сейчас в Positive Technologies в подготовку технической документации вовлечено около 320 сотрудников: 23 технических писателя, 5 редакторов, 11 инженеров по локализации и около 280 ревьюеров и авторов других подразделений.

Обновление системы

Помимо плановой работы, нам пришлось реагировать на внешние изменения. Вендор выпустил обновление нашей системы управления контентом. Мы развернули и проверили обновление в тестовой среде и приняли решение не переходить на новую версию из-за наличия критически значимого бага, связанного с публикацией контента.

Тестирование обновления заняло около четырех рабочих дней.

Прочие задачи

Мы настроили публикацию «Политик поддержки версий ПО». Эти документы уже доступны на справочном портале в веб-формате и PDF (например, для MaxPatrol VM: https://help.ptsecurity.com/ru-RU/projects/vm/common/eos). Также мы занимались настройкой вывода проектной документации по ГОСТ, устраняли ложные срабатывания автоматических проверок контента (добавили исключения для специфичного контента: теперь команда реагирует только на реальные нарушения, а время на подготовку контента сократилось) и мониторили нагрузку на систему. Кроме того, реализовали возможность создания перекрестных ссылок между справками разных продуктов Positive Technologies и актуализировали ряд статей во внутренней базе знаний.

Рассмотренные в статье задачи — это пример за месяц, но у нас возникают и другие задачи, которые не раскрыты в этом материале.

Всего за месяц командой архитекторов контента было выполнено 104 задачи. По показателям трех последних лет в среднем за квартал мы успеваем сделать около 170 задач.

Каждый из архитекторов контента уделяет на профильные задачи примерно 25—40% рабочего времени, остальное время мы занимаемся подготовкой технической документации в рамках проектов. 

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

Вывод

Все описанные ключевые задачи месяца я свела в одну таблицу для наглядности. Ниже видно, сколько времени ушло на каждое направление работы.

За месяц мы потратили на задачи архитекторов контента около 220 часов. В среднем каждый из нас уделял этой работе почти треть времени — 32% (примерно 54 часа).

Как видите, работа архитектора не ограничивается только структурой базы контента. Архитектор контента решает проблемы любого уровня: от видимой пользователю части до внутреннего устройства системы документирования. Мы выступаем и как технические специалисты, настраивающие инструмент, и как хранители стандартов, и как стратеги, связывающие продукты в единую экосистему. Такое разнообразие требует постоянной гибкости и широкого кругозора. Это подтверждает, что роль архитектора находится на стыке управления контентом, разработки и системного проектирования.