今天和一個學長談論他實習的事情，他是文法院的，想去實習產品經理相關職位，順帶給我看了其崗位要求，我上網查了一下，軟件項目管理的相關知識。

在軟件工程飛速發展今天，軟件項目管理，與其稱之為一項工程，倒更不如說是一門藝術。在這個過程中，不僅要根據軟件項目的具體環境中巧妙整合軟件技術，經濟學和人際關系，更好考慮到高人員密集度，長時期跨度下可能出現的各種風險和問題。最近，根據對600多家公司的調查表明，35%的公司至少有一個失控的軟件項目。一方面，順序的，經典的流程驅動的瀑布模型使得人們在理解其風險和影響之前，過度地提出具有約束力的需求規範中的軟件功能。另一方面，代碼主導的開發過程，往往誘使企業過分註重功能復雜和代碼實現，而忽略了需求，工期，質量，資源等因素間的平衡。工作時"用程序代替用戶需求"，其結果必然如目前媒體"程序員生存狀況"所言，以開發人員在時間的犧牲為代價來換取項目的結束。無數軟件開發的殘酷的現實告訴我們：沒有規則的軟件開發過程帶來的只可能是無法預料的結果。如何改善我們的軟件開發管理，其實有許多的原則和經驗值得我們為之借鑒。

　　一.平衡原則

　　在我們討論軟件項目為什麽會失敗時可以列出很多的原因，如 管理問題、技術問題、人員問題等，但是有一個根本的思想問題是 最容易忽視的，也是軟件系統的用戶、軟件開發商、銷售代理商最 不想正視的，那就是：需求、資源、工期、質量這四個要素之間的 平衡關系問題。結合實際，我們可以通俗地理解這四者之間彼此的聯系，需求的增多，必然會帶來資源消耗的增多和工期的延長；而用戶的需求又與工期密切關聯，用戶不希望工程交付過晚；相對而言，追求更高的質量，需要我們投入更多的人力物力資源，甚至更長的工期；同樣，一個高質量的產品，也不是盲目得趕工期，多投入就可以完成的。這就要求我們在實際中考慮平衡需求，資源，工期，質量並得到各方面均衡的一個最優解。在軟件項目中我們不僅僅是關註項目的進度，質量，範圍和成本四要素的平衡。還需要關註人員角色分工的平衡，冒險和保守的平衡，外部和內部的平衡，紀律和靈活性間的平衡等等。任何一個方面失去平衡，項目都可能處於危險中。

　　這就要求我們在軟件開發伊始，就建立細致長遠的開發和管理計劃，平衡各要素間的分配。沒有計劃，就無從知道什麽時候控制和變更。制定一個詳盡的計劃，以詳細到開發人員可以理解的程度為宜。計劃能夠告訴你什麽時候應該做什麽。由於沒有計劃或是計劃太粗糙、不切實際，很多項目1/3甚至1/2的時間花在返工上面。因為計劃中遺漏了某一項關鍵任務，或者因為計劃太過簡陋，就會出現在實際開發過程中，一旦遇到大的問題，急於解決的過程中就會使得原本設計好的需求，資源，工期與質量間的平衡被打破，隨之帶來的，無論是工期上的延長，還是質量上的紕漏，都可能導致項目最終宣告失敗。

　　 二.高效原則

　　記得看過一篇facebook創始人紮克伯格回憶自己創業之初的故事，有一句話讓我印象深刻，“真正決定人生高度的，是你做事的速度”。當初，心血來潮的紮克伯格從產生想法，到實現一款簡單的應用--大頭照對比評分應用FaceMash，僅用了6個小時。在短短的時間內，他獨自一人完成了產品的設計，開發，上線....這在當時可能是一個小型企業兩天的日常工作量。而他的對頭，在哈弗就讀的Winklevoss兄弟，總說紮克伯格抄襲了他們的創意，才有了後來的facebook，而事實呢？在Winklevoss兄弟在猶豫是否要投入做社交網站時，紮克伯格的facebook已經覆蓋了29所學校，7.5萬註冊用戶。促成他們以後差距的，正是二者執行力的差距。也只有像這樣在短時間內完成高質量的任務才能稱之為高效。

　　在實際情況中，軟件項目的人力資源分配大致符合Norden-Rayleigh曲線分布。①區域代表開始階段，人力過剩；②區域表示開發的中後期，人手不足；③區域表示後來的補償時間過晚，反而會出現Brooks定律的情況:“向一個已經拖延的項目追加新的開發人員，可能會使這個項目完成得更晚”。因為作為新加入的員工來說，相關培訓、環境熟悉和人員之間的溝通通路的增加，迫使項目的工作效率急劇下跌。工作效率下降需要加班來進行彌補，但加班造成的疲勞會再次使工作效率降低。同時工作成本卻不斷的向上攀升。

　　基於高效性原則，需要對項目管理考慮以下幾個方面：1.選擇精英成員，雖然現實中開發人員不可能，也做不到像紮克伯格那樣擁有天才般的速度和執行力，但總可以從現有人力資源中挑選出其中精英，對不同專長的人安排不同分工；2.目標要明確，範圍要清楚，明確開發目標和功能的覆蓋範圍，並在實際操作過程中堅定地保持始終如一；3.溝通要及時、充分，溝通管理是對項目過程中產生的各種信息進行收集、存儲、發布和最終處理，由溝通計劃編制、信息發送、性能報告和階段的結束構成。溝通，不僅包括項目組內部程序員和項目經理的溝通，還需要客戶與項目組的溝。溝通的不足會導致效率的降低；4.要在激勵成員上下工夫，通過評估我們可以激勵人員，保證績效。良好的績效管理可以一目了然地反映項目成員的業績，一切以數據說話，更能體現公平。績效考核分項目績效和個人績效兩個部分，項目績效從項目成本、利潤、完成計劃情況、項目質量、規範程度、文檔水平、技術、產品化和共享度方面評價項目效果。

　　三.優先原則

　　在軟件工程中存在這樣的PARETO定律：在實際中企業80%的問題可以用20%的投資解決，而20%的次要問題則需要花費80%的投資的。在軟件項目中，如果出現了過多的需求，通常會導致項目超出預算和預定進度，最終導致軟件項目的失敗，此時需求的優先級可能比需求本身更為重要。仔細分析一下，這些項目要求分為必須的非必須的，因此我們建議是壓縮非必須的部分或是暫時將其放在一邊不必太重視。軟件項目開發事實告訴我們，開發人員在非必須的項目要求上耗費了太多的精力，用戶的需求變更的大部分出現在"最好有"這一部分，實際上用戶並不看重這些需求（即使去除這些需求），而我們所做的，往往是舍本求末。

　　在實際情況中，軟件開發負責人員往往會面臨需求方提出的一系列繁復的需求，在實施過程中一定要將需求劃分為不同的優先級，建立項目開發的需求優先級隊列，對於一個管理良好的軟件工程必不可少。反之，盲目追求對細枝末節的全覆蓋，反而會極大拖慢工期進度，甚至影響產品質量。

　　四.分解原則

　　“分而治之”是計算機領域的一個重要思想，對於軟件項目來講，可以將大的項目劃分成幾個小項目來做，將周期長的項目化分成幾個明確的階段。在需求管理中首先要進行分類管理，將軟件需求分出層次，不同層次需求的側重點、描述方式和管理方式是不同的。對於管理層而言，提出的需求可能會更加偏向於全局性的目標需求，對於底層實現和分工並不關心；而中層需要將具體的操作，代碼分配給不同部分，人員進行實現，同時需要考慮各部分之間的相互銜接。項目越大對項目組的管理人員、開發人員的要求越高，參與的人員越多，需要協調溝通的渠道越多，周期越長，開發人員也容易疲勞，將大項目拆分成幾個小項目，可以降低對項目管理人員的要求，減少項目的管理風險，而且能夠充分地將項目管理的權力下放，充分調動人員的積極性，目標會比較具體明確，易於取得階段性的成果，使開發人員有成就感。

　　五.風險原則

　　某家知名軟件公司曾總結出排行前幾的為軟件管理埋下風險的罪魁禍首，分別是：

　　1.人為缺陷；2.不切實際的時間表和預算；3.開發錯誤的功能和屬性；4.開發錯誤的用戶交互；5.畫蛇添足；6.持續的需求更改.....

　　軟件項目管理的過程中，唯一不變的就是"變化"。風險管理也是始終貫穿於軟件項目管理之中的重要元素，在項目中不考慮可能發生的變化是不可思議的。不過在面對項目可能發生變化而帶來的項目風險時，項目管理人員往往會懷有逃避的態度。經濟學裏大名鼎鼎的風險規避原則便是項目管理人員心理的有效描述。作為項目管理人員來說，應該及早預測可能出現的風險，做好風險儲備。雖然風險儲備不能解決所有的問題，但預防勝於治療"。通過學習項目管理知識掌握風險識別、量化、對策研究、反應控制的工具和方法，掌握項目風險管理所必備的知識。通過加強對項目規劃中風險管理計劃的審核提高項目組的風險管理意識。

　　小結：

　　隨著軟件開發的深入、各種技術的不斷創新以及軟件產業的形成，人們越來越意識到軟件過程管理的重要性，管理學的思想逐漸融入軟件開發過程中，項目開發的管理日益受到重視。然而，實施切實有效的軟件項目管理在實際操作中絕非易事，了解和運用上述原則是不夠的，若要達成軟件工程管理的最終目標——保證軟件項目能夠按照預定的成本，進度，質量按期，順利地交付用戶使用，還必須深入學習項目管理、管理心理學、質量管理學、組織變革、系統論等方面的知識，並在工作中不斷的總結和實踐。

參考文獻:

[1]BARRY W. BOEHM，SENIOR MEMBER.Theory-W Software Project Management: and Examples，IEEE

[2]Software project management，維基百科詞條

[3]BARRY W. BOEHM，Defense Advanced Research Projects Agency.Software Risk Management: Principles and Practices，IEEE

[4]曾祥鵬.淺談軟件開發項目管理，今日科苑

[5]孫鴻飛，武慧娟.淺談軟件開發項目管理的意義和原則，商場現代化

軟件項目管理