Software People 2010: Как построить эффективную базу знаний компании

Здорово. Страшно интересно. Пошла вкуривать.

Сразу вопрос: действительно "оказалось" насчёт самого сложного?
Просто когда мы только начинали строить свой маленький скромный knowledge base, то это уже сразу было обозначено как основная цель, она же трудность. Поэтому хочется понять, как к этой мысли шли те, кому она не была очевидна с самого начала. Расскажете?

SharePoint + Confluence -- тоже знакомая связочка :) А что ещё пробовали? Там у Вас волшебная строчка "пилотирование wiki-систем" -- это в смысле игрались с разными? Как господь уберёг от желания сделать своё? ;)

Систему доступов интегрировали с ActiveDirectory (если используете) или ручками клонировали?

Допиливали ли Confluence? Нпр., какая-нибудь "улучшалка" URL'ов (укорачивать, латинизировать) ну просто напрашивается.

Как решаете проблему устаревших документов? У нас руки не дошли её решать.

Как работаете с комментариями? Мы их нафиг отключили, только создают иллюзию обмена информацией, но не обеспечивают режим "сдал-принял" и не дают всем желающим участвовать в дискуссии (нет e-mail-нотификаций на рассылки).

Что происходит со вновь образовавшимися потребностями внутренних пользователей к базе знаний, каков их жизненный цикл? У нас был спец. человек -- "wiki гуру", помогавший быстро сделать на wiki приемлемое решение, но такой путь весьма компромиссен.

Как поступаете с частными страницами пользователей -- не включаете их в систему knowledge base или как-то всё-таки используете? У нас просто просветительской работой убеждали гуманитариев не хранить рабочую информацию на частных страницах.

Строите ли в Confluence отчёты и агрегирующие страницы? И если да, то как решили проблему, мягко говоря, неудобного и тормозного {metadata}? Мы долго мучились с разными плагинами, но идеала не нашли.

Хм... Пожалуй, так я долго могу спрашивать-то :)

Самая большая сложность состояла в том, чтобы в enterprise компании было разрешено строить KB не на основе заранее разработанной архитектуры и жестких правил публикации, а на основе парадигмы "базарности". Но... говорил несколько раз на выступлении и еще раз повторю здесь. Я не утверждаю, что продуманная архитектура и строгие правила публикации - это обязательно зло. Это тоже МОЖЕТ работать. Но требует бОльших затрат на администрирование, особенно на начальных этапах.

Из различных wiki систем наиболее активно работали с MediaWiki. Первой общекорпоративной wiki cистемой была именно она. Но потом решили не пожалеть немного денег на коммерческий Confluence и, как показала практика, это было очень мудрым решением.

Это, кстати, предопределило успешное построение корпоративной системы управления проектами на основе Atlassian tool. Я имеею в виду решение потратить немного денег на коммерческую систему. А удержало от не "написать самим" наличие мозгов и большой опыт "написания самими". И относительно гуманная стоимость продуктов Atlassian.

Проблему устаревших документов решаем при помощи рейтингов, лейблов и еще нескольких технических особенностей поиска. Если коротко - стараемся решить эту проблему естественным образом. Старые документы должны "опускаться" в рейтингах, если только они активно не используются (и тогда на них есть много ссылок, рейтинг использования высок, пользователи ставят высокий рейтинг и пр.).

Комментарии не отключали. С e-mail нотификацией действительно есть сложность - у большинства пользователей она идет прямиком в корзину из-за больших объемов новостей. Проблему планируем решать как настройкой confluence и плагинов, так и кастомизацией.

У нас тоже есть специалисты по wiki, которые помогают другим в использовании системы. Многое происходит по принципу: увидел интересное решение у другого (в другом разделе), сделал такое же у себя (благо, wiki разметка открыта). Также происходят управляемые изменения в рамках работы над нашей системой управления проектами (KB - ее часть). А там все по-взрослому. У КВ есть product owner, от него поступают запросы. Они оцениваются, приоретизируются, рассматриваются и становятся частью плана развития всего продукта.

Частные страницы пользователей не рассматриваются частью КВ.

Строим. С неудобством встроенных средств боремся при помощи написания собственных макросов.