?

Log in

No account? Create an account
 
 
13 Апрель 2008 @ 23:22
Корпоративные 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 - не лучший формат.
 
 
 
Макс Васенковwinzard on Апрель, 14, 2008 05:18 (UTC)
Хочу еще вот что сказать: не важно, как оно на самом деле, не важно - как правильно. Важно, что клиенты хотят этот фантик, а не другой.
Максим Крамаренкоmaximkr on Апрель, 14, 2008 06:39 (UTC)
Это понятно, но не все целенаправленно хотят именно wiki, чаще нужно чего-нибудь для коллективного написания документации. Если не завязываться именно на wiki-форматирование то можно найти очень приличные open source системы.

Если считать wiki-разметку недостатком, то правильные системы уже не будут называться wiki, даже если все остальное там полностью аналогично:
http://kolomeetz.ru/blog/wiki/google-sites.html
http://kolomeetz.ru/blog/wiki/wiki-text-only.html
http://kolomeetz.ru/blog/wiki/3-mustdie-things.html
kolomeetz on Апрель, 14, 2008 08:32 (UTC)
Ох. Вики не определяется именно и только вики-разметкой.
Максим Крамаренкоmaximkr on Апрель, 14, 2008 09:04 (UTC)
ok, а что еще ? Вот нам самим сейчас нужна подобная система для накопления информации (в первую очередь, для документации от партнеров и скриптов/триггеров TrackStudio), пока похоже, что бесплатный drupal отлично подходит, чем бы для нас была лучше wiki-система - непонятно даже теоретически.

Можно подойти к этому вопросу с другой стороны. Есть компании-производители коммерческих wiki-систем. Для них тот же Drupal - явный конкурент, но почему-то фичи приводятся по сравнению с e-mail, 90% этих фич даже в TrackStudio есть :-)
http://www.socialtext.com/products/features/

Тогда почему именно wiki ? Неужели все хотят сделать корпоративную wikipedia ?



Максим Крамаренкоmaximkr on Апрель, 14, 2008 09:33 (UTC)
Или вот еще задачка: у нас есть крупные российские клиенты, договоры с которыми приходится долго согласовывать. Процесс согласования выглядит так:
1) Я отправляю клиенту почтой стандартный договор в word
2) Юр. служба клиента исправляет его как им хочется, рядом с исправлениями пишет комментарии.
3) Я читаю комментарии, исправлению либо подтверждаю, либо нет.
4) После нескольких итераций договор подписывается.

Казалось бы, это и есть коллективная работа с документами, коммерческие wiki с такими задачами должны отлично справляться. Но мне нужна возможность не только утвержать или откатывать все изменения со стороны клиента, а возможность делать это с каждой фразой. Т.е. изменения клиента в пункте 1.1 договора мы принимаем, а по пункту 1.2 пишем возражения и изменения откатываем - есть ли wiki-системы, где это реализовано ?

Насколько я понял, возможность просмотра истории документа в wikipedia делалось для защиты от вандалов, а т.к. вандалы редко вместе с бредом пишут что-то полезное и читают комментарии - там эта задача не актуальна.
myckolah on Апрель, 15, 2008 12:40 (UTC)
»возможность делать это с каждой фразой
делайте
но для этого придётся кадую фразу представлять отдельной статьёй в wiki
Kind Knightarsoron on Апрель, 15, 2008 13:29 (UTC)
Не обязательно. В MediaWiki статья разбивается на секции.