2018-12-18: Управление знаниями - отдельная абстракция. Нужна ли она вам?
Знания и Управление знаниями - абстракции. Как "документ" среди накладных, платежек, договоров и т.п. Абстракцию документа можно выделять в коде - у тебя система документооборота, и дальше все - частные случаи. Можно в коде не выделять, но выделить логически на уровне набора паттернов реализации, отделить от справочников, для которых паттерны другие. А можно просто использовать как обобщенное слово, не вкладывая в него какого-то особого смысла.
Так и Знания и управление ими. Можно просто использовать как обобщенное понятие для управления требованиями, описания архитектуры, задач создания эксплуатационной документации и передачи в эксплуатацию, задач погружения нового члена команды разработки, инженера эксплуатации, пользователя, задач обучения специалиста, который пришел без профессиональной подготовки и многих других. И дальше решать эти частные задачи. При этом поляна - очень большая, задачи почти всегда решаются разными людьми и по-разному, в меру их понимания и концептуального представления о правильном, которые у всех разные. А можно выделить эту абстракцию - знания, хотя бы на уровне обсуждений между этими людьми, и дальше выделить обобщенные паттерны. И тогда задачи выделения важных знаний, подлежащих фиксации в виде концептуальных документов, которые поддерживаются актуальными; выделения знаний, которые надо фиксировать в документации к продукту, вынося из переписке в таск-трекере; задачи фиксации договоренностей по задачам и работе в трекере и протоколах встреч, выделенные из устного потока коммуникации и переписке в трекере - становятся частными случаями одной задачи отделения важного знания от не важного, и отделения знания, передаваемого документами от знания в устной традиции.
И как только мы выделяем абстракцию знаний, и ставим обобщенные задачи управления ими, происходит то же самое, что из документами. Пока это было обобщенное слово, у одних документов было состояние как выделенный атрибут, через который работает вся бизнес-логика, а у других - не было, было несколько атрибутов, на которые опирались. А там, где состояние документов было, применялись разные паттерны реализации (их не меньше четырех описано) и точно код был свой. Как только мы выделили абстракцию, тут же следующий логичный шаг - предписать общие паттерны реализации, а, может быть, и написать обобщенный код. И в этот момент ведущие разработчики/архитекторы не могут договориться, потому что каждый считает свой способ реализации хорошим, хоть и не лишенным недостатков, который поэтому стоит взять за основу и совершенствовать. И вот на этой основе договариваться согласен легко. А на основе чужого способа - не слишком, потому что для этого надо же его освоить - а чем он лучше? Послушать других - да, но не более.
Так и с управлением знаниями. Надо ли писать протоколы встреч и каких именно, и какой подробности: решения, заметки для тех, кто был или рассказ для тез, кто не был? Надо ли вести архитектурные описания проекта, и что в них должно быть? Надо ли выделять важные договоренности из потока переписке в таск-трекере и фиксировать их в постановке, какие, и кто это должен делать? Можно ли переписываться по задаче в приватном мессенджере, или вся переписка должна быть в задаче таск-трекере? Когда, наконец, надо прекратить переписку и поговорить голосом, и надо ли для этого идти ногами или ехать, или достаточно позвонить? Выделение абстракции предполагает, что ответы на эти вопросы - единообразны, иначе какой в ней смысл. С другой стороны, все проекты и продукты - разные, какой смысл пытаться сделать единообразную методику, будет ли от этого выгода? Как известно, обобщенный код может давать профит, а может служить оковами для разработки. Тут тоже самое. Нужна ли единообразная методика погружения нового члена команды разработки, нового инженера сопровождения, нового админа и нового пользователя, или это все - по-разному, в разных командах и для разных ролей?
Но даже если мы не делаем единообразные решения, выделение знаний как отдельной абстракции может нести вот какую дополнительную пользу. Мы можем видеть увидеть набор потенциально однородных задач, для каждой из которых существует набор шаблонов решения - и изучить их, воспользоваться ими. В мире, то есть за пределами IT-отрасли, абстракция управления знаний - выделена. И поставлены задачи управления и какие-то принципы решения. И владение этим аппаратом - полезно. Понимание, что не все надо переводить в документы, потому что это имеет свою цену, особенно поддержание актуальных документов, и не все можно перевести в документы, и устная традиция - вполне достойный способ передачи знания и задача управления как раз в поддержании этого баланса, разного для разных проектов и продуктов. Но, с другой стороны, как человек, активно заглядывающий в эту стороны с 2010 года, с первой книге Учитесь летать, которая ввела для меня эту абстракцию и первой конференции KM Russia (отчеты), я могу сказать, что там наработано не так много, по сравнению с тем, что наработано в IT для ведения архитектурных описаний и погружения нового члена команды разработки в продукт. В IT, пожалуй, наработано больше, правда, оно нагружено предметной спецификой.
При этом, как всегда есть принципы, с которыми все согласны, и есть практика. Все согласны концептуальные документы надо вести. А на практике их - дефицит. И там очень часто не прописаны концептуальные вещи, которые неявно понимаются теми, кто занимается предметом давно. Вон я недавно осваивал новую область WebGL 3d фреймворков. И для всех есть очень краткое концептуальное введение про представление в виде геометрии и материала, есть аналог hello world для быстрого старта, и reference. Для популярных - еще статьи-рассказы тех, кто осваивал. И, в принципе, быстрый старт на этом делается, а вот концептуальную картину не получишь. И даже решение частной, но нетривиальной задачи не найдешь - мне там в качестве объектов были нужны доски со сменными изображениями на грани, сделанными из фотографий. Доска - это box, тут все понятно, но дальше все грани - из треугольников, а не прямоугольников, и что делать? То, что надо сделать сложный объект из box и прямоугольника, и фото накладывать на прямоугольник - дошло сильно не сразу, и это такая вот концептуальная нетривиальность. И не нашел я таких описаний быстро. Штука в том, что такие есть в любой области. Я часто вспоминаю про собственное освоение SQL после процедурных языков. У меня совершенно четко был прорыв, когда я понял как писать запросы с join'ами, путешествуя по связям ER-диаграммы, и дальше все пошло легко. А в книгах об этом нет, там про реляционную алгебру, для которой SQL - всего лишь реализация, и на этом сложные join не напишешь.
В общем, заглядывание в чужие области, после установления соответствий, часто всего лишь позволяет понять, что проблемы - одинаковы, а не увидеть обобщенные решения. Впрочем, это тоже помогает мыслить об этом, искать свои решения, использовать чужие как источник вдохновения. Кроме того, там оказываются выявлены нетривиальные факты и решения. Например, реабилитация устной традиции. Или знание про отдельную позицию на форумах и сообществах знаний - те, кто понимает вопросы новичков в данной области и умеет по ним определить специалиста, которому адресован вопрос, да еще перевести этот вопрос понятным для специалиста образом. Оказывается, без этой позиции сообщества по управлению знаниями не живут, эксперты не понимают вопросов новичков, не опознают их как свои - это опыт IBM, когда они организовывали сообщества, и они получили его эмпирически, сравнивая сообщества, которые взлетели с теми, где само не получилось - дело оказалось в такой позиции, которую изначально в конструкцию не заложили.
На этом, пожалуй, все. Выводов и рецептов не будет. Нужна ли вам абстракция управления знаниями - решайте сами. У меня - есть, я об этом написал. А этот пост родился не просто так, он инициирован размышлениями про будущую конференцию по управлению знаниями, которую сейчас организовывает Олег Бунин и куда меня позвали в ПК. Будет предположительно в апреле, следите за новостями :)
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.