Ну само собой, я и не ударяюсь во вторую крайность. Без доков будет непонятна база — как, в принципе, функционирует продукт. Конечно, доки — это часть управления знаниями. Просто тут надо разделять понятия знаний и информации. Доки — это информация, данные, факты. Знания — это результат использования этой информации.
То же самое в pmbok про необходимость.
Вики, истории проектов (проектный опыт) и прочие. Даже стартану через пару лет трудно будет разобраться в первых проектах, ибо текучка.
Ээ… ну английский там, пассивный залог и вот это вот все. Quality — это существительное. Не доверяете мне, спросите у переводчика :) а так, у меня есть русская версия стандарта. Мой работодатель по нему сертифицирован.
О, я не про гугл же :) Про внутренний ресурс, где лежат всякие скрипты, описания проблем с решениями и т.д. :) А если проблема не описана, и ее нельзя нагуглить, то тут и юз-кейсы не помогут. Ведь вы их из реальных кейсов от клиентов собираете, как вы сказали. Тут уже мастерство агента и его понимание поддерживаемого продукта выходят на первый план.
Вот это уже интересно :) Осуществлять коммуникацию со сменными инженерами о «новинках», произошедших в другую смену, через работу над юз-кейсами — прямо круто :) А сколько времени выделяется агенту на работу с юз-кейсами в начале смены? Это на рост бэклога никак не влияет? Т.к. это, вроде бы, время не в production.
Просто, да не совсем :) Качество — вещь абстрактная. Вот, скажем, у вас уровень удовлетворенности поддержкой — 90%. И что? Что это означает в контексте бизнеса? Что 90% клиентов, столкнувшихся с проблемами и сходивших в техподдержку, продолжат покупать ваш продукт в следующем году, через год, через 10 лет? Или что? Как это самое абстрактное качество посчитать в hard dollars?
Ни в коем случае не критикую подход и позицию, просто очень глубоко погрузился в этот вопрос — интересуюсь с корыстной целью :)
Ситуация, которую я достаточно часто вижу: цель поддержке ставится в метриках, но никто не может ответить, а что дает выполнение этих метрик? Вы вкладываете время = деньги в повышение EKi, имеете достаточно приблизительную корреляцию с CSi на уровне тренда, а вот ваше значение в CSi в деньгах измеримо? Т.е., вы вложили в обучение определенную сумму, получили какой-то эффект на других метриках — можете ли вы посчитать этот эффект в деньгах, чтобы понять, больше ли вы заработали/сэкономили, чем потратили на обучение изначально? Если сумеете ответить на этот вопрос, я очень хочу вашу методику расчета!
Больше похоже на маркетинговый лозунг :) Мне кажется, хороша та техподдержка, которая решит проблему клиента :) И если клиент нацелен на конструктив, а не покричать в трубку, то он готов подождать 10 секунд, которые у инженера уйдут на поиск готового и заведомо работающего решения :) Я не знаю, какова структура уровней техподдержки у вас. Может быть, конкретно в вашей компании 10 секунд решают, и это критично для бизнеса. Но большая часть пользователей услуги, за которую они заплатили, стремится, чтобы потраченные ими деньги все же окупались (т.е. починить услугу, чтобы ей можно было дальше пользоваться). Так что, если им вежливо сказать, что «прошу подождать несколько секунд, я предоставлю вам решение (в рамках корпоративного Tone of voice эта фраза может звучать иначе, но суть такая)», то клиент подождет. Лишь бы заработало.
А вот если у агента в голове перемешалось 500 юз-кейсов, и он, отвечая на 80-ый звонок за смену, насоветует клиенту что-нибудь по ошибке, проблем может быть больше :)
Повторюсь, имхо :)
Интересно, но реально сложновато. А вот эти usecase — это что? Это какие-то реальные кейсы от юзеров? Или абстрактные, придуманные (кем? кто решает, какой кейс следует включать в ротацию (должность в компании)? на основании чего? сколько времени на составление кейсов тратится?)
Как переводится в деньги тот же CSi?
Если вы говорите, что корреляция между EKi и CSi неочевидна, то, наверное, usecases не совсем коррелируют с реальными потребностями юзеров, которых поддерживает ваша команда.
А еще интересна история с необходимостью помнить много всего. Я сам вырос в КМ из инженера второй линии поддержки. Помню, что есть часто возникающие кейсы, а есть возникающие раз в квартал, но тоже имеющие типовые решения. Прошло 6 лет, и я до сих пор помню алгоритмы решения типовых задач и даже номера статей, которые надо отправлять клиенту по той или иной проблеме. А вот редко встречающиеся кейсы я и тогда смотрел в базе кейсов, и сейчас бы поступил точно так же. Зачем их все время помнить, если они лежат в известном месте, задокументированы и четко описаны? С таким подходом и учу агентов сейчас. На мой взгляд, наиболее важные знания и так из памяти не вылетят, а все остальные нужно уметь найти на корпоративных ресурсах. Базы знаний как раз для того, чтобы найти быстро, а не чтобы агенты в любой момент помнили массу редко всплывающих кейсов.
Может быть, лучше вложиться в нормальное тегирование инструкций в базе и поиск по внутренним ресурсам, а не в удержание в головах агентов большого объема информации?
Имхо, разумеется :) Но, вроде, у меня работает :)
Ну само собой, я и не ударяюсь во вторую крайность. Без доков будет непонятна база — как, в принципе, функционирует продукт. Конечно, доки — это часть управления знаниями. Просто тут надо разделять понятия знаний и информации. Доки — это информация, данные, факты. Знания — это результат использования этой информации.
Шум, кстати, вообще ценная штука) он неформальный, а неформально люди чаще делятся всякими рассказами о костыльных решениях кмк :)
То же самое в pmbok про необходимость.
Вики, истории проектов (проектный опыт) и прочие. Даже стартану через пару лет трудно будет разобраться в первых проектах, ибо текучка.
Ээ… ну английский там, пассивный залог и вот это вот все. Quality — это существительное. Не доверяете мне, спросите у переводчика :) а так, у меня есть русская версия стандарта. Мой работодатель по нему сертифицирован.
В чатике конфы в ТГ спросите. @KnowledgeConfTalks. Насколько я знаю, там как-то их купить надо, чтобы не ждать полгода. пока в паблик начнут постить.
Ни в коем случае не критикую подход и позицию, просто очень глубоко погрузился в этот вопрос — интересуюсь с корыстной целью :)
А вот если у агента в голове перемешалось 500 юз-кейсов, и он, отвечая на 80-ый звонок за смену, насоветует клиенту что-нибудь по ошибке, проблем может быть больше :)
Повторюсь, имхо :)
Как переводится в деньги тот же CSi?
Если вы говорите, что корреляция между EKi и CSi неочевидна, то, наверное, usecases не совсем коррелируют с реальными потребностями юзеров, которых поддерживает ваша команда.
А еще интересна история с необходимостью помнить много всего. Я сам вырос в КМ из инженера второй линии поддержки. Помню, что есть часто возникающие кейсы, а есть возникающие раз в квартал, но тоже имеющие типовые решения. Прошло 6 лет, и я до сих пор помню алгоритмы решения типовых задач и даже номера статей, которые надо отправлять клиенту по той или иной проблеме. А вот редко встречающиеся кейсы я и тогда смотрел в базе кейсов, и сейчас бы поступил точно так же. Зачем их все время помнить, если они лежат в известном месте, задокументированы и четко описаны? С таким подходом и учу агентов сейчас. На мой взгляд, наиболее важные знания и так из памяти не вылетят, а все остальные нужно уметь найти на корпоративных ресурсах. Базы знаний как раз для того, чтобы найти быстро, а не чтобы агенты в любой момент помнили массу редко всплывающих кейсов.
Может быть, лучше вложиться в нормальное тегирование инструкций в базе и поиск по внутренним ресурсам, а не в удержание в головах агентов большого объема информации?
Имхо, разумеется :) Но, вроде, у меня работает :)