表一：變更表

所以一看這個表您就明白了，其實這個表反映了一個最樸實的道理：就是項目三角形在發生變形時需要保持的對應關系。大家會說，我看明白了，可是這張表應該怎么去使用？誰去填表？什么時候填表？如果有人不愿意填，那該怎么辦？下面我們分七個步驟來討論操作中可能會遇到的問題

第一步
首先得說到變更流程的事情。不管什么樣的變更，首先都有第一步：變更申請。有人就不樂意聽了：我們的客戶都是“變更命令”！這個回頭再說。只要有人提出變更，我們就稱之為變更申請。我們來看第一節變更內容描述：大家會說哎呀，這個首先行不通！我們的客戶從來都是口述，打電話或當面交流。這個我們不怕，客戶只要說出來，我們是不是就可以記錄下來（有人又不高興了：憑什么他說我記呀？別急，這樣做對項目組有好處）？

除非客戶不做任何表示讓我們猜啞謎，我們是一定能夠把客戶的需求變更轉成文字記錄。大家可能又會說，我們可以幫他們記錄，可是他們不愿意簽字那怎么辦？簽字不是關鍵，此處我們關心的是把變更描述記下來，我們能不能把紀錄的描述給客戶看，客戶會不會翻臉不認賬：“不是我說的！” ？不會的，果真這樣我們就不做了！第一個問題是不是解決了？

往后看這可有點懸，什么叫對業務的影響呀？客戶要改需求還需要理由嗎？您說需要不需要？有人可能會說那是客戶的事情，我們干涉不了。這個說法可是大謬不然也！業務上不需要的功能我們為什么要做？有人會說:客戶不需要的功能他們會提出來給我們做嗎？老大，您可是真糊涂了！你還以為客戶每提一個需求都那么深思熟慮嗎？所以得先讓客戶想一想！又有人說了，您搞形式主義！客戶直接就寫“如果做，對業務是極大促進；反之會對業務造成負面沖擊”，你有什么辦法？如果有人竟然有這樣的想法，我真是替你們的領導難過：什么叫斗智斗勇？你要動腦筋呀！你能不能從客戶的談話中間去捕獲信息？！你能不能去了解客戶的業務了解變更的必要性？！！當然可以，要不還做什么項目！徹底成了客戶的跟班了！怎么樣？這個問題是不是也解決了？

第二步

我們再看第二步：技術評審。技術評審評什么？就是我們能不能做得了？比如說有這么一個糊涂客戶提出說他們要求訂單的最大處理時間是0.1秒，你應該做什么？直接告訴別人做不了。當然，大部分情況下技術還是可以滿足新需求的。好，第二步問題也解決了吧？

第三步

好，接著來看第三步。第三步評價對工期的影響，有人可能馬上會反駁說，工期評價沒用，反正是自己消化掉。其實此處將工期、成本、質量都要量化的重要目的之一就是強迫我們的項目組先要想清楚，一個變更意味著什么。一定要把它落實到具體的數據上？為什么？我們在項目中、甚至工作和生活中，因為沒有確切量化數據的情況比比皆是，而結果就是導致不必要的矛盾和摩擦。這也就是為什么細化、量化、圖形化，在細化的基礎上去量化才有意義。先看對具體活動工期的影響，可能是7天也可能是5天或其他；再看對于整體工期的影響，大家應該對關鍵路徑的概念應該比較熟悉了。一個額外活動的工期需要10天，但是體現在整體工期卻不一定是10天，還有可能是5天或者是0天，因為它有可能正好是一項非關鍵路徑上的活動。所以這兩種情況我們都要了解，簡單吧？好，第三步就這么簡單。

第四步

來看第四步，第四步也不會有什么歧義。因為一項變更有可能導致項目中需要添加新的人手（可能因為獨特的技術背景），而現有的人員怎么樣加班也是無濟于事的，所以項目組人員可能會增加。在看對應的工作量增加，這個應該相對容易，估算需要幾個人（很多情況會是一個人）、多長時間（天或小時），自然工作量就出來了。

小時工資率是什么？我們國內企業發工資一般會是基于工作天數的月薪，而許多外企則是基于工作小時數的月薪，所以這里有一個區別：一天可以是8個小時也可以是18個小時，難怪我們國內企業加班是家常便飯：沒有請你周六周日來啊，不就是每天多那么幾個小時嘛！而外企加班相對少許多：額外的工作時間要付加班費的（或許是工商局對它們看得比較嚴，而對我們國內的企業則網開一面的緣故吧）。說遠了，小時工資率的設定與計算可依據組織的特點設定，自己搞不定請財務部門幫你出個數吧。

人時乘以小時工資率不就是人員工作量對應的成本嘛！其他的有時候可能涉及到材料費用、軟硬件的采購費用、差旅費用等，我們統一將它歸結為非人力成本好了。這樣我們將這兩部分相加就得到需求變更對應的成本增加情況。第四步也是這么一目了然，沒有問題吧。

第五步

要說第五步還真不太容易給一個統一的建議，這得取決于項目組的情況。如果項目組沒有量化的歷史數據參考，只能以定性的方式去描述需求變更對于項目不同階段的影響。例如我們在測試階段的后期實施一項大的變更，那么它對測試階段的質量影響是可以想見的：因為引入新功能或更改功能，一定導致更多的缺陷，而在回歸過程中如發現新的問題需要修改的話又可能帶來更多的問題。所以對于測試階段的質量是負面的。對于產品運行階段的質量影響也是顯然的：系統的穩定性、可靠性、安全性可能都會受到波及。

當然，如果項目所在的組織有些歷史數據作參考，那判斷起來就容易多了。如果變更的需求是30個功能點,又假定測試階段缺陷密度是0.4/FP到0.8/FP之間,我們容易推測變更將導致增加的缺陷個數介于12到18個之間；而如果殘余缺陷密度是0.02/FP到0.05/FP之間，則上線后暴露給客戶的問題數目為0.6個到1.5個之間，也即一到兩個。

我們將對質量的影響是不是也可做相應的分析？當然嘍！

第六步

這個小節關注的是風險，變更往往意味著更多的功能，更多的功能意味著更多的工作要做，因而面臨更多的變數，也即我們就常所說的風險。比如說變更往往伴隨著工期的延長，而對于在外地開發的項目此種情形尤其有可能導致項目組成員普遍的厭倦情緒，對應的風險表述就是項目組士氣低下，導致工作效率下降，甚至會引起人員的流失，對于項目組來說不得不預見這種類型的風險，所以變更分析應該做出對應的風險分析。

第七步

這一步就很簡單了，主要是根據前面的給定的各方面信息權衡以后做出是否變更的決定。有人又說了：才不是呢，如果是需求變更，那一定得客戶簽字，客戶如果不簽字，我們一點招數都沒有！我們再一次退而求其次：能不能把客戶的名字寫上，表明他（她）知曉這件事情？應該是可以的吧
至于表頭信息，我想應該沒什么問題，所提供的相關信息主要是供以后做統計分析之用。

好，到此為止，我們介紹了軟件需求變更管理七步法。