Вскоре всплыл ещё один момент - необходимо было отказаться от Evernote. Это был прекрасный инструмент. В нём было легко искать информацию и легко её создавать.
Но дело в том, что политика компании запрещала привязываться к облачным сервисам (в целях безопасности и для того, чтобы не зависеть от работоспособности сторонней инфраструктуры).
Работа с Evernote у нас была по собственной инициативе и как-бы из под полы. Неофициально.
А для Knowledge Centered Support мне необходимо было создать официальные регламенты, которые необходимо было бы соблюдать всем сотрудникам.
На замену Evernote я рассматривал всяческие Wiki-движки, корпоративные порталы по накоплению знаний. Сервисы документирования:
После отсева остались вот такие варианты:
- Atlassian Confluence
- Xwiki
- Bookstack
- И вариант, который выиграл.
Atlassian Confluence
Это был топ жир. Система специально предназначенная, чтобы большие компании вели там свою документацию. Отточенная, отлаженная, с большим сообществом. Дорогая. Связывающая руки.
В тот момент мы не могли себе позволить потратить такие деньги, которые требовались за 20-50 лицензий на Конфлюенс.
Xwiki
Корпоративная Open-Source замена Конфлюенсу.
Тяжелая, глючная, сложная. Бесплатная.
Мы в неё копнули, но вынуждены были остановится из-за непреодолимых приступов тошноты.
Bookstack
Прекрасный Open-Source аналог и Confluence и XWiki. Красивая, простая, удобная система с контролем доступа. Там даже можно нативно подключить
draw.io для рисования блоксхем и совместного их редактирования.
Погоняли её, но не взлетела.
Два нюанса:
- По какой-то причине движок разметки ломал оглавление на длинных документах
- На тот момент было всего два уровня вложенности каталогов и народ не понимал как распихать текущие проекты на такую бедную структуру.
Вариант который выиграл
Это текстовые файлики. Вернулись обратно к истокам.
В тот момент у нас развернули корпоративный портал - Bitrix24. Там можно было создавать аналог яндекс.диска, но по проектам.
Мы делали общий шаренный диск, куда складывали файлы в удобном нам формате.
Там же можно было отследить историю изменений.
Битрикс это не только корпоративный портал, но и система управления задачами. Поэтому жизненный цикл статьи мы выстараивали через задачи.
Правда тут речь уже не шла о "выращивании" статей из зародышей. Тут уже были запросы "сверху" на написание той или иной статьи исходя из потребностей.
Поиск по базе файликов выполнялся с помощью DocFetcher.
Но Битрикс система глючная. То и дело у кого-то случался конфликт синхронизаций. Процесс работы со статьями вызывал споры из-за разных форматов. Написание статей по запросам попахивало бюрократией и не позволяло статьям появляться органичным образом.
База со статьями разросталась и вместе с ней рос её размер. Это создавало проблемы на компьютерах с заканчивающимся жестким диском.
DocFetcher был костылём, который люди тяжело воспринимали.
Ну и весь этот подход не очень пересекался с идеей KCS.
А я размышлял. Людям явно зашла работа с простыми файликами. И тут мы в отдел разработки установили GitLab.
Вот оно!
Репозиторий со статьями в Markdown-формате. Гит как контроль версий. Поиск по всем репозиториям! Ишью! Теги!
Сейчас мы перевели всю базу внутренних и внешних статей в Git-репозитории.
Новые статьи пишем сразу туда. Чуть позже накатим на них какой-нибудь генератор статических сайтов и откажемся от стороннего сервиса UserEcho в качестве хостинга статей для клиентов.
Параллельно прорабатываем вопрос по работе с документацией как с кодом. Идея в том, чтобы техпис работал с текстовым файлом и языком разметки и не заморачивался по поводу форматирования. Форматирование будет выполнять машина по заранее заданному шаблону.
В общем, всё то же, что и в абзаце выше, только более богатый язык разметки. Вместо markdown - asciidoc
Ведение статей и документации в простом языке разметки в git развязало нам руки, для того чтобы полноценно внедрить KCS.
