конкурентоспособность определяется не только станками и капиталом, но и способностью быстро учить людей новым инструментам, языкам, интерфейсам, системам управления и инженерным практикам
Интересно, а будет ли как в Матрице, и насколько вообще будут важны знания, если их сможет получить любой за 5 секунд загрузки?
По статье. Наверное стоило бы выделить критерии "Разрозненность. Неактуальность" и т.п. в подзаголовки, чтобы не сливались с текстом. Рисунки понравились, т.к. поясняют текст, однако "схему взаимодействия" стоит перекрасить, чтобы лучше видеть акторов.
Наверное сложно только первое время или если нет хорошего базового образования. Не думаю, что каждая новая технология фундаментально отличается от предыдущей. В какой-то момент начинаешь понимать общий принцип, где меняются только названия и иконки
Deflection Rate — коэффициент предотвращенных обращений. Это процент пользователей, которые получили ответы в базе и не создали тикет.
CES (Customer Effort Score) — измеряет, сколько усилий потребовалось клиенту для решения проблемы: как долго искал ответ, сколько статей открыл.
А как их посчитать?
Про контроль со стороны технического писателя или контент-менеджера:
Рейтинги просмотров полезны при создании FAQ. Правда, комментарии пишут редко, тут нужно скорее опрос ключевых пользователей проводить - тоже своего рода метрика;
Я бы добавил метрики тимлида или старшего специалиста поддержки - это же их зона ответственности: "как найти описание такого-то параметра и понятно ли написана статья";
Тимлид (а скорее техлид или аналитик) здесь больше нужен для контроля корректности с технической точки зрения.
Кажется, что роль «Knowledge Manager» едва ли приживется, т.к. в компаниях до сих пор не совсем понятен ее статус. С одной стороны, это продвинутая версия техписа, а с другой - чтобы построить нормальную базу, нужно выстроить процессы всех участвующих подразделений. То есть КМ должен быть на уровне с руководителями этих подразделений или иметь право требовать с них соответствующего исполнения.
Да! Просто начните писать :) Когда "все постоянно заняты" можно использовать старую добрую "бюрократию" - выделите себе ежедневный слот на "написание чего-нибудь". Например, есть же периоды для походов за кофе, перекуров и общения с коллегами - вот в такие моменты мысли работают лучше всего. Возвращайтесь и фиксируйте.
Пятое. Не бойтесь тавтологии.
Здесь я бы рекомендовал создать глоссарий со всеми возможными синонимами. Повторять термины полезно, но без пересказа работы целого механизма - пусть это будет описано отдельно, вот на это место и ссылаться.
1.Следите за объемом информации. Если ее много, читать вряд ли будут внимательно или полностью. Практика показывает, что длинные тексты мало кому нравится читать.
Информации может быть много, но важнее её подача - форматирование текста. Как минимум, разделять мысли на абзацы и использовать списки.
2.Не распыляйте внимание на детали. Одного-двух предложений будет достаточно.
В формате базы знаний можно вставлять сворачивающиеся инфоблоки.
5.Лучшее решение – порядок слов прямой!
Уж точно не использовать страдательный залог - из текста должно быть понятно кто и что выполняет, система или пользователь (https://habr.com/ru/articles/772022/).
7.Смело добавляйте схемы, картинки и скриншоты для визуализации.
Даже лучше именно с этого и начинать - визуал обычно заходит быстрее текста и дольше запоминается. А еще так намного проще увидеть где чего не хватает.
Если управляемость системы определяется переходами между состояниями, то эти переходы не могут быть произвольными. Для них должны существовать правила, ограничивающие допустимые переходы и делающие их проверяемыми.
До тех пор, пока жизненный цикл продукта не зафиксирован как модель состояний и переходов, любые роли, инструменты и методологии работают вхолостую.
А где и как это должно прописываться? Допустим, есть и workflow и регламент, но все же: "постоянные переделки, хаос в требованиях, конфликты между ролями и ощущение, что команда всё время занята". Что или с кем здесь не так?
Если человеку реально настолько интересна шарага, он и подготовится, изучив её историю-миссию-ценности-прочую фигню, и сам об этом расскажет.
В том-то и дело, что зачастую сайт компании неинформативен - на за что зацепиться, везде "наш главный актив - это люди". За ФИО руководства, где фамилия пишется на первом месте? За "няшно-зумерский" стиль и обращение на "ты"? Даже дизайн сайта не всегда показывает реальное положение вещей - иногда он может казаться заброшенным, но не потому что там всем пофиг, просто у людей работы много.
Лучший способ похоронить базу знаний — это спустить её сверху, обязать всех искать там информацию и бросить в таком состоянии.
Заглавное изображение идеально это подчеркивает. Мужчина в костюме (явно менеджер на корпоративе) понимает, что его участие здесь не требуется и направляется к более интересным проектам. Наверное, это все, что нужно знать, про управление знаниями.
Менеджер, секретарь проекта или любой другой человек, способный справиться с задачей.
В идеале должны быть 2 роли: тот, кто пишет, и тот, кто отвечает за написанное. К последней может относится аналитик проекта, который занят написанием ТЗ и писать что-либо еще у него нет времени. С другой стороны он больше в курсе актуальности информации. Техподдержка же может корректировать (дополнять) информацию практическими кейсами.
Для себя я делю контент на четыре типа
Тут зависит от контента, у меня была ситуация, когда все эти типы хочется видеть в одной статье (но подачу информации все равно нужно нормализовывать, не кидать все в кучу).
Под пользовательской документацией мы понимаем руководство пользователя...где юзер, не обращаясь в саппорт, может получить информацию о вашем продукте.
Однажды я пришел к выводу, что самый полезный подход - это сценарии - "как сделать то", "как сделать это", но для этого нужно хорошо понимать продукт.
Сначала хотел возразить, что начинать нужно именно с глоссария, но если уже есть какие-то разделы - то это более показательный пример, а глассарий собирать в фоновом режиме.
Касательно конфлюенса - там есть неприятная особенность, если дерево статей уже есть и проставлены ссылки на заголовки в этих статьях, то при переименовании самой статьи эти ссылки потеряют смысл. Так что структуру нужно продумывать с самого начала.
Как раз этим и славится хорошее базовое образование - оно помогает проще и быстрее адаптироваться, если контекст постоянно меняется.
Интересно, а будет ли как в Матрице, и насколько вообще будут важны знания, если их сможет получить любой за 5 секунд загрузки?
Да, хотелось бы, чтобы текст был более понятным, без этого:
Хороший цикл статей, полезный, хотелось бы почитать в переводе на русский язык.
По статье. Наверное стоило бы выделить критерии "Разрозненность. Неактуальность" и т.п. в подзаголовки, чтобы не сливались с текстом. Рисунки понравились, т.к. поясняют текст, однако "схему взаимодействия" стоит перекрасить, чтобы лучше видеть акторов.
Ваш комментарий недостаточно подробный, а именно: не совсем понятно как чтение руководства связано с работой, тут можно еще пару абзацев написать :)
Дополню в комменты к https://habr.com/ru/articles/830584/
А почему его зовут «Хрен попадешь»? — Потому что в него хрен попадешь :)
Нельзя не запостить плохие примеры к 1 апреля - https://habr.com/ru/articles/1016642/
Практические примеры: https://vkvideo.ru/playlist/-223804668_4/video-223804668_456239165?linked=1
Наверное сложно только первое время или если нет хорошего базового образования. Не думаю, что каждая новая технология фундаментально отличается от предыдущей. В какой-то момент начинаешь понимать общий принцип, где меняются только названия и иконки
Про метрики оценки базы знаний и роли:
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/
Сначала хотел возразить, что начинать нужно именно с глоссария, но если уже есть какие-то разделы - то это более показательный пример, а глассарий собирать в фоновом режиме.
Касательно конфлюенса - там есть неприятная особенность, если дерево статей уже есть и проставлены ссылки на заголовки в этих статьях, то при переименовании самой статьи эти ссылки потеряют смысл. Так что структуру нужно продумывать с самого начала.
это довольно спорный способ - всегда найдется сценарий, по которому статью посчитают бесполезной