1. 程式人生 > >blog、wiki、專案管理和專案知識管理

blog、wiki、專案管理和專案知識管理

題目涉及的這些關鍵字顯得很龐雜,每一個關鍵字都值得大書特書,這裡我只關注它們只關注它們各自特點、是否可能融合、如何融合以及融合會產生怎樣的力量。

各自特點

blog:以網路為載體,讓獨立的個體進行表達的簡單寫作工具,其特點它象寫日記一樣,是以我為中心,自我表達的,看到一個人的blog,如同看到他的profile一般。我如果你不清楚blog是什麼,那就去google一下吧。

wiki:以網路為載體,圍繞某一主題進行自由寫作的工具。在這種寫作環境之下,每一個人都可以自由的修改所有他能看到的頁面(這也意味者易於破壞)。它的哲學是:“人群性本善”-即是當行善的人和行惡的人擁有同樣的力量的時候(這是因為頁面用版本管理工具管理),整個人群所彰顯出來的就是“善” 的特性。

blog和wiki的共同特點:簡單,自由--利於釋放人們的表達慾望,不象傳統的寫作方式,如在報紙上發表文章,出書,搭建個人網站… 那樣難以表達自我。千萬可別小看簡單、自由這兩項特性,這是blog和wiki之所以存在的基石,下面的論述中,你會常常感嘆於--正是因為其簡單,才能…..

專案管理所面臨的主要挑戰來自於溝通的困難。無數的廠商/組織提供了無數的工具/開發流程、在各個不同的層面,針對對團隊的開發模式、組織方式、溝通機制/工具、氛圍來試圖解決這一困難。

專案知識管理對於一個組織的積累、成長,其重要性毋庸置疑。但是我們見到更多是無積累、無意義積累的組織(大多數中小組織都屬於此種情況--專案完成後,成百上G的文件以簡單組織、難以訪問的方式累積下來,再無人問津)。大公司可能會有能力去支付象IBM內容管理軟體的高昂費用,來達成這一目標,但由於其嚴格控制的許可權,個人的思想難以沉澱在組織裡。

專案管理過程積累下來的知識構成了組織的知識庫。

融合的基本思路

相似融合:
* 專案組由不同個性的人組成,這些人有共同的工作目標。
* blog是個人自我表達的工具,wiki圍繞某主題進行寫作。

  • 多個專案組積累的知識,構成更大的專案知識庫。
  • 多個wiki主題,通過interwiki的形成更大的主題。

互補融合:
專案管理有很強的組織性,在協調、組織和分工的同時,也會對組內成員造成一定的壓抑,並且降低某一部分組員的成就感。blog+wiki形成的自由表達溝通平臺可以從另一種方式平衡這樣的壓抑,從而形成更強的專案組。

從這樣的思路出發,我們會很自然的得出blog和wiki融合的基本思路和特性:
1)blog是作為專案組成員表達自我的一個平臺,但是涉及專案部分的文章(如,小技巧,週報,程式碼評審意見..)將會自動送到wiki系統中去。
2)wiki作為專案組溝通平臺,一方面,關於專案的資訊(主要是動態的方面),由於其簡單易於訪問的方式,更容易讓組員接受,樂於通過這樣的平臺進行有效的溝通;另一方面,組員的blog將會出現在專案組的wiki中,個人在完成自身積累的同時,也讓組織完成了積累。
3)由於有相當多專案開發是在客戶臨時準備的現場進行,專案組的網路環境差強人意,訪問Internet可能都不行,逞提對外發布的平臺。這時候,專案組就可以架設一個簡單的wiki+blog系統,定期或專案完成後通過interwiki的方式加入組織的專案知識庫。

blog+wiki如何解決專案管理中的一些具體問題

程式碼評審(code review)是許多專案經理認同的、有效的專案管理手段之一,但是具體操作起來確令許多專案經理卻步:如何評價、監督評審者的工作,如何評價被評審者,如何緩和審查者和被審查者可能的矛盾。在blog+wiki介入的專案中,可以採用這樣的操作方法:組員貼出自己的程式碼邀請其他人進行評審,評審者自由選擇程式碼進行評審,完成平均評審程式碼量。專案經理對於評審者的工作量一目瞭然;由於是公開並留下記錄的評審,評審者如果有“對人不對事”的傾向,在這樣的半正式的情景之下也會慎重考慮;解決了“對人不對事”的問題,評審者和被評審者之間的矛盾自然消失。

專案經驗的積累--我們常常會有這樣的經歷,當前碰到的問題在以前的專案中遇到過,於是開始在龐雜的、各種各樣格式的專案資料庫中翻查,這時候一般都是無功而返,然後尋找相關的人員回憶,運氣好的話可以回憶起來,運氣差的話,連相關的人員也找不到了。而blog+wiki的介入下,無論個人還是組織都有了一個良好的專案經驗積累的容器。

此外還有工作進展、會議既要、TODOlist、週報的問題都可以在wiki+blog找到適合的答案。

blog+wiki引擎選擇

關於blog和wiki獨立的引擎極大繁榮,這方面的介紹不是本文的主旨,可以查閱相關資料,不再贅述。但是blog+wiki的成熟整合方案目前還較少,服務於專案管理的blog+wiki就更少。選擇的原則如下:
1)簡單。功能複雜既無必要又損害了使用者的積極性;
2)還是簡單。維護blog+wiki平臺所需的技能越少越好,懂得這些技能的人群越廣泛越好。
3)blog系統之間和wiki系統要有足夠的互動能力,擁有同樣的執行環境,但是又不能過於緊密的耦合。
4)支援中文:中文編輯/顯示,中文頁面名,interwiki中文支援。
遍尋一晚,我選擇了基於perl的MovebleType+Oddmuse整合版本http://www.qinyu.net/archives/000281.html,但我仍嫌它不夠簡單,而且二者的互動能力仍然很弱,需要改進。考慮到java技能的廣泛使用,使用java技術的的blog+wiki系統應該是較好的選擇,但我只發現了基於jsp的wiki系統JSPWiki http://www.jspwiki.org,沒有發現基於jsp的blog系統。

MovebleType+Oddmuse

JSPWiki

總結

blog+wiki仍然不是軟體工程問題的“銀彈”,但是這兩項技術所倡導的哲學與軟體工程需要解決的主要問題的答案,在我看來隱然相和。

對團隊知識管理的一些思考

最近的一點折騰和思考,歡迎討論交流。

論壇
BBS和論壇是廣場,是大家交流討論的地方,時效性非常強。雖然有精華貼等方式來沉澱有價值的主題,但很難整理維護好。傳統BBS的精華區,靠的是有責任心的版主去維護。參加工作後,很少有人會有這份熱心和精力。

這種模式,決定了論壇的三個發展方向:1. 娛樂論壇,比如天涯社群,最熱的是新聞八卦貼圖等娛樂版塊。很多技術論壇,最活躍的也是“水上樂園”。2. 諮詢論壇,比如CSDN社群,杭州的19樓空間等。使用者去這些論壇的目的性比較強,比如提問,查詢房屋出租資訊等。這些論壇很難留住高手,蓬勃中透露出浮躁。3. 專業論壇或者說圈子論壇,比如好久以前的RoR,還有如今的CCF和DRL等。圈子雖小,但會員的興趣愛好都比較相近,談討的話題也就比較專業化。這種論壇讓人有歸屬感,但對新人來說,很難融入。

可以看出,論壇的強項是交流,是討論,並不合適團隊知識的沉澱和管理。

Wiki
對於Wiki, 其精髓是詞條化管理和協作開發,願景是儲存團隊成員們認為的最好的答案和方法。Wiki的搭建非常容易,很多團隊搭建了Wiki,就以為將知識管理起來了,其實大不然。網際網路上公開的知名Wiki,也就維基百科,其它還有些經營得不錯的專業Wiki,總的來說是非常有限的。用Google搜尋Wiki,更多的是年久失修的站點。接觸過幾個公司的內部Wiki,絕大部分都已成為陳舊不堪、沒人維護更新的資訊孤島。

Wiki真的適合知識積累嗎?最近試用了MediaWiki,TWiki,PBWiki,還有商業版的Confluence,以及號稱地球上最好的Deki等,從功能上講,都非常不錯。與論壇相比,Wiki的優點是能更便捷地更新維護,但缺點也很明顯:缺乏吸引力和激勵性。Wiki的維護成本相當高,一般都得通過行政或獎勵等手段來有效運作。Wiki基本上屬於公共福利,在中國,目前大部分開發人員的經濟水平決定了對公共福利的熱情和興趣很難持久,這是Wiki經常成為荒島的原因。

簡言之,從形式上講,Wiki很適合團隊的知識積累。但從操作和維護上講,Wiki只是看起來很美,實際操作卻非常艱難。

Blog
人都有慾望,有所求。論壇上的活躍會員,求的是認同感和榮譽感。企業內部Wiki的搭建者和維護者,求的是自我和團隊知識的系統化管理和沉澱提升,但這種熱情很難持久和延續,行政和獎勵手段的作用是有限的。

從知識沉澱和參與積極性上講,Blog介於論壇和Wiki之間。Blog是先有自我的沉澱,再有讀者的評論反饋。一個好的Blogger會在自我和讀者之間做很好的權衡,讀者從自己總結的文章中獲益,自己也能從讀者的反饋中提升自己。這是一種雙贏策略,彼此收益,因此自從Blog誕生,就一直連綿不絕發展到現在。

但Blog依舊更傾向於論壇,適合個人發表意見和獲取反饋。對團隊來說,需要的是一個持續穩定的知識庫。而且糟糕地是,一旦用Blog做為團隊的知識積累工具,Blog原生的激勵性可能很快就會喪失殆盡。

對團隊來說,用Blog來做知識管理看起來也不靠譜-.-

人件
除了上面三種,還有Drupal等CMS系統,以及OpenKM等Doc管理系統,就不多說了。至於Sharepoint,實在感覺很混亂,或許混亂本身就是一種良好的狀態?

有效的團隊知識管理系統需要滿足兩個條件:1. 知識的新增、維護和查詢很方便,可用性好。2. 能有效的激勵團隊成員自主地去閱讀和更新知識庫,可持續性好。

可用性上,無論是Blog還是Wiki, CMS等,都沒什麼問題。

可用性上還涉及知識的分類組織,這是一件非常頭疼的事情。MediaWiki採用詞條組織海量知識,GMail採用Tags組織海量郵件,拋棄細化的Categories是一種理念上的革新。但對非海量的團隊知識庫來說,Categories能讓知識更有序,新人也能更方便的瀏覽和查閱。要做出適用性較強的分類和組織,需要不斷思考和取捨。

可持續性上,無論什麼系統,用來做團隊知識管理,都必須行政化或獎懲化或商業化才能有效運作。

可持續性是關於人的,只有人才能減緩資訊的“腐爛”。因此知識管理的核心不是知識,而且尋找某種適當的運作方式,能讓團隊成員真正參與到知識的新增和維護中來。

用什麼系統關係並不大,最重要的是保持系統的“活性”,這就是知識管理。