Deflection Rate — коэффициент предотвращенных обращений. Это процент пользователей, которые получили ответы в базе и не создали тикет.
CES (Customer Effort Score) — измеряет, сколько усилий потребовалось клиенту для решения проблемы: как долго искал ответ, сколько статей открыл.
А как их посчитать?
Про контроль со стороны технического писателя или контент-менеджера:
Рейтинги просмотров полезны при создании FAQ. Правда, комментарии пишут редко, тут нужно скорее опрос ключевых пользователей проводить - тоже своего рода метрика;
Я бы добавил метрики тимлида или старшего специалиста поддержки - это же их зона ответственности: "как найти описание такого-то параметра и понятно ли написана статья";
Тимлид (а скорее техлид или аналитик) здесь больше нужен для контроля корректности с технической точки зрения.
Кажется, что роль «Knowledge Manager» едва ли приживется, т.к. в компаниях до сих пор не совсем понятен ее статус. С одной стороны, это продвинутая версия техписа, а с другой - чтобы построить нормальную базу, нужно выстроить процессы всех участвующих подразделений. То есть КМ должен быть на уровне с руководителями этих подразделений или иметь право требовать с них соответствующего исполнения.
Да! Просто начните писать :) Когда "все постоянно заняты" можно использовать старую добрую "бюрократию" - выделите себе ежедневный слот на "написание чего-нибудь". Например, есть же периоды для походов за кофе, перекуров и общения с коллегами - вот в такие моменты мысли работают лучше всего. Возвращайтесь и фиксируйте.
Пятое. Не бойтесь тавтологии.
Здесь я бы рекомендовал создать глоссарий со всеми возможными синонимами. Повторять термины полезно, но без пересказа работы целого механизма - пусть это будет описано отдельно, вот на это место и ссылаться.
1.Следите за объемом информации. Если ее много, читать вряд ли будут внимательно или полностью. Практика показывает, что длинные тексты мало кому нравится читать.
Информации может быть много, но важнее её подача - форматирование текста. Как минимум, разделять мысли на абзацы и использовать списки.
2.Не распыляйте внимание на детали. Одного-двух предложений будет достаточно.
В формате базы знаний можно вставлять сворачивающиеся инфоблоки.
5.Лучшее решение – порядок слов прямой!
Уж точно не использовать страдательный залог - из текста должно быть понятно кто и что выполняет, система или пользователь (https://habr.com/ru/articles/772022/).
7.Смело добавляйте схемы, картинки и скриншоты для визуализации.
Даже лучше именно с этого и начинать - визуал обычно заходит быстрее текста и дольше запоминается. А еще так намного проще увидеть где чего не хватает.
Если управляемость системы определяется переходами между состояниями, то эти переходы не могут быть произвольными. Для них должны существовать правила, ограничивающие допустимые переходы и делающие их проверяемыми.
До тех пор, пока жизненный цикл продукта не зафиксирован как модель состояний и переходов, любые роли, инструменты и методологии работают вхолостую.
А где и как это должно прописываться? Допустим, есть и workflow и регламент, но все же: "постоянные переделки, хаос в требованиях, конфликты между ролями и ощущение, что команда всё время занята". Что или с кем здесь не так?
Если человеку реально настолько интересна шарага, он и подготовится, изучив её историю-миссию-ценности-прочую фигню, и сам об этом расскажет.
В том-то и дело, что зачастую сайт компании неинформативен - на за что зацепиться, везде "наш главный актив - это люди". За ФИО руководства, где фамилия пишется на первом месте? За "няшно-зумерский" стиль и обращение на "ты"? Даже дизайн сайта не всегда показывает реальное положение вещей - иногда он может казаться заброшенным, но не потому что там всем пофиг, просто у людей работы много.
Лучший способ похоронить базу знаний — это спустить её сверху, обязать всех искать там информацию и бросить в таком состоянии.
Заглавное изображение идеально это подчеркивает. Мужчина в костюме (явно менеджер на корпоративе) понимает, что его участие здесь не требуется и направляется к более интересным проектам. Наверное, это все, что нужно знать, про управление знаниями.
Менеджер, секретарь проекта или любой другой человек, способный справиться с задачей.
В идеале должны быть 2 роли: тот, кто пишет, и тот, кто отвечает за написанное. К последней может относится аналитик проекта, который занят написанием ТЗ и писать что-либо еще у него нет времени. С другой стороны он больше в курсе актуальности информации. Техподдержка же может корректировать (дополнять) информацию практическими кейсами.
Для себя я делю контент на четыре типа
Тут зависит от контента, у меня была ситуация, когда все эти типы хочется видеть в одной статье (но подачу информации все равно нужно нормализовывать, не кидать все в кучу).
Под пользовательской документацией мы понимаем руководство пользователя...где юзер, не обращаясь в саппорт, может получить информацию о вашем продукте.
Однажды я пришел к выводу, что самый полезный подход - это сценарии - "как сделать то", "как сделать это", но для этого нужно хорошо понимать продукт.
Сначала хотел возразить, что начинать нужно именно с глоссария, но если уже есть какие-то разделы - то это более показательный пример, а глассарий собирать в фоновом режиме.
Касательно конфлюенса - там есть неприятная особенность, если дерево статей уже есть и проставлены ссылки на заголовки в этих статьях, то при переименовании самой статьи эти ссылки потеряют смысл. Так что структуру нужно продумывать с самого начала.
когда сотрудник был назначен ответственным, он стал обязан отвечать
Наверное не он, а ему, но во-первых, об этом все должны знать и во-вторых, об этом где-то должно быть написано - "автоматически предполагается" работает редко
По ГОСТу рекомендуется выделять в документе два раздела: «Обозначения и сокращения» и «Термины и определения». Предлагаю так и вести эти списки раздельно, чтобы для целей документа легко было найти нужное.
Можно писать в одном разделе и термины и сокращения. Например: "База знаний (БЗ)" - очевидно, что дублировать такое смысла мало.
ГОСТ также рекомендует алфавитный порядок – нет смысла тут спорить.
Дополню. В верхней строчке можно обозначить термин "Компания" (ООО "Рога и копыта"), а далее перечислить сокращения названий ее подразделений - так будет нагляднее, чем искать по алфавиту.
Почему поиск терминов и сокращений в тексте вообще является какой-то отдельной задачей, в чём проблема?
Потому что людям не свойственно договариваться по терминам. "У нас как-то так". Сам был свидетелем, когда в одном отделе слово "вьюха" носила двойной смысл. Где-то это представление в базе данных (т.е. витрина), а где-то GUI, то есть какая-то графическая оболочка.
Докладчик рассказывает материал, попутно зачитывая то, что уже и так написано на экране...
Добавлю:
Автор постоянно листает слайды туда-сюда ("ну типа тут и так все понятно"), слайды в разных презентациях и повествование получается рваным
Автор зачитывает текст на слайде, а не рассказывает про особенности тех или иных ситуаций
Есть еще один момент, на котором я стал настаивать при прохождении курсов - предоставить мне слайды заранее, чтобы я мог по ним немного подготовиться и идти на лекцию с вопросами. Но так мало кто делает.
Вообще, мое общее требование к любому курсу - понятный на выходе конспект. Либо автор поможет мне его сделать в ходе лекции, либо предоставит уже систематизированный материал. Если такого не происходит, то считаю курс провальным.
Не уверен, что полноценно совмещать системного и бизнесового аналитика - хорошая идея. Водитель и механик - разные роли, но один немного должен понимать работу другого, иначе как систему создавать
Спасибо, что не спросили про языки программирования, т.к. анализ данных же можно делать только в коде. Первый инструмент - это голова, без нее работать сложно. Однажды от руководителя проектного отдела услышал фразу "а зачем БА нужно знать SQL"....
Про метрики оценки базы знаний и роли:
https://habr.com/ru/companies/teamly/articles/1001044
Спасибо за метрики, полезно.
А как их посчитать?
Про контроль со стороны технического писателя или контент-менеджера:
Рейтинги просмотров полезны при создании FAQ. Правда, комментарии пишут редко, тут нужно скорее опрос ключевых пользователей проводить - тоже своего рода метрика;
Я бы добавил метрики тимлида или старшего специалиста поддержки - это же их зона ответственности: "как найти описание такого-то параметра и понятно ли написана статья";
Тимлид (а скорее техлид или аналитик) здесь больше нужен для контроля корректности с технической точки зрения.
Кажется, что роль «Knowledge Manager» едва ли приживется, т.к. в компаниях до сих пор не совсем понятен ее статус. С одной стороны, это продвинутая версия техписа, а с другой - чтобы построить нормальную базу, нужно выстроить процессы всех участвующих подразделений. То есть КМ должен быть на уровне с руководителями этих подразделений или иметь право требовать с них соответствующего исполнения.
Да! Просто начните писать :) Когда "все постоянно заняты" можно использовать старую добрую "бюрократию" - выделите себе ежедневный слот на "написание чего-нибудь". Например, есть же периоды для походов за кофе, перекуров и общения с коллегами - вот в такие моменты мысли работают лучше всего. Возвращайтесь и фиксируйте.
Здесь я бы рекомендовал создать глоссарий со всеми возможными синонимами. Повторять термины полезно, но без пересказа работы целого механизма - пусть это будет описано отдельно, вот на это место и ссылаться.
Информации может быть много, но важнее её подача - форматирование текста. Как минимум, разделять мысли на абзацы и использовать списки.
В формате базы знаний можно вставлять сворачивающиеся инфоблоки.
Уж точно не использовать страдательный залог - из текста должно быть понятно кто и что выполняет, система или пользователь (https://habr.com/ru/articles/772022/).
Даже лучше именно с этого и начинать - визуал обычно заходит быстрее текста и дольше запоминается. А еще так намного проще увидеть где чего не хватает.
А где и как это должно прописываться? Допустим, есть и workflow и регламент, но все же: "постоянные переделки, хаос в требованиях, конфликты между ролями и ощущение, что команда всё время занята". Что или с кем здесь не так?
В том-то и дело, что зачастую сайт компании неинформативен - на за что зацепиться, везде "наш главный актив - это люди". За ФИО руководства, где фамилия пишется на первом месте? За "няшно-зумерский" стиль и обращение на "ты"? Даже дизайн сайта не всегда показывает реальное положение вещей - иногда он может казаться заброшенным, но не потому что там всем пофиг, просто у людей работы много.
Заглавное изображение идеально это подчеркивает. Мужчина в костюме (явно менеджер на корпоративе) понимает, что его участие здесь не требуется и направляется к более интересным проектам. Наверное, это все, что нужно знать, про управление знаниями.
В идеале должны быть 2 роли: тот, кто пишет, и тот, кто отвечает за написанное. К последней может относится аналитик проекта, который занят написанием ТЗ и писать что-либо еще у него нет времени. С другой стороны он больше в курсе актуальности информации. Техподдержка же может корректировать (дополнять) информацию практическими кейсами.
Тут зависит от контента, у меня была ситуация, когда все эти типы хочется видеть в одной статье (но подачу информации все равно нужно нормализовывать, не кидать все в кучу).
Однажды я пришел к выводу, что самый полезный подход - это сценарии - "как сделать то", "как сделать это", но для этого нужно хорошо понимать продукт.
Как организовать базу знаний:
https://habr.com/ru/companies/oleg-bunin/articles/969600/
https://habr.com/ru/companies/oleg-bunin/articles/969606/
Сначала хотел возразить, что начинать нужно именно с глоссария, но если уже есть какие-то разделы - то это более показательный пример, а глассарий собирать в фоновом режиме.
Касательно конфлюенса - там есть неприятная особенность, если дерево статей уже есть и проставлены ссылки на заголовки в этих статьях, то при переименовании самой статьи эти ссылки потеряют смысл. Так что структуру нужно продумывать с самого начала.
это довольно спорный способ - всегда найдется сценарий, по которому статью посчитают бесполезной
Наверное не он, а ему, но во-первых, об этом все должны знать и во-вторых, об этом где-то должно быть написано - "автоматически предполагается" работает редко
Это же все в формат базы знаний переводить нужно!
Можно писать в одном разделе и термины и сокращения. Например: "База знаний (БЗ)" - очевидно, что дублировать такое смысла мало.
Дополню. В верхней строчке можно обозначить термин "Компания" (ООО "Рога и копыта"), а далее перечислить сокращения названий ее подразделений - так будет нагляднее, чем искать по алфавиту.
Потому что людям не свойственно договариваться по терминам. "У нас как-то так". Сам был свидетелем, когда в одном отделе слово "вьюха" носила двойной смысл. Где-то это представление в базе данных (т.е. витрина), а где-то GUI, то есть какая-то графическая оболочка.
О, про «altgr» вообще не знал, нашел как делать правильные кавычки :)
Дизайн... кто бы мне рассказал, зачем в макбуках существуют клавиши control и option? все равно же все через command делается
Найдешь ссылку?
Не факт, у меня был такой преподаватель в институте - просто подошел к задаче формально. Мы ему также и зачет сдавали, но важна была посещаемость
Добавлю:
Автор постоянно листает слайды туда-сюда ("ну типа тут и так все понятно"), слайды в разных презентациях и повествование получается рваным
Автор зачитывает текст на слайде, а не рассказывает про особенности тех или иных ситуаций
Есть еще один момент, на котором я стал настаивать при прохождении курсов - предоставить мне слайды заранее, чтобы я мог по ним немного подготовиться и идти на лекцию с вопросами. Но так мало кто делает.
Вообще, мое общее требование к любому курсу - понятный на выходе конспект. Либо автор поможет мне его сделать в ходе лекции, либо предоставит уже систематизированный материал. Если такого не происходит, то считаю курс провальным.
Вот поддержу, что ни новость, то перечень версий каких-то пакетов, то есть автор никак не опробовал на себе пользовательский опыт. Пост ради поста.
Не уверен, что полноценно совмещать системного и бизнесового аналитика - хорошая идея. Водитель и механик - разные роли, но один немного должен понимать работу другого, иначе как систему создавать
Спасибо, что не спросили про языки программирования, т.к. анализ данных же можно делать только в коде. Первый инструмент - это голова, без нее работать сложно. Однажды от руководителя проектного отдела услышал фразу "а зачем БА нужно знать SQL"....