2

說起來我也算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!!

Comments

# by Aspect Solution

wiki rocks.

# by steve

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

Post a comment