Максим Крамаренко (maximkr) wrote,
Максим Крамаренко
maximkr

Categories:

Корпоративные wiki

Скажу сразу - идея использования wiki в качестве корпоративного хранилища знаний, вроде локальной wikipedia, мне давно и активно не нравится. Но так как сейчас использование wiki в таком качестве набирает популярность, то приходится рассказывать про негативные стороны этой затеи не только клиентам, но даже нашим сотрудникам.

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

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

Но ведь в корпоративных wiki никто не собирается хранить историю развития компании или биографию руководителей - это средство позиционируется для документирования проектов/продуктов, которые сейчас находятся в разработке/работе и постоянно меняются. Т.е. я могу написать детальную статью про то, как у нас работает генератор отчетов, но кто будет ее править при каждом изменении подсистемы кеширования или форматов вывода даты/времени ? Меня периодически ставит в тупик куда более простая задача - вот мы тут чуть подправили это,  что теперь нужно перетестировать и какие скриншоты переснимать. Если я не знаю всю документацию и все скриншоты - я эту задачу решу только полным перебором, а если знаю - зачем мне wiki ?

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

Второй важный момент: когда пишется документация, то важно понимать для кого именно она пишется, и как он ее будет использовать. Статьи энциклопедического плана ("как работает генератор отчетов", "как настроен Subversion", "что означают кнопки на странице Task") тут не годятся - нужны статьи, описывающие _действия_ конкретных людей в конкретных ситуациях ("как написать еще один отчет", "как вытащить исходник из subversion", "как создать/удалить задачу").

У нас есть один замечательный документ 2000 года под названием "Как у нас устроен CVS репозитарий" в котором на 3-х страницах описано на каких серверах что запущено, в какие конфиги что прописывалось при настройке, и как оно все работает. Теоретически, дока была бы полезна для админа, который настроил CVS, после этого отформатировал диск и хочет повторить процесс :-)
У нас такого админа не нашлось, мы уже года 3 назад переехали на Subversion, а про наличие этой доки вспомнили буквально несколько месяцев назад во время ревизии документации. Почему о ней все забыли ? Да никому не интересно, как у нас устроен CVS репозитарий, хотя пошаговые инструкции "как подключится к нашему репозитарию" и "как быстро настроить репозитарий для тестирования интеграции" были бы полезны.

Энциклопедии - это ведь развлекательная литература, они годятся для расширения кругозора, но не помогут, если нужно что-то конкретное. Скажем, та статья о микроволновках какое-то представление о них дает, почитать интересно. Но
- если я хочу купить микроволновку - мне нужна информация по производителям, характеристикам, ценам, наличии, условиям доставки.
- если я хочу собрать микроволновку - мне нужна принципиальная схема, информация о деталях и их производителях.
- если я хочу приготовить что-то в микроволновке - мне нужны рецепты.
и т.п.

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

Возвращаясь к корпоративным wiki, я не вижу их преимуществ перед CMS (типа Drupal) или ECM (типа Alfresco). Больше всего мне не нравится дураций язык разметки, совсем обычным пользователям понятнее Word, а IT-шникам - подмножество HTML.
Еще одна важная группа пользователей - переводчики. В большинстве своем они освоили тэгированные форматы и не пытаются переводить HTML-тэги, а системы translation memory хорошо понимают word, HTML и форматы издательских систем. Но разметку wiki практически никто не знает, софтом она не поддерживается, про зависимость форматирования от количества вставленных пробелов молчу, со времен Clarion такого "чуда" не видел.
Тогда зачем все это ?
Защита от вандалов ? Для корпоративных систем это не очень актуально.
Возможность коллективного творчества ? Практически не используется.

Да, знания внутри организации надо накапливать и систематизировать, но ведь энциклопедии все равно не получится, а для всего остального wiki - не лучший формат.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 53 comments
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →
Previous
← Ctrl ← Alt
Next
Ctrl → Alt →