需求變更控制的流程和(如何有效控制需求變更)
1.如何有效控制需求變更
需求變更對軟件開發(fā)項目成敗有重要影響，既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以實施需求變更之前必須做好控制。
需求變更控制的目的不是控制變更的發(fā)生，而是對變更進行管理，確保變更有序進行。 （1）明確合同約束，建立需求基線 需求變更給軟件開發(fā)帶來的影響有目共睹，所以在與客戶簽訂合同時，可以增加一些相關(guān)條款，如限定客戶提出需求變更的時間，規(guī)定何種情況的變更可以接受、拒絕或部分接受，還可以規(guī)定發(fā)生需求變更時必須執(zhí)行變更管理流程。
雖然軟件開發(fā)合同很難在簽訂之初就能夠精確定義每項需求，單靠合同是幫不上忙的，但也不能忽視合同的約束力。 明確和樹立需求基線是需求變更的依據(jù)。
在開發(fā)過程中，需求確定并經(jīng)過評審后（客戶參與評審），建立第一個需求基線。此后每次變更并經(jīng)過評審后，都要重新確定新的需求基線，做到小需求可以變更，但大方向要力保不頻繁變更。
例如，對于項目中的需求，可以實行分級管理，以達到對需求變更的控制和管理。 （2）建立變更審批流程 在實踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程，認為降低開發(fā)效率，浪費時間。
正是這種觀念才使需求變更變得不可控，最終導致項目的失敗。因此，小的需求變更也要經(jīng)過正規(guī)的需求管理流程，否則會積少成多，積重難返。
明確需求變更審批環(huán)節(jié)、審批人員、審批事項、審批流程。這么做的目的有兩個：一是將客戶下達變更的流程盡可能地規(guī)范化，減少張嘴就來的非必要、非緊急、非合理、非高層領導意圖的無效變更。
二是留下書面依據(jù)，為今后可能的成本變更和索賠準備好“變更賬”。凡未履行審批程序的“變更”，一律是無效變更不予受理。
（3）分級管理變更，定時批量處理 軟件開發(fā)項目中，“客戶永遠是對的”和“客戶是上帝”并不完全正確，因為在已經(jīng)簽定的項目合同中，任何新需求的變更和增加除了影響項目的正常進行以外，還影響到客戶的成本投入收益。因此，用戶不斷提出對項目進度有重大影響的需求對雙贏也并不是好事。
當遇到客戶提出需求，不及時處理可能會使項目不能驗收通過時，也不能一味拒絕不予開發(fā)。因此，當客戶堅持變更新需求時，可以建議客戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項依據(jù)。
例如，每周或每兩周甚至每月召開一次需求變更專題會議，集中研究處理這些零碎變更事項，主動控制好工作節(jié)奏，盡量避免由于處理零碎變更而影響項目進度。針對會議結(jié)果可向客戶正式提交一份需求變更計劃，注明變更引起的時間、成本、工期代價和增加工作量等。
要求客戶配合需求變更計劃，確定變更時限，控制變更規(guī)模，過時變更不候，離譜變更不做，保大局棄小變。 （4）安排專職人員負責變更管理 有時開發(fā)任務較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與客戶的隨時溝通。
因此，需要安排一名專職的需求變更聯(lián)絡人員，負責與客戶及時交流，跟蹤和匯報需求變更完成進度和情況。同時，可以成立項目變更控制小組，負責裁定接受哪些變更，小組由項目所涉及的多方人員共同組成，應該包括客戶方和開發(fā)方的決策人員在內(nèi)。
（5）確認客戶是否接受變更的代價 要讓客戶認識到變更都是有代價的，要和客戶一起判斷需求變更是否依然進行。例如，變更是沒有問題的，但是要明確客戶能否接受由此引起的如進度延遲、費用增加、效率下降等問題。
一般來說，如果客戶認為該變更是必須的（不是其上級領導拍腦袋提出的）就會接受這些后果。通過與客戶協(xié)商，這樣開發(fā)團隊即使沒有回報，也不會招致公司和客戶雙方的埋怨。
如果客戶認為該變更雖然有必要但是可以暫緩，雙方簽署備忘錄后留待以后解決。如果客戶認為該變更可有可無，多數(shù)情況下會取消變更。
這樣即可防止頻繁變更，也讓客戶認識到不是所有的需求都需要變更。
2.如何做好需求變更管理
項目是以客戶的需求為中心，而不是為技術(shù)而遷就需求。
本章包括以下內(nèi)容： 一. 讓客戶暢所欲言，羅列出所有的需求 二. 透過現(xiàn)象分析潛在的需求 三. 利用自然的語言描述項目模型 四. 利用示意圖和圖表將用戶的需求表現(xiàn)出來。 五. 什么人要看需求分析報告？ 六. 建立需求變更日志，制作新版本的需求分析報告。
七. 本階段重點工作角色 八. 總結(jié) 一：讓客戶暢所欲言，羅列出所有的需求 讓用戶將所有的想法盡可能的闡述清楚，并把所有的要求羅列出來，不要遺漏。這時候不應該害怕“勾引”起客戶的潛在需求而增加設計開發(fā)的工作量，從而被今后客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時可能會產(chǎn)生意想之外的變更，甚至這個變更會破壞已經(jīng)做的模型及結(jié)構(gòu)，那么這個項目從開始就注定了會失??；比如站點所有的功能都實現(xiàn)了，本地測試起來也沒有什么問題了，但是你卻不知道客戶的系統(tǒng)是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經(jīng)驗的開發(fā)人員都會明白這樣的設計是個災難，無論是應用服務器、數(shù)據(jù)庫還是程序全部要重新開發(fā)！ 二：透過現(xiàn)象分析潛在的需求 很多情況下客戶并非專業(yè)人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術(shù)難關(guān)，這需要我們?nèi)榭蛻暨M行分析、歸納和整理，尤其是客戶談的不多卻又是技術(shù)上實現(xiàn)難度和強度很高的地方特別值得注意。 客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統(tǒng)而且尺度難以控制的，這就要求業(yè)務人員在傾聽了客戶的詳細說明以后，幫助客戶進行整理和分析，同時預測客戶在開發(fā)過程中變更及今后應用中可能進行修改升級的潛在需求。
比如在為客戶設計辦公自動化系統(tǒng)的時候，也許就要為客戶預留將來與他們的業(yè)務單位進行交互的通道；在設計郵件系統(tǒng)的時候要考慮可能會需要廣告管理服務器；設計網(wǎng)絡電子商店時今后增加庫存產(chǎn)品進銷存統(tǒng)計分析等等；限于時間財力的考慮，客戶通常能夠接受分階段實施的開發(fā)過程，在需求分析時，提早為客戶設想到今后的需求變更除了使項目開發(fā)更加順利以外，也為今后業(yè)務的進一步深入打下了更好的基礎。 筆者曾負責一個大型新聞網(wǎng)站的設計，當客戶拿著將近五十頁厚的一本設計要求報告時，我發(fā)現(xiàn)有四十頁的內(nèi)容對程序開發(fā)來說都是重復的，而在其中一頁的角落卻畫了個“搜索其他網(wǎng)站相關(guān)新聞”的按鈕，并且沒有做任何說明，僅僅這10個字所完成的工作量完全頂?shù)纳掀渌氖撝貜唾樖鏊龅墓ぷ?，客戶完全不知道這個要求引發(fā)的問題實際就是一個搜索引擎的開發(fā)，通過協(xié)商，客人同意了修改成站內(nèi)搜索的引擎。
三：利用自然的語言描述項目模型 在業(yè)務員與客戶進行溝通和調(diào)查時撰寫的需求分析，盡可能用自然的語言進行描述，雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項目開發(fā)的各個成員都能清楚地理解需求含義，不至于在理解上產(chǎn)生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，并能以此為測試和驗收的依據(jù)。
3.如何控制需求變更
你必須面對這個現(xiàn)實：需求變更是不可避免的。項目經(jīng)理應該做的，是如何在發(fā)生需求變更的情況盡量減少其對項目的影響。需求變更不可避免，不是說就不做需求變更的控制了，需求變更如果量很大，對項目的影響無論如何也降不下來，因此還是要在控制需求變更上下功夫，但不要奢望杜絕需求變更。
對于管理信息系統(tǒng)的項目，其需求的核心點在于業(yè)務流程，如果業(yè)務流程保證沒問題了，那么系統(tǒng)就不會發(fā)生大的需求變更，界面調(diào)整一下，多一兩個字段，甚至多一兩個查詢頁面，都對系統(tǒng)不會產(chǎn)生太大的影響；但是如果流程變了，比如中間加了一個環(huán)節(jié)，或是環(huán)節(jié)間數(shù)據(jù)交互的變更，都可能會給整個系統(tǒng)帶來很大甚至致命的影響，有可能因為某流程的變化導致整個系統(tǒng)都要重新翻一遍，這樣的修改對質(zhì)量的影響是非?？膳碌摹?/p>
要把握用戶的流程，首先看用戶這個業(yè)務流程是否正在正常的運行，在這種情況下，你把這個流程調(diào)研清楚了就沒有問題了；但是如果業(yè)務流程是用戶新構(gòu)想出來，正指望著你通過系統(tǒng)去實施（也可以說試試）這個流程，那你就要小心了，必須仔細的分析這個流程的可行性，主動的和客戶探討這個流程的缺陷，可能面臨的問題，必要時請有關(guān)專家做咨詢，總之，一定要保證流程的可行性，否則流程一旦執(zhí)行不下去，雖然軟件本身沒有任何質(zhì)量問題，你還得改。
對于流程分析要了解哪些關(guān)鍵點呢，首先當然是有哪些環(huán)節(jié)，環(huán)節(jié)間的運作關(guān)系，比如報銷流程，有填單、部門領導審批、財務稽核、主管副總審批、結(jié)算這些環(huán)節(jié)，簡單來說是依次傳遞的；其次要了解每一環(huán)節(jié)的控制點，比如領導審批，可以通過、不通過，一定要注意不通過這個非正常流程的下一節(jié)點，也許是終點（該報銷單作廢，要求報銷人重填），也許又到了填報環(huán)節(jié)（報銷人可以修改后重新提交審批）；然后一定要搞清楚環(huán)節(jié)間的數(shù)據(jù)和傳遞關(guān)系，這是非常重要的，因為這些數(shù)據(jù)和關(guān)系至少會影響兩個環(huán)節(jié)的處理，甚至可能影響整個流程的處理，而其他的無需傳遞的數(shù)據(jù)項，一般只對某個環(huán)節(jié)的處理產(chǎn)生影響，即使發(fā)生變化也無關(guān)大局。
這三點把握住了，流程也就基本清楚了，但是要注意，了解這些信息首先是通過和客戶的直接交流，同時一定要注意分析客戶提供的每一環(huán)節(jié)的表單和最終的分析報表，確定每一信息的來源，因為表單和報表的數(shù)據(jù)理論上講都是通過流程的處理得到的，它們真的都包含在流程處理中了嗎？
4.如何控制需求變更
你必須面對這個現(xiàn)實：需求變更是不可避免的。
項目經(jīng)理應該做的，是如何在發(fā)生需求變更的情況盡量減少其對項目的影響。需求變更不可避免，不是說就不做需求變更的控制了，需求變更如果量很大，對項目的影響無論如何也降不下來，因此還是要在控制需求變更上下功夫，但不要奢望杜絕需求變更。
對于管理信息系統(tǒng)的項目，其需求的核心點在于業(yè)務流程，如果業(yè)務流程保證沒問題了，那么系統(tǒng)就不會發(fā)生大的需求變更，界面調(diào)整一下，多一兩個字段，甚至多一兩個查詢頁面，都對系統(tǒng)不會產(chǎn)生太大的影響；但是如果流程變了，比如中間加了一個環(huán)節(jié)，或是環(huán)節(jié)間數(shù)據(jù)交互的變更，都可能會給整個系統(tǒng)帶來很大甚至致命的影響，有可能因為某流程的變化導致整個系統(tǒng)都要重新翻一遍，這樣的修改對質(zhì)量的影響是非常可怕的。 要把握用戶的流程，首先看用戶這個業(yè)務流程是否正在正常的運行，在這種情況下，你把這個流程調(diào)研清楚了就沒有問題了；但是如果業(yè)務流程是用戶新構(gòu)想出來，正指望著你通過系統(tǒng)去實施（也可以說試試）這個流程，那你就要小心了，必須仔細的分析這個流程的可行性，主動的和客戶探討這個流程的缺陷，可能面臨的問題，必要時請有關(guān)專家做咨詢，總之，一定要保證流程的可行性，否則流程一旦執(zhí)行不下去，雖然軟件本身沒有任何質(zhì)量問題，你還得改。
對于流程分析要了解哪些關(guān)鍵點呢，首先當然是有哪些環(huán)節(jié)，環(huán)節(jié)間的運作關(guān)系，比如報銷流程，有填單、部門領導審批、財務稽核、主管副總審批、結(jié)算這些環(huán)節(jié)，簡單來說是依次傳遞的；其次要了解每一環(huán)節(jié)的控制點，比如領導審批，可以通過、不通過，一定要注意不通過這個非正常流程的下一節(jié)點，也許是終點（該報銷單作廢，要求報銷人重填），也許又到了填報環(huán)節(jié)（報銷人可以修改后重新提交審批）；然后一定要搞清楚環(huán)節(jié)間的數(shù)據(jù)和傳遞關(guān)系，這是非常重要的，因為這些數(shù)據(jù)和關(guān)系至少會影響兩個環(huán)節(jié)的處理，甚至可能影響整個流程的處理，而其他的無需傳遞的數(shù)據(jù)項，一般只對某個環(huán)節(jié)的處理產(chǎn)生影響，即使發(fā)生變化也無關(guān)大局。 這三點把握住了，流程也就基本清楚了，但是要注意，了解這些信息首先是通過和客戶的直接交流，同時一定要注意分析客戶提供的每一環(huán)節(jié)的表單和最終的分析報表，確定每一信息的來源，因為表單和報表的數(shù)據(jù)理論上講都是通過流程的處理得到的，它們真的都包含在流程處理中了嗎？。
5.軟件項目管理實踐之如何控制需求變更?
需求變更的控制關(guān)鍵在于建立建立相應的控制組織、變更控制和跟蹤系統(tǒng)以及規(guī)范變更流程，主要有：
1、建立組織。項目啟動時，需要盡可能的與客戶溝通，建立正式的對變更進行控制的組織，成員包括雙方高層（掛名）、甲乙雙方的項目負責人、相關(guān)的需求負責人等。如果客戶認為無需單獨設置這樣的正式組織，也會要求客戶指定項目的負責人，每個相關(guān)的業(yè)務科室指定一名需求負責人，這樣做的目的是如出現(xiàn)變更可以很快的臨時組建一個對變更負責的組織，并且可以找到相應的負責人；
2、建立變更控制和跟蹤系統(tǒng)。建立該系統(tǒng)的目的是統(tǒng)一管理需求變更和跟蹤變更的狀態(tài)，便于項目組測試人員、開發(fā)人員、系統(tǒng)分析員以及PM相互之間的溝通和交流；經(jīng)比較和選型，可以選用了JIRA作為變更控制和跟蹤系統(tǒng)；
3、規(guī)范流程。甲乙雙方的項目組成立后，根據(jù)角色定義，確定變更流程。
1）變更申請。系統(tǒng)界面如按鈕的位置、字段的位置的細微調(diào)整，不涉及到業(yè)務規(guī)則，對基線基本沒有影響的變更，由測試人員直接在變更控制系統(tǒng)中提出；其他如操作風格的較大變化、業(yè)務規(guī)則的變化等，均要求客戶提出電子和書面的需求變更單；
2）變更評估。由項目組組織人員對變更進行變更的合理性分析，變更替換方案分析，工作量的估算以及涉及什么模塊、影響什么模塊等影響分析；
3）變更決策。根據(jù)上節(jié)確定的溝通策略，與客戶溝通交流，確定變更的處理方式；
4）變更實施。由測試人員在變更控制系統(tǒng)中填寫變更信息（狀態(tài)：待處理），由系統(tǒng)分析員填寫處理方法和影響分析后交由開發(fā)人員實施（狀態(tài)：處理中）；
5）變更驗證。測試人員根據(jù)變更控制系統(tǒng)的變更狀態(tài)反饋（狀態(tài)：已解決），待相應的版本發(fā)布后，對變更進行驗證測試，這時候特別要注意的是記錄該變更的修改是否引起了該模塊或其他模塊產(chǎn)生缺陷。通常，測試人員根據(jù)系統(tǒng)分析員在變更控制系統(tǒng)中標注的影響模塊，逐一進行回歸測試，以確保不影響原有模塊的前提下變更已正確實施；內(nèi)部測試完畢后，如系統(tǒng)已上線，則由客戶相關(guān)負責人在模擬生產(chǎn)環(huán)境中進行驗收測試；
6）溝通歸檔。變更驗證后，測試人員關(guān)閉變更（狀態(tài)：已關(guān)閉），項目經(jīng)理告知客戶已測試完畢，溝通發(fā)布時間并說明那些模塊可能有影響以及發(fā)現(xiàn)問題的反饋途徑和方式。
通過以上幾種手段，如執(zhí)行實施到位，基本可以有效的把變更置于控制之下。
最后，值得一提的是，變更實施或者系統(tǒng)缺陷修復涉及到多方面的人員，可能牽涉軟件系統(tǒng)中的多個模塊，處理和驗證的流程復雜，溝通等管理成本高昂，如果變更和質(zhì)量控制不好，會直接影響項目的進度和成本。
6.如何做好需求變更管理
項目是以客戶的需求為中心，而不是為技術(shù)而遷就需求。
本章包括以下內(nèi)容： 一. 讓客戶暢所欲言，羅列出所有的需求 二. 透過現(xiàn)象分析潛在的需求 三. 利用自然的語言描述項目模型 四. 利用示意圖和圖表將用戶的需求表現(xiàn)出來。 五. 什么人要看需求分析報告？ 六. 建立需求變更日志，制作新版本的需求分析報告。
七. 本階段重點工作角色 八. 總結(jié) 一：讓客戶暢所欲言，羅列出所有的需求 讓用戶將所有的想法盡可能的闡述清楚，并把所有的要求羅列出來，不要遺漏。這時候不應該害怕“勾引”起客戶的潛在需求而增加設計開發(fā)的工作量，從而被今后客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時可能會產(chǎn)生意想之外的變更，甚至這個變更會破壞已經(jīng)做的模型及結(jié)構(gòu)，那么這個項目從開始就注定了會失??；比如站點所有的功能都實現(xiàn)了，本地測試起來也沒有什么問題了，但是你卻不知道客戶的系統(tǒng)是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經(jīng)驗的開發(fā)人員都會明白這樣的設計是個災難，無論是應用服務器、數(shù)據(jù)庫還是程序全部要重新開發(fā)！ 二：透過現(xiàn)象分析潛在的需求 很多情況下客戶并非專業(yè)人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術(shù)難關(guān)，這需要我們?nèi)榭蛻暨M行分析、歸納和整理，尤其是客戶談的不多卻又是技術(shù)上實現(xiàn)難度和強度很高的地方特別值得注意。 客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統(tǒng)而且尺度難以控制的，這就要求業(yè)務人員在傾聽了客戶的詳細說明以后，幫助客戶進行整理和分析，同時預測客戶在開發(fā)過程中變更及今后應用中可能進行修改升級的潛在需求。
比如在為客戶設計辦公自動化系統(tǒng)的時候，也許就要為客戶預留將來與他們的業(yè)務單位進行交互的通道；在設計郵件系統(tǒng)的時候要考慮可能會需要廣告管理服務器；設計網(wǎng)絡電子商店時今后增加庫存產(chǎn)品進銷存統(tǒng)計分析等等；限于時間財力的考慮，客戶通常能夠接受分階段實施的開發(fā)過程，在需求分析時，提早為客戶設想到今后的需求變更除了使項目開發(fā)更加順利以外，也為今后業(yè)務的進一步深入打下了更好的基礎。 筆者曾負責一個大型新聞網(wǎng)站的設計，當客戶拿著將近五十頁厚的一本設計要求報告時，我發(fā)現(xiàn)有四十頁的內(nèi)容對程序開發(fā)來說都是重復的，而在其中一頁的角落卻畫了個“搜索其他網(wǎng)站相關(guān)新聞”的按鈕，并且沒有做任何說明，僅僅這10個字所完成的工作量完全頂?shù)纳掀渌氖撝貜唾樖鏊龅墓ぷ?，客戶完全不知道這個要求引發(fā)的問題實際就是一個搜索引擎的開發(fā)，通過協(xié)商，客人同意了修改成站內(nèi)搜索的引擎。
三：利用自然的語言描述項目模型 在業(yè)務員與客戶進行溝通和調(diào)查時撰寫的需求分析，盡可能用自然的語言進行描述，雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項目開發(fā)的各個成員都能清楚地理解需求含義，不至于在理解上產(chǎn)生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，并能以此為測試和驗收的依據(jù)。
7.怎么樣處理需求變更
可以在合同上規(guī)定，
在正式確定《需求說明書》前，可以由客戶自由提出需求（當然需求分析人員保證需求的質(zhì)量）。
一旦《軟件需求說明書》完成，并且客戶簽字確認了它。那么就禁止客戶隨意的更改需求。
1）客戶新/變更的需求按照某個價格另外的收取費用。
2）開發(fā)方有權(quán)拒絕客戶的某種新/變更需求。
不過這要在合同中明確客戶在確認了《需求說明書》后不得隨意的提出新/變更需求。
8.什么是需求變更
需求變更，即對項目或者軟件開發(fā)需求的更變，是指在跟客戶簽訂了項目或軟件開發(fā)協(xié)議之后，在完成交付之前，客戶提出的對項目或者軟件的功能或非功能性的更改要求。
客觀地說，“項目一旦啟動，變更也就隨之而來”，但是，需求的變更必然會影響到項目的開展或者軟件的開發(fā)，需求變更對項目或者軟件開發(fā)成敗有重要影響，我們既不能一概拒絕客戶的變更要求，也不能一味地遷就客戶，所以控制需求變更才是最好的應對策略。當然，需求變更控制的目的不是控制變更的發(fā)生，而是對變更進行科學的管理，要確保變更有序地進行。
一般地說，為了確保需求變更符合雙方的利益，可以采取如下措施來控制需求變更：
1.分級管理客戶需求，重點客戶重點管理；
2.項目開發(fā)生命周期全過程需求變更管理，確保整個項目順利完成；
3.專人負責需求變更管理工作，確保工作同步進行；
4.契約化管理需求變更。合作雙方在簽訂協(xié)議之初，書面約定需求變更的提出方式、評價程序、修改要求、執(zhí)行過程以及驗收要求等。只有這樣，才能確保需求變更按程序和要求有序進行。
5.需求變更必須提前溝通，雙方要加強信息交換，防止搞突然襲擊，更不能提出超越雙方能力的需求變更。
