建立項目管理方法論

建立項目管理方法論遠遠不是整理出一堆文檔那么簡單 

作者：余曉平

引言：

如今，許多IT咨詢機構都聲稱自己擁有一套成熟、獨立、經過實踐檢驗的方法論。但是實際上，時間和經驗告訴我們，許多的機構都是在夸夸其談。它們很難有把握的復制自己的成功案例，甚至失敗案例也不能復制，也就是說，它們很難說有什么方法論。

一個失敗的案例

曾經有這樣一個經典的案例。某咨詢公司在系統的部署和運行方面有很好的聲譽，它曾經實施過許多成功的案例，并且有龐大的客戶群。在其事業的頂峰期，實施了一個接一個的成功項目。其技術實施團隊成功的把客戶服務、充滿智慧的系統部署、穩定的系統運行（這一點帶來了長期的業務關系）結合到了一起。

就在公司隨著成功飛速前進時，管理層開始安排具有業務流程、寫作和客戶服務各方面經驗的員工總結一套方法論。因為他們知道公司不可能永遠的照此發展下去，不能永遠都依靠運氣和員工的盲目努力來獲得成功。

接受任務的員工開始認真的投身于自己的任務。他們花了幾個月時間研究項目管理、反復軟件開發、流程設計、溝通交流以及管理學方面的理論。他們與客戶、內部員工、共事的CXO們進行了廣泛的溝通交流。他們把收集到的所有好方法和好點子通通揉合到一個龐大的模板和設計圖里面。這個模板包含了從業務前咨詢到項目運作的結束程序的所有內容，甚至包括了一些項目陳述和圖片的樣板，因為開發人員認為這可能對公司的銷售隊伍有幫助。

結果是，沒有人使用這套東西。無論同事們說他們有多么喜歡這東西，事實證明這樣的包羅萬象的文檔對于項目的日常運作來說太麻煩了?？蛻粢膊幌矚g這套東西，他們幾乎不看它。他們要么被這個文檔所淹沒，要么就找不到他們想要的東西。

我們現在還能看到許多的系統集成商和咨詢機構吹噓他們的方法論。這些所謂的方法論的大部分比上述案例中的文檔好不到哪里去。有些粉飾成復雜理論的方法在實質上還是同樣的東西——一套模板和一堆沒有什么應用價值的文檔。在許多IT用戶那里，我們還可以看到很多的項目檔案和技術設計材料，蓋著一層灰塵，從它們被送給用戶的第一天起就再也沒動過。

應該建立方法論，而不是方法

問題并非是這些文檔里的那些思想和點子有問題，也并不是因為這些文檔的內容太多了。相反，是這些文檔內在的理論和運用之間的不恰當結合讓我們接受起來有困難。

當我們談到方法論時，我們往往想到的是那些可以直接體現出來的東西（deliverables）：比如可以列出的一系列風險、循序漸進的規劃步驟、以迅捷的方式進行關鍵信息交流的方法。有些時候我們談論的層次可能比這要高一點點，我們可能會涉及到開發人員開發系統的過程，但這仍然是不夠的。只有極少的情況下我們才有可能會談到，為了適應特定的客戶需要我們應該任何修改那些現成的模板。

然而不幸的是，上述的那些我們關注的，可以直接體現出來的內容、以及那些系統開發過程的相關內容，都還算不上是方法論。它們只能算作是方法論的產物，是我們把理論轉化來更適應實際操作的產物。關于開發過程的內容離總結出方法論只有一步之遙了，它是特定的工作團隊或組織的特定習慣和能力與普遍化的方法論相結合的結果。那些可以直接體現的內容離總結出方法論就更遠了，它是那些開發過程的知識和實際應用、完成項目所作的工作相互作用的結果。

舉一個簡單的例子。理論指出，項目存在的原因是某項任務不是日常重復的，所以要成立項目組來專門解決這項任務。網絡設計方法論則進一步指出，要完成一個項目，必須準備好下一步移交給實際的操作。所以，你就必須對執行操作的團隊解釋清楚，各種網絡構件（比如訪問點、身份驗證系統、服務、服務器）之間是怎樣相互作用的。開發過程的知識則更進一步，大致勾畫了項目中的人員該如何圍繞解釋清楚這些內容而出力。這類解釋采用的是文檔的形式（書面的或者電子化的），讓用戶能夠以最方便的形式讀取。

那些模板之類的東西最恰當的作用是向參加到操作流程中的開發人員提供一個可參照的范例。最好的模板都是從以使用文檔為主的方法中產生出來的，而文檔方法論則與以設計、部署、運行為中心的、更貼近實踐的方法論有所不同，它主要的作用是向項目團隊提供技術應用所需要的各種信息。所以，搜集一堆模板并不能算作是總結出來方法論，這些模板也不是放之四海而皆準的真理，它們是需要作適當調整才能適應不同客戶和團隊的需要的。

一個成功的案例

在另一個發生在一家系統集成公司的案例里，開發人員負責開發一個“技術方法論”來向那些初級的員工提供幫助。開發人員的想法是要利用自己廣博的專業知識和技能開發出一套包羅萬象而又和諧的方法論。開發團隊的人員們總的加起來，共擁有100多年的研發經驗，其中80多年是和基礎設備的開發有關。

該團隊開始了這個方法論開發的項目，其間編輯了大量的文稿、無數的負責流程圖。他們幾乎綜合了每一個細節可能用到的模板。在最初的混亂與繁雜處理好了之后，有成員建議再往回看看，搞清楚團隊到底要完成什么樣的目標。他們的目標和對方法論的描述寫了滿滿一張紙。然后，他們又對這些原則進行了進一步的解釋，花了四頁紙的篇幅。借助于這些較詳盡的解釋，其它的使用者可以自己創造出一個操作流程。而他們最初寫出的那些大量的文檔就是從這類流程中總結出來的，也就是說者四頁紙的內容實際上已經提煉了那些大量的文檔的基本內容。這樣的一套方法論就自然的更容易理解了，咨詢機構的銷售人員自然也更容易向客戶介紹這套東西。它同樣還涉及到了業務運作的內容，在那些原本很難溝通的部門之間創造了一種共同語音。

在第一個案例里，開發人員非常關注于最后開發出來的文檔，并沒有真正的設計方法論的核心；在第二個案例里，開發人員始終關注于開發出清晰簡潔的指導原則。這就是為什么兩個案例的結果截然不同的原因。

原文轉自：http://www.anti-gravitydesign.com