專案管理中各環節的方法和實踐經驗(轉)

專案管理中各環節的方法和實踐經驗
開始做專案是一件令人激動的事情，專案組的每個成員都面臨著新的機會和挑戰。但同時也多少有些令人不安，大家都會考慮這樣一個問題："我們如何按時完成一個高質量的專案？"因為在專案開始之前往往存在許多不確定的因素，它們也許會一直持續到整個專案結束。所以在專案準備階段，也有許多工作要做。

前提條件與主要任務

開始做專案是需要前提條件的（輸入條件），不同的專案型別有不同的前提條件。如果是為客戶定製的專案，需要與客戶達成某種形式的合作意向，對於比較大型的專案，則中標往往被作為一個最基本的前提條件；如果是產品專案，則需要市場調查報告等作為輸入條件；即使是那些內部研發專案，也需要類似可行性報告的分析來表明執行專案的必要性。通常，我們把此階段稱為調研階段或論證階段，一旦此階段的結論認為可以正式啟動專案，就進入專案的準備階段或啟動階段。

專案準備階段的主要任務是簽訂合同（外部專案）或立項（內部專案），此階段所生成的工作說明書（Statement Of Work，SOW）與後續軟體開發活動直接相關。SOW通常作為合同或立項材料一個最主要的組成部分。在SOW中定義專案的工作範圍，並依據工作範圍確定所需的時間、質量、費用和資源。這些內容要得到相關利益人的認可，作為合同的組成部分對雙方具有約束力。

典型困境與分析

客戶：你們最多需要多長時間能夠完成專案？

開發方：我們現在還不清楚需要完成的工作，如果你們把需求提得更明確一些，我們會給出一個可信度較高的計劃。

客戶：你們最好先做出一個東西來，我們就可以提出更明確的需求。現在不可能提出所有的需求。

開發方：那我們如何確定交付時間？我們甚至不知道需要完成哪些功能。

客戶：交付時間已經確定了，系統必須在三個月的期限內上線。你們可以安排更多的人員來參加這個專案。

這是軟體開發的一個典型的例子，也許就是我們總有那麼多的專案滯後於交付時間的主要原因。這種情形對於開發商和客戶都充滿了風險，其結果往往是風險變成了事實。如何在這個階段降低這種由於工作範圍不明確所造成的風險，具有重要的意義。軟體開發的同行們經常會彼此詢問："你們是不是又要封閉開發了？"所謂的封閉開發即是每週工作六天（也有七天的情形），每天工作接近12小時。封閉開發或專案延期的最主要原因來自兩個方面：一是工作範圍不明確；另一點是不知道自己的生產率有多高。這兩個因素使專案計劃與實際的情況偏離甚遠。

對於軟體專案而言，一個最為直觀的衡量標準就是時間，每個人都可以對時間做出直觀的判斷。影響專案的交付時間主要有三方面的因素：專案的工作範圍、成本和質量。有這樣一個比喻可以說明它們之間的關係：將專案看作是一部複雜的機械裝置，把專案的交付時間、工作範圍、成本和質量看作是四個控制桿，調節每一個控制桿都要至少調節其它的控制桿。所以我們經常會在專案的執行過程中調節專案的人員投入。而對於質量的調節，則通過壓縮測試時間保證專案的交付時間不至於延遲過多。進度拖延的壓力使開發組織往往不計成本地投入人力，而使專案的收益狀況惡化；進度的壓力同時導致測試時間的壓縮，使專案在交付給使用者以後仍然存在許多遺留缺陷，降低了客戶的滿意度；而專案範圍的變更則更直接地影響到其它三個方面，會使本來就充滿風險的專案雪上加霜。基於上述原因，我們實際執行的專案往往需要同時滿足四個方面的要求。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21356/，如需轉載，請註明出處，否則將追究法律責任。