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

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

Видео

Аннотация

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

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

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

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

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

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

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

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

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

130657.strip.gif


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

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

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

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

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

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

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

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

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

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

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

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

Not Invented Here-2010-03-09.jpg

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 для научных статей).

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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