13. 項目需求管理

我們知道，項目需求是所有項目建設工作的實現目標和工作基礎。在建設過程中，其任何一點調整都會對後續的工作進度、軟體質量和項目成本造成一定的影響，而且調整的時點與項目結束的時間越近、調整的範圍越大，對項目的影響也就越大。因此，為了減少需求調整對項目建設工作的影響，甲方項目經理應基於項目建設工作的實際情況、結合項目「完成」的定義，來對需求的制定、變更等相關的工作進行決策和管理，我們將這一過程被稱之為項目需求管理。

對於甲方項目經理來說，項目需求管理工作主要是圍繞著業務需求來展開的，其目標主要有以下兩方面：一是確保業務需求能夠滿足項目建設的需要；二是控制需求變更的範圍和時點，以降低對項目建設工作的影響。一般情況下，需求管理工作包含以下幾個方面：需求計劃管理、需求質量管理、需求變更管理。其中，需求變更管理工作是甲方項目經理在進行需求管理工作時的重點。

13.1. 需求計劃管理

需求計劃指的是在編製或調整業務需求文檔的時候，為確保相關的工作可跟蹤、可管理而制定的文檔編寫計劃，主要內容包含編寫相關的工作項、完成日期和責任人等內容。其中常見的工作項有需求溝通、需求確認、需求編寫、需求評審等幾個方面。

表 13.1

甲方項目經理在對需求計划進行管理時，其工作主要包含以下兩個方面：一個方面是確保需求計劃是合理、可行的，同時也能夠滿足整體工作計劃的要求；另一個方面是甲方項目經理要通過各種項目管理手段來確保項目需求編寫工作能夠按計劃開展。

13.2. 需求質量管理

本文中，需求質量主要指從項目需求文檔相關的可讀性、準確性和齊備性等方面來判別其完成的情況。通常情況下，高質量的需求具有以下屬性：完成目標明確、業務流程直觀、功能描述清晰、文字內容易於理解、文檔結構清晰、圖表使用合理等。這裡需要注意的是，需求文檔是乙方團隊了解和掌握項目建設要求的主要途徑，其質量的高低對軟體產品的質量、項目建設的進度等方面都有著直接的、不可忽略的影響。因此，為了確保項目需求文檔能夠將建設要求清晰、準確、全面的傳遞給乙方團隊成員，甲方項目經理需要對需求質量進行相應的管理。

依據筆者的個人經驗來看，甲方項目經理在對需求質量進行管理時，可以從以下三個方面入手：一是提供需求模板。其可以參照其他項目的文檔來編製需求文檔模板，從而明確文檔結構和編寫要求，有利於業務人員編製出高質量的文檔；二是需求講解。由需求編寫人員向相關人員講解需求的內容，並解答其存在的疑問。這樣做的目的是從需求使用者的角度，來判別文檔能否向其提供清晰、準確的項目建設信息；三是需求評審。甲方項目經理組織相關業務專家、同事等組成專門的評審委員會，從專業的角度來對需求文檔進行評審，以確保其內容可以滿足項目建設的要求。

13.3. 需求變更管理

需求變更是指因某些原因而對已定稿的業務需求進行調整的過程，主要是針對功能性或非功能性需求的變更、取消或新增。依據筆者的經驗來看，其通常發生在項目的中、後期。對於甲方項目經理來說，為了避免因需求變更而導致的進度、質量、成本等方面的風險，其需要基於項目建設工作的實際情況並結合項目「完成」的定義，來對需求變更的範圍、時點進行管理。

1. 需求變更風險

我們知道，項目建設的大部分工作都是圍繞著業務需求來開展的，因此一旦需求發生了變更，就會有非常大的可能使得已通過評審的實現方案、產品設計或已完成功能等做出相應的調整。而這些調整不僅會給項目建設工作增加大量額外的工作量，同時也會對軟體的整體結構、已完成代碼的前後邏輯以及基於需求而生成的功能設計、技術方案、測試案例等相關文檔的完整性造成相當大的影響，不僅極大的增加了質量問題發生的概率，同時也勢必會導致項目建設時間和建設成本的增加。可以說，需求變更會給項目建設工作帶來進度、質量、成本等多個方面的風險：

1) 進度風險。對於需求變更來說，其通常會要求與之相關的項目文檔、功能設計、技術方案、工作計劃和軟體代碼等內容做出相應的調整。但需要注意的是，由於這些調整工作並不屬於預定的工作計劃，因此在執行這些工作的時候，一方面會給項目建設增加大量額外的工作量，另一方面則會使得在進行的工作無法按計劃推進。對於甲方項目經理來說，這些計劃之外的工作如無法得到妥善處置的話，則可能會導致項目整體工作無法在預定的時間內完成，從而給項目建設工作造成進度方面的風險；

2) 質量風險。大多數情況下，為了滿足變更後的業務需求，我們會對相關的文檔、代碼的整體結構、邏輯關係和功能屬性等內容進行相應的調整。而這些調整工作則會給項目建設工作帶來質量方面的風險，主要體現在以下幾個方面：一是調整工作涉及到的文檔主要有需求規格說明書、實現方案、產品設計和測試案例等，如不能及時、全面的對其進行調整，則可能會導致文檔方面的質量風險；二是在對相關的業務功能進行調整時，如不能同步對所有與之關聯的功能進行調整，則可能會導致功能相關的風險；三是調整工作可能會改變軟體已有的產品架構或代碼結構，從而打破了軟體原有的穩定結構，可能會導致其出現穩定相關的質量風險；四是在實現變更後的需求時，乙方團隊成員可能會因編碼能力、需求理解、工作溝通、測試不足等方面的問題而導致質量風險；

3) 成本風險。由於絕大多數需求變更所對應的調整工作通常都不在工作計劃的範圍之內，因此為了確保這些工作的完成，乙方團隊需要在已有資源的基礎上投入更多的人員或時間。對於甲方項目經理來說，乙方團隊新增的資源會導致項目整體工作量的增加，而這些工作量最終都將會體現到項目的成本上。所以，當需求變更所增加的工作量累積到一定程度後，項目的總成本就有可能會超出預算的範圍，進而造成項目成本風險。

2. 變更管理原則

對於甲方項目經理來說，其在進行需求變更管理的時候，不能只關注於發生了變更的需求，還需要通過相應的管理手段來對需求變更進行防範和控制，從而使其能夠更好的促進項目建設工作的開展。

依據筆者個人的經驗來看，在具體的項目建設工作中，甲方項目經理可以按照項目建設的前、中、後期，來將不同階段的變更管理原則分為以下三個方面：前期防範、中期控制、後期抉擇。其中，前期防範指在項目建設的前期，需求尚未通過評審定稿的時候，通過充分調研、模擬路演、內部討論等多種手段來最大限度的發現需求中存在的不足，以減少定稿後對需求進行調整的風險；中期控制指在需求定稿後的開發建設過程中，通過劃分優先順序、影響分析、集中調整等手段來控制需求調整的頻率、範圍，以減少需求變更對項目建設工作的影響；後期抉擇指的是在項目建設的尾期，為了避免需求變更對已完成工作和完成時間的影響，甲方項目經理需結合具體的變更內容、項目實際情況和「完成」定義等信息來對變更需求進行綜合的分析，以抉擇是否全部接受、部分接受還是延期處理。

3. 需求變更管理

對於甲方項目經理來說，其進行需求變更管理工作的目標主要是在確保項目「完成」定義的前提下，結合項目工作的具體情況，來最大程度的實現業務方所提出的變更需求。為了達成相應的管理目標，甲方項目經理在對需求變更進行管理時應遵循以下的處置原則：一是確保項目「完成」的核心項不會受到需求變更的影響。如核心項為時間，那麼為了確保項目能夠如期完成，就不能接受太多的需求變更；二是對變更需求進行分級。由於項目團隊能夠額外增加的人力、時間等資源是有限的，因此為了避免有限的資源被非關鍵、非重要的變更需求所佔用，甲方項目經理應依據變更需求對項目的重要性來對其進行分級，以優先解決級別較高的需求；三是避免對已完成功能的影響。甲方項目經理在同乙方團隊一起制定變更需求的解決方案時，應盡量不要改動已完成的功能，以減小變更需求對軟體產品的影響。

我們知道，需求變更是對項目「完成」定義所對應的範圍的調整，那麼甲方項目經理在對需求變更進行管理時，為了確保質量、時間、成本等要素項不會受到範圍變更的影響，其首先應明確以下兩方面的信息：一是明確乙方團隊可以接受的需求變更量。為了避免因需求變更而導致項目費用超出合同金額的情況，我們一般會在項目的商務合同中明確乙方團隊應免費接受的需求變更量。同時，由於風控、審計、監管等方面的原因，甲方項目通常不會在建設過程中增加項目相關的預算。因此，對於甲方項目經理來說，乙方團隊能夠接受的需求變更總量就是合同中所明確的變更量，其可以承受的需求變更量則等於變更總量減去已完成變更量；二是明確項目剩餘建設時間。通常情況下，項目剩餘建設時間主要指當前日期到建設完成日期之間所有工作日的總和。但這裡需要注意的是，甲方項目經理在計算項目剩餘建設時間時，首先應判別項目的建設完成時間能否做出調整，如能調整，那麼可以調整的範圍有多大，然後再依據項目建設的完成時間來計算項目剩餘的建設時間。

甲方項目經理在明確了上述信息後，則可以對變更的需求進行具體的管理工作，主要有以下幾個方面：一是確定需求的接受範圍，全部接受、部分接受或不接受；二是對乙方團隊的提交的處置方案進行評審；三是調整項目工作的計劃，並對乙方團隊的執行情況進行跟蹤。這裡需要注意的是，需求接受範圍和乙方團隊的解決方案是相互影響的、相互制約的。依據筆者的個人經驗，其在對需求變更進行管理時，可以採用以下步驟，如下圖13.1所示：

圖 13.1

1) 變更需求了解。對於變更需求來說，甲方項目經理一方面應通過與需求提出人員的溝通，來掌握和了解具體的需求內容；另一方面則應通過文檔學習、人員溝通、需求反講等方法，來確保乙方團隊可以全面、準確的掌握變更需求的相關內容；

2) 變更工作梳理。甲方項目經理應要求乙方團隊在對變更需求理解的基礎上，對所有相關的工作進行梳理，主要包含以下內容：影響分析、實現方案、修改或新增功能列表、投入時間、預計工作量、投入人員、待調整文檔列表等；

3) 需求變更管理。甲方項目經理應依據項目「完成」定義和建設的具體情況，並結合乙方團隊對變更工作梳理的內容，來判別變更工作能否滿足項目建設要求，如可以滿足則進行下一步工作，如不能則需要對需求變更相關的範圍、時間、成本、質量和實現方案等方面進行調整，直至變更工作可以滿足相應的建設要求。如「完成」核心項是時間，當變更工作無法在規定時間內完成時，那麼就應採用縮小變更需求的範圍、降低軟體質量、增加建設成本或優化解決方案等方法來確保變更工作不會影響項目最終的完成時間。其中，對於這種情況常見的處理方案有以下幾種：一是對需求變更進行分級，優先解決高優先順序的變更。對於其他的變更可以不做處理或留待項目完成後再另行處理；二是調整變更範圍或實現要求，從而縮小變更的工作量，使之滿足可接受的範圍；三是調整實現方案，採用簡化的實現方案或部分實現的方案來降低所需的工作量；四是將原需求中不重要的部分捨去，從而留出足夠的工作量空間；五是要求乙方項目團隊增加人員，進而增加可分配的工作量；

4) 制定處置方案。乙方團隊應依據最終確定的變更需求和解決方案來制定出相應處置方案，主要包含：工作影響分析、解決方案、工作計劃和工作量；

5) 方案評審。甲方項目經理依據項目的實際情況，並結合項目「完成」定義等信息來對乙方團隊提交的處置方案的可行性、合理性進行評審。通常情況下，可以採用以下的評審標準：一是解決要方案能夠滿足需求變更中所提出的要求；二是需修改的內容要盡量的少，不要影響到變更需求之外的其他功能；三是不要對變更需求做過度的設計，實現方案恰好覆蓋變更需求即可；四是解決方案在實現起來的時候要盡量的簡潔。如處置方案無法滿足要求，則應要求乙方廠商返回步驟4，重新制定處置方案；

6) 方案執行。乙方團隊按照通過評審的處置方案，來開展具體的實施工作。

13.4. 常見的需求問題

在本節中，筆者依據自身的工作經驗，對項目建設過程中經常出現需求問題進行了梳理，主要有需求不明確、需求文檔更新不及時等幾個方面，同時筆者也將基於個人的經驗給出了相應的解決方案和注意事項。具體如下：

1. 需求不明確

需求不明確，主要指在需求文檔中對建設目標、業務功能、操作流程等具體的業務需求的描述存在模糊不清、理解歧義或前後矛盾等情況。其一方面會使得項目建設要求無法準確、全面的傳遞給相關人員；另一方面則會使得項目建設工作中出現嚴重的質量問題，進而導致工作無法按計劃正常開展。

甲方項目經理在處置這種類型的問題時，可以遵循的以下的處置原則：明確可確定的需求、屏蔽無法確定的需求，嚴禁相關人員按照自己的理解去猜測不確定需求的含義。在針對某一具體問題進行處置時，甲方項目經理需在對需求不明確的原因進行深入的分析後，結合項目建設的實際情況和個人工作經驗來給出具體的解決方案。一般情況下，我們會將導致需求不明確的原因分為兩類，分別為人為原因和非人為原因。其中人為原因指在業務明確的情況下，因需求編寫人員的個人能力問題而導致的表述不明確，比如需求編寫人員對業務的了解不全面、多人編寫時存在協調問題或需求編寫人員個人表述能力不足等；非人為原因則指因該業務所依賴的外部條件不可控而導致的需求不明確，如政策或制度無法確定。這種問題通常無法由需求編寫人員控制，一旦出現對項目影響極大。

針對兩種不同類型的問題原因，甲方項目經理的處理方案也略有不同。對於人為原因而導致的需求不明確來說，首先要做的就是要求需求人員將需求中不明確的部分重寫或補充完整，其次應針對修改的部分組織人員進行講解、評審，最後為了防止類似的問題再次發生，應採取提高人員素質、加強需求評審等措施；對於非人為原因而導致的需求不明確來說，導致該問題的主要原因來自於外部的不可控因素。因此對於這種類型的需求問題，首先要做的是確定不明確的範圍以及對已有需求的影響程度，其次對受影響的需求進行分析，對於其中可以明確的部分，將其補充完善，而對於其中無法明確的部分，則應在對其標識後不再做任何處理，直至與之關聯的外部條件明確。

2. 需求文檔更新不及時

需求文檔更新不及時，主要指業務發生變更後，在相應的軟體已做出調整的情況下，與之對應的需求文檔尚未及時的做出調整，而導致項目軟體和需求文檔不一致的情況。由於大多數項目工作，如軟體設計、開發、測試等，都是依賴於需求文檔的，所以需求文檔更新不及時極易導致與之相關的項目工作因缺乏準確、統一的依賴基礎，而產生需求實現、驗證方面的風險。

一般情況下，導致需求文檔未及時更新的原因主要有以下兩種：一是項目時間較為緊急，為了保障項目的建設進度，在得到項目各參與方認可的情況下，將需求文檔的更新工作延後至某個約定的時間；二是需求編寫人員自身的原因，未能及時的對文檔進行更新。

甲方項目經理在處理這種類型的問題時，需要依據問題的原因來分情況處理：對於因需求編寫人員自身的問題而導致文檔未更新的情況，首先應與其約定文檔完成的時間並制定編寫計劃，然後按照計劃對其編寫工作進行跟蹤管理，確保需求文檔能夠按計劃完成；對於因項目進度原因而導致文檔未更新的情況，首先應要求需求人員提供需求文檔之外的其他形式的需求變更說明，如需求變更單、需求變更郵件或需求變更溝通會等，以確保變更後的需求可以準確的傳達給項目組的每一位成員；其次要求相關人員進行需求反講，以確定其對變更後的需求的理解是正確無誤的；最後制定需求編寫計劃，明確需求文檔更新完成的時間和工作安排。