審批流程
在實踐中，人們往往不愿意為小的需求變更去執(zhí)行正規(guī)的需求管理過程，認(rèn)為降低開發(fā)效率，浪費時間。正是這種觀念才使需求變更變得不可控，最終導(dǎo)致項目的失敗。因此，小的需求變更也要經(jīng)過正規(guī)的需求管理流程，否則會積少成多，積重難返。
明確需求變更審批環(huán)節(jié)、審批人員、審批事項、審批流程。這么做的目的有兩個：一是將客戶下達(dá)變更的流程盡可能地規(guī)范化，減少張嘴就來的非必要、非緊急、非合理、非高層領(lǐng)導(dǎo)意圖的無效變更。二是留下書面依據(jù)，為今后可能的成本變更和索賠準(zhǔn)備好“變更賬”。凡未履行審批程序的“變更”，一律是無效變更不予受理。
（3）分級管理變更，定時批量處理
軟件開發(fā)項目中，“客戶永遠(yuǎn)是對的”和“客戶是上帝”并不完全正確，因為在已經(jīng)簽定的項目合同中，任何新需求的變更和增加除了影響項目的正常進(jìn)行以外，還影響到客戶的成本投入收益。因此，用戶不斷提出對項目進(jìn)度有重大影響的需求對雙贏也并不是好事。
當(dāng)遇到客戶提出需求，不及時處理可能會使項目不能驗收通過時，也不能一味拒絕不予開發(fā)。因此，當(dāng)客戶堅持變更新需求時，可以建議客戶將新需求按重要和緊迫程度劃分檔次，作為需求變更評估的一項依據(jù)。例如，每周或每兩周甚至每月召開一次需求變更專題會議，集中研究處理這些零碎變更事項，主動控制好工作節(jié)奏，盡量避免由于處理零碎變更而影響項目進(jìn)度。針對會議結(jié)果可向客戶正式提交一份需求變更計劃，注明變更引起的時間、成本、工期代價和增加工作量等。要求客戶配合需求變更計劃，確定變更時限，控制變更規(guī)模，過時變更不候，離譜變更不做，保大局棄小變。
?。?）安排專職人員負(fù)責(zé)變更管理
有時開發(fā)任務(wù)較重，開發(fā)人員容易陷入開發(fā)工作中而忽略了與客戶的隨時溝通。因此，需要安排一名專職的需求變更聯(lián)絡(luò)人員，負(fù)責(zé)與客戶及時交流，跟蹤和匯報需求變更完成進(jìn)度和情況。同時，可以成立項目變更控制小組，負(fù)責(zé)裁定接受哪些變更，小組由項目所涉及的多方人員共同組成，應(yīng)該包括客戶方和開發(fā)方的決策人員在內(nèi)。
?。?）確認(rèn)客戶是否接受變更的代價
要讓客戶認(rèn)識到變更都是有代價的，要和客戶一起判斷需求變更是否依然進(jìn)行。例如，變更是沒有問題的，但是要明確客戶能否接受由此引起的如進(jìn)度延遲、費用增加、效率下降等問題。一般來說，如果客戶認(rèn)為該變更是必須的（不是其上級領(lǐng)導(dǎo)拍腦袋提出的）就會接受這些后果。通過與客戶協(xié)商，這樣開發(fā)團(tuán)隊即使沒有回報，也不會招致公司和客戶雙方的埋怨。
如果客戶認(rèn)為該變更雖然有必要但是可以暫緩，雙方簽署備忘錄后留待以后解決。如果客戶認(rèn)為該變更可有可無，多數(shù)情況下會取消變更。這樣即可防止頻繁變更，也讓客戶認(rèn)識到不是所有的需求都需要變更。
以上便是本人在頻繁需求變更的血淚史中收獲的經(jīng)驗，與大家分享。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html
