Сформулируйте одну, локальную проблему с управлением знаниями — и это уже принесёт пользу, ведь хорошо сформулированный вопрос — это уже половина ответа.

Например, вы нашли:

  • Проект/часть проекта, в котором плохо разбирается команда

  • Хороший приём и хотите сделать его общим соглашением

  • Бизнес-критичное знание (доступы, контакты, договорённости и т.п.), которое не зафиксировано и не зарезервировано

  • Насколько устаревшую статью, что она стала вредной

  • Проблему, которая повторяется уже более 3х раз и каждый раз "съедает" много времени

  • Группу задач, которые "подвисают" при уходе в отпуск уникального эксперта

Формулировка проблем в том виде, в каком её поймут и осознают её серьёзность —— одна из задач Управления Знаниями.

Как отличить хорошо сформулированный вопрос?

Универсальную методику, позволяющую находить и формулировать проблемы, сделать невозможно. При разговорах о проблемах вы можете встретить разные формы сопротивления, например:

  • Эта проблема не важна, есть более важные

  • Этой проблемы вовсе нет

  • Нужно экономическое, либо какие-то другие обоснования (которые, на самом деле, не всегда возможны и не всегда нужны)

Корень возражений зачастую совсем в другом, например:

  • Ваш коллега не понимает возможных решений проблемы, поэтому отрицает саму проблему (у некоторых людей есть такой защитный механизм)

  • Ваш коллега не хочет тратить силы на вникание, но и не доверяет вам, поэтому рассказывает вам про более важные задачи (таким образом, как бы обесценивая вашу проблему)

  • Ваш коллега убеждён, что решение проблем, вроде той, которую вы озвучиваете, не принесёт ему выгоды (из-за своих представлений о жизни и ценностях, отличных от ваших)

и многие, многие другие.

Если вам дали отказ — это не значит, что вы не правы. Чтобы быть увереннее — нужно разобраться самостоятельно.

Допустим, вы говорите: "В платёжном модуле modulename разбирается только Вася — это беда!". Что было бы неплохо выяснить для формулировки проблемы?

  • Найти наглядные доказательства: конкретные разговоры, ссылки, чаты переписки, зарегистрированные в трекерах факты. В случае с modulename — можно опросить всю команду и убедиться, что действительно никто не разбирается в этим модулем, либо найти список людей, которые выполняли задачи по модулю в таск-трекере, либо посмотреть историю коммитов в системе контроля версий.

  • Разобраться в том, как проблема затрагивает бизнес. В случае с modulename — платёжный модуль может быть единственным источником прибыли (если это онлайн-касса), либо дополнительной функцией, не особенно использующейся клиентами

  • Предположить, в чём станет лучше, когда проблема будет решена? — этот вопрос ключевой и отвечать на него может быть непросто, но как-то попробовать сформулировать — нужно.

  • Хотя бы предположить и внятно сформулировать почему проблему до сих пор не решили?. В стартапе, к примеру, могут игнорировать многие бизнес-критичные проблемы, потому что менеджмент опасается каких-то другие, более существенных, на их взгляд, проблем.

и другие