В наше время базами знаний пользуются многие клиенты и компании, но далеко не все знают, что с их помощью можно решить многие внутренние проблемы. В предыдущей части мы разобрали прокачку сотрудников и почему не все хотят писать статьи. В этой части тимлид Анжелика Федько расскажет про однообразные вопросы, которые повторяются, про онбординг и ограниченный круг «писателей».
Когда мы в Plesk столкнулись с проблемами поддержки клиентов и адаптации сотрудников, то подумали, что их можно решить с помощью базы знаний. Мы разработали для себя 5 критериев, которые указывают на то, что база знаний используется не на всю катушку.
Меня зовут Анжелика Федько, я успела поработать с базой знаний с разных сторон. Например, пока была инженером технической поддержки, занималась её наполнением, созданием новых статей и актуализацией. Когда стала тимлидом, взяла на себя уже более стратегические проекты, которые нацелены не на улучшение конкретной статьи, а на базу знаний в целом. Таким образом, за 6 лет работы с базой знаний я успела рассмотреть ее с разных сторон.
Сегодня расскажу, с какими подводными камнями мы столкнулись, какие бенефиты смогли из этого извлечь, как вообще у нас проходил этот процесс и подробно разберу 5 критериев недоиспользования базы знаний.
Критерий №2. База знаний растет, количество клиентов увеличивается, а вопросы от них все те же.
Со временем у нас появлялось все больше клиентов, но мы стали замечать, что и новые клиенты, и уже знакомые нам, приходят с одними и теми же вопросами. Первым критерием мы уже настроили централизованное документирование, то есть статьи с решением их проблем уже были в базе знаний, но почему-то клиенты их не находили.
Причина скрывалась в том, что мы записывали статьи языком сотрудника, а не клиента. Если взять пример статей из первого критерия: «Symptoms», «Cause» и «Resolution», то симптомы были записаны так, что их не могли найти.
Решение
Чтобы решить эту проблему, мы начали писать языком клиента, то есть описывать все так, как это видит клиент. Например, у человека есть сайт. Он заходит на него и видит 502 ошибку — это всё, что видит клиент. Он не знает, что в одном из десятков логов на сервере есть упоминание о том, что какой-то сервис не стартует, и из-за этого не работает его сайт. Он никогда к вам с этим не придет. Он приходит именно с тем, что у него ошибка.
Та же самая история с поиском по базе. Если в симптомах будут записаны, как в данном случае, только ошибки из логов и не будет того, что видит клиент, он никогда не найдет эту статью, а придет к вам за помощью.
Что дает такой подход?
Когда мы начали записывать проблему так, как ее видит клиент, то 50% заявок стали решаться на моменте их заведения. По сути, они перестали до нас доходить.
Для этого на сайте есть форма для заведения заявки. Когда человек описывает свою проблему в этой заявке, ему автоматически всплывает «выпадашка» со статьями, которые потенциально могут решить его проблему. Люди действительно этим пользуются. Им гораздо быстрее самим решить проблему, чем ждать ответа от инженера технической поддержки.
Второй очень важный момент. Нашим сотрудникам стало интереснее работать, им больше не приходилось решать одни и те же вопросы миллион раз. Выросло удовольствие от работы, а значит, и процент удержания сотрудников тоже.
То есть, этот подход решает не только проблемы клиентов, но и проблемы сотрудников.
Критерий №3. Вы сделали крутые онбординг-тренинги, но новенькие все равно буксуют.
Когда я слышу об этом, первое, что приходит на ум — это мы взяли не тех людей. Но мы сами провели собеседование, сами отобрали кандидатов и решили, что они подходят по каким-то критериям. Значит, проблема не в них.
Онбординг в Plesk
После того, как мы взяли человека, он на месяц попадает в отдел обучения, и тренера дают ему необходимый базис по знаниям. Только после этого он идет в команду, где ему предстоит работать. Безусловно, ему помогает тимлидер. Он приставляет к новичку опытного сотрудника из команды (коуча), который объясняет процессы, как работает база знаний, как писать статьи и прочее.
То есть, после основного обучения у тренеров нам приходилось дообучать сотрудника и тратить дополнительное время коуча и тимлида. Таким образом мы получали долгий и дорогостоящий онбординг.
Когда мы об этом задумались, то решили, что нужно найти баланс между тренингами по продукту и тренингами по процессам.
Когда искать в базе знаний?
Безусловно, очень важно дать базис по продукту. Но разве не менее важно научить человека работать с базой знаний? Например, как искать статьи, когда их стоит искать. Ответы на эти простые вопросы кажутся очевидными, но это не так. Приведу два примера, чтобы их раскрыть.
Пример 1
Возьмём условного инженера технической поддержки Женю. Пришла новая заявка и он начал применять все знания, которые у него есть: что-то самостоятельно делал и исследовал. Когда у него не получилось решить своими знаниями, он начал искать решение на сторонних форумах и использовать знания других инженеров, то есть спрашивал их и отвлекал. Через какое-то время идеи иссякли, и Женя решил поискать в базе знаний. Буквально с первого симптома он нашел статью, применил решение и тут же закрыл заявку.
Женя потратил много времени на изобретение колеса, несмотря на то, что была статья с этим решением. Но это не всегда единственный вариант. Сделать можно по-другому.
Пример 2
Жене пришла новая заявка. Он начал искать решение в базе знаний. Безусловно, человек, который заводит заявку, описывает какой-то симптом, по которому он решил, что у него что-то не работает. По этому симптому Женя не нашел решение. Он начал искать новые симптомы, а затем снова обратился к базе знаний. Со второго раза он нашёл статью, применил решение и закрыл заявку. Вместо того, чтобы выискивать решение, во втором случае Женя искал симптомы.
Если посмотреть на время, видно, что в первом случае заявка решалась на треть дольше, чем во втором. Поэтому очень важно знать, когда и как искать в базе знаний.
На самом деле второй пример описывает очень важный принцип «Ищи раньше, ищи чаще».
Он говорит о том, что искать в базе знаний нужно на каждом из этапов решения заявки, искать с помощью каждого симптома. Ведь как во втором примере, если вы не нашли решение по первому симптому, то, возможно, оно найдется по второму.
Что дает такой подход?
Во-первых, наши новенькие стали быстрее обучаться. Их учили не только необходимому базису технических знаний, но и как диагностировать проблемы. После этого им оставалось — только получить необходимые теоретические знания из статей и тут же их применить.
Во-вторых: инженеры начали получать подсказки из статей. Чтобы убедиться, что статья подходила, нужно было запустить еще одну команду, о которой он мог до этого не знать.
Два этих пункта сильно уменьшили время, которое требовалось новичкам, чтобы стать автономными работниками, с полугода до 2-3 месяцев (в зависимости от входных знаний сотрудника).
Помимо более эффективного обучения новых сотрудников, этот подход дает и другие бенефиты. В базе знаний стало меньше дубликатов, которые ухудшают поиск по ней.
Также мы стали постоянно улучшать статьи. Например, в примере с Женей, он нашел статью только по второму симптому, но ему должно было изначально хватить первого. То есть необходимо этот первый симптом тоже добавить в статью — вот оно, улучшение.
Критерий №4. Только ограниченный круг людей пишет в базу знаний.
Казалось бы, что в этом плохого? Мы думали так же, поэтому до того, как включили в документирование всех, сначала посадили писать статьи только самых технически подкованных ребят.
Пусть статьи пишут только «избранные»
В итоге мы получили то, что статьи были настолько тяжело написаны, что их не то, что было тяжело применить, их даже трудно было найти.
После того, как не получилось с технически скилловыми ребятами, мы посадили тех, у кого самые крутые знания по английскому языку.
Безусловно, мы добились эффекта, статьи стало легче читать и воспринимать. Но порой упускались какие-то технические детали, которые были критично важны. В это же время появилась и еще одна проблема.
Представьте, что наполнением базы знаний занималось 5 человек. Им нужно было создать плюс-минус 200 статей за неделю и сделать это качественно. А еще актуализировать уже имеющийся стек базы знаний. В нашем случае, на тот момент было 11000 статей.
Здесь возникают сайд-эффекты:
- Проблема приоритизации. То есть, какую статью создавать или актуализировать сейчас, а какую позже?
- Устаревание статей. Отложенные статьи безусловно устаревают, но именно они могут потребоваться клиенту.
- Потеря экспертизы. Люди, которые записывают знания, но не используют их, быстро теряют техническую экспертизу. Это происходит с любыми чисто теоретическими знаниями.
Последствия… и решения
Первое, что мы сделали — это начали вовлекать всех сотрудников в процесс документирования, это подробно описано в 1 критерии. Но ещё не стоит забывать, что важны знания как джуниора, так и синьора, потому что клиентский уровень тоже разный.
Второй момент, который мы изменили в подходе — начали записывать только те знания, с которыми к нам приходят. Простой принцип: «нет спроса — нет предложения».
Это позволило решить проблемы связанные с «избранным кругом» для процесса документирования.
Что дает такой подход?
Отменой специальных групп мы добились роста технической экспертизы на 70%. Помимо записи этих знаний, они также применяют их, и это дает свой эффект.
Ежегодный опросник показал, что люди стали на 30% более довольны своей работой из-за отмены рутины и уменьшения однообразных задач. То есть, мы ещё снизили вероятность выгорания сотрудников.
Дополнительным эффектом стала поддержка актуальности статей.
5 критериев неэффективной базы знаний — как всё исправить Часть 3
17-18 мая на площадке из двух этажей Крокус-Экспо встретятся 2000 тимлидов и руководителей со своим опытом, инсайтами и энергией. Расписание конференции TeamLead Foundation 2022 уже готово, а купить билеты можно здесь.
Кроме того, от сервиса поиска менторов Getmentor.dev на конференции будут индивидуальные консультации с экспертами. Приглашаем вас прямо сейчас принять участие в конкурсе. Заполните форму и, возможно, именно вы выиграете 5 часов наставничества. Ментора (или менторов) вы сможете выбрать сами, сейчас в сообществе уже более 500 наставников. Больше информации — по ссылке.