黑式KM理論


說起來我也算Coding界的異類。
絕大部分的程式設計師談起搞程式抓問題,無不眉飛色舞;但只要一提到寫文件這檔事,頓時就面如死灰,判若兩人。如果你給一群Programmer兩個選擇:
要寫文件或是掃廁所? 大部分的Programmer會立刻衝向洗手間搶唯一一枝的馬桶刷。
我熱愛Coding,三天沒寫程式就會坐立難安;但是跟大部分Programmer所不同的,只要是邏輯較複雜的程式碼片段,註解列佔程式碼的比例常常會高達30%。而解決技術問題後,我多半會寫下技術心得(姑且稱之為知識庫文章,Knowledge Base,KB),跟同組的夥伴分享,更重要的是在多年之後再遇同樣的問題時,可以立即回想起所有的細節,而非抱頭苦思數小時,最後重頭Try起。
幾年下來,我大約累積了近千篇的KB文章,也開始進入倒吃甘蔗的境界。這一大堆自己留下的麵包屑變成我多年IT生涯取寶貴的資產,到後期有人向我求援詢問時,有時兩分鐘就能完成搜尋+轉寄的動作,立即結案。這樣的水準,即使稱不上"文件達人",也總可以說是"KB魔人"了吧?!
除了自己寫,在過去一小段扮演主管角色的歲月中,我也試著去營造撰寫技術文件的風氣。在當年KM喊得震天價響的年代,每每有與KM沾上邊的計劃,也總與我脫不了關係。但幾次經驗下來,我的心得是:
KM最困難的一段在於如何讓大家樂於分享。除了KM理論派一定會提的獎勵外,我個人則主張在蒐集的管道上不要加太多限制,例如: 設計了KB基本資料表,要填一堆類別、關鍵字、適用軟體之類的。當User想到要填就很頭大,往往就是讓KB貢獻量以幾何級數下降的元凶。在我看來,我們能累積的KB數很難達到"罄竹難書"的規模,因此用全文檢索或靠印象多半就能解決搜索的需求,這些詳細的分類與索引工程幫了倒忙,沒在快速檢索上做出貢獻,反而成為扼殺人們分享熱誠的幫凶。
我看過好幾次的KM工程,一開始就花了80%的時間在討論分類方式與項目,決心要用最嚴謹的知識體架構來歸納各個部門千奇百怪的知識。不過要涵蓋這麼大範圍的知識領域實在是件龐大的工程,加上人多口雜,大多被押著來開會的可憐蟲多半只想應付了事,通常還沒能熬到討論出結論,KM計劃就無疾而終了。哈!
所以我的主張是,要做KM,與其想架構、搞機制,不如快建起讓大家可以方便書寫、自由發揮的平台,早點打開知識匯入的水龍頭,這樣還比較實際。Blog、Exchange Public Folder都是很不錯的選擇,至於分類? 等知識多到每次查什麼關鍵字都會查出幾百筆時,再找兩三個人花一星期去整理,都還來得及。
簡而言之,Just Do It!!
歡迎推文分享:
Published 25 May 2006 10:17 PM 由 Jeffrey
Filed under:
Views: 7,871



意見

# Aspect Solution said on 27 May, 2006 03:06 AM

wiki rocks.

# steve said on 29 May, 2006 10:11 PM

Google有分類嗎?沒有
手上兩個客戶,用了敝公司總共賣出的三套「KM」的其中兩套
誰在用啥子分類?沒有
只有搜尋是唯一的王道,真的
訓練user去瞭解你的分類
不如訓練user如何下好關鍵字搜尋

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<May 2006>
SunMonTueWedThuFriSat
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910
 
RSS
創用 CC 授權條款
【廣告】
twMVC

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication