Внутренняя база знаний: как заставить команду в неё писать
Подняли внутреннюю вики для инженерной команды - поиск работает, заметки копятся. Главная проблема оказалась не техническая: как сделать так, чтобы люди писали, а не звонили.
Web 2.0-инструменты приходят в офис: внутренние блоги и базы знаний вместо рассылок
Есть разговор, который мы ведём с каждым клиентом примерно раз в год. Звонит кто-то из его команды и говорит: «А помнишь, ты в прошлом году чинил у нас проблему с репликацией Active Directory? Как там было?» Мы помним, но смутно. Письмо ищем двадцать минут. Иногда не находим.
Этим летом мы решили, что хватит, и подняли внутреннюю базу знаний для своей команды. Потратили на это больше сил, чем ожидали - не на техническую часть, а на то, чтобы туда вообще начали писать.
Что взяли и почему
Выбирали из нескольких вариантов. TWiki - зрелый, есть у людей опыт, но интерфейс такой, что хочется закрыть страницу и позвонить. MediaWiki - то, на чём работает Википедия, появившаяся четыре года назад, интерфейс понятнее, но настройка под локальный сервер занимает время. Confluence от Atlassian - коммерческий, дорогой для команды нашего размера.
Взяли MediaWiki. Поставили на выделенную виртуалку (как раз отработали схему с VMware ESX в январе), настроили поиск, добавили категории. Технически всё поднялось за день.
Через неделю в базе знаний лежало четыре статьи. Все написал один человек - тот, кто её и ставил.
Почему не пишут
Мы думали об этом честно, без самообмана. Причин несколько, и они слоями.
Первое - писать неудобнее, чем не писать. Решил проблему - хорошо, закрыл задачу и пошёл дальше. Открыть вики, создать страницу, сформулировать, что именно ты сделал и почему - это отдельные десять минут. В момент, когда задача закрыта, мотивации к этим десяти минутам почти ноль.
Второе - непонятно, кому это нужно. Когда не видишь, что кто-то читает твои заметки, ощущение что пишешь в пустоту. Рассылку хотя бы прочитают сегодня - пусть и удалят. Вики будет лежать и ждать.
Третье - нет привычки формулировать. Инженер решает проблему в голове, часть действий делает интуитивно, часть - методом проб. Если его попросить написать про это, он не знает с чего начать. «Ну, попробовал одно, не сработало, потом другое, заработало». Как из этого сделать статью - не очень понятно.
Что помогло
Первое и самое важное: ввели правило для самих себя. Если задача заняла больше двух часов и её решение не было очевидным - пишешь заметку. Не монографию, не руководство. Просто: что была за проблема, что пробовали, что сработало. Два абзаца. Можно кривовато. Перфекционизм здесь враг - человек не пишет, потому что «это ещё не готово».
Второе: шаблон. Мы сделали стандартную структуру для технических заметок. «Симптом» - что наблюдал. «Диагностика» - что проверял и в каком порядке. «Решение» - что сделал. «Ссылки» - документация, форум, если нашёл. Шаблон убирает вопрос «с чего начать». Просто заполняешь по пунктам.
Третье: поиск должен работать. Это звучит очевидно, но MediaWiki ищет по умолчанию только по заголовкам - надо настраивать полнотекстовый поиск отдельно. Если человек зашёл, не нашёл то что искал и позвонил - он больше не зайдёт. Мониторинг помогает понять, что происходит внутри системы, но с базой знаний проще: если люди ею не пользуются, значит что-то не так.
Что реально изменилось за два месяца
Сейчас в базе около сорока заметок. Несколько раз было так: один инженер спрашивает другого про проблему с Exchange или репликацией DNS - и тот, вместо того чтобы объяснять устно, говорит «посмотри в вики». Это и есть момент, ради которого всё затевалось.
Не скажем, что пишут все и всегда - нет. Дисциплина держится за счёт того, что на разборе задач в helpdesk мы спрашиваем: «это записано?» Не ругаем, просто спрашиваем. Человек идёт и пишет, пока не остыл.
Ещё обнаружили побочный эффект: несколько старых заметок о конфигурациях - тех, которые делали год-два назад - теперь есть в письменном виде. Это помогло при инвентаризации: вместо «кажется, мы там делали вот так» - конкретная запись с датой.
Что пока не решили
Категоризация разросшаяся. Заметки есть, но найти нужную через навигацию по категориям сложно - проще через поиск. Это надо будет разгрести, пока база не стала совсем большой.
Клиентские конфигурации мы туда не кладём - отдельный вопрос про конфиденциальность и доступы. Пока это остаётся в папках по клиентам и в голове. Задача следующего этапа.
Главный вывод прозаичный: база знаний - это не инструмент, это привычка. Инструмент можно поставить за день. Привычку - за несколько месяцев, и только если есть простые правила и кто-то про них напоминает.