|
Персональные инструменты |
|||
|
Оранжерея знаний с MediaWikiМатериал из CustisWikiКороткая ссылка: Mediawiki-knowledge-conservatory
Управление знаниями—область достаточно молодая, с неясно очерченными границами, включающая как программную, так и социальную инженерию. Упоминания «knowledge management» в интернете и публикациях часто склоняются к крайним взглядам:
К сожалению, русский перевод-калька «Управление Знаниями» не совсем соответствует исходному понятию. «Управление» ближе к «контролю», а «management» тут скорее «забота и обеспечение». А ожидаемая цель «Knowledge Management-a» — не бесконечный затратный процесс с «ручным приводом, бурлаками и аниматорами»[2], а обеспеченное инфраструктурой состояние организации, когда с минимальными накладными расходами знания фиксируются и распространяются по всем доступным каналам, где спрашивающие эффективно получают ответы и знакомятся с экспертами по своим темам. При этом важно нащупать работающий компромисс между крайними точками разных граней:
Получившаяся инфраструктура должна быть достаточно удобна для массового использования без существенной мотивации, ведь премиями или угрозой штрафов и увольнения пользователя можно заставить работать со сколь угодно неудобной системой, а тут ожидается «Счастья всем, даром, и пусть никто не уйдет обиженным» ©. Откуда же ждать такие системы и инструменты? Ведь полно примеров неработающих дорогих систем: установленных и внедренных, которыми сотрудники так и не стали пользоваться. И возникает желание решить проблему менеджерскими методами, мотивировать сотрудников работать с системой — «премия наиболее активным пользователям портала»[3]. Это опасно, ибо подменяет истинную мотивацию, и если «перестать платить за любовь» — все будет кончено. Тут очень уместна притча о пенсионере и хулиганах:
А как сделать, чтобы все это заработало без материального подогрева и смазки? Забегая вперед, скажем, что все наши решения, о которых мы расскажем, уже есть, проверены нашим опытом, и можно использовать совершенно бесплатно! Например, open-source системы поддержки разработки гораздо гуманней, ведь в мире проектов с открытым кодом обычно нет материальной власти менеджеров над участниками и нельзя навязать жесткие процессы или инструменты. Более подробно см. книгу «Producing Open Source Software» Оказалось, надо всего лишь присмотреться к процессам, происходящим в Большом Интернете, где различные тематические сообщества уже десятилетия решали все эти задачи, и эволюционно сложился набор систем, интерфейсов и практик массово удобных и эффективных. А именно, появились:
Основным средством доступа стали:
Почему бы не присмотреться к этим инструментам и шаблонам их использования, а потом инсталлировать лучшие экземпляры у себя в компании и дать сотрудникам привычные для образованного человека третьего тысячелетия интерфейсы и практики? Вместо того, чтобы размещать очередную «Библиотеку» или «Систему документооборота», где все основано на бумажных метафорах доинтернетной эры. Это будет антипод инженерного подхода типа «есть задача — разработать конструкцию для ее решения», после чего все это пустует, как заброшенные промздания. Тут скорее «агротехника» — высаживается правильная жизнеспособная рассада, обеспечивается поливка и прочая инфраструктура, а дальше нужно наблюдать за внутренними тенденциями, внося коррективы лишь по необходимости. И такое садоводство, по крайней мере в IT-компаниях, встречается все чаще, ударяясь в одну из двух крайностей:
Что же делать? Хорошие новости! На самом деле все стандартные системы блогов/форумов/закладок созданы для агрессивной внешней интернет-среды, где нужно учитывать противодействие спаму, вандалам и идиотам. Даже вики-системы справляются только благодаря активному сообществу — заброшенная вики очень быстро превращается в ферму ссылок для SEO[5]-спаммеров. Но внутри компании, в интранете — доверенная среда, где, если обнаруживается спаммер/вандал/идиот — это радость для HR службы: ему можно вправить мозги или уволить, пока он не наломал серьезных дров. В компании можно создать не просто «сад знаний», а настоящую оранжерею на базе мощной вики-системы, что невозможно в Большом Интернете — ведь там мало кто согласится вести блог, который сможет испортить любой прохожий. В компании становятся осмысленными даже микроблоги. Ведь твит[6] в Интернете о том, что какой-то «sdk756f разобрался с технологией XXX» несет практически нулевую информацию. Ну разве что эта технология настолько редка и важна для вас, что вы попробуете с ним связаться. Совсем другое дело, если это заметка от «Васи из соседнего отдела» — теперь, когда вы нашли этот микропост-маркер, вы знаете, с кем эту тему можно обсудить, а сделать запись Васе ничего не стоило! Так вот, можно реализовать все концепции: закладки, блоги, форумы и вики на базе одной системы, наиболее мощной из всех. А именно — качественной вики, такой как MediaWiki! Т.е. получить все, да еще бонусы вики-систем: совместное редактирование, управление версиями, удобную разметку, поддержку шаблонов и разнородного мультимедиа контента! Внимательно присмотревшись, можно даже убрать концептуальный раздел между блогами и форумами — это на самом деле одно и то же, вопрос только в представлении и классификации. В обоих случаях это список блоков «тема, сообщение, обсуждение». Но блоги — это в первую очередь хронологическая лента сообщений от отдельного автора, а форум — это «самое свежее от всех», т.е. только что опубликованные темы, либо те, где уже кипит обсуждение. Технически это может быть единая система, просто имеющая два представления — «Блоги» и «Форумы» — и не возникает никакого ментального барьера, куда писать сотруднику, когда у него возникла мысль или вопрос, или то и другое одновременно. Да, информация в блогах и форумах может стать:
И все это не теоретические соображения, а реальный опыт: именно такое расширение «ВикиЛоги» MediaWiki мы реализовали в нашей компании. Широк спектр обсуждаемых в компании тем — от политических и организационных новостей в блоге генерального директора, до жарких технологических споров с сотнями комментариев, в которых, если и не рождается истина, то, по крайней мере, составляется резюме возможных проблем и решений, а участники определяются с позицией. Выросла и вовлеченность сотрудников в процесс наполнения базы знаний. Да, «блогосфера» взлетела не сразу, ведь не все сотрудники «продвинутые интернетчики», сначала пришлось показывать пример, вести «блог команды», «политические и инфаструктурные новости», «обзоры книг» — а затем — все полетело само! Начался активный обмен опытом, рефлексия над практиками и культурой компании, и т.п. Некоторое представление об этом взрывном росте, можно получить с помощью этого инфографического ролика:
(Сделан с помощью ShowTeamWork). Иногда еще встречается мнение, что вики-системы — это какие-то унылые поделки для программистов и прочих гиков, у которых нет денег на «что-то серьезное от солидного вендора». Это не так. Добротные вики-системы являются отличным компромиссом между эффективностью фиксации и актуализации знаний и их простотой и доступностью для всех категорий сотрудников. Важно запомнить: правильная вики-система — это не когда «все плоским текстом», а когда «быстро-быстро»[7]. Т.е. можно грузить сколь угодно «богатый» контент — фото, видео, скринкасты, звук, диаграммы, майндмапы, статьи и книги в PDF/DjVu и, на худой конец, просто документы в офисных форматах. А мощность самой концепции позволяет использовать вики практически для всего, хоть как-то попадающего в категории «база знаний» и «публикация материалов». Единственная уязвимость веб-контента — это неудобство при выполнении постраничной верстки для бумажной печати (которая, впрочем, становится все менее ценной). Более подробно все это разобрано в статье «MediaWiki — Серебряная пуля или швейцарский нож?»[8] Осталось поговорить о «Закладках» или, вернее, о «Вырезках» — ведь нечто схожее аналитики доинтернетной эры, пользуясь ножницами и кнопками, вытворяли с газетами. Они очень важны при Knowledge Miningе во внешнем интернете — ведь сейчас пользователь компьютера совсем не похож на «оператора ЭВМ», сидящего перед клавиатурой с 10:00 до 18:00. Мы постоянно «серфим» в интернете — ноутбуки и прочие девайсы сделали возможным чтение/просмотр информационных потоков в любом месте и положении, на улице и в туалете, стоя, лежа и сидя. Чисто физически приходится разделять режимы «Читателя» и «Аналитика-Реализатора»: заметив интересное, выделить важное, чтобы позже, сидя за столом, проанализировать и применить. Или обратить внимание экспертов или ответственных товарищей на что-то важное. Например, можно собрать ключевые цитаты из книги или статьи, чтобы потом написать рецензию. Или добавить ссылки-заметки на плюсы и минусы технологии, а затем заняться их реальной проверкой. Или отметить активность конкурентов, чтобы отдел маркетинга сделал правильные выводы. Проблемы стандартных сервисов закладок в том, что «личный склад» очень быстро замусоривается, в нем сложно искать. Набор закладок не может быть персональной базой знаний, его очень трудно рефакторить — быстро удалять, переносить куда-то содержимое, к тому же большинство сервисов не хранят цитаты. Велики и накладные расходы на добавление ссылки: «заполните поля», «выберите категорию»…. Нет групповой работы. Как вы уже, наверное, догадались, мы сделали свой сервис «ВикиЗакладки» на базе MediaWiki. Там можно завести неограниченное число «каналов закладок» — статей, где будут размещаться ссылки и вырезки. Для добавления закладки и вырезки нужно всего лишь выделить интересное в броузере и нажать кнопку букмарклета. Сервис работает во всех броузерах без инсталляции. Закладки можно вести в одиночку и коллективно («Сводки аналитического отдела по рыночному сектору X»), разделять по темам («Книга YYY») или перемешивать. Закладки автоматически сортируются в хронологическом порядке по разделам статьи, но хранить их вечно не обязательно. Лучше время от времени разбирать их: на основе каких-то писать новые или дополнять существующие статьи базы знаний, какие-то превращать в реализованные проекты. А что-то вскоре потеряет важность и эти закладки можно будет стереть. Все это делается быстро, ибо интерфейс самый эффективный — редактирование теста: copy-paste, перенос и удаление блоков. Чтобы сделать «pull»-интерфейс, нужно уметь превращать в RSS-поток любое изменение, будь то свежий пост в блоге, новая статья, закладка, редактирование и другие гибко задаваемые события. И сделать удобной подписку на эти каналы, с централизованной агрегацией и веб-интерфейсом, чтобы можно было их просматривать откуда угодно, быстро и удобно, — короче, сделать внутри-корпоративный «Google Reader». Мы сделали и его — это система «FeedOnFeeds»! Реализован отличный полнотекстовый поиск с русской морфологией по всей вики-системе, включая блоги-форумы-закладки, с настраиваемым выбором пространства поиска: например, можно искать в «блогах» или наоборот, везде, кроме них. Впрочем, есть и «push»-интерфейс, реализованный через электронную почту, когда важна именно оперативность реакции: например, в виде писем приходят ответы к авторским постам и комментариям. Это привычный интерфейс для любого интернет-пользователя. Иногда знания нужно передавать не просто «обычной почтой без гарантии доставки», а «заказным письмом, с уведомлением о вручении», проверив, что авторские мысли поняты правильно. Например, обучающие курсы или какие-то важные регламенты. Общеизвестен софизм Горгия: «Ничто не существует; если и существует, то оно не познаваемо; если оно и познаваемо, то непередаваемо». И трудно с ним не согласится: просто диву даешься, насколько люди склонны пропускать или неверно трактовать элементарные регламенты! Но выход есть! Как прочность программного обеспечения увеличивается при покрытии кода проверочными тестами, так и надежность передачи знаний увеличится, если сопроводить ее «автоматическими проверочными тестами на понимание». Система тестов с выбором вариантов — классический подход GMAT, GRE, ЕГЭ и даже тренажера ПДД. При всей критике, это очень дешево и эффективно. Ведь критикуют именно систему оценивания, с линейной зависимостью от числа баллов. А достаточно просто отсекать «тяжелые случаи», тугодумов или лентяев, и дополнять оценку по другим критериям. И очень эффективно использовать систему тестов в роли тренажера-симулятора[9]. Но неужели нужна специальная система для редактирования тестов и выполнения проверок? Нет! Мы и это реализовали как расширение MediaWiki «MediaWikiQuizzer», т.е. тесты — это те же вики-статьи, а все функции быстрой и эффективной публикации под рукой. Можно делать сколь угодно сложные композиции новых тестов из уже существующих, использовать вариации одной и той же тестовой базы — выдавать случайные блоки по N вопросов, перетасовывать варианты, включать режим экзамена или обучения и т.п. Тесты могут работать как в проверочном режиме, так и в обучающем: «вы выбрали не тот вариант, правильно так-то и потому-то». Если использовать MediaWiki для публикации курсов и MediaWikiQuizzer-тесты, то никакие «профессиональные системы e-learningа», скорее всего, не потребуются. Ведь остальной бюрократический функционал (учет студентов, оценок), предлагаемый этими системами, в организации разумного размера и с нормальными отношениями попросту не нужен. И еще об обучении: Mediawiki можно использовать не только в режиме «человек-компьютер», но и для передачи знаний «человек-человек» — а именно, для семинаров и курсов со слайдами. Широко известны проблемы правильных слайдов:
Мы решили и эту задачу, реализовав MediaWiki-расширение «S5SlideShow», позволяющее выпускать «гибридные» статьи, пригодные и для чтения, и для показа в виде слайдов. К сожалению, объем бумажной статьи ограничен и «за бортом» осталось много наших MediaWiki-изобретений: календарь с системой регистрации, совместное редактирование изображений и много другое. Но для читателя важны два момента:
Репликация: База Знаний «Заказных Информ Систем» → «Оранжерея знаний с MediaWiki» Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
||