在系統需求分析階段，項目組成員和客戶的深入交流是項目成功的關鍵。但是由于雙方的誤解通常使交流難以進行。AMT的劉立軍先生總結的Why、What、How方式可以非常有效的使 溝通順暢。簡單的說，在項目初期， 項目經理首先需要考察客戶做這個項目有什么用處，就是“為什么”，這樣才能真正從客戶的角度來考慮系統的設計；接下來需要總結出整個項目是“做什么”，并能概括出各個子任務，讓開發人員對項目內容的大方向有很好的把握；最重要的當然是“怎么做”了，對信息系統集成項目而言，這個階段多花點時間絕對值得。其中也有些小技巧：需求分析報告應以客戶認為易于翻閱和理解的方式進行編寫，同時也要有助于開發人員開發出真正需要的系統；項目組成員最好就需求分析報告給客戶詳細的講述，并達成共識，溝通手段在這里很重要；另外，需求確認之后，最好讓客戶方管理層書面簽字，作為終止需求分析過程的標志，但是絕不是作為拒絕范圍變更的手段。
四、行之有效的 變更控制
一個項目的范圍計劃可能制訂的非常好，但是想不出現任何改變幾乎是不可能的。項目經理和項目小組必須意識到范圍變更本身并沒有什么不對，事實上很多時候這會讓你的系統更健壯、更實用�？蛻敉ǔ２荒芤婚_始就確定所有需求，而且情況會隨時間而變化，如果不能包容變更，那么最終解決方案可能就達不到應有的價值。
但是如果變更失控，后果也非常嚴重，甚至于導致整個項目的失敗。根據1995年斯坦迪什公司的研究結果，最可能引起IT項目失敗的前三個因素分別為：缺乏用戶參與、不完整的要求和說明、易變的要求和說明，這幾個因素都直接或間接與范圍變更管理有關。
因此，必須進行范圍變更管理。潘東先生認為：“變更控制的目的不是控制變更的發生，而是對變更進行管理，確保變更有序進行�！�
為執行變更控制，必須建立有效的范圍變更流程。這個流程應該包括確認變更、評估變更的商業價值、分析變更對項目的影響，以及提交給項目發起人進行評價以確定是否執行變更。
但是僅有范圍變更流程尚不足以真正控制變更，這是因為項目組的外部有許多壓力，同時與缺乏行之有效的變更控制手段密切相關。
目前流行的變更管理思想認為在范圍變更流程中有四個關鍵點必須嚴格控制，既：誰有權確認變更、什么樣的變更需要執行、變更的影響多大、客戶是否接受變更的代價。
1、誰有權確認變更：
不應當為節省時間而允許客戶的業務人員與開發人員直接聯系，這樣無法控制變更。必須事先明確客戶方有權提出變更請求的人員和項目組有權受理變更的人員，變更請求必須有書面材料。
在筆者參與實施某大型信息系統集成項目感受頗深：項目經理曾提醒我們，客戶出錢請我們來做實施，這應該算是“公對公”的事情，如果有用戶以“私人感情”為由要求范圍變更，開發人員可以拒絕。
當時用戶如果發現由于業務變化而引起的需求變更，需要向客戶方項目負責人提出書面申請，由客戶方項目負責人審批后移交實施方項目經理。
這樣對所有的變更，雙方的項目負責人都能做到心里有數。而且用戶在遞交書面變更申請時比較慎重，一般都在自己科室內部經過討論后進行，這樣減少了因用戶內部看法不同導致的反復變更。
2、什么樣的變更需要執行：
不是所有的變更都需要修改，更不是所有的變更都需要立刻修改。必須對客戶提出的范圍變更進行審核，來決定哪些變更需要修改和什么時候修改。
客戶一般對信息系統集成項目不甚了解，他們認為很簡單的事情，可能由計算機來解決會很復雜。因此項目經理和項目小組要冷靜的分析：用戶到底想要實現什么目的，抓住本質的需求。如果用戶建議很難實現，可以和用戶進行溝通，詢問用戶是否可以用其他方式來實現其目的。
以筆者的經驗來看，一般來說用戶的鍍金（Golden Plating）需求可以延期解決甚至不考慮。用戶的新增需求如果不是影響到核心業務的實現，也可以安排在現有功能的完善之后。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
