2. 項目「完成」的定義

來自專欄 如何做好甲方項目經理

2.1.項目工作的第一步

我們都知道「萬事開頭難」這句話，對於軟體項目的建設工作來說也同樣如此。當甲方項目經理在首次面對項目時，要怎樣開始項目工作呢？是去了解業務需求還是制定工作計劃、評估工作量？儘管說這些工作的完成情況會對後續相關工作產生直接的影響，是甲方項目經理在項目籌劃階段必須完成的工作，但它們還不是甲方項目經理開展項目工作的第一步。

就筆者個人的經驗來看，甲方項目經理在開始一個信息化項目時，首先需要做的工作是對項目各方的進行深入溝通、調研，來明確其對項目建設的核心要求和原始目標，如市場部門希望6月底一定要有一個可用於推廣的產品、業務部門希望產品功能齊全並可以滿足後續的業務擴展等等。可以說，這些建設要求不僅是項目各利益方對項目工作的期望，同時也是項目工作開展的基本原則和考核依據。但在實際的項目建設過程中，由於時間、資源、人員等方面的限制，使得絕大多數項目都無法完全的滿足各方的要求，特別是不同部門基於自身利益提出的要求會存在一定程度上的矛盾。這就要求甲方項目經理在項目工作開始前，不能簡單的對這些要求全盤接受，而應對這些不同的建設要求進行綜合的梳理和分析，積極同各方進行溝通，制定出受到各方都可以接受的項目建設要求。通常，我們將這一過程稱為對項目「完成」的定義。其中，項目「完成」指項目建設工作應滿足的一系列建設要求，是項目建設的工作準則、實現目標和考核標準。

對於信息化項目來說，其只有在滿足「完成」的情況下，才可以算作是真正的完成，達到了項目建設的預期要求。可以說，「完成」的項目一定是完成的，但完成的項目不一定是「完成」的。例如，為了搶佔市場先機，要求產品在指定的時間內推向市場，那麼產品只要能夠按時完成，就可以算作是達到了「完成」的標準。而沒有如期完成的產品，儘管它的功能齊全、運行穩定，顯然也不能算作是真正的「完成」。

「完成」是項目建設工作的最終目標，所有工作都是為了實現這個目標而開展的。只有在工作開始前明確了最終的目標，後續的項目工作才能夠做到有的放矢、事半功倍。因此，甲方項目經理在項目開始時要做的第一步工作，就是明確該項目「完成」的定義。

2.2. 項目「完成」的4要素

我們知道，項目「完成」定義是在項目各方所提出的項目建設要求的基礎上，經過深入的分析、比較、均衡後，形成的對項目完成狀態的描述，是項目建設工作的最終目標和考核標準。通常情況下，甲方項目「完成」的定義通常是由甲方項目經理依據各方對項目的建設要求，結合自身的工作經驗而得出的。

那麼對於「完成」來說，其通常是從哪些方面來對建設工作提出要求呢？對於不同的項目參與方來說，由於各自不同的工作立場和職能定位，使得其對項目建設提出的要求也會側重於不同的方面，如項目完成時間、需求實現範圍、一定要實現某一特定功能、界面好看等等。但對於甲方項目經理來說，這些不同角度、不同維度、不同層面和不同來源的建設要求整合在一起，需要耗費大量的工作和精力。因此，為了簡化項目「完成」定義的梳理工作、便於後期的跟蹤管理，筆者基於自身的工作經驗，參照項目管理三角，將這些不同的側重點歸納總結成為以下4個方面，分別是質量、時間、範圍和成本（資源）。

甲方項目經理在定義「完成」時，應從上述4個方面來對各參與方提出的建設要求進行梳理。其可以將項目建設中需要優先滿足的方面作為中心，其餘部分作為三角形的三條邊，從而形成一個項目「完成」三角。使用項目「完成」三角的好處是可以直觀的看到項目建設的核心訴求，以及3條邊相互之間的關聯和影響關係。如下圖2.1，選擇質量作為項目核心，時間、範圍和成本圍繞它形成相應的項目「完成」三角。假如保證質量、時間不變，增加範圍的話，勢必會導致成本的增長。

圖 2.1

對於項目「完成」三角來說，質量、時間、範圍和成本（資源）分別代表了項目「完成」在該方面的建設要求，具體如下：

1. 質量代表項目軟體產品的質量

質量是軟體產品的生命，沒有質量的軟體只能是一堆無用的代碼，發揮不了任何作用。軟體產品的質量越好，留存的bug就越少，出現異常的概率就越低。

但在實際情況中，極少有軟體產品能夠做到百分之百的沒有bug，這是由於以下兩個方面的原因：一是現在軟體的功能越來越複雜，代碼量為百萬級的項目比比皆是。對於這些日益龐大、複雜的軟體，使得在有限的資源下，查找所有bug就像海底撈針一樣，很難確保百分之百的找到所有bug；二是當bug減少到一定程度後，繼續減少所要付出的成本將會是前期的幾倍甚至是百倍。因此，對於絕大多數軟體來說，高質量並不意味著沒有任何bug，而是將其對質量的影響程度控制在了一個可以接受的範圍內。

那麼，我們又是如何分析bug對質量的影響程度呢？一般情況下，主要通過以下兩個指標，分別是bug危害程度和bug出現概率。其中，危害程度越高，bug對軟體正常使用的影響就越大；出現概率越高，bug在軟體使用過程中出現的概率就越高。甲方項目經理在對軟體產品的質量進行管理時，首先要確保的是產品能用，然後才是好用。因此，在解決bug時，一般會遵循以下的順序和思路，首先是高危害、高頻率的必須解決；其次是低危害、高頻率的盡量解決；再次是高危害、低頻率的絕大部分解決；最後是低危害、低頻率的依據情況解決。詳見表2.1。這樣做的好處是，可以將有限的資源用於解決最重要的問題，確保軟體的質量可以滿足正常使用的要求。

表 2.1

對於項目來說，其質量標準就是依據實際情況，來明確不同影響程度的bug所對應的處置順序和處理原則，哪些需要優先解決、哪些需要全部解決或部分解決甚至是不解決。其中，降低質量標準可以極大的減少時間、降低成本，但是要承擔較高的質量風險；反之提高質量標準，則可以降低運行時出現異常的風險，但是付出更多的時間和成本。

2. 範圍代表項目需要實現的需求

範圍代表了在項目中應當實現的各類需求，包含功能性需求和非功能性需求。其中，功能性需求，指滿足業務要求所需要實現的所有功能；非功能性需求，指功能描述以外的所有需求，包含了安全、性能、擴展性、持續運行時間、無差錯率、易用性、美觀等多個方面的內容。如果我們將項目涉及到的需求比作一棵樹的話，那麼功能性需求就相當於樹的主幹和枝葉，是項目工作中重點關注的部分；非功能性需求則是樹的根，儘管很少有人會關注到，卻決定著樹的高度。可以看到，功能性需求和非功能性需求對於項目整體需求來說，是相輔相成、缺一不可的。這就要求甲方項目經理在對需求進行管理時，不能僅僅關注功能性需求或是非功能性需要，而是要做到兩手都要抓、兩手都要硬。

我們知道，在項目建設過程中，需求的範圍不會是一成不變的，而是會隨著項目建設情況的變化而隨之進行調整的。但需要注意的是，需求調整的時間點越接近項目後期或是調整的範圍越大，對項目的影響也就越大，需要付出的時間和成本也就越多，個別情況下甚至會導致項目失敗。這就像是修改一幅接近完成的畫作，其難度要遠遠大於修改一幅剛畫了幾筆的畫。所以，儘管說需求範圍可以接受變更，並且適當的變更可以使需求更貼近實際使用的要求，有利於提升產品的質量。但是提出變更的時點應越早越好、範圍越小越好，否則就會對項目建設工作產生不利的影響。

在確定了項目的範圍後，就相當於明確了項目建設的相關需求，系統需要實現哪些功能、滿足哪些要求，就都有了明確的依據。我們將這些依據落實到紙面上，就形成了項目需求文檔，其是貫穿整個項目建設周期的核心文檔，也是項目建設工作的實現目標和參考依據。

3. 時間代表項目最終的完成時間

時間指項目完成的最終日期，是綜合考慮政策、市場、成本和技術等多個方面的影響而確定的，但也可能是由上級領導直接敲定的。可以說，項目的完成時間一旦確定，整個項目的總體工作時間就不會再發生大的變化，相關的工作計劃、資源配置、人員協調等建設規劃都就隨之確定了下來，各項工作都將按計劃有序開展以確保在指定時間內完成。

儘管說項目完成時間一旦確定，就不允許再隨意的進行調整。但是在實際的項目建設工作中，總是存在一些特殊的情況使得完成時間必須進行調整，如市場要求提前上線、增加了大量新的需求、建設進度遠低於預期等等。而項目完成時間一旦進行了調整，那麼所有在進行和未進行的工作，都需要按照新的完成時間來重新進行規劃，相關資源也需要按照新的要求來重新安排。為了降低調整完成時間對項目工作造成的影響，甲方項目經理需要依據調整後的完成時間，並結合項目具體的建設情況，來對後續工作涉及到的計劃、資源等內容重新進行規劃、梳理。如有必要，還需要對項目的「完成」定義進行相應的調整。

完成時間對於項目建設工作來說，是非常直觀、簡單的建設標準，其判別依據主要就是項目工作能否在規定時間內完成。相較於質量、範圍等較為主觀的建設標準，其更加的客觀，且對項目建設工作得而約束力更強。

4. 成本（資源）代表項目需要付出的人力、研發、管理等方面的成本

為了確保項目建設相關的各項工作能夠達到預期的目標，在建設過程中需要不斷的投入各式各樣的資源，為此所付出的費用稱之為項目成本。按照投入資源的類型，我們可以將成本分為人力成本、研發成本和管理成本等多種類型。對於大多數甲方項目來說，人力成本主要指在項目建設工作中，為了引入業務、市場、法律、財務等項目相關的人員所要付出的成本。通常情況下，這些人員主要來自於甲方機構的各個部門；管理成本指為了確保項目工作能夠按計劃有序進行，甲方項目經理在進行管理、溝通、協調等工作時所付出的成本；研發成本主要指為了確保乙方團隊能夠按計劃、按要求的完成項目研發工作，所需要付出的相關成本。

這裡需要注意的是，人力成本、管理成本主要涉及對象是甲方機構的相關人員，除非有明確的內部人員支持定價制度和相應的考核機制，否則是不會將這些成本計入項目總成本的。同時，對於大多數項目來說，場地費、水電費等基礎費用，也並不會計入到項目成本中的。因此，在一定程度上來說，甲方機構的項目成本主要就是研發成本，甲方項目經理在評估項目預算時，其標準也是該預算能否覆蓋研發成本。

對於甲方項目經理來說，項目成本管理就是對研發成本的管理，如成本超出了預算，那麼就需要通過縮減需求範圍、降低質量等方式來減小研發支出，確保成本始終處於預算覆蓋範圍之內。否則的話，就需要向公司管理層提出申請，提升項目對應的預算。

2.3. 定義「完成」的流程

對於甲方項目經理來說，定義項目「完成」的過程就是其在對項目各方所提出的項目建設要求進行綜合的比較、分析、權衡後，從質量、範圍、時間和成本這4個方面，形成各方均認可的項目建設要求的過程。按照筆者個人的工作經驗，甲方項目經理在定義項目「完成」的時候，可以採用如下流程：首先應從質量、範圍、時間和成本等「完成」要素中確定該項目「完成」的核心要素；其次按照核心要素、普通要素的順序，來制定出項目「完成」所對應的建設要求。

1. 確定「完成」核心要素

我們知道，項目「完成」定義是對信息化建設項目建設要求的描述，一般從質量、範圍、時間和成本這4個方面，為各參與方給出了明確的建設要求、工作方針和考核標準。但需要注意的是，由於時間、資源、人員等方面的限制，使得在項目建設時無法同時滿足「完成」的所有要素，如時間不變的情況下，擴大範圍勢必會導致質量的下降。這就要求，甲方項目經理在定義「完成」時，為了確保項目建設工作能夠最大程度的滿足預期要求，就必須將這些要素進行分級，優先保證對項目最重要的要素，然後再在保障核心要素的基礎上完成其他要素。因此，在開始定義項目「完成」時，首先要做的就是確定這4個要素項中，哪個要素項是該項目「完成」的核心要素。

按照筆者的個人工作經驗，在確定項目「完成」核心要素時，可以採用以下2種方法，分別是關鍵角色法和評分法：

1) 關鍵角色法

關鍵角色法就是找出項目中特定的關鍵角色，並將其最為關心的項目「完成」要素作為該項目的核心要素。在這裡，項目的關鍵角色，主要指對項目有巨大影響力，甚至是可以直接決定項目生死的人。在甲方機構中，項目關鍵角色通常指對項目負有主管職責的高層領導。

2) 評分法

評分法是將質量、範圍、時間和成本這4要素列為評分項，由各項目參與方在最低1分到最高5分中，依據自身的要求來進行打分。然後將不同參與者對項目的影響力作為權重，對各評分項進行加權平均，最後得分最高的項就是該項目「完成」的核心要素。評分表樣例如下表2.2：

表 2.2

在這裡我們需要注意的是，「完成」的核心項在項目建設過程中並不是一成不變，而是會隨著項目具體情況的變化來進行相應的調整，如「完成」核心項是時間，但隨著項目建設工作的開展，產品質量始終無法達到預期要求，那麼當質量對項目的影響大於時間的影響時，「完成」核心項就會由時間變為質量。對於甲方項目經理來說，其在項目建設過程中，應依據項目實際情況的需要來及時的對「完成」核心項進行調整，從而使項目團隊的工作重心向項目的核心問題轉移。否則的話，項目可能會因其核心關注點得不到解決而無法滿足建設要求，進而導致項目失敗。

2. 定義項目的「完成」

在確定了項目「完成」的核心要素後，我們就可以開始對項目的「完成」進行定義工作了。在定義時，我們應首先確定核心要素項對應的建設要求，然後以核心要素對應的要求為基礎，梳理出其他要素所對應的建設要求，最後將這些建設要求整合在一起，形成項目「完成」的定義。具體流程如下：

1) 建立包含各方建設要求的項目要求匯總表

將所有項目參與方對「完成」的要求通過表格的形式列示出來，分為項目參與方、質量、範圍、時間和成本5列，通常會將「完成」的核心項放在最左邊。然後，按照參與方對項目的影響權重，由大到小逐行錄入所有參與方對「完成」的要求。如下表2.3。

表 2.3

2) 依據項目匯總表，形成各要素對應的建設標準

我們可以按照從核心要素到普通要素的順序，來逐項的定義出該要素所對應的建設要求。這裡需要注意的是，為了項目建設工作能夠最大程度的滿足建設要求，非核心要素項對應的建設要求，如無特殊原因的情況下，是絕對不能對核心要素項產生不利於的影響的。如，核心項要素是時間，要求1個月內上線。那麼範圍作為非核心要素項，其提出的需求應確定可在規定時間內完成，否則為了確保時間的要求，就要對範圍做出相應的調整。因此，在梳理建設要求時，核心要素項和非核心要素項的流程會略有不同，具體如下：

a) 確定核心要素項對應的建設要求

在梳理建設要求時，應以權重最高的參與方的建設要求為基礎要求，然後按照權重由大到小的順序將其他參與方的要求與之進行比較、分析，如果完全相同或完全對立則跳過，其他的情況則應在與雙方溝通後，形成新的基礎要求。不斷重複直至沒有新的建設要求，最後形成的基礎要求，就是核心要素所對應的建設要求。如下圖2.2。

圖 2.2

b) 確定非核心要素項對應的建設要求

非核心要素項目對應的建設要求在梳理時，流程、方法基本同核心要素的方式相同，但在對每一個參與提出的建設要求進行梳理前，需要分析其是否會對核心要素產生影響，如有影響的話，則需要通過相關的溝通、協調，消除相關的影響。如下圖2.3。

圖 2.3

3) 整合各要素對應的建設要求，形成「完成」定義

在明確各要素對應的建設要求後，需要對非核心要素對應的建設要求進行比較、分析，確保相互之間不存在衝突。然後按照核心要素、非核心要素的順序，將這些要求有機的整合在一起，即形成了該項目對應的「完成」定義。