Что не надо делать при управлении знаниями

Не делать свою систему управления знаниями

Во-первых, есть много систем, которые подходят под хранение знаний, например wiki.
Во-вторых, пока будете делать систему управления знаниями, переругаетесь по поводу ее функционала и интерфейса. Когда система будет готова, выяснится что часть людей не хочет ей пользоваться из того принципа, что их требования не были учтены.
В-третьих, пока ее будут разрабатывать, само желание что-то где-то хранить может угаснуть.

Не предопределять структуру, в которую знания укладываются

Нет ничего хуже чем видеть красивое, но полупустое дерево каталогов.
Каждый участник должен иметь максимально простой способ скинуть знания в общий котел. Как их структурировать — разберетесь по ходу наполнения.
Теги рулят, но тут тоже нужно без фанатизма — они имеют плоскую структуру и в какой-то момент начнут конкурировать между собой за внимание пользователя.
Лучше начните с хорошего поиска по контенту.

Не вводить ограничения по доступу на изменения

Ну разве что можно ввести историю изменений.
Таким образом снимается вопрос «а разрешит ли мне система сделать то-то?» — порой сам такой вопрос уже останавливает человека.
Также это позволяет исправлять ошибки в чужой информации.
Не бойтесь, что все участники имеют полные и равные права. Вандалов у вас в компании нет, согласитесь?

Не запрещать выкладывать книги и копипастить интернет

Насчет книг — вопрос копирайтов. Тут можно подойти без фанатизма — база знаний локальная, поэтому правообладатели к вам не придут. Наверняка вы храните книги у себя на харде, так что можно сделать это и в общей базе знаний.

Копипастить статьи из интернета хорошо и полезно. Вы приносите новую информацию — это хорошо. Вы ее выставляете на всеобщее обозрение и предоставляете возможность обсудить ее значимость друг с другом — это полезно.
Возможность каждому участнику вносить изменения может привести к качественной переработке найденного в инете материала. Или его удалению, если вы закопипастили фигню.
Также полезно копипастить что-то из проектной докции, если вы считаете, что это будет хорошим примером. Хотя бы для вас.

Не делать ввод информации обязаловкой

Это очевидно — начнется или выкладка всякого псевдополезного мусора, или поиск причин чтобы ничего не выкладывать. Каждое из этих действий приведет к тому, что базой перестанут пользоваться.
В коллективе аналитиков основной элемент информации — совет. Вот пара вариантов:
  • Один аналитик говорит про предметку на своем проекте, другой говорит что у него есть в архивах нечто как раз по этой теме и советует это использовать, ищет и передает первому.
  • Один аналитик спрашивает, а нет ли примеров, скажем, схемы взаимодействия участников со стороны заказчика и исполнителя. Ему может ответить аналитик, ПМ или еще кто-то, дать совет и пример.
Вся информация, которая передается от одного человека к другому в этих примерах, является идеальным контентом для базы знаний.

Не считать, что все накопленные знания очевидны

А также не слушать умников, которые говорят, что все накопленные знания очевидны.
Знания становятся очевидными сразу после того, как вы их прочитали — это их свойство.

Не слушать тех, кто сокрушается, что текст на английском

Таких не берут в космонавты.

Не забывать про накопленные знания

Есть такая проблема — кинул текст в базу знаний, и с глаз долой, из сердца вон.
Чтобы про базу не забывали, можно вспоминать про нее на подходящих совещаниях — например, когда на скраме обсуждается как реализовать функцию, отобразить что-то в интерфейсе. При этом можно сообщать, что это уже описано / еще не описано в системе знаний. Если скачать что что-то еще не описано в базе — это галочка тому, кто будет составлять описание, чтобы скопипастить его потом в базу.

Комментарии

  1. "Каждый участник должен иметь максимально простой способ скинуть знания в общий котёл" без проработки вопроса "как их структурировать" и какого-то представления о том, как будет развиваться процесс дальше приведёт к хаосу.

    Энергичные джуниоры заспамят базу всякой ерундой из самых лучших побуждений, так, что потом ничего в ней уже не раскопаешь никаким поиском.

    Рассчитывать, что сработает эффект википедии, когда весь процесс как-то самоорганизуется во что-то осмысленное я не стал бы. Количество участников слишком мало и мотивация их другая.

    Не будет опытный аналитик тратить время на разгребание ерунды, которую наложил его энергичный молодой коллега, у которого и свободного времени побольше.

    Опят же в википедии можно и посутяжничать и повоевать если с чем-то не согласен. На работе никто отношения с коллегами портить не будет ради какой-то ерунды.

    ОтветитьУдалить
    Ответы
    1. На моей практике хаоса не случилось. Аналитики довольно осмотрительны в выкладке знаний и советуются со старшими и с овнером в том, что выкладывать и что нет.
      Сложно было только договориться в начале о структуре, но довольно быстро все устаканилось и заработал эффект "так принято".

      Сравнение с википедией тут не совсем корректно, потому что у систем разные цели и разные аудитории — как читатели, так и те, кто вводит информацию.

      Поделитесь вашим опытом управления знаниями среди аналитиков? Как у вас это устроено, какие основные правила работы со знаниями?

      Удалить
    2. Гриша, а какие вы цели преследовали, когда создавали базу знаний? Зачем она была вам нужна? Просто ответ на этот вопрос поможет понять всё то, о чем ты говоришь. А без него есть острое желание спорить по каждому пункту :)

      Удалить
    3. 1. Чтобы люди не наступали на одни и те же грабли - примеры хороших документов из проектов.
      2. Чтобы не тратили время на поиски того, что у нас уже есть - учебник по UML, например.

      Удалить
  2. Ещё одна мысль про "не запрещать выкладывать книги", мне кажется это не совсем про управление знаниями.

    Хорошо бы сделать упор именно на эксклюзивный контент, которого нет в интернете. Особо на информацию с реальножизненных проектов.

    Наложить PMBOK'ов и BABOK'ов и рассчитывать, что процесс управления знаниями пошёл - смешно.

    В работе в книжку хочеться слазить редко, а вот хороший пример посмотреть хочется часто.

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Карта компетенции аналитика

Оценка эффективности работы руководителя проектов

Драйв