Оранжерея знаний с MediaWiki

Короткая ссылка: Mediawiki-knowledge-conservatory

Ссылки сюда (4) →

• Стас Фомин, заместитель директора по информационным технологиям компании CUSTIS.
• «Оранжерея знаний с MediaWiki»

---

Управление знаниями—область достаточно молодая, с неясно очерченными границами, включающая как программную, так и социальную инженерию. Упоминания «knowledge management» в интернете и публикациях часто склоняются к крайним взглядам:

«Библиотекарский»

Знания — это то, что надо хранить целостно в некоторой библиотеке, куда нужно все занести, каждый элемент детально описать и каталогизировать, «составить карточки», далее выдавать по атрибутным запросам. Управление заключается в контроле над этим процессом. Это основа разного рода систем документооборота и прочих библиотек, выдаваемых за «базы знаний».

«Менеджерский»

«Библиотека» — это утопия, основной объем знаний всегда остается в головах сотрудников, поэтому надо занимать «проактивную» позицию, шевелить людей, сбивать их в сообщества, проводить собрания-семинары-конференции. Для этого нужны специально обученные люди, сводящие ищущих со знающими, занимающиеся «фасилитацией» общения и оргвопросами, — и все это представляет разновидность обычного организационного менеджмента. Типичный пример популярной книги от гуру Knowledge Management с такой позицией — «Learning to Fly: Practical Knowledge Management from Leading and Learning Organizations».

К сожалению, русский перевод-калька «Управление Знаниями» не совсем соответствует исходному понятию. «Управление» ближе к «контролю», а «management» тут скорее «забота и обеспечение». А ожидаемая цель «Knowledge Management-a» — не бесконечный затратный процесс с «ручным приводом, бурлаками и аниматорами», а обеспеченное инфраструктурой состояние организации, когда с минимальными накладными расходами знания фиксируются и распространяются по всем доступным каналам, где спрашивающие эффективно получают ответы и знакомятся с экспертами по своим темам.

При этом важно нащупать работающий компромисс между крайними точками разных граней:

• Измерение «ПЗУ vs. ОЗУ» — все ли должно быть 100% формально зафиксировано, разложено по полочкам, прошито семантическими связями? К этому стремятся тяжелые системы управления требованиями. Или пусть все будет в головах, просто нужно больше общаться? Это Agile-подход.
• Грань «Полнота или актуальность?» — надо ли стремиться к широте в ущерб актуальности, или бороться за целостность? «Обо всем, с ошибками» или «точно, но о малом»?
• Субъективность «авторского взгляда» или выстраданные компромиссы?
• Передача знаний — «PUSH vs. PULL» — «Толкать в людей» или дать им свободу «тянуть то, что им нужно»?
• Синхронные или асинхронные процессы?

Получившаяся инфраструктура должна быть достаточно удобна для массового использования без существенной мотивации, ведь премиями или угрозой штрафов и увольнения пользователя можно заставить работать со сколь угодно неудобной системой, а тут ожидается «Счастья всем, даром, и пусть никто не уйдет обиженным» ©.

Откуда же ждать такие системы и инструменты? Ведь полно примеров неработающих дорогих систем: установленных и внедренных, которыми сотрудники так и не стали пользоваться. И возникает желание решить проблему менеджерскими методами, мотивировать сотрудников работать с системой — «премия наиболее активным пользователям портала». Это опасно, ибо подменяет истинную мотивацию, и если «перестать платить за любовь» — все будет кончено. Тут очень уместна притча о пенсионере и хулиганах:

Хулиганы каждый день беспокоили одного старика, играли в футбол в его дворе, шумели и т.п. Рычагов воздействия у пенсионера никаких не было. Тогда он сказал, что эта игра ему нравится, и стал давать каждому гопнику по доллару «за работу» — каждую игру в его дворе. После такой недели он, с видимым сожалением (кризис!), урезал оплату до 50 центов. Еще через неделю — до 25. В следующий раз шпана уже не пришла — «нашел дураков вкалывать за копейки».

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

Например, open-source системы поддержки разработки гораздо гуманней, ведь в мире проектов с открытым кодом обычно нет материальной власти менеджеров над участниками и нельзя навязать жесткие процессы или инструменты. Более подробно см. книгу «Producing Open Source Software»

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

А именно, появились:

Закладки

Самая первая парадигма, сбор находок в безбрежном интернете. Затем они эволюционировали в сетевые закладки и даже в «закладки-цитаты» — Google Notebook, Evernote.

Блоги

Простейшая фиксация «ответов на не заданные вопросы». Минимальные «налоги» на регистрацию — не нужно классифицировать и актуализировать. Каждая запись — это только мнение автора на момент публикации.

Форумы

Место, где вопросы встречаются с ответами. Здесь уже есть попытка найти объективную истину или хотя бы собрать спектр мнений. Опять-таки, актуализировать ничего не требуется, представлен весь спектр мнений вокруг одного вопроса, а вычленение сухого остатка — обычно работа читателя.

Вики-системы

То место, где выжимаются актуальные и объективные знания, после чего они классифицируются и обрастают семантическими связями.

Основным средством доступа стали:

Полнотекстовый поиск

Все научились «гуглить» и, даже если есть отличная документация, пользователям так быстрее найти ответы на свои конкретные вопросы.

Концепция RSS/Atom-каналов

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

Почему бы не присмотреться к этим инструментам и шаблонам их использования, а потом инсталлировать лучшие экземпляры у себя в компании и дать сотрудникам привычные для образованного человека третьего тысячелетия интерфейсы и практики? Вместо того, чтобы размещать очередную «Библиотеку» или «Систему документооборота», где все основано на бумажных метафорах доинтернетной эры.

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

• Установить только какую-нибудь вики-систему, и ждать, когда она сама наполнится знаниями — Получилось в мировом масштабе «Википедии», значит и у нас все будет ОК. Но «Википедия» работает на мощности огромного числа авторов и редакторов и упор там сделан не на полноту, а на целостность и актуальность — удаление недостаточно важного, недостаточно объективного, не имеющего твердых доказательств и т.п. В масштабе компании так делать нельзя — надо «допустить» информацию разной степени актуальности и обновляющие её «дельты». Именно это и обеспечивает «поток» информации в противовес модели склада. И это как раз модель блогов и форумов. И дать персональное пространство для хранения личного опыта.
• «Дать людям все! © к/ф. Фонтан». Установить и вики-систему, и блоги, и форумы, и закладки! Увы, в этом случае возникает конфликт использования — разные интерфейсы систем, невозможность переноса содержимого из-за несовместимых форматов разметки и концепций ссылок и т.п.

Что же делать? Хорошие новости! На самом деле все стандартные системы блогов/форумов/закладок созданы для агрессивной внешней интернет-среды, где нужно учитывать противодействие спаму, вандалам и идиотам. Даже вики-системы справляются только благодаря активному сообществу — заброшенная вики очень быстро превращается в ферму ссылок для SEO-спаммеров.

Но внутри компании, в интранете — доверенная среда, где, если обнаруживается спаммер/вандал/идиот — это радость для HR службы: ему можно вправить мозги или уволить, пока он не наломал серьезных дров. В компании можно создать не просто «сад знаний», а настоящую оранжерею на базе мощной вики-системы, что невозможно в Большом Интернете — ведь там мало кто согласится вести блог, который сможет испортить любой прохожий. В компании становятся осмысленными даже микроблоги. Ведь твит в Интернете о том, что какой-то «sdk756f разобрался с технологией XXX» несет практически нулевую информацию. Ну разве что эта технология настолько редка и важна для вас, что вы попробуете с ним связаться. Совсем другое дело, если это заметка от «Васи из соседнего отдела» — теперь, когда вы нашли этот микропост-маркер, вы знаете, с кем эту тему можно обсудить, а сделать запись Васе ничего не стоило!

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

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

Да, информация в блогах и форумах может стать:

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

И все это не теоретические соображения, а реальный опыт: именно такое расширение «ВикиЛоги» MediaWiki мы реализовали в нашей компании. Широк спектр обсуждаемых в компании тем — от политических и организационных новостей в блоге генерального директора, до жарких технологических споров с сотнями комментариев, в которых, если и не рождается истина, то, по крайней мере, составляется резюме возможных проблем и решений, а участники определяются с позицией. Выросла и вовлеченность сотрудников в процесс наполнения базы знаний.

---

Да, «блогосфера» взлетела не сразу, ведь не все сотрудники «продвинутые интернетчики», сначала пришлось показывать пример, вести «блог команды», «политические и инфаструктурные новости», «обзоры книг» — а затем — все полетело само! Начался активный обмен опытом, рефлексия над практиками и культурой компании, и т.п.

Некоторое представление об этом взрывном росте, можно получить с помощью этого инфографического ролика:

(Сделан с помощью ShowTeamWork).

---

Иногда еще встречается мнение, что вики-системы — это какие-то унылые поделки для программистов и прочих гиков, у которых нет денег на «что-то серьезное от солидного вендора». Это не так. Добротные вики-системы являются отличным компромиссом между эффективностью фиксации и актуализации знаний и их простотой и доступностью для всех категорий сотрудников. Важно запомнить: правильная вики-система — это не когда «все плоским текстом», а когда «быстро-быстро». Т.е. можно грузить сколь угодно «богатый» контент — фото, видео, скринкасты, звук, диаграммы, майндмапы, статьи и книги в PDF/DjVu и, на худой конец, просто документы в офисных форматах.

А мощность самой концепции позволяет использовать вики практически для всего, хоть как-то попадающего в категории «база знаний» и «публикация материалов». Единственная уязвимость веб-контента — это неудобство при выполнении постраничной верстки для бумажной печати (которая, впрочем, становится все менее ценной). Более подробно все это разобрано в статье «MediaWiki — Серебряная пуля или швейцарский нож?»

Осталось поговорить о «Закладках» или, вернее, о «Вырезках» — ведь нечто схожее аналитики доинтернетной эры, пользуясь ножницами и кнопками, вытворяли с газетами. Они очень важны при Knowledge Miningе во внешнем интернете — ведь сейчас пользователь компьютера совсем не похож на «оператора ЭВМ», сидящего перед клавиатурой с 10:00 до 18:00. Мы постоянно «серфим» в интернете — ноутбуки и прочие девайсы сделали возможным чтение/просмотр информационных потоков в любом месте и положении, на улице и в туалете, стоя, лежа и сидя. Чисто физически приходится разделять режимы «Читателя» и «Аналитика-Реализатора»: заметив интересное, выделить важное, чтобы позже, сидя за столом, проанализировать и применить. Или обратить внимание экспертов или ответственных товарищей на что-то важное. Например, можно собрать ключевые цитаты из книги или статьи, чтобы потом написать рецензию. Или добавить ссылки-заметки на плюсы и минусы технологии, а затем заняться их реальной проверкой. Или отметить активность конкурентов, чтобы отдел маркетинга сделал правильные выводы.

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

Как вы уже, наверное, догадались, мы сделали свой сервис «ВикиЗакладки» на базе MediaWiki. Там можно завести неограниченное число «каналов закладок» — статей, где будут размещаться ссылки и вырезки. Для добавления закладки и вырезки нужно всего лишь выделить интересное в броузере и нажать кнопку букмарклета. Сервис работает во всех броузерах без инсталляции. Закладки можно вести в одиночку и коллективно («Сводки аналитического отдела по рыночному сектору X»), разделять по темам («Книга YYY») или перемешивать. Закладки автоматически сортируются в хронологическом порядке по разделам статьи, но хранить их вечно не обязательно. Лучше время от времени разбирать их: на основе каких-то писать новые или дополнять существующие статьи базы знаний, какие-то превращать в реализованные проекты. А что-то вскоре потеряет важность и эти закладки можно будет стереть. Все это делается быстро, ибо интерфейс самый эффективный — редактирование теста: copy-paste, перенос и удаление блоков.

Чтобы сделать «pull»-интерфейс, нужно уметь превращать в RSS-поток любое изменение, будь то свежий пост в блоге, новая статья, закладка, редактирование и другие гибко задаваемые события. И сделать удобной подписку на эти каналы, с централизованной агрегацией и веб-интерфейсом, чтобы можно было их просматривать откуда угодно, быстро и удобно, — короче, сделать внутри-корпоративный «Google Reader». Мы сделали и его — это система «FeedOnFeeds»!

Реализован отличный полнотекстовый поиск с русской морфологией по всей вики-системе, включая блоги-форумы-закладки, с настраиваемым выбором пространства поиска: например, можно искать в «блогах» или наоборот, везде, кроме них.

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

---

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

Общеизвестен софизм Горгия: «Ничто не существует; если и существует, то оно не познаваемо; если оно и познаваемо, то непередаваемо». И трудно с ним не согласится: просто диву даешься, насколько люди склонны пропускать или неверно трактовать элементарные регламенты!

Но выход есть! Как прочность программного обеспечения увеличивается при покрытии кода проверочными тестами, так и надежность передачи знаний увеличится, если сопроводить ее «автоматическими проверочными тестами на понимание».

Система тестов с выбором вариантов — классический подход GMAT, GRE, ЕГЭ и даже тренажера ПДД. При всей критике, это очень дешево и эффективно. Ведь критикуют именно систему оценивания, с линейной зависимостью от числа баллов. А достаточно просто отсекать «тяжелые случаи», тугодумов или лентяев, и дополнять оценку по другим критериям. И очень эффективно использовать систему тестов в роли тренажера-симулятора.

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

Тесты могут работать как в проверочном режиме, так и в обучающем: «вы выбрали не тот вариант, правильно так-то и потому-то». Если использовать MediaWiki для публикации курсов и MediaWikiQuizzer-тесты, то никакие «профессиональные системы e-learningа», скорее всего, не потребуются. Ведь остальной бюрократический функционал (учет студентов, оценок), предлагаемый этими системами, в организации разумного размера и с нормальными отношениями попросту не нужен.

И еще об обучении: Mediawiki можно использовать не только в режиме «человек-компьютер», но и для передачи знаний «человек-человек» — а именно, для семинаров и курсов со слайдами.

Широко известны проблемы правильных слайдов:

• Автор пытается угнаться за двумя зайцами: подготовить слайд-презентацию, которую можно одновременно и показывать во время доклада, и раздавать для самостоятельного чтения. Из-за этого получаются страшные «слайдоменты» — гибриды «слайдов и документов», совершенно бессмысленные для выступления.
• Авторы не могут работать совместно: быстро параллельно редактировать слайды.
• Нет богатых возможностей семантической подготовки материала, таких как автоматическое построение графов и диаграмм, раскраски исходных кодов и т.п. — все это приходится делать вручную и повторять при изменении материала.
• Хочется включать мультимедиа контент на современном уровне — видеоролики, майднмапы, анимацию и т.п.
• Сложно делать целостный reusable контент — например, составлять презентации для разных аудиторий из одних и тех же блоков слайдов.

Мы решили и эту задачу, реализовав MediaWiki-расширение «S5SlideShow», позволяющее выпускать «гибридные» статьи, пригодные и для чтения, и для показа в виде слайдов.

К сожалению, объем бумажной статьи ограничен и «за бортом» осталось много наших MediaWiki-изобретений: календарь с системой регистрации, совместное редактирование изображений и много другое.

Но для читателя важны два момента:

• MediaWiki «расцветает» в «оранжерее» корпоративного интранета, огражденная от вандалов и спаммеров, и на ней можно удобно реализовать все привычное для обмена знаниями: блоги, форумы, закладки, слайды, проверочные тесты.
• Мы не просто «делимся опытом», а выложили все наши доработки в open-source и предлагаем всем заинтересовавшимся совершенно бесплатно установить все это у себя: просто зайдите по адресу http://wiki.4intra.net/Mediawiki4Intranet.

---

Репликация: База Знаний «Заказных Информ Систем» → «Оранжерея знаний с MediaWiki»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

---