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

Я начал заниматься базой знаний, будучи зеленым джуном, так что все описанные в посте рекомендации применимы даже в том случае, если у вас нет административных или финансовых ресурсов. Иными словами, советов в духе "просто заставьте всех писать и штрафуйте непослушных" тут не будет, мы пойдем другим путем.

Про меня и мою базу знаний

В людях живал — свету видал: топор на ногу обувал, топорищем подпоясывался

Ahoj. Меня зовут Коля, я QA тимлидер в компании Veeam. QA в нашей компании включает в себя не только тестирование, но и обеспечение качества в самом широком смысле. И среди этих смыслов затесалась такая штука, как управление знаниями. Я занимаюсь внутренней корпоративной базой знаний компании практически с самого ее появления, при этом поддержка базы знаний не входит в список моих обязанностей: это скорее что-то вроде pet-проекта. Долгое время у вики был статус поделочки, а мои попытки навязать вики коллегам приводили лишь к пополнению корпоративного стикер-пака моей фотографией.

Впрочем, время идет, времена меняются. Сейчас вики насчитывает 700 пользователей, 11 000 страниц, 56 000 правок и 688 000 слов (примерно полтора романа "Война и мир", если говорить только о тексте). Всего-то в 2 000 раз меньше русскоязычной Википедии, и это при условии работы на исключительно добровольных началах: никто не принуждает сотрудников пользоваться нашей вики.

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

Общий подход

Ищи себе прибыли, а другому не желай гибели

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

Главный совет, который я бы хотел дать в этой статье, звучит так: относитесь к проекту базы знаний как к публичному проекту. Скажем, если бы вы придумали Википедию или Хабрахабр, как бы вы продвигали их в массы? Реклама? Уникальный контент? Холодные как хвост вашей бывшей звонки на случайные номера из телефонной книги? Возможны любые варианты продвижения, но не забывайте адаптировать их к реалиям вашей компании и вашего коллектива. А еще не забывайте, что в случае недобросовестной рекламы коллеги узнают, где вас найти. Не перегибайте палку.

Кроме прочего, подход к вики как к публичному проекту позволяет проще относиться к проблеме продвижения. Я часто слышал обиды и сетования, что, мол, коллеги не делятся знаниями, не пишут внутреннюю документацию. Но вы же не обижаетесь на пользователей за то, что они не скачивают ваше приложение или не покупают ваши чудо-подушки за $9,99? Вы ищете способ понравиться вашим пользователям, ищете путь к их теплокровному сердцу, а не способ подчинить их вашей воле.

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

Собирайте статистику

Красна птица перьями, а человек — знанием

А начнем мы с того, что нам нужно как-то оценивать качество тех способов продвижения, что мы будем пробовать. В связи с этим первое, чем стоит озаботиться — это сбор статистики. Скажем, я пользуюсь Matomo (которые раньше звались Piwik), но похожий функционал есть у десятков аналогов.

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

Помимо оценки эффекта продвижения, статистика предоставляет и пачку других плюшек:

• Анализ поисковых запросов решает сразу несколько проблем:

  • Вы понимаете, что людям интересно, что они хотели бы видеть на вики. Если у вас нет статей по теме, которая интересна вашим коллегам, это отличный повод их туда добавить.

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

• Можно добавлять логирование конкретных действий, что позволит вам узнать, как часто пользуются тем или иным функционалом. Так вы не будете вкладывать силы в то, чем абсолютно никто не пользуется. И сможете продвигать базу знаний, подчеркивая в обсуждениях объективно самые популярные фичи.

Накопите критическую массу знаний

Там хорошо, где нас нет

Если вы лишь недавно начали развивать базу знаний, найдите способ наполнить ее контентом.

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

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

Еще один очевидный источник контента — ваши личные заметки и ваши личные знания. Об этом аспекте давайте поговорим поподробнее.

Вам надо — вот сами и пользуйтесь

Не ищи в селе, а ищи в себе

Первое время основным пользователем базы знаний скорее всего будете вы сами. С одной стороны, это не особо воодушевляет, но, с другой стороны, вы можете изначально строить базу знаний на тех принципах, что близки и удобны именно вам. Это хорошая позиция для начальных этапов развития портала: если даже вам не хочется пользоваться базой знаний, то почему кто-то другой должен относиться к ней иначе?

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

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

Сделайте вики единой точкой доступа для поиска любых знаний

И чтец, и жнец, и на дуде игрец

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

• Можно сделать просто каталог внутрикорпоративных сайтов (привет, девяностые). Да, подход, мягко говоря, не самый свежий, но и у вас в компании скорее всего не тысячи порталов. Для пары десятков сайтов и каталог обычно подходит неплохо.

• Или же можно идти по пути Гугло-поисковика и встраивать себе поиск по другим сайтам. При этом необязательно писать свой краулер, можно обойтись и более дешевым решением. Например, воспользоваться поисковым API сторонних сайтов и выводить результаты поиска по другим сайтам, если на вашей вики результатов не нашлось.

При этом не забывайте, что поиск "любых знаний" не ограничивается знаниями техническими. Такие вещи, как процедуры оформления отпусков или контакты HR/бухгалтерии/охраны/etc могут оказаться не менее важной частью вашей базы знаний, чем описания фичей или продуктов.

Создавайте зону комфорта для окружающих

Не хвались теплом в нетопленой избе

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

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

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

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

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

• Долго время на моей вики не было визуального редактора: его настройка для приватной MediaWiki на тот момент была делом нетривиальным, и руки у меня до него не доходили. Когда же наконец визуальный редактор появился, ежемесячное число новых статей увеличилось в полтора раза.

  Вам может показаться, что ваши коллеги с тремя высшими легко освоят очередной markdown, и в этом нет большой нужды, но вы ошибаетесь: они могут освоить ваш маркдаун за час, но не хотят. Им это неинтересно, так к чему плодить страдания без необходимости?

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

  В базе знаний этот вопрос решился введением постоянно пополняемого словаря синонимов, аббревиатур и прочего. Словарь используется при поиске, так что пользователь всегда видит, что, например, по запросу "data mover" находится "VeeamAgent" компонент. Составлять словарь приходится вручную, так что иногда доводится выбираться в лингвистические экспедиции для сбора материала в соседние отделы.

  Конечно, остается проблема с тем, что одно и то же слово может означать сразу несколько вещей (скажем, "бекап" — это резервная копия, задание резервного копирования, процесс резервного копирования, продукт Veeam Backup & Replication или отдел Backup QA в зависимости от контекста). Это пока что решаем по аналогии с Википедией: создаем страницу с термином и расписываем, что этот термин может значить.

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

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

Рассказывайте о новостях

Из серебряных речей пулю не отольешь

Никто не узнает о том, какая у вас крутая база знаний, если вы не будете об этом рассказывать. И желательно не один раз. Как говорил один мой университетский преподаватель:

Обычному человеку нужно повторить одно и то же десять раз, прежде чем он запомнит. Однако вы — интеллектуальная элита страны, лучшие из лучших. Вам достаточно девяти.

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

• Заведите дайджест в почте, в котором вы периодически будете рассказывать о разработке базы знаний: что появилось нового, что починили старого, куда двигаетесь дальше. Если не перебарщивать с письмами, это может быть весьма действенным инструментом продвижения.

• В группах по фиче/продукту/проблеме рассказывайте о новых статьях по теме, написанных вашими коллегами. Русскоязычные айтишники — скромный народ, мы обычно не любим хвастаться плодами своего труда. Сделайте это за них: во-первых, авторам будет чертовски приятно, а во-вторых, это будет поводом ввернуть пассаж про важность, пользу или даже просто про существование базы знаний.

Как и во всем, здесь стоит знать меру. Однако не пренебрегайте информированием коллег о том, что происходит с вашей базой знаний.

Угрозы, вымогательства

Воруй любовь, убивай скуку

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

• Рассказывайте коллегам про угрозы отсутствия документации. Если ранее у вас никогда не было базы знаний, то начать стоит с самых основ, пусть даже вам они могут показаться очевидными.

  Расскажите про пресловутый bus factor и проиллюстрируйте примером, ведь наверняка вы с этим уже сталкивались на практике (надеюсь, впрочем, что не в такой трагичной форме).

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

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

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

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

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

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

Играйте на здоровом самолюбии

Птицу кормом, а человека серебряной пулей обманывают

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

• Добавьте блок новостей на главную страницу, где будет информация обо всех новых правках (или хотя бы обо всех новых статьях). Рядом с именем статьи непременно должен светиться ник автора правки.

• Если вам позволяют ресурсы, можно попробовать варианты геймификации и добавить рейтинги или ачивки (например, за N статей/правок). Хотя есть мнение, что эти штуки сработают далеко не в каждом коллективе.

• У меня не было столько времени, чтобы добавлять геймификацию, но я добавил блок "Your impact" на главную страницу. Там выводится 10 самых просматриваемых статей из числа отредактированных вами, а рядом с ними — число просмотров с момента вашей первой правки.

  Идея эта не моя, я подсмотрел ее на MediaWiki хакатоне в Праге, где growth team рассказывали про свои исследования аналогичной фичи большой Википедии и предлагали поучаствовать в разработке. Конечно, мне пришлось переписать фичу с нуля, поскольку у меня совсем другие источники данных, чем у Wikipedia, но в остальном я старался следовать рекомендациям Growth team.

• Маленькое расширение Thanks может послужить аналогом лайков для конкретных правок. Оно, конечно, не очень удобное, но лучше, чем ничего. И реагируют коллеги на такие "спасибо" обычно очень положительно.

• Как я уже писал выше, не упускайте шанса похвалить ваших коллег, если они написали что-то крутое. Положительная обратная связь не будет лишней.

Расскажу, как я начал заниматься базой знаний. На заре моего трудоустройства коллега организовал мини-конкурс: автор наибольшего вклада в развитие вики должен был получить награду, достойную чемпиона — стакан черной смородины (напомню, Veeam — IT компания с достойными зарплатами, мы тут не голодаем). Смородина та кончилась пять-шесть лет назад, а проектом я занимаюсь и поныне. Не могу сказать, что это был гениальный ход с его стороны, но он сработал, а это главное.

Присматривайте за другими

У семи нянек детеныш без серебряной пули

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

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

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

Вместо заключения или "насильно мил не будешь"

Лучше на гривну убытку, чем на алтын стыда

Ваша база знаний подойдет не для всего и не всем. Даже в моем случае MediaWiki — самая популярная и большая внутренняя база знаний, но далеко не единственная. Есть команды, привыкшие на прошлых местах работы к Confluence/Sharepoint/впишите нужное. Отдельные команды все еще бойкотируют создание внутренней документации под теми или иными поводами. На мой взгляд, это нормально.

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

Пожелание "сделайте так, чтобы мою вики использовали, пожалуйста" мало чем отличается от "сделайте так, чтобы в мою игру играло много человек". Да, у продвижения разных сервисов и услуг есть свои особенности, но у них гораздо больше общего, чем может показаться. Чтобы продвигать базу знаний, попробуйте мыслить как SMM специалист и основатель стартапа в одном лице, а не как Пётр I, насильно сбривающий бороды (никаких претензий к Петру, просто подход другой). И хотя идеального способа продвижения нет и вероятно, никогда не появится, в ваших силах найти рабочие для вашей конкретной компании способы. Удачи!