В наше время базами знаний пользуются многие, но не все знают, что с их помощью можно решить внутренние проблемы. В предыдущей части мы узнали про однообразные вопросы, онбординг и ограниченный круг «писателей». Осталось разобрать последний критерий — база знаний и функционал. В этом нам поможет тимлид Анжелика Федько.
Когда мы в Plesk столкнулись с проблемами поддержки клиентов и адаптации сотрудников, то подумали, что их можно решить с помощью базы знаний. Мы разработали для себя 5 критериев, которые указывают на то, что база знаний используется не на всю катушку.
Меня зовут Анжелика Федько, я успела поработать с базой знаний с разных сторон. Например, пока была инженером технической поддержки, занималась её наполнением, созданием новых статей и актуализацией. Когда стала тимлидом, взяла на себя уже более стратегические проекты, которые нацелены не на улучшение конкретной статьи, а на базу знаний в целом. Таким образом, за 6 лет работы с базой знаний я успела рассмотреть ее с разных сторон.
Сегодня расскажу, с какими подводными камнями мы столкнулись, какие бенефиты смогли из этого извлечь, как вообще у нас проходил этот процесс и подробно разберу 5 критериев недоиспользования базы знаний.
Критерий №5. Ни новые фичи, ни фикс багов не улучшают NPS (Net Promoter Score) продукта, либо улучшают незначительно.
На первый взгляд этот критерий никак не связан с базой знаний, но лишь на первый. Представьте, что можно обнаружить функционал, который необходим клиентам, даже не спрашивая их об этом. Разве цель IT-бизнеса не в том, чтобы продукт, который мы делаем, нравился нашим клиентам, чтобы они им пользовались и были довольны функционалом?
Допустим, у каждой статьи есть свой счетчик, и он накручивается каждый раз, когда статью просматривают.
У нас одна и та же статья была в топе по количеству просмотров в течение нескольких месяцев. Она описывала, какие порты необходимо открыть на сервере после установки продукта Plesk.
Когда мы это обнаружили, то подумали, а зачем люди сами их открывают? Разве не проще нам это сделать? Таким образом, мы открыли для себя пользовательский сценарий, о котором никто раньше не догадывался. С этим мы пошли к разработчикам, они привинтили простой скрипт, который открывал необходимые порты на сервере.
Статья тут же ушла из топа, потому что в ней больше не было необходимости, а продукт стал более интуитивным и простым в конфигурировании. Это прямая выгода — текущим клиентам нравится ваш продукт, и они рекомендуют его своим коллегам.
Варианты решений
Чтобы найти решение для анализирования статьи, сопоставьте заявку и статью. Для этого нужна техническая возможность узнать, какая статья помогла в конкретной заявке.
Помимо этого, мы смотрели на комментарии к статьям. Люди пишут понравилась им статья или нет, помогла или не помогла, и если не помогла, то почему. Для этого мы использовали приложение Hotjar. Разные аддоны предлагают различный функционал для того, чтобы анализировать статьи и заявки. Также можно прикрутить бесплатный сервис Google Analytics и использовать его.
Мы разобрали 5 критериев, но я решила добавить еще один, потому что считаю его важным. Конечно, логичнее было бы поставить его в начало статьи. Но после разбора всех остальных критериев, начинаешь лучше понимать зачем на самом деле нужна база знаний и что она делает. Становится всё это проще объяснить другим.
Критерий №6. Сотрудники либо топ-менеджмент не понимают, зачем нужна база знаний
Как понять что это происходит? Есть следующие признаки:
- Сотрудники то пишут статьи, то не пишут, но чаще всего принимаются за работу, после пинка руководителя.
- Топ-менеджеры выделяют все меньше ресурсов на развитие базы знаний.
Убеждение топ-менеджмента в том, что вам необходима база знаний — это шаг №0. Он должен быть предпринят еще до начала всей затеи.
Решение: убедите!
Решение на самом деле простое: убедить всех людей, вовлеченных в процесс документирования знаний, что им это нужно! Например, в компании Plesk есть три звена, которые вовлечены в работу с базой знаний:
- Инженеры технической поддержки;
- Тимлиды и operations-менеджеры;
- Директор и вице-президент.
Разберем каждое из них.
Инженерам наверняка нравится решать только новые задачи, а не тратить время на уже решенные. Если изначально, когда мы только начинали использовать KCS, некоторых людей нужно было заставлять писать статьи, то сейчас для наших инженеров это столь же естественная задача, как и технический аспект. Их работа стала более разнообразной. Людям нравится делиться знаниями, они знают, что это помогает другим.
Для тимлидов и operations-менеджеров тоже возникают явные плюсы — люди довольны своей работой, в команде работают слаженно, уменьшается текучка.
Если говорить о топ-менеджменте, то здесь стоит обратить внимание на метрику ROI (Return On Investment). Она поможет показать, что вложенные в развитие базы знаний средства окупятся. В нашем случае мы предотвратили рост штата технической поддержки на 25%, при том, что наша клиентская база за 2 года выросла на 18%. Несмотря на это, мы смогли плюс-минус сохранить объем заявок, за счет того, что люди сами находили решение своих проблем. Есть прямая зависимость: не растет headcount — не растут затраты на техническую поддержку. Это может убедить топ-менеджеров.
Я дала 6 критериев вместо обещанных 5. Как бы перевыполнила план. Теперь давайте подведем итоги, чтобы это все как-то уложилось.
Подведем итоги
Безусловно, некоторые перечисленные мною критерии могут быть абсолютно не связанными с базой знаний. Но мы ведь с вами говорим именно о знаниях, поэтому просто необходимо проверить и убедиться, так это или нет.
- Научите сотрудников работать с базой знаний. Сделайте тренинги. Таким образом вы уменьшите порог вхождения человека в автономный процесс работы. В нашем случае он упал с полугода до 2-3 месяцев.
- Вовлекайте всех сотрудников в процесс документирования. Не важно, джуниор он, синьор или мастер — все знания важны.
- Записывайте все знания, с которыми сталкиваетесь — не бывает знаний, которые не нужны.
- Убедитесь, что все вовлеченные в работу с базой знаний люди понимают ее важность и ценность. Причем важность и ценность именно для них.
- Не пытайтесь думать за клиентов и писать статьи заранее. Предоставляйте знания тогда, когда за ними приходят. Та вы сэкономите время инженеров, и они потратят его на помощь клиентам, развитие своих навыков и участие в других проектах.
- Анализируйте посещаемость статей. Используйте данные анализа для улучшения вашего продукта.
База знаний — это не дополнение к решению проблемы, это и есть метод её решения.
17-18 мая на площадке из двух этажей Крокус-Экспо встретятся 2000 тимлидов и руководителей со своим опытом, инсайтами и энергией. Расписание конференции TeamLead Foundation 2022 уже готово, а купить билеты можно здесь.
Кроме того, от сервиса поиска менторов Getmentor.dev на конференции будут индивидуальные консультации с экспертами. Приглашаем вас прямо сейчас принять участие в конкурсе. Заполните форму и, возможно, именно вы выиграете 5 часов наставничества. Ментора (или менторов) вы сможете выбрать сами, сейчас в сообществе уже более 500 наставников. Больше информации — по ссылке.
