Записать полезную информацию на салфетке, в чате или комментарии к задаче точно лучше, чем сразу же забыть. Однако может наступить момент, когда «салфеток» стало слишком много. А значит, пришло время зафиксировать самое важное в формате базы знаний.

Меня зовут Станислав, и я столкнулся с этой ситуацией, когда работал в технической поддержке «РТК-ЦОД». Из обрывков информации и разрозненных сообщений нам с командой удалось сформировать внушительную базу знаний. Мы очень быстро убедились, что одна хорошая инструкция, на которую один сотрудник потратил несколько часов, облегчает работу всей команде, помогая сэкономить недели.

Когда стоит подумать о создании базы знаний

Я пришёл в команду 1,5 линии поддержки на заре её существования. Нас было двадцать человек, мы помогали клиентам и консультировали коллег из выездного подразделения. Формально база знаний у нас уже была. Правда, она представляла собой сборник тяжеловесных мануалов и презентаций о стратегии развития. Посмотрев её один раз, новички почти сразу забывали дорогу на этот ресурс, и собранные документы покрывались виртуальной пылью.

По-настоящему ценной информацией — например, способами решения сложных инцидентов — инженеры делились друг с другом при пересменке, в почте и чатах. Поиск нужных сообщений превращался в задачу со звёздочкой. Если мы натыкались на что-то редкое, приходилось лихорадочно вспоминать, не сталкивался ли кто-нибудь ранее с чем-то подобным и не описал ли способ решения. Если да, то какими словами? Ошибка или проблема? Торможение или медленная работа? Баг или фича, в конце концов.

А сколько времени тратилось на обучение! Более опытные сотрудники объясняли новичку способы тонкости одних и тех же задач, потом объясняли то же самое другому новичку, потом — третьему. Такое наставничество с бесконечным повторением пройденного старожилов не вдохновляло и сильно отвлекало от основных обязанностей.

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

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

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

Ещё один сигнал — когда инженеры собирают для себя мини-базы в отдельных текстовых документах или заметках. Например, наши сотрудники сохраняли у себя список контактов вендоров. А дальше его актуализировали от случая к случаю, и периодически кто-то из нас звонил уже уволившимся коллегам. Кстати, совместный разбор таких локальных «баз знаний» поможет подготовить статьи, которые в будущем окажутся самыми востребованными.

Требования к базе знаний

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

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

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

Из этих вводных в итоге выросли основные требования к новой базе знаний, а именно:

• Простота поиска, т.е. возможность вбить в поисковую строку несколько букв и сразу же получить статью с нужной информацией.

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

• Ёмкие прикладные инструкции. Тяжеловесные мануалы с обилием административной информации могут быть приложением, но не основой БЗ. Пишем статьи для пользователей, а не для научного совета.

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

С чего начать?

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

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

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

Первые инструкции я показывал более опытным коллегам для правок и дополнений. Любопытно, что желанием создавать инструкции с нуля некоторые из них не горели, зато черновики редактировали охотно. Обычно подготовка статьи для БЗ представляется объёмной задачей, для которой нужно выкроить время, а вот приготовить её «полуфабрикат» можно довольно быстро.

Как структурировать информацию?

Если в базе знаний планируется несколько статей, стоит сразу предусмотреть смысловые блоки или разделы. Здесь возможны, как минимум, два подхода:

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

2. Структурирование разделов по актуальности тематики в порядке степени её убывания. Для стороннего «читателя» такой способ выглядит менее очевидным, но, если вы объясните его логику коллегам, он может оказаться для них более предпочтительным. В нашем случае верхним разделом базы знаний стала инструкция по ведению аварийного инцидента. Она могла срочно потребоваться дежурным инженерам, а значит, доступ к ней должен быть максимально простым и быстрым, без поисковых запросов. Последующие разделы располагались по такой же логике.

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

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

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

Идём на рекорд

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

• к какому домену относится логин для авторизации

• он вводится с собачкой или без

• как сбросить пароль и т.д.

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

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

Что может пойти не так

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

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

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

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

Мы обсудили этот вопрос с руководителем и пришли к тому, что при выполнении показателей KPI новые статьи в базе знаний будут эквивалентны группе решённых инцидентов. Были и нестандартные подходы. Однажды я организовал голосование за лучшую статью недели с материальным призом автору. Нельзя сказать, что в команде начались «голодные игры», но двое ребят с азартом вступили в борьбу за голоса. Долгосрочным мотиватором голосование с призом не стало, зато запомнилось.

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

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

Автору, который полностью разобрался во всех нюансах решения инцидента, много времени на написание текста инструкции не понадобится — максимум около получаса. Представим, что опытный сотрудник объяснил бы этот материал новичку за пятнадцать минут. Две таких «лекции» — и учитель уже затратил время, за которое мог бы подготовить статью для целого «поколения». А что, если новичок не полностью уловил суть и вернётся с просьбой повторить пройденное?

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