問：什么比變態(tài)的需求更變態(tài)？

答：需求變更。

開發(fā)說需求，項目經(jīng)理磨破嘴；甲方說需求，項目經(jīng)理跑斷腿。需求變更應(yīng)該是最令讓項目經(jīng)理頭疼的事情了。

老板改想法、預(yù)算有變化，在付出了大量時間、精力后，臨時的需求變更，導(dǎo)致不得不重新修改設(shè)計、重寫代碼、修改測試用例、調(diào)整項目計劃等，導(dǎo)致進度延遲，大家都會感到煩躁。

為了盡量避免這種情況的發(fā)生，縮減因為變更而產(chǎn)出的高額成本，就要了解需求變更的原因，針對各階段的變更給出相應(yīng)的解決辦法。

需求變更的原因

01

需求定義不明確

當客戶提出需求時，要學(xué)會判斷客戶給出的信息，有時候客戶覺得他講明白了，但其實他沒說明白，你沒聽明白。就開始根據(jù)客戶模糊的概念總結(jié)進行需求分析細化，這樣就會造成細化后的需求并不是最初的客戶需求，造成偏差。

前期的需求分析做得越好，基準文件定義的范圍越詳細清晰，后期的“麻煩”也就會越少。

02

需求理解有偏差

開發(fā)者也有可能對客戶需求理解錯誤或者開發(fā)團隊內(nèi)部溝通時、人員更替時造成的信息偏差。有溝通的地方，就有“誤會”。在整個溝通過程中，盡量避免信息差，也會減少后期的變更。

03

缺少指定需求基線

需求基線是指是否容許需求變更的分界線。對于需求變更，一味選擇無條件接受，指定是不行的，要明確不可更改的需求范圍，例如在軟件整體結(jié)構(gòu)已經(jīng)設(shè)計出來后，是不容許改變需求范圍的，避免影響整個項目的進度和成本。隨著項目的進展，容許的變更的范圍將越少。

此后每次變更并經(jīng)過評審后，都要重新確定新的需求基線，做到小需求可以變更，但大方向要力保不頻繁變更。例如，對于項目中的需求，可以實行分級管理，以達到對需求變更的控制和管理。

在與客戶簽訂合同時，可以增加一些相關(guān)條款，規(guī)定何種情況的變更可以接受、部分接受或拒絕，還可以規(guī)定發(fā)生需求變更時必須執(zhí)行變更管理的流程。明確需求變更會帶來的后果，看客戶是否可以承擔后果。

需求變更控制流程

1

明確問題

當客戶提出需求變更時，了解客戶的目的。

2

書面申請

申請書上要清晰描述需求變更的內(nèi)容，并包括客戶的簽字確認。

3

判斷變更需求類別

需求產(chǎn)生的原因，分為功能變更、設(shè)計調(diào)整、范圍擴大、工期變動、產(chǎn)品原因和其他。

4

評估影響

評估變更所造成的影響，范圍、進度、成本、質(zhì)量等方面。

5

判斷變更的緊急級別

從以下內(nèi)容中選擇：“很緊急、緊急、一般”，以該問題或需求對項目的影響程度和需求完成的時限來劃分。

6

溝通確認

就變更影響，與客戶進行溝通，達成共識。

7

明確解決方案

針對變更內(nèi)容，提出相應(yīng)的解決方案。

8

審批管理

向CCB（變更控制管理委員會）提交正式申請，召開變更控制會議，做決策，是接受變更，還是拒絕變更。

9

執(zhí)行變更

把審批的結(jié)果告知相關(guān)人員，并執(zhí)行與跟蹤變更的執(zhí)行情況。

10

版本控制

記錄變更的全過程，這是項目過程可控的重要保證。

最后還是祝愿大家都能擺脫需求變更。