軟體項目管理

軟體項目管理的根本目的是為了讓軟體項目尤其是大型項目的整個軟體生命周期（從分析、設計、編碼到測試、維護全過程）都能在管理者的控制之下，以預定成本按期，按質的完成軟體交付用戶使用。而研究軟體項目管理為了從已有的成功或失敗的案例中總結出能夠指導今後開發的通用原則，方法，同時避免前人的失誤。軟體項目管理的提出是在20世紀70年代中期的美國，當時美國國防部專門研究了軟體開發不能按時提交，預算超支和質量達不到用戶要求的原因，結果發現70%的項目是因為管理不善引起的，而非技術原因。於是軟體開發者開始逐漸重視起軟體開發中的各項管理。到了20世紀90年代中期，軟體研發項目管理不善的問題仍然存在。據美國軟體工程實施現狀的調查，軟體研發的情況仍然很難預測，大約只有10％的項目能夠在預定的費用和進度下交付。 1995年，據統計，美國共取消了810億美元的商業軟體項目，其中31％的項目未做完就被取消，53％的軟體項目進度通常要延長50%的時間，只有9％的軟體項目能夠及時交付並且費用也控制在預算之內。軟體項目管理和其他的項目管理相比有相當的特殊性。首先，軟體是純知識產品，其開發進度和質量很難估計和度量，生產效率也難以預測和保證。其次，軟體系統的複雜性也導致了開發過程中各種風險的難以預見和控制。Windows這樣的操作系統有1500萬行以上的代碼，同時有數千個程序員在進行開發，項目經理都有上百個。這樣龐大的系統如果沒有很好的管理，其軟體質量是難以想象的。軟體項目管理的內容主要包括如下幾個方面：人員的組織與管理，軟體度量，軟體項目計劃，風險管理，軟體質量保證，軟體過程能力評估，軟體配置管理等。這幾個方面都是貫穿、交織於整個軟體開發過程中的，其中人員的組織與管理把注意力集中在項目組人員的構成、優化；軟體度量把關注用量化的方法評測軟體開發中的費用、生產率、進度和產品質量等要素是否符合期望值，包括過程度量和產品度量兩個方面；軟體項目計劃主要包括工作量、成本、開發時間的估計，並根據估計值制定和調整項目組的工作；風險管理預測未來可能出現的各種危害到軟體產品質量的潛在因素並由此採取措施進行預防；質量保證是保證產品和服務充分滿足消費者要求的質量而進行的有計劃，有組織的活動；軟體過程能力評估是對軟體開發能力的高低進行衡量；軟體配置管理針對開發過程中人員、工具的配置、使用提出管理策略。因為大家對人力資源管理和軟體過程能力比較有興趣，下面就詳細的對這兩方面展開討論。

軟體項目計劃是一個軟體項目進入系統實施的啟動階段，主要進行的工作包括：確定詳細的項目實施範圍、定義遞交的工作成果、評估實施過程中主要的風險、制定項目實施的時間計劃、成本和預算計劃、人力資源計劃等。

軟體項目管理過程從項目計劃活動開始，而第一項計劃活動就是估算：需要多長時間、需要多少工作量、以及需要多少人員。此外，我們還必須估算所需要的資源（硬體及軟體）和可能涉及到的風險。

為了估算軟體項目的工作量和完成期限，首先需要預測軟體規模。度量軟體規模的常用方法有直接的方法——LOC（代碼行），間接的方法——FP（功能點）。這兩種方法各有優缺點，應該根據軟體項目的特點選擇適用的軟體規模度量方法。

根據項目的規模可以估算出完成項目所需的工作量，我們可以使用一種或多種技術進行估算，這些技術主要分為兩大類：分解和經驗建模。分解技術需要劃分出主要的軟體功能，接著估算實現每一個功能所需的程序規模或人月數。經驗技術的使用是根據經驗導出的公式來預測工作量和時間。可以使用自動工具來實現某一特定的經驗模型。

精確的項目估算一般至少會用到上述技術中的兩種。通過比較和協調使用不同技術導出的估算值，我們可能得到更精確的估算。軟體項目估算永遠不會是一門精確的科學，但將良好的歷史數據與系統化的技術結合起來能夠提高估算的精確度。

當對軟體項目給予較高期望時，一般都會進行風險分析。在標識、分析和管理風險上花費的時間和人力可以從多個方面得到回報：更加平穩的項目進展過程；更高的跟蹤和控制項目的能力；由於在問題發生之前已經做了周密計劃而產生的信心。

對於一個項目管理者，他的目標是定義所有的項目任務，識別出關鍵任務，跟蹤關鍵任務的進展情況，以保證能夠及時發現拖延進度的情況。為此，項目管理者必須制定一個足夠詳細的進度表，以便監督項目進度並控制整個項目。

常用的制定進度計劃的工具主要有GANTT圖和工程網路兩種。Gantt圖具有悠久歷史、直觀簡明、容易學習、容易繪製等優點，但是，它不能明顯地表示各項任務彼此間的依賴關係，也不能明顯地表示關鍵路徑和關鍵任務，進度計劃中的關鍵部分不明確。因此，在管理大型軟體項目時，僅用Gantt圖是不夠的，不僅難於做出既節省資源又保證進度的計劃，而且還容易發生差錯。

工程網路不僅能描繪任務分解情況及每項作業的開始時間和結束時間，而且還能清楚地表示各個作業彼此間的依賴關係。從工程網路圖中容易識別出關鍵路徑和關鍵任務。因此，工程網路圖是制定進度計劃的強有力的工具。通常，聯合使用Gantt圖和工程網路這兩種工具來制定和管理進度計劃，使它們互相補充、取長補短。

進度安排是軟體項目計劃的首要任務，而項目計劃則是軟體項目管理的首要組成部分。與估算方法和風險分析相結合，進度安排將為項目管理者建立起一張計劃圖。

對於軟體開發項目而言，控制是十分重要的管理活動。下面介紹軟體工程式控制制活動中的質量保證和配置管理。其實上面所提到的風險分析也可以算是軟體工程式控制制活動的一類。而進度跟蹤則起到連接軟體項目計劃和控制的作用。

軟體質量保證（SQA，Software Quality Insurance）是在軟體過程中的每一步都進行的“保護性活動”。SQA主要有基於非執行的測試（也稱為評審）、基於執行的測試（即通常所說的測試）和程序正確性證明。

軟體評審是最為重要的SQA活動之一。它的作用是，在發現及改正錯誤的成本相對較小時就及時發現並排除錯誤。審查和走查是進行正式技術評審的兩類具體方法。審查過程不僅步數比走審多，而且每個步驟都是正規的。由於在開發大型軟體過程中所犯的錯誤絕大數是規格說明錯誤或設計錯誤，而正式的技術評審發現這兩類錯誤的有效性高達75%，因此是非常有效的軟體質量保證方法。

軟體配置管理（SCM，Software configuration management）是應用於整個軟體過程中的保護性活動，它是在軟體整個生命周期內管理變化的一組活動。

軟體配置由一組相互關聯的對象組成，這些對象也稱為軟體配置項，它們是作為某些軟體工程活動的結果而產生的。除了文檔、程序和數據這些軟體配置項之外，用於開發軟體的開發環境也可置於配置控制之下。

一旦一個配置對象已被開發出來並且通過了評審，它就變成了基線。對基線對象的修改導致建立該對象的版本。版本控制是用於管理這些對象而使用的一組規程和工具。

變更控制是一種規程活動，它能夠在對配置對象進行修改時保證質量和一致性。配置審計是一項軟體質量保證活動，它有助於確保在進行修改時仍然保持質量。狀態報告向需要知道關於變化的信息的人，提供有關每項變化的信息。

8ManagePPM新一代軟體項目管理工具，項目立項-計劃-實施-收尾全過程管理，進度可視化，實時跟蹤進度，需求，問題，變更等，可自定義，預警提醒。

軟體功能：

1、交易型管理：支持所有項目成員同時更新項目動態，並通過設置可交付成果及審批流程確保項目數據的客觀性，同時自動、實時地匯總項目數據，確保項目數據的精準。2、WBS架構：支持利用項目模板快速創建項目的WBS；支持對項目計劃進行分解、設置優先順序、依賴等，項目架構一目了然；支持為每個項目子活動設置負責人，界定責任，避免推諉。3、OGSM（業務地圖）：將策略、項目、日常工作（崗位例行工作、重大事項、公文執行等）進行有機整合，動態實時地展示和監控工作落實情況，幫助管理層輕鬆了解策略執行情況，追蹤每個環節出現的問題。4、多項目管理：實現在一個頁面對多個項目進行管理，幫助管理層同步管理多個項目的目標、進度、成本及質量，同時還可以追溯到每個項目的情況，提升項目管理效率。5、項目成本管控：支持“自上而下”項目預算及“自下而上”項目支出，實時跟蹤項目成本的變化情況，對於超支的情況則以高亮形式自動提醒；提供費用控制功能，可自定義項目或單個事項的費用在某個範圍內需要再被審批。

PPM亮點: 1、項目計劃與執行合二為一, 能實時且可靠地追蹤每一個變更的起因及影響, 因責任分明及有效問責而減少借口及增強履職盡責。2、動態項目資源管理, 能計劃並追蹤資源種類、技能、負荷及時間安排, 並能實時知道資源變更的影響及代替資源的可用性; 支特多部門、多站點、多項目及多資源種類的資源管理。3、動態項目產品、物料、BOM、進度、溝通、變更、問題、風險、質量、交付、驗收、成本及收入管理4、簡單項目管理，複雜項目管理、多項目管理、項目辦公室管理及項目組合管理5、通用項目管理、研發項目管理、工程項目管理、生產項目管理及投資項目管理8ManagePPM解決什麼問題: 1、超資超時或根本完成不了的項目 (不可控項目)2、跨部門及跨地域的大型項目管理3、多個項目同時進行 (多項目管理)4、項目申請、立項管理及ROI管理PPM靈活性: 1、多貨幣及實時3語轉換2、已有豐富即裝即用的頁面和欄位, 後台支特增加/更改/刪除欄位3、8Manage隨時可添加OA、CRM、採購、ERP及BI等模塊或與客戶現有模塊對接, 且能保持數據實時性4、預建的數據倉庫及點選式報表生成器可讓用戶選擇2D或3D表格、柱形圖、餅狀圖或趨勢圖及欄位生成報表或BI實時儀錶盤來實現數據可視化、圖形數據分析及多維度分析

軟體項目可以是一個單獨的開發項目，也可以與產品項目組成一個完整的軟體產品項目。如果是訂單開發，則成立軟體項目組即可；如果是產品開發，需成立軟體項目組和產品項目（負責市場調研和銷售），組成軟體產品項目組。公司實行項目管理時，首先要成立項目管理委員會，項目管理委員會下設項目管理小組、項目評審小組和軟體產品項目組。

3.1、項目管理委員會項目管理委員會是公司項目管理的最高決策機構，一般由公司總經理、副總經理組成。主要職責如下：

（1）依照項目管理相關制度管理項目；

（2）監督項目管理相關制度的執行；

（3）對項目立項、項目撤消進行決策；

（4）任命項目管理小組組長、項目評審委員會主任、項目組組長.

3.2、項目管理小組項目管理小組對項目管理委員會負責，一般由公司管理人員組成。主要職責如下：

（1）草擬項目管理的各項制度；

（2）組織項目階段評審；

（3）保存項目過程中的相關文件和數據；

（4）為優化項目管理提出建議。

3.3、項目評審小組項目評審小組對項目管理委員會負責，可下設開發評審小組和產品評審小組，一般由公司技術專家和市場專家組成。主要職責如下：

（1）對項目可行性報告進行評審；

（2）對市場計劃和階段報告進行評審；

（3）對開發計劃和階段報告進行評審；

（4）項目結束時，對項目總結報告進行評審。

3.4、軟體產品項目組軟體產品項目組對項目管理委員會負責，可下設軟體項目組和產品項目組。軟體項目組和產品項目組分別設開發經理和產品經理。成員一般由公司技術人員和市場人員構成。主要職責是：根據項目管理委員會的安排具體負責項目的軟體開發和市場調研及銷售工作。

從軟體工程的角度講，軟體開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。根據公司實際情況，公司在進行軟體項目管理時，重點將軟體配置管理、項目跟蹤和控制管理、軟體風險管理及項目策劃活動管理四方面內容導入軟體開發的整個階段。在20世紀80年代初，著名軟體工程專家B.W.Boehm總結出了軟體開發時需遵循的七條基本原則，同樣，在進行軟體項目管理時，也應該遵循這七條原則。它們是：

（1）用分階段的生命周期計劃嚴格管理；

（2）堅持進行階段評審；

（3）實行嚴格的產品控制；

（4）採用現代程序設計技術；

（5）結果應能夠清楚地審查；

（6）開發小組地人員應該少而精；

（7）承認不斷改進軟體工程實踐的必要性。

項目組成立的第一件事是編寫《軟體項目計劃書》，在計劃書中描述開發日程安排、資源需求、項目管理等各項情況的大體內容。計劃書主要向公司各相關人員發放，使他們大體了解該軟體項目的情況。對於計劃書的每個內容，都應有相應具體實施手冊，這些手冊是供項目組相關成員使用的。

是否進行配置管理與軟體的規模有關，軟體的規模越大，配置管理就顯得越重要。軟體配置管理簡稱SCM（Software Configuration Management的縮寫），是在團隊開發中，標識、控制和管理軟體變更的一種管理。配置管理的使用取決於項目規模和複雜性以及風險水平。

6.1、目前軟體開發中面臨的問題：在有限的時間、資金內，要滿足不斷增長的軟體產品質量要求；開發的環境日益複雜，代碼共享日益困難，需跨越的平台增多；程序的規模越來越大；軟體的重用性需要提高；軟體的維護越來越困難。

6.2、軟體配置管理應提供的功能:

在ISO9000.3中，對配置管理系統的功能作了如下描述：唯一地標識每個軟體項的版本；標識共同構成一完整產品的特定版本的每一軟體項的版本；控制由兩個或多個獨立工作的人員同時對一給定軟體項的更新；控制由兩個或多個獨立工作的人員同時對一給定軟體項的更新；按要求在一個或多個位置對複雜產品的更新進行協調；標識並跟蹤所有的措施和更改；這些措施和更改是在從開始直到放行期間，由於更改請求或問題引起的。

6.3、版本管理軟體配置管理分為版本管理、問題跟蹤和建立管理三個部分，其中版本管理是基礎。版本管理應完成以下主要任務：

建立項目；

重構任何修訂版的某一項或某一文件；

利用加鎖技術防止覆蓋； ?當增加一個修訂版時要求輸入變更描述；

提供比較任意兩個修訂版的使用工具；

採用增量存儲方式；

提供對修訂版歷史和鎖定狀態的報告功能；

提供歸併功能；

允許在任何時候重構任何版本；

許可權的設置；

晉陞模型的建立；

提供各種報告。

軟體開發中的開發人員是最大的資源。對人員的配置、調度安排貫穿整個軟體過程，人員的組織管理是否得當，是影響對軟體項目質量的決定性因素。

首先在軟體開發的一開始，要合理的配置人員，根據項目的工作量、所需要的專業技能，再參考各個人員的能力、性格、經驗，組織一個高效、和諧的開發小組。一般來說，一個開發小組人數在5到10人之間最為合適，如果項目規模很大，可以採取層級式結構，配置若干個這樣的開發小組。

在選擇人員的問題上，要結合實際情況來決定是否選入一個開發組員。並不是一群高水平的程序員在一起就一定可以組成一個成功的小組。作為考察標準，技術水平、與本項目相關的技能和開發經驗、以及團隊工作能力都是很重要的因素。一個一天能寫一萬行代碼但卻不能與同事溝通融洽的程序員，未必適合一個對組員之間通訊要求很高的項目。還應該考慮分??個網站開發項目，小組中有頁面美工、後台服務程序、資料庫幾個部分，應該合理的組織各項工作的人員配比。對於一個中型農技110網站，對數據採集量要求較高，一個人員配比方案可以是2個美工、2個後台服務程序編寫、3個數據採集整理人員。

可以用如下公式來對候選人員能力進行評分，達到一定分數的則可以考慮進入開發組，但這個公式不包含對人員數量配比的考慮。

Score=∑WiCi(i=1to8)

Ci是對項目組人員各項能力的評估。其值含義如下

在決定一個開發組的開發人員數量時，除了考慮候選人素質以外，還要綜合考慮項目規模、工期、預算、開發環境等因素的影響，下面是一個基於規模、工期和開發環境的人員數量計算公式：

L=Ck*K1/3*td4/3

L:開發規模，以代碼行LOC為度量td:開發時間K：人員數

Ck：技術常數表示開發環境的優劣

取值2000：表示開發環境差，沒有系統的開發方法，缺乏文檔規範化設計；

取值8000：表示開發環境較好；

取值11000：表示開發環境優。

在組建開發組時，還應充分估計到開發過程中的人員風險。由於工作環境、待遇、工作強度、公司的整體工作安排和其他無法預知的因素，一個項目尤其是開發周期較長的項目幾乎無可避免的要面臨人員的流入流出。如果不在項目初期對可能出現的人員風險進行充分的估計，作必要的準備，一旦風險轉化為現實，將有可能給整個項目開發造成巨大的損失。以較低的代價進行及早的預防是降低這種人員風險的基本策略。具體來說可以從以下幾個方面對人員風險進行控制：

a．保證開發組中全職人員的比例，且項目核心部分的工作應該盡量由全職人員來擔任，以減少兼職人員對項目組人員不穩定性的影響。

b．建立良好的文檔管理機制，包擴項目組進度文檔、個人進度文檔、版本控制文檔、整體技術文檔、個人技術文檔、源代碼管理等。一旦出現人員的變動，比如某個組員因病退出，替補的組員能夠根據完整的文檔儘早接手工作。

c．加強項目組內技術交流，比如定期開技術交流會，或根據組內分工建立項目組內部的開發小組，是開發小組內的成員能夠相互熟悉對方的工作和進度，能夠在必要的時候替對方工作。

d．對於項目經理，可以從一開始就指派一個副經理在項目中協同項目經理管理項目開發工作，如果項目經理退出開發組，副經理可以很快接手。但是只建議在項目經理這樣的高度重要的崗位採用這種冗餘複製的策略來預防人員風險，否則將大大增加項目成本。

e．為項目開發提供儘可能好的開發環境，包括工作環境、待遇、工作進度安排等等，同 時一個優秀的項目經理應該能夠在項目組內營造一種良好的人際關係和工作氛圍。良好的開發環境對於穩定項目組人員以及提高生產效率都有不可忽視的作用。

軟體過程能力描述了一個開發組織開發軟體開發高質量軟體產品的能力。現行的國際標準主要有兩個：ISO9000.3和CMM。

ISO9000.3是ISO9000質量體系認證中關於計算機軟體質量管理和質量保證標準部分。它從管理職責、質量體系、合同評審、設計控制、文件和資料控制、採購、顧客提供產品的控制、產品標識和可追溯性、過程式控制制、檢驗和試驗、檢驗/測量和試驗設備的控制、檢驗和試驗狀態、不合格品的控制、糾正和預防措施、搬運/貯存/包裝/防護和交付、質量記錄的控制、內部質量審核、培訓、服務、統計系統等二十個方面對軟體質量進行了要求。

CMM（能力成熟度模型）是美國卡納基梅隆大學軟體工程研究所（CMU／SEI）於1987年提出的評估和指導軟體研發項目管理的一系列方法，用5個不斷進化的層次來描述軟體過程能力。現在CMM是2.0版本。

ISO9000和CMM的共同點是二者都強調了軟體產品的質量。所不同的是，ISO9000強調的是衡量的準則，但沒有告訴軟體開發人員如何達到好的目標，如何避免差錯。CMM則提供了一整套完善的軟體研發項目管理的方法。它可告訴軟體開發組織，如果要在原有的水平上提高一個等級，應該關注哪些問題，而這正是改進軟體過程的工作。

CMM描述了五個級別的軟體過程成熟度（初始級，可重複級，已定義級，已定量管理級，優化級），成熟度反映了軟體過程能力的大小。

初始級特點是軟體機構缺乏對軟體過程的有效管理，軟體過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，其軟體項目的成功來源於偶爾的個人英雄主義而非群體行為，因此它不是可重複的；可重複級的特點是軟體機構的項目計劃和跟蹤穩定，項目過程可控，項目的成功是可重複的；已定義級的特點在於軟體過程已被提升成標準化過程，從而更加具有穩定性、可重複性和可控性；已定量管理級的軟體機構中軟體過程和軟體產品都有定量的目標，並被定量地管理，因而其軟體過程能力是可預測的，其生產的軟體產品是高質量的；優化級的特點是過程的量化反饋和先進的新思想、新技術促進過程不斷改進，技術和過程的改進改進被作為常規的業務活動加以計劃和管理。

CMM是科學評價一個軟體企業開發能力的標準，但要達到較高的級別也非常困難，根據1995年美國所做的軟體產業成熟度的調查，在美國的軟體產業中，CMM成熟度等級為初始級的竟佔70％，為可重複級的佔15％，為定義級的所佔比例小於10％，為管理級的所佔比例小於5％，為優化級的所佔比例小於l％。而國內企業的水平就更加堪優，到目前為止，只有東軟一家達到優化級，少數幾家能夠達到可定義級。儘快改變這種局面，科學化、規範化、高效的進行軟體開發活動，從整體提高我國軟體行業的水平，是國內軟體企業的當務之急，也是專業人員應該為自己制定的目標。如果有一天也能指揮一個數千人的龐大開發隊伍，操作Windows這樣巨型規模的軟體項目，並生產出高質量的產品，才有理由宣稱自己的軟體項目管理能力達到了一個“自主自足”的水平。

沒有項目管理，項目也有可能成功。但沒有管理的項目，很難保證項目的利潤空間，對公司來說，虧損的風險就大。所以我們要有項目管理，以保證公司在總體上是盈利的，注意不是每一個項目都要盈利。

另外，有了項目管理，就有了管理改進的基礎，無論剛開始的項目管理多麼糟糕，只要有管理，就有了改進的可能性，至於能不能得到改進，以及改進的快慢，則取決於兩個因素：一個是人，特別是各級管理者；另一個是利益。關鍵是"利益"，準確的說是"利益的分配"，在權責利明確的前提下，人才能充分的發揮作用。還需要指出的是"利益"是多元的，這裡的多元不僅指利益的具體形式，而且指利益的受眾是多元的，包括客戶方相關人員個人的利益。

專業化是一個趨勢，因為在專業化的條件下，可以有效降低成本，提高利潤率。項目經理的工作內容歸根到底只有一項：識別並管理風險。這項工作的目的是控制項目成本。

由於項目的風險是多方面的，而且風險的表現形式也是多種多樣的。從風險範圍上來說，既有公司內部風險，也有和客戶交流、合作的風險；從風險的類型上來說，既有管理風險，也有技術風險；從風險產生的階段來說，包括了從業務分析到上線后維護的項目周期各個階段。

我認為一個項目經理是否優秀，主要是看他/她能在多大程度上提前識別並消除風險，而不是彌補和解決了多少問題（風險未被及時識別或妥善處理，就會轉換成問題）。當然能彌補和解決問題的項目經理也是相當合格的，但還不夠優秀。

項目組的範圍界限可以有三種劃分：

1、包括客戶方所有參與該項目的立項、調研、審批、測試和使用人員，包括開發商市場開發、管理審批、商務談判、後勤保障和具體負責該項目開發的人員；

2、包括客戶方項目經理、業務需求提出人和測試人，包括開發商具體負責該項目開發的人員；

3、僅包括開發商具體負責該項目開發的人員。

大部分人在思想上可以接受範圍1，而在實務中接受的是範圍3。而我個人認為項目經理，特別是開發商方面的項目經理應該採用的是範圍2。

對項目組範圍理解不同，將影響項目經理對工作的處理方式，範圍1實際上是很虛的，在項目管理實務操作中沒有太大的意義；而範圍3實質是把客戶方和該項目有密切關係的人與開發商具體負責該項目開發的人對立起來，也就是所謂的甲方、乙方。在這種對立的前提下處理項目的分歧和矛盾，效果肯定要打折扣。

而按範圍2來理解，在項目管理實務中項目經理就必須要讓客戶方和該項目有密切關係的人也接受這一觀點，從而拆除雙方之間的"障礙"，達到相互信任、相互尊重、共同協商解決問題的良性氛圍，以達到降低項目外部風險的目的。當然，這樣就增大了項目經理工作的難度，但對項目的成功則是很重要的。

對"成功項目"的標準解釋為：項目範圍、項目成本、項目開發時間、客戶滿意度四點達到要求。我認為其實只有一點--利益。項目範圍、客戶滿意度主要代表客戶的利益，項目成本主要代表開發商的利益，項目開發時間同時影響雙方的利益。但每一個人關心的"利益"是不同的。

1平衡原則

在我們討論軟體項目為什麼會失敗時可以列出了很多的原因，答案有很多，如管理問題、技術問題、人員問題等等，但是有一個根本的思想問題是最容易忽視的，也是軟體系統的用戶、軟體開發商、銷售代理商最不想正視的，那就是：需求、資源、工期、質量四個要素之間的平衡關係問題。

需求定義了"做什麼"，定義了系統的範圍與規模，資源決定了項目的投入（人、財、物），工期定義了項目的交付日期，質量定義了做出的系統好到什麼程度，這四個要素之間是有制約平衡關係的。如果需求範圍很大，要在較少的資源投入下，很短的工期內，很高的質量要求來完成某個項目，那是不現實的，要麼需要增加投資，要麼工程延期；如果需求界定清楚了，資源固定了，對系統的質量要求很高，則可能需求延長工期。

對於上述四個要素之間的平衡關係最容易犯的一個錯誤，就是鼓吹"多快好省"四個字，"多快好省"，多麼理想的境界啊？需求越多越好，工期越短越好，質量越高越好，投入越少越好，這是用戶最常用的口號。

多：需求越多越好嗎？

軟體系統實施的基本原則是"全局規劃，分步實施，步步見效"，需求可以多，但是需求一定要分優先順序，要分清企業內的主要矛盾與次要矛盾，根據PARETO的80-20原則，企業中的80%的問題可以用20%的投資來解決，如果你要大而全，對不起，你那20%的次要問題是需要你花費80%的投資的！而這一點恰恰是很多軟體用戶所不能忍受的。

快：真能快起來嗎？

"快"是用戶、軟體開發商都希望的。傳統企業里強調資金的周轉情況，軟體企業里強調的是人員的周轉情況，開發人員應儘快做完一個項目再做另外一個項目，通過快速的啟動項目、結束項目來承擔更多的項目，來獲利。但是"快"不是主觀的拍腦袋定工期就可以完成的，工期的定義一定要基於資源的狀況、需求的多少與質量的需求來進行推算的。軟體畢竟需要一行代碼一行代碼的寫出來，他的工作量是客觀的，並非?quot;人有多大膽，地有多大產"式的精神鼓動就可以短期完成的。

省：省到什麼程度？

"一分錢一分貨"，這是中國的俗話，他是符合價值規律的。甲方希望少投入，乙方希望降低自己的生產成本，省到乙方僅能保本的時候，再省，乙方就虧損了。

正視這四個要素之間的平衡關係是軟體用戶、開發商、代理商成熟理智的表現，否則系統的成功就失去了一塊最堅實的理念基礎。

企業實施IT系統的首要目標是要成功，而不是失敗，企業可以容忍小的成功，但不一定容忍小的失敗，所以需要真正理解上述四個要素的平衡關係，確保項目的成功。

2高效原則

在需求、資源、工期、質量四個要素中，很多的項目決策者是將進度放在首位的，現在市場的競爭越來越激烈，"產品早上市一天，就早掙一天錢，掙的就比花的多，所以一定要多掙"，基於這樣一個理念，軟體開發越來越追求開發效率，大家從技術、工具、管理上尋求更多更好的解決之道。

基於高效的原則，對項目的管理需要從幾個方面來考慮：

要選擇精英成員

目標要明確，範圍要清楚

溝通要及時、充分

要在激勵成員上下工夫

3分解原則

"化繁為簡，各個擊破"是自古以來解決複雜問題的不二法門，對於軟體項目來講，可以將將大的項目劃分成幾個小項目來做，將周期長的項目化分成幾個明確的階段。

項目越大對項目組的管理人員、開發人員的要求越高，參與的人員越多，需要協調溝通的渠道越多，周期越長，開發人員也容易疲勞，將大項目拆分成幾個小項目，可以降低對項目管理人員的要求，減少項目的管理風險，而且能夠充分地將項目管理的權力下放，充分調動人員的積極性，目標會比較具體明確，易於取得階段性的成果，使開發人員有成就感。

作者主管過的一個產品開發項目代號為SB，該項目前期投入了5人做需求，時間達3個多月，進入開發階段后，投入了15人，時間達10個月之久，陸續進行了3次封閉開發，在此過程中經歷了需求的裁剪、開發人員的變更、技術路線的調整，項目組成員的壓力極大，大家疲憊不堪，產品上市時間拖期達4個月。項目完工後總結下來的很致命的一個教訓就是應該將該項目拆成3個小的項目來做，進行階段性版本化發布，以緩解市場上的壓力，減少項目組成員的挫折感，提高大家的士?

在一家大型的軟體公司中，有一位很有個性的項目經理，該項目經理很少談起什麼管理理論，也未見其有什麼明顯的管理措施，但是他連續做成多個規模很大的軟體項目，而且應用效果很好。作者一直很奇怪他為什麼能做的如此成功，經過仔細觀察，終於發現他的管理可以用"緊盯"2字來概括，即每天他都要仔細檢查項目組每個成員的工作，從軟體演示到內部的處理邏輯、數據結構等，一絲不苟，如果有問題，改不完是不能去休息的。正是在他這種簡單的措施下，支撐他完成了很多大的項目，當然他也是相當的辛苦，通常都是在凌晨才去休息。我們並非要推崇這種做法，這種措施也有他的問題，但是，這種實踐卻說明了一個很樸實的道理：如果你沒有更好的辦法，就要辛苦一點，實時控制項目的進展，要將項目的進展情況完全的實時的置於你的控制之下。

上述的方法中對項目經理的個人能力、犧牲精神要求是很高，我們需要有一種進行實時控制項目進度的機制，依靠一套規範的過程來保證實時監控項目的進度。如在微軟的管理策略中強?quot;每日構建"，這確實是是一種不錯的方法，即每天要進行一次系統的編譯鏈接，通過編譯鏈接來檢查進度、檢查介面、發現進展中的問題、大家互相鼓勵互相監督。

實時控制確保項目經理能夠及時發現問題、解決問題，保證項目具有很高的可見度，保證項目的正常進展。

5分類管理原則

對於不同的軟體項目其項目目標差別很大，項目規模也是不同的，應用領域是不同的，採用的技術路線差別也很大，因而，針對每個項目的不同特點，其管理的方法、管理的側重點應該是不同的。就像古人講的，"因材施教"，"對症下藥"。對於小項目你肯定不能象管理大項目那樣去做，對於產品開發類的項目，你也不可能象管理系統集成類的項目那樣去做，項目經理需要根據項目的特點，制訂不同的項目管理的方針政策。如，下表是作者為一家應用軟體公司制訂的項目管理的方針：

在該案例中，將項目分成了訂單類項目與非訂單類項目，非訂單類項目是指由公司根據市場的需求開發一個標準產品的項目，而訂單類是指針對某個具體的客戶定製軟體的項目，訂單類的項目根據需要協調的資源的範圍有劃分成了公司級、部門級、個人級三類，非訂單類根據估算的工作量的大小也分成了A、B、C三類，估算的工作量超過720人天的為A類，超過360人天的為B類，360人天以下的為C類。不同類的項目管理的側重點是不同的，從立項手續的完備性、計劃的嚴格層度、周報的完備層度、規範的嚴格層度、跟蹤的實時性、是否進行階段總結、是否核算項目成本、是否嚴格進行階段評審等多個方面來考慮，以確保管理的可行性。

6簡單有效原則

項目經理在進行項目管理的過程中，往往會得到開發人員這樣的抱怨"太麻煩了，浪費時間，沒有用處"，這是很普遍的一種現象。當然這樣的抱怨要從2個方面來分析，一方面從開發人員本身可能存在不理解，或者逆反心理的情況，另一方面，項目經理也要反思：我所採取的管理措施是否簡單有效？搞管理不是搞學術研究，沒有完美的管理，只有有效的管理，而項目經理往往試圖堵住所有的漏洞，解決所有的問題，恰恰是這種理想，會使項目的管理陷入一個誤區，作繭自縛，最後無法實施有效的管理，導致項目的失敗。

7規模控制原則

該原則是和上面提到的其他原則相配合使用的，即要控制項目組的規模，不要人數太多，人數多了，進行溝通的渠道就多了，管理的複雜度就高了，對項目經理的要求也就高了。在微軟的MSF中，有一個很明確的原則就是要控制項目組的人數不要超過10人，當然這不是絕對的，也和項目經理的水平有很大關係。但是人員"貴精而不貴多"，這是一個基本的原則，這和我們上面提到的高效原則、分解原則是相輔相成的。

空白1：為效益而實施項目管理

為什麼我們要實施項目管理，是為了提高項目的效益。這裡所指的項目的效益是一個綜合性的指標，包括低風險、高產出等。為此我們不難得出我們在實施項目管理應該掌握的度。即：引入項目管理后所產生的效益減去項目管理的成本后必須大於未引入項目管理時的效益。由於引入項目管理后所產生的效益與項目管理的複雜度（項目管理的成本）並非線性相關的，因此項目管理的複雜度必然存在一個最優值，這就是我們應該把握的度。也許上面的說法比較抽象。一個實際行之可效的判斷項目管理的度規則就是：大家認可並且能夠準確地理解和實施。拿美國項目管理專家James P Lewis的話說就是kiss原則（Keep it simple and stupid），拿物理學家愛因斯坦的話說就是：Keep it simple but not too simple.

空白2：考慮所處環境

任何系統都是建立在一個具體的系統環境中的，一般情況下受上一級系統影響最為顯著，這是系統論的觀點。項目管理是企業管理的下屬層次，因此在很大程度上項目管理的成功與否常常受企業管理的制度制約（比如說設備採購的批複等待會延誤工期），這就是為什麼常常會出現計劃不如變化來的快的原因。因為我們在制定計劃時根本就沒有考慮自身和客戶雙方的企業管理的環境，所以我們的計劃在實施過程中會受到企業管理環境因素的影響。我敢跟你打賭：在沒有人事激勵機制常常拖欠或故意剋扣員工工資但獲得CMM5認證的公司開發效率不會比一個沒有實施項目管理的開發團隊的效率高多少。因為惡劣的公司人事制度扼殺了開發人員的天才和積極性。因此，作為一個項目管理者，審視自身的項目所處的企業環境並做出準確的判斷是非常有必要的。缺少良好的項目環境，項目管理者的心血常常白費。這往往是我們中的一些項目經理在不同的公司里項目管理表現大相徑庭的原因。

此外，正是基於企業環境這樣一個觀點，目前美國PMI，日本ENAA等提出了項目管理成熟度模型（OPM3和P2M），改變了傳統PMBOK的缺陷（忽略外部因素和自身的靈活性）。有興趣的項目管理者可以參看有關項目管理成熟度和企業管理方面（建議參看職業經理人方面）的資料。

空白3：合理評判軟體項目管理

我們總是把過多的項目失敗歸罪到項目經理的名頭上。他們的角色常常是替罪羊而不是領導者，他們擁有的更多的是責任而絕非職權。實際上項目失敗並非完全決定於項目管理，比如說信息系統過低的報價。一個項目按時在預算範圍內完成了而另外一個則沒有按時完成，這不意味著第一個項目管理得比較好。因為前者可能是項目時間和成本寬鬆的項目而後者根本就是不可能完成的項目。前者項目管理的意義在於獲得較高的項目效益而後者的意義在於避免更大的項目損失。很可惜，充滿了浮躁的軟體企業沒有諸如此類的意識，一些項目在未開始前註定就是失敗的，項目經理們一上手便被扣以一責任人的鐐銬。因此，項目管理有無具體效果，需要合理地進行評判，單純以出效益為上的觀點未必有失偏頗。

空白4：心理學的必要性

沒有一個領域像軟體項目管理中人的因素更為重要，在軟體領域沒有實現自動化之前，一切試圖取代人的主要作用的機制都是收效甚微的。人的行為是心智活動的表現。開發人員的心理活動決定了其在開發的表現。合適的壓力能夠勾起開發人員的成功慾望但是過大的壓力卻直接影響著項目參與者的身心健康。特別是後者一直以來都未能引起軟體開發界的重視。很多人曾經有過不明不白的辭職經歷，在沒有學習《管理心理學》之前，筆者對這些人的"過激"行為有時想想都覺得奇怪。作為一個軟體項目管理者，不了解和掌握管理心理學，很難針對複雜多變的人的因素採取合理的應對措施，同時自身的心理健康也未必能夠得到保證。為此筆者建議有條件的軟體企業，可以通過聘用心理顧問來處理員工的心理問題，以此緩和由於工作壓力而導致的員工之間矛盾衝突和項目坍塌。

空白5：尊重常識，系統性考慮問題

這個觀點筆者在《軟體項目管理原則談》已經重申過。就像不要指望人一秒鐘跑二十米一樣指望項目中有過多的奇迹出現。可惜我們中的大多項目管理者在進行項目管理時依然實施"大躍進"。我們的管理者都知道自然規律不可違抗性，但是卻很少有人意識到一些社會規律的不可違抗性。他們總以為唯物的主觀能動性能夠替代實際，產生奇迹。加班被認為是解決資源匱乏的唯一途徑，通過開發人員"無上"的生產力來達成項目的成功。很少有人會意識到加班造成的疲勞會再次使工作效率降低這一事實。這是一種缺乏常識和系統性思考問題的表現。諸如此類的表現還有"唯工具論"和"唯方法論"。

實際上，項目管理涉及各個方方面面，一味提高某一方面作用而忽略該方面對其它方面的影響，並不能提高項目管理的層次和最終產出，這是制止我們的項目管理者走偏激（極端）立場的一劑良藥，希望項目管理者們能有所意識。

空白6：學會思考

項目管理不是拿來主義，需要項目管??者中不乏PMP和IPMP但是項目卻未能如願以償的原因。理論和實踐的差距極大地挫傷項目管理者的積極性。"證書無用論"所持的觀點其依據也在於此。理論是一種完美的抽象，而現實是各種條件的集合。我們的項目管理者在實踐上往往生搬硬套而忽略其依存條件，這就是招聘項目經理"唯經驗論"的來源。一位項目管理者跟我交流的時候提到無法使用掙值（Earned Value）的概念，原因是公司人事部和財務部不願意出示員工的收入清單。我建議他將掙值換為掙時（Earned Time），以時間替代成本。從項目進度的意義上來看這兩者其實是一致的，問題馬上得到了解決。可惜的是我們的項目管理者往往未學會思考具體概念的真正含義之前並匆匆上驢，提著長槍去和風車做鬥爭去了（註：唐吉訶德）。

空白7：學會計劃

現實中我們往往用補救措施代替計劃，其效果便如軟體缺陷的放大效應。在項目經理的招聘中，你聽到的只是幾個項目管理白痴問你項目出了什麼問題應該怎樣解決的提問，這些項目管理白痴在不斷地做各種問題假設，而你必須根據假設採取各種符合這些項目管理白痴口味的回答。但是，作為項目管理的來說，項目管理的真正意義在於事先預防各種偏離項目目標的問題出現而不是在於解決問題。古話說得好"磨刀不誤砍柴工"。你不能期望癌症有100％的治癒率，但是你可以通過合理的生活習慣和鍛煉來防止癌症的出現。我們在進行項目管理時，首先應該考慮如何防止問題的出現，雖然它不能保證所有的問題（風險）都可以避免，但是通過計劃，你將擁有更多問題（風險）應對儲備，能夠在問題出現時有備無患。一個只會在問題出現時考慮應對措施的項目經理只是一個失敗的項目經理。其項目結果無異是把健康交給醫生而不是自己。作為項目管理的定位來說，項目管理應該是"管理會計"的角色而不是"成本會計"的角色。

最後，以某電影的台詞來結束本文；人為什麼犯病？簡單的東西想複雜了，複雜的東西想簡單了，人就會犯病"。拿這句台詞來形容我們目前的項目管理狀況一點也不為過。軟體項目管理是一個從"自發"走向"自覺"的過程，也是一個從經驗主義走向理性主義的過程。軟體項目管理是一個主動的管理，而這一切，需要廣大項目管理者的項目管理思維和積極實踐。