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

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

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

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

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

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

更多內(nèi)容敬請訪問：http://m.shlenka.com/active38.html