軟件項目管理實(shí)踐之如何控制需求變更

    需求變更往往會(huì )引起返工，從而影響項目的范圍、時(shí)間、質(zhì)量和成本等多個(gè)要素，如果控制不好，會(huì )導致項目范圍蔓延、進(jìn)度延遲、質(zhì)量不滿(mǎn)足干系人要求和成本超支等問(wèn)題，因而需求變更在很多項目中都是一件頭疼的事情。這一章節主要介紹需求變更的原因、需求變更的方式以及我們如何控制需求變更。

一、需求變更的原因
　　行業(yè)軟件與國家政策相關(guān)較大，可以說(shuō)國家政策是需求變更的一大來(lái)源。另外，客戶(hù)的想法、需求有缺陷等也是需求變更的重要起因�？偨Y起來(lái)，變更原因主要有：
　　1. 國家政策改變了。這種情況在政府行業(yè)表現尤其明顯，三天兩頭一個(gè)紅頭文件，要求下級單位貫徹落實(shí)執行；
　　2. 客戶(hù)的要求變了�？蛻�(hù)一開(kāi)始沒(méi)有想好，或者一開(kāi)始沒(méi)有想法但隨著(zhù)項目的進(jìn)行、參考其他地方好的做法，產(chǎn)生了一些新的想法;也有一種情況是因為外部壓力，主動(dòng)或被動(dòng)作出調整，比如因為業(yè)務(wù)流程太復雜，手續太繁瑣遭辦事人投訴等；
　　3. 需求有缺陷。系統分析員經(jīng)驗不足，沒(méi)有捕獲到客戶(hù)的關(guān)鍵業(yè)務(wù)需求或者客戶(hù)整理需求能力不足，遺漏了關(guān)鍵的需求點(diǎn)等。

二、需求變更的形式
　　根據先前幾個(gè)項目的觀(guān)察，總結起來(lái)，常見(jiàn)的提出需求變更的形式主要有：
　　1. 客戶(hù)在項目開(kāi)發(fā)過(guò)程中，向系統分析員提出變更。提法主要有：“這個(gè)功能我想改成這樣，你看怎么樣?”，“這個(gè)業(yè)務(wù)我有新的想法，參考某地的做法，最好改成這樣”；
　　2. 客戶(hù)在驗收測試過(guò)程中，向系統分析員或測試人員提出變更。常見(jiàn)的提法有：“這個(gè)功能能不能這樣?”，“這個(gè)界面不太好用，改成這樣子”，“這個(gè)業(yè)務(wù)應該加上這個(gè)限制”，“這個(gè)地方原來(lái)沒(méi)有考慮到，要改成這樣”等等；
　　3. 客戶(hù)在正式的項目例會(huì )上提出變更。正式的會(huì )議往往會(huì )有高層參與，客戶(hù)準備的較為充分，這些變更通常會(huì )以書(shū)面的形式提出；
　　4. 項目組提出變更。由于需求有缺陷或者技術(shù)實(shí)現難度太大，需要提出需求變更。這時(shí)候項目組需要詳細的書(shū)面文檔說(shuō)明變更的理由以及替換的方案。

三、需求變更的溝通
　　了解了變更產(chǎn)生的原因，在此基礎上，我們可以建立相應的變更溝通策略，具體定義如下：
　　1. 國家政策變化導致的需求變更。國家政策變化屬于強制的變更，這時(shí)候客戶(hù)為了完成政治任務(wù)，變更是一定要發(fā)生的。對于項目組來(lái)說(shuō)，需要對這些變更做好評估工作，包括變更新增的工作量估算、對項目目標（范圍、時(shí)間、質(zhì)量和成本）的影響等等，基于量化的數據與客戶(hù)談判。工作量不大，對基線(xiàn)影響很小的，納入開(kāi)發(fā)計劃予以實(shí)施，但需與客戶(hù)明確，我們這是在幫忙，這些工作不是項目范圍的一部分;工作量較大，對基線(xiàn)有很大影響的，與客戶(hù)進(jìn)行商務(wù)談判，要求項目追加預算或者以后通過(guò)在新項目中加入該部分的工作予以補償。一般情況下，由于國家政策都有時(shí)限，為滿(mǎn)足客戶(hù)需求，變更都會(huì )先實(shí)施，然后再談補償；
    2. 客戶(hù)想法或要求導致的需求變更。由于社會(huì )在發(fā)展，人的觀(guān)念也在不斷更新，可以說(shuō)，客戶(hù)提出變更也是可以理解的。項目組基于變更評估與客戶(hù)溝通，策略有三類(lèi)，一是指出變更不合理，影響太大，直接拒絕；二是提出替換方案；三是商務(wù)談判，具體的做法與第1點(diǎn)類(lèi)似；
　　3. 需求本身有缺陷導致的變更。這時(shí)候與客戶(hù)溝通，說(shuō)明考慮不周的情況，提出解決方案。要注意的是，如果是項目組的失誤導致的缺陷，需承認客觀(guān)事實(shí)，不要掩飾或者推卸責任，否則可能會(huì )引致客戶(hù)對項目組不信任，降低客戶(hù)滿(mǎn)意度，影響合作關(guān)系。

四、需求變更的控制
　　需求變更的控制關(guān)鍵在于建立建立相應的控制組織、變更控制和跟蹤系統以及規范變更流程，主要有：
　　1. 建立組織。項目啟動(dòng)時(shí)，我們會(huì )盡可能的與客戶(hù)溝通，建立正式的對變更進(jìn)行控制的組織，成員包括雙方高層（掛名）、甲乙雙方的項目負責人、相關(guān)的需求負責人等。如果客戶(hù)認為無(wú)需單獨設置這樣的正式組織，我們也會(huì )要求客戶(hù)指定項目的負責人，每個(gè)相關(guān)的業(yè)務(wù)科室指定一名需求負責人，這樣做的目的是如出現變更可以很快的臨時(shí)組建一個(gè)對變更負責的組織，并且可以找到相應的負責人；
　　2. 建立變更控制和跟蹤系統。建立該系統的目的是統一管理需求變更和跟蹤變更的狀態(tài)，便于項目組測試人員、開(kāi)發(fā)人員、系統分析員以及PM相互之間的溝通和交流；經(jīng)比較和選型，我們選用了JIRA作為變更控制和跟蹤系統；
　　3. 規范流程。甲乙雙方的項目組成立后，根據角色定義，確定變更流程。
　　1） 變更申請。系統界面如按鈕的位置、字段的位置的細微調整，不涉及到業(yè)務(wù)規則，對基線(xiàn)基本沒(méi)有影響的變更，由測試人員直接在變更控制系統中提出；其他如操作風(fēng)格的較大變化、業(yè)務(wù)規則的變化等，均要求客戶(hù)提出電子和書(shū)面的需求變更單；
　　2）變更評估。由項目組組織人員對變更進(jìn)行變更的合理性分析，變更替換方案分析，工作量的估算以及涉及什么模塊、影響什么模塊等影響分析；
　　3） 變更決策。根據上節確定的溝通策略，與客戶(hù)溝通交流，確定變更的處理方式；
　　4） 變更實(shí)施。由測試人員在變更控制系統中填寫(xiě)變更信息（狀態(tài)：待處理），由系統分析員填寫(xiě)處理方法和影響分析后交由開(kāi)發(fā)人員實(shí)施（狀態(tài)：處理中）；
　　5） 變更驗證。測試人員根據變更控制系統的變更狀態(tài)反饋（狀態(tài)：已解決），待相應的版本發(fā)布后，對變更進(jìn)行驗證測試，這時(shí)候特別要注意的是記錄該變更的修改是否引起了該模塊或其他模塊產(chǎn)生缺陷。通常，測試人員根據系統分析員在變更控制系統中標注的影響模塊，逐一進(jìn)行回歸測試，以確保不影響原有模塊的前提下變更已正確實(shí)施；內部測試完畢后，如系統已上線(xiàn)，則由客戶(hù)相關(guān)負責人在模擬生產(chǎn)環(huán)境中進(jìn)行驗收測試；
　　6）溝通歸檔。變更驗證后，測試人員關(guān)閉變更（狀態(tài)：已關(guān)閉），項目經(jīng)理告知客戶(hù)已測試完畢，溝通發(fā)布時(shí)間并說(shuō)明那些模塊可能有影響以及發(fā)現問(wèn)題的反饋途徑和方式。
　　通過(guò)以上幾種手段，如執行實(shí)施到位，基本可以有效的把變更置于控制之下。
    最后，值得一提的是，變更實(shí)施或者系統缺陷修復涉及到多方面的人員，可能牽涉軟件系統中的多個(gè)模塊，處理和驗證的流程復雜，溝通等管理成本高昂，如果變更和質(zhì)量控制不好，會(huì )直接影響項目的進(jìn)度和成本。（資料來(lái)源：項目管理者聯(lián)盟）

更多內容敬請訪(fǎng)問(wèn)：http://www.firg8.com/active38.html