Knowledge Management: От Склада к Потоку (Software People-2010)

Короткая ссылка: Knowledge-management-from-store-to-flow

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

Выступление на конференции Software People-2010.

Видео

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/11152969?byline=0&portrait=0" width="720" height="404" frameborder="0"></iframe>

Аннотация

В любой компании, переросшей «комнатный» размер, возникает проблема накопления и трансляции знаний.

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

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

Она остается, даже если компания развивает коммуникацию, как внутрикомандную, так и с заказчиком/потребителем:

• сервис-ориентированная культура (Agile/SCRUM);
• внутрикомандные коммуникации — регулярные scrum-митинги, планирование, креативные open-space комнаты;
• регулярные демонстрации для заказчика.

Даже в таком волшебно-идеальном случае наблюдаются проблемы:

• Трансляция знаний только внутри команд:

• • Неизвестно, кто и что делает в другой команде. И что более важно, конкретные области компетенции разных сотрудников, («работал с библиотекой X», «пробовал технологию Y», «настраивал систему Z», «столкнулся с ошибкой RRR-SSS-DDD», и «о, он тоже читал книгу W»)!
  • Нет P2P-обмена практиками использования процессов и инструментов, и не работает оптимизация процессов в компании «снизу». Нет не только обмена идеями, но даже откликов на предложения.

• Плохо работает синхронизация ценностей на уровне всей компании, ведь информация с верхнего уровня происходит через иерархию руководителей, с классическими проблемами искажения и личностных конфликтов. В результате, в компании возникают неясные слухи, часто панические. А нужно совместное видение ситуации всей компанией, а в идеале, и гармонизация эмоциональных отношений.
• Несмотря на оптимальный набор инструментов, в них оседает только проектная информация, что далеко от полного опыта, собранного сотрудником. А ведь «continuous learning» это один из основных мотиваторов! Cотрудник начинает фиксировать свои знания в Большом Интернете, используя сервисы закладок, блоги, персональные базы знаний, что приводит:

• • к потере знаний компанией (ведь микрозаметка/закладка «работал с библиотекой XXX» мало даст стороннему читателю, а для сотрудника этой же компании, это бы означало классный факт — «в соседней комнате сидит человек который уже разбирался с XXX»).
  • жесткому, демотивирующему фидбеку (любой с опытом публикации на habrahabr.ru, понимает, что это).
  • к утечкам конфиденциальной информации.

Резюме проблемы:

• Нет места и возможностей для быстрой и удобной фиксации «персональных знаний».
• Нет Свободного Потока Знаний внутри компании.

Мы расскажем о нашем гуманном, инструментальном решении перечисленных проблем, основанном на использовании удобных и привычных всем интерфейсов. Идею некоторых решений мы просто взяли из глобальных практик, проверенных временем в мировом масштабе, некоторые — сугубо свежие наши изобретения, элегантно разрешающие существующие конфликты юзабилити, но в любом случае, это не голые слова («talk is cheap, show me the code» © Линус Торвальдс) — мы готовы, в случае интереса сообщества, опубликовать все это для свободного и бесплатного использования.

Расширенная аннотация

В любой компании, переросшей «комнатный» размер, возникает проблема накопления и трансляции знаний. До этого такая проблема обычно не стоит — всегда есть один-два эксперта, которые знают почти все, и рады ответить всем, и нет никаких проблем с трансляцией — устное общение в одной комнате рулит. С ростом компании, конечно, такая работа через живые Центры Коммуникации и Знаний, становится невозможной.

Представим, что компания абсолютно грамотная, и в теме современных тенденций: вводит учет задач и другой ответственности в таск-трекере, код и дистрибутивы грамотно хранятся в современной и удобной системе контроля версий, ну и самое главное — стоит самая классная вики-система, которую можно найти/купить за деньги. Да, часто с установкой такой вики-системы и считают задачу «БазаЗнаний в Компании» решенной (это же сработало для «Википедии», должно сработать и у нас). Представим даже, что максимально облегчен поиск — отличный поиск с русской морфологией позволяет найти все и в хранилищах кода и документов (с учетом поиска по истории), и по трекеру, и по вики-системе, реализована, как любят говорить traceability — связь артефактов кода, задач, документации, требований. Достаточно?

Нет. Более умная компания идет дальше — форсирует коммуникацию, как внутри команд, так и с заказчиком:

• внедрена сервис-ориентированная культура (какая-нибудь разновидность Agile-методологии, например SCRUM),
• форсированы коммуникации внутри команды — регулярные scrum-митинги, планирование, команды находятся в open-space комнатах, все стены работают на креативную атмосферу — доски задач, прототипы, эскизы.
• много общения и с заказчиком — регулярные демонстрации.

Красота! Вроде бы сделано все возможное, что рекомендуют здравый смысл и рекомендации ведущих собаководов.

Однако даже в таком волшебно-идеальном случае наблюдаются странные эффекты:

• Трансляция знаний в компании идет только внутри команд.

• • Неизвестно, кто и что делает в другой команде, и что более важно, кто в чем компетентен — ведь это фантастически важно, знать области компетенции разных сотрудников. Причем не на обобщенном «HR-ном» уровне («разработчик 7-го уровня», «эльф 80-го уровня»), а на уровне — «работал с библиотекой X», «пробовал технологию Y», «настраивал систему Z», «столкнулся с ошибкой RRR-SSS-DDD», и «о, он тоже читал книгу W»!
  • Нет P2P-обмена практиками использования процессов и инструментов — т.е. не работает оптимизация процессов в компании «снизу», причем нет не только обмена идеями, но даже откликов на готовые идеи.

• Плохо работает синхронизация ценностей на уровне всей компании, ведь трансляция информации на уровне выше «команд» (особенно от топменеджмента и вниз) происходит через иерархию руководителей, с классическими проблемами искажения, личностных конфликтов — в результате в компании возникают неясные слухи, часто панические. Например, в департаменте XXX заказчика YYY решили закрыть один из проектов, и в компании начинают бродить слухи — «Все пропало! Гипс снимают, клиент уезжает, мы теряем нашего заказчика YYY!». А ведь важно добиться совместного видения ситуации со всей компанией, а в идеале — и гармонизации эмоциональных отношений.
• Несмотря на оптимальный набор инструментов (трекер-вики-VCS), в них оседает в основном информация непосредственно связанная с проектом, что разумно, но далеко не полностью описывает собранный сотрудником опыт! А ведь в нашей индустрии — «continuous learning» это один из основных мотиваторов. В результате, часто наблюдается, что сотрудник начинает фиксировать свои знания в Большом Интернете, используя сервисы закладок, блоги, персональные базы знаний, что приводит:

• • к потере знаний компанией (ведь микрозаметка/закладка «работал с библиотекой XXX» мало даст постороннему читателю, а для сотрудника этой же компании, это бы означало классный факт — «в соседней комнате сидит человек который уже разбирался с XXX»).
  • жесткому, демотивирующему фидбеку (любой с опытом публикации на habrahabr.ru, понимает, что это).
  • к утечкам конфиденциальной информации.

Т.е. если кратко резюмировать перечисленное:

• Нет места и возможностей для быстрой и удобной фиксации «персональных знаний».
• Нет Свободного Потока Знаний внутри компании.

Конечно, с частью проблем можно пытаться бороться оргмерами, например, организовывать регулярные собрания с выступлением гендиректора, устраивать регулярные тематические семинары или групповые лекции-тренинги, на эту же тему рекомендации приглашать коллег на демонстрации SCRUM-команд, но факт остается фактом — «синхронные» мероприятия, требующие непосредственного присутствия людей — очень дорогая вещь, ведь это потеря рабочего времени, рабочего ритма и настроя, причем с ростом «объема синхронизации» в людях, затраты растут нелинейно! Отвлеченная заметка на полях: собственно путь «Синхронного Ритма» очень эффективен, но жесток и ресурсоемок, поэтому применяется именно для небольших команд (SCRUM и т.п.), одновременно с изоляцией команды от внешних воздействий. Но обратная сторона этой изоляции описана выше. Да, несмотря на все рекомендации приглашать коллег на SCRUM-демонстрации, мало кто готов выбиться из ритма своих итераций, и потратить время на личное присутствие на чужом демо.

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

Может использовать стандартную корпоративную электронную почту для массовых рассылок? Ну, в некоторых случаях («обращения ГенДирИнформБюро») это, наверное, оправдано, но в остальном, это не поможет. Вообще, электронная почта, по своей природе, это тоже инструмент-прерыватель с push-интерфейсом: письмо — это отдельное событие, каждое письмо нужно читать отдельно (нельзя читать тематические каналы-агрегации набора писем), причем адресата должен выбрать отправитель. Т.е. нельзя, совершив маленькую победу или открытие слать куда-то письма, без боязни прослыть «спамером» (и только совсем бесстыжие люди рассылают ссылки на баянистые анекдоты и интернетные фишки в массовую корпоративную рассылку). Ну и в любом случае, «communication is not information» — почтовая переписка не есть часть целостной базы знаний компании.

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

Идею некоторых решений мы просто взяли из глобальных практик, проверенных временем, некоторые — сугубо свежие наши изобретения, элегантно разрешающие существующие конфликты юзабилити, но в любом случае, это не голые слова («talk is cheap, show me the code» © Линус Торвальдс) — мы готовы, в случае интереса сообщества, опубликовать все это для свободного и бесплатного использования.

Итак, как же организовать удобный Поток Информационных Каналов, асинхронных, не прерывающих читателя, оставляющих ему полную свободу выбора, и удобство чтения в виде непрерывных информационных лент?

Как перейти от прерывающиего push-интерфейса, к pull-парадигме купания в выбранных потоках информации? В Большом Интернете этот вопрос уже решен — блоги и Google Reader RSS-каналы, и RSS-агрегаторы. Да, RSS-каналы это более общее понятие, чем блоги, ну а найти современного человека, вышедшего в интернет и не пользующегося RSS-агрегаторами, практически невозможно. Кстати, немаловажным фактором их победного шествия стало изобретение быстрой прокрутки (мышиным колесиком и тачпадом), благодаря которым выяснилось, насколько эффективно просматривать большие простыни текста, без разбиения на отдельные страницы. Впрочем, влияние мышиного колесика на веб-юзалилити, и почему часто вебприложения с крупными элементами интерфейса и длинными страницами, удобней обычных, с окнами запертыми в пределах одного монитора, это отдельная интересная тема.

RSS-агрегаторы могут быть и обычным, клиентским приложением (например, эта функциональность встроена во все уважающие себя броузеры и почтовые клиенты), но наибольшее удобство достигается, когда RSS-агрегатор реализован как веб-приложение, и им, и своим уникальным набором подписок (причем персонально категоризованным, с «памятью», что пользователь уже прочитал, а что и пометил тегами и значками интереса) можно рулить независимо от используемого. Такие сервисов много в Большом Интернете — Google Reader, Яндекс.Лента или Яндекс.Подписки, Yahoo.Pipes и т.п., но плохо одно — нельзя (как политически, так и технически) в них тащить закрытые корпоративные информационные потоки, а готовых решений для корпоративного RSS-агрегатора долгое время не было.

Итак, что же сделали мы? Мы взяли один из только что появившихся в open-source веб-агрегаторов (весьма близок к Google Readerу по интерфейсу и фунциональность, хотя и чуть более аскетично выглядит), быстро довели его до ума, добавили функциональность подписки на защищенные RSS-каналы, после чего, сделали так, чтобы любые изменения в корпоративной информации можно было отслеживать через RSS-потоки (разумеется, также доступны все RSS-каналы из большого Интернета). Например:

• Комментарии, изменения статусов, и прочая активность по задачам (багам, заявкам) в таск-трекере.
• Все правки в централизованных репозитариях исходного кода — можно подписаться на любые запросы типа «все правки такого-то сотрудника по файлам в таких-то каталогах и т.п.».
• Изменения в вики-системах (правки по отдельной статье, выбранным категориям статей и т.п.).
• Статьи-микроблоги, где сверхпросто добавлять новые записи — каждая строчка списка порождает новые пост. Оптимально для статей сопровождающих продукт или фреймворк — каждая строчка о выходе новой версии, превращается в новость.

Я сказал микроблоги? А как же блоги? Конечно, внутренние блоги как раз решат объявленную задачу фиксации знаний, и полно готовых свободных open-source систем, которых можно остановить и использовать. Проблема только будет с тем, что как только у нас в «области знаний» появится несколько конкурирующих вебсистем — блог-движок и вики-система, начнется конкуренция, материалы начнут оседать и «застревать» в блогах, в которых легко делать короткие наброски, но трудно сделать грамотную классификацию и прочий «рефакторинг». Плюс большинство блог-движков имеют очень простые возможности редактирования, рассчитанные на размещение постов в пару абзацев, и совершенно нет той эффективности вики-систем, позволяющих вести и групповое редактирование, и контроль версий, и удобную разметку, и поддержку сотен расширений для быстрого порождения контента и ссылочной целостности и т.п. Конечно, в интернете встречаются блоги в которых публикуют и большие статьи и даже книги (с разбиением глав по нескольким постам), но все это некоторое извращение.

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

Да, кстати о трансляции ценностей, блог ведет даже наш генеральный директор, где он лично, без всякой PR-команды, напрямую доводит свое понимание текущей ситуации (новости компании и заказчиков, новые приоритеты и направления, разбор конфликтных ситуаций), ну и соответственно получает публичную обратную связь, без ожидания в приемной или времяпожирающих совещаний. Ну а для сотрудников, возможность публично «выговориться» на волнующую их тему, имеет, по крайней мере, большой психотерапевтический эффект (в этом есть что-то от сайта killmepls.ru).

Дальше, мы задумались о «быстром персональном кеше знаний». Не секрет, что перегрузка кратковременной человеческой памяти — основная проблема knowledge mininga в интернете. Читатель находится в потоке потенциально интересной ему информации (читает RSS-каналы, гуглит сложный запрос, отбирая интересные варианты) — и пока он находится в состоянии «Потока», причем «Потока Читателя», ему ужасно неудобно переключатся в режим «Писателя» — т.е. делать какие-то заметки, фиксировать промежуточные идеи. Более того, возможно это ему даже трудно делать технически, ибо он осуществляет информационный поиск используя мининетбук, или планшетный компьютер, удобно развалившись на диване (или как-нибудь еще веселей…), в общем, текстописание действие невозможное для него как психически, так и физически. Единственное, что он может сделать используя мышь или тачпад — выделить заинтересовавшее, и как-то быстро отметить это, чтобы потом, уже в состоянии «Анализа» иметь возможность быстро вернутся к найденному.

Собственно на этой идее и базируются многочисленные сервисы закладок (от Google Bookmarks и Яндекс.Закладок, до десятков аналогичных или даже специфических, типа CiteULike для научных статей).

Проблема в том, что они находятся вне корпоративной базы знаний, плюс у них тоже специфические проблемы использования:

• Как правило, добавлять закладки можно просто (в один клик).
• Но потом, навести какой-то порядок в них практически невозможно. Их даже трудно массово удалить.
• Ссылка никак не атрибутирована, кроме как заголовком страницы. А хотелось бы выделять блок заинтересовавшего контента, и сохранять закладку в месте с этой «цитатой». Кстати, именно так работал сервис Google Notebooks, к сожалению, разделивший судьбу десятков других гугл-сервисов, не «доживших в весны».

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

Так вот, мы предоставили нашим сотрудникам сервис решающий все эти проблемы, и опять таки, являющийся расширением MediaWiki. Пользователь может создавать страницы-агрегаторы (под любую тему, с любым названием, будь то «Достижения Конкурентов» или «Участник:StasFomin/СмишныеКортинки»), и одним кликом (специальный букмарклет), добавлять на нее цитаты-закладки с интернет-страниц. Более-того,

• эти страницы также являются RSS-каналами, к которым можно подписаться (т.е. функциональность микроблогов);
• любой пользователь может присоединится к наполнению;
• добавляются не только ссылки, но и вырезанные блоки контента (aka Google Notebook);
• не нужно мирится с растущей кучей информационного мусора — это скорее кеш, т.е. обычная вики-статья, разбитая на хронологические разделы, и можно легко провести рефакторинг — перенести ценное в полноценные викистатьи, удалить неактуальное.

Но на этом, наши изобретения по разгону Потока Знаний не закончились! Какой еще известный и очень важный канал трансляции знаний?

Классические презентации, т.е. устное выступление перед аудиторией, дополняющее аудиоканал визуальным каналом со слайдами.

Какие самые известные проблемы таких презентаций? Вероятно все знакомы с «Смерть от Powerpoint» — презентацией про проблемы презентаций, где показано, что самая основная проблема — перегруженность слайдов информацией. Дело в том, что выступающий всегда обычно делает слайды двойного назначения — чтобы под них можно было «выступить», и чтобы их можно было читать отсутствующим на выступлении. Обычно гонясь за этими двумя зайцами, не ловится ни один — страшные гибриды документа и слайда, называемые «слайдоментами», вырубают аудиторию, с трудом пытающуюся прочитать мелкий текст, не обращая внимания на параллельно бубнящего то же самое диктора. В то же время эти «слайдоменты» проигрывают обычной статье, с точки зрения самостоятельного чтения. Ситуация усугубляется еще тем, что обычно слайды являются бинарными документами (Open Office, Keynote, PowerPoint) с которыми невозможны конкурентные правки, и вообще не очень удобны инкрементальные изменения. В результате, обычно презентации являются write-only продуктом, который, захватив много времени одного автора на разработку (коллективное творчество слайд-презентаций в PowerPoint вообще отдельный ад), потом более не развивается и пылится в дальних углах файлохранилища.

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

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

Так вот, нам удалось поймать всех этих зайцев!

Решение — очередное расширение к MediaWiki, являющейся у нас корпоративной базой знаний.

Любая статья MediaWiki теперь может быть не только прочитана, но и показана частично в виде слайдов! Разумеется, в слайд-части включаются иллюстрации, тезисы, а поясняющая текстовая часть статьи, при этом не показывается. Сохраняются все возможности MediaWiki:

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

И при этом используются все возможности веб-публикации

• встраивание видео, флеш-объектов и т.п., они гораздо богаче возможностей PowerPoint или PDF-слайдов.
• можно мгновенно перейти от просмотра статьи к показу слайдов используя только броузер.
• есть навигация по слайдам, функциональность таймера.

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

---

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