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

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

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

Докладчик: Стас Фомин

Видео

Аннотация

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

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

Она остается, даже если над всем этим есть отличный поиск, который позволяет найти все и в хранилищах кода, документов и задач (с учетом поиска по истории), и даже когда отлично реализовано 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» © Линус Торвальдс) — мы готовы, в случае интереса сообщества, опубликовать все это для свободного и бесплатного использования.

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

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

130657.strip.gif

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

Репликация: База Знаний «Заказных Информ Систем» → «Knowledge Management: От Склада к Потоку (Software People-2010)»

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