Для доступа к материалам доклада
купите билет
или авторизуйтесь, если у вас он уже есть
или авторизуйтесь, если у вас он уже есть
7 ошибок в проектировании базы знаний
26 февраля
17.40-18.20
Технические писатели
Когда я разрабатывала базу знаний с нуля, я прошла путь от красивых шаблонов, которые никто не использует, до автоматизаций, которые добавляют ручного труда. В докладе я расскажу о 7 ошибках, которые совершила при проектировании базы знаний, и поделюсь рабочими решениями.
Доклад будет полезен техническим писателям, контент-редакторам, владельцам баз знаний, продакт-менеджерам внутренних инструментов и всем, кто заинтересован в разработке и поддержке корпоративных баз знаний.
1. Делать сложные шаблоны
Ошибка: шаблоны получаются слишком «технологичными» или декоративными — их заполняют с усилием или вовсе игнорируют.
Что происходит: авторы тратят время не на контент, а на борьбу со структурой.
Решение: проектировать минимально рабочий шаблон для пользователей, работающих с вики-системой на базовом уровне. «Не превращайте шаблон в фреймворк.» (с) ChatGPT
2. Красота в ущерб универсальности
Ошибка: стремясь к визуальной выразительности, мы усложняем жизнь машинам.
Что происходит: разноцветный текст и ручные стили не добавляют смысла, но при экспорте плодят метаданные, ломают бэкапы и миграции.
Решение: пересмотреть стайлгайд в части форматирования и учесть совместимость форматов при интеграциях и выгрузках.
3. Автоматизация ради автоматизации
Ошибка: мы автоматизируем каждое действие, даже там, где проще вручную.
Что происходит: «умные» процессы добавляют ручного труда. Например, при создании задачи на техписа автоматически генерируется название, в котором делается mention проекта. Но зачастую задача не привязана к проекту — как итог, название приходится переписывать вручную.
Решение: детальнее прорабатывать пользовательские сценарии при проектировании автоматизаций, потому что не всегда реальный процесс соответствует «канону» или «здравому смыслу».
4. Дробить большой документ на мелкие
Ошибка: кажется, что в век клипового мышления короткие статьи воспринимаются легче.
Что происходит: пользователи теряются в однотипных названиях, устают кликать и ждать загрузку страниц. Люди любят CTRL + F, а не бесконечные переходы.
Решение: оставлять единый документ с якорями и оглавлением. Определить критерии деления больших статей на более мелкие.
5. …А потом объединять и ломать ссылки
Ошибка: после объединения мелких документов в один большой база превращается в минное поле битых ссылок.
Что происходит: старые ссылки расползаются по чатам, тикетам, закладкам — отследить все упоминания и заменить старую ссылку на новую становится невозможно.
Решение: действовать превентивно и перед объединением или разбиением анализировать используемость документа. Если изменения неизбежны — информировать коллег (анонсы в чатах, редиректы на старых страницах, обновление ссылок в ключевых источниках).
6. Не собирать метрики
Ошибка: нет точки А, относительно которой можно замерить эффект от изменений в базе знаний.
Что происходит: невозможно доказать пользу изменений, определить приоритеты и разговаривать с бизнесом на языке цифр.
Решение: определить ключевые метрики и отслеживать их с некоторой периодичностью (чем раньше — тем лучше, чтобы наблюдать динамику).
7. Не делать «метадокументацию»
Ошибка: у базы знаний нет собственной базы знаний — не описаны теги, фильтры, автоматизации.
Что происходит: появляются избыточные теги, слетают фильтры и связи, ломаются автоматизации.
Решение: создать «паспорт базы знаний» — живой документ с картой тегов, фильтров, автоматизаций и владельцев.
Может заинтересовать
#похожие доклады
