軟件項目管理計劃問題分析

　有人說“做項目計劃，如同給一個待出生的嬰兒寫傳記那樣困難。如果允許項目結束后再寫計劃，那就輕松多了，并且可以 100% 地準確”。確實是這樣，為什么項目的計劃這么難呢？

　　在軟件開發項目實踐中，關于計劃主要有以下一些常見問題

　　1、項目目標不夠清晰明確

　　這實際上在軟件開發項目中是一個普遍的現象。缺乏詳細的工作目標以便在項目結束時驗證是否取得了預期的成果。對于軟件開發項目而言，在進度、任務范圍、質量、成本等項目目標中，進度是最容易清晰明確的，也是用戶最為關心的。不管是獻禮工程或一把手工程，進度都是項目目標諸多方面中最先制定的，并且能夠很快在招標文件或合同中訂下來。當然，這種進度的合理性未必是經得起考驗的。而統計數字事實說明，大部分的軟件開發項目的進度是不合理的。無論是急于求成的客戶還是缺乏軟件開發經驗和軟件工程知識的項目經理都存在對進度過于樂觀的問題，其原因較多是因為他們對項目范圍的認識是在一種比較粗的顆粒度基礎之上。大多數的軟件開發項目在開始階段可能存在項目范圍不夠清晰的問題，需要經過需求調研之后才可以清晰。質量目標是最不容易清晰和明確的，這主要是因為軟件系統的質量量化比較難。由于質量目標的不確定性，它在進度、成本、范圍等目標的壓力之下就很容易被忽視。這似乎說明了，質量目標是這些目標中最不重要的一個，最有可能被犧牲的一個。成本目標可能用戶方面不太關心，確實軟件開發組織最為關心的，軟件開發的成本主要是人力資源的成本，其他的設備基礎設施都是可以重復使用的。所以，在進度、任務范圍、質量明確以后，人力資源的成本就可以經過經驗等方式估算出來。

　　2、對編寫計劃的過程在思想意識上重視不夠

　　實際上是對項目計劃的重要性認識還不夠充分，雖然大家都知道知道“作計劃”很重要，是項目成功的關鍵，但又認為計劃就是寫文檔，也許是因為一些人善于寫程序但不善于寫文檔，所以有些項目經理會認為寫文檔是一種走形式，或對繁瑣的文檔有一種排斥心理。其實不能把計劃當成僅僅是寫一個計劃文檔的問題，而是要通過編寫計劃文檔的過程，理清項目目標、項目范圍、項目所需資源、制定合理的項目進度、制定完成項目所需的各種約定(溝通、變更)、制定應對風險的有效對策。對于這一問題的解決，首先應當提高項目經理的計劃意識，采用項目計劃制定相關各種知識、技術、工具，加強對開發計劃、階段計劃的有效性進行事前事后的評估與評審工作。

　　3、制訂計劃時沒有進行充分的溝通

　　項目經理制訂計劃時沒有和項目主要成員和主要項目干系人共同討論協商，達成共識；或者最終計劃沒有發布到所有相關的項目干系人，取得他們的認同、理解，最重要的是對計劃中共同責任、目標和各自責任、目標的承諾；由此而造成的后果是項目計劃缺乏項目組成員的支持，沒有成為項目組成員的共識，沒有使每個項目組成員努力實現在項目計劃中所作的承諾。因此項目經理制訂計劃時首先要分清或確定主要項目成員和主要項目干系人，然后與他們進行充分的溝通協商，使項目計劃是一個大家都認同的，形成共識的有效文件。

　　一種更為嚴重的情況是遺漏了重要的項目干系人。在制定計劃時沒有考慮到所有項目干系人，特別是那些對于項目的成敗有重要影響的項目干系人，在制定計劃時要和他們進行充分溝通取得對項目進度、資源、驗收標準等計劃的共識和保證。

　　4、對總體計劃、階段計劃的作用認識不足

　　項目經理認為計劃不如變化快，項目中也有很多不確定的因素，做計劃是走過場，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮，或者是有一種等一下再說的想法；階段計劃因工作忙等理由經常拖延，造成計劃與控制管理脫節，無法進行有效的進度控制管理。那些號稱“所見即所得”的OA，邊做、邊提需求、邊改、邊完善的“四邊形”的所謂“快速”軟件開發也可能竟然是本企業周期延續最長的項目，因為無休無止的需求變更而永無止境。從項目的計劃階段來看，因為邊做、邊提需求、邊改、邊完善，所以他們首先就對計劃沒有信心，基本上計劃對他們來說只是應付，久而久之，對計劃方面的鍛煉意識不如其他項目，甚至養成不容易改掉的習慣。

　　5、任務和職責劃分不夠清晰或有遺漏

　　目標、任務的分解不夠清晰、工作有遺漏，沒有確定項目組成員職責的差別，如程序員的職責都籠統地寫成“編碼”。其主要原因是一些新任的項目經理是由程序員提拔起來的，不太熟悉軟件工程各階段工作職責中某些具體工作的分配，無法按任務分清每個人的責任。如應該分清楚需求人員該做什么、設計人員該做什么、編碼人員該做什么、測試人員該做什么。責任似乎很容易分清，但大家卻經常聽到“這是需求的事”、“這是設計的事”這樣的爭論，嚴重的造成項目組內部的糾紛扯皮。就是因為這些新的項目經理對一項具體工作，如界面設計、數據規格等應該由需求分析人員來做，還是設計人員來做分不清楚，還有就是做到什么程度算概要設計，什么程度算詳細設計，職責上也要搞清楚。建議新上任的項目經理應該多學習軟件工程的相關知識。

　　6、項目任務分工或進度計劃表的顆粒度太大

　　常見的現象有對任務持續時間進行不切實際的估計；或未考慮到任務的相互依賴關系而造成遺漏工作。其主要原因是軟件工程的分析與設計經驗的不足，無法細化系統需求，并從需求推導出設計，根據設計去分配任務。根據細化的需求也可以分配任務，但是由于需求中的功能點和設計中的模塊往往不是一一對應的，如一個需求功能點需要一系列的模塊來實現，多個需求功能點也可以共用同一組模塊加上不同的設置參數來實現。所以根據設計來確定程序代碼階段的任務分配比較合理。需求是整個項目的基礎、需求的清晰顆粒度對后面的工作及工作計劃的準確性至關重要。項目計劃的準確度是以一開始以需求(包括設計層需求)為基礎得出的工作結構分解的完整性、清晰性為基礎的。如果沒有這個基礎，項目計劃就不可能做得很準確。在無法準確制定項目計劃的情況下，對其風險要足夠重視，并制定出具體可行的對策。如果對整體的需求或工作結構分解無法一次完整的清晰，就應當把它先分解為幾個大塊，分塊進行，已經清晰的先制定本塊(階段)計劃，下一環節的工作也可以開始(分塊)進行。再項目開始階段往往還沒有得到詳細的需求成果，因此根據項目計劃漸進明晰的特點，在需求調研分析階段過后，需求成果清晰是，應當及時細化項目計劃，在概要設計完成時，要更進一步地細化后面編碼測試階段的詳細計劃。

7、與上一種情況相反的是計劃表的顆粒度太細

　　就是說軟件開發的工作雖然可以被劃分為若干階段，但是這些階段不應該是整齊劃一的。雖然每個環節階段成果是下一環節階段成果的基礎，但即使在階段成果通過評審之后下一環節對上一環節也應當隨時進行檢查驗證，上一環節根據下一環節的驗證檢查情況進行調整。在上一環節沒有得出可以供下一環節開展工作的基本成果時，下一階段的投入可能是浪費時間?！鞍慈蝿辗智迕總€人的責任”并不是說上一環節的人員在初次完成本環節后交給下一環節就了事了，而應該繼續與下一環節的人員共同作戰、相互影響、不斷進行同步完善,及時地解釋和調整上一階段的成果。如果上一階段與下一階段的負責人是同一個人，就沒有這方面的問題，但是在實際工作匯報時要考慮到在某個階段可能進行著前一個階段或后一個階段的工作。

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