人員不應該做這方面的工作，項目開發(fā)人員對于需求變更的正確態(tài)度應該和軟件測試的態(tài)度一樣，在需求變更發(fā)生之前盡量減少需求變更，以將需求變更帶來的風險降低到最低。項目開發(fā)人員切忌在項目設(shè)計之前試圖消除需求變更，這樣做往往費力不討好。
　　相比于需求開發(fā)人員而言，客戶可能對需求變更認識不足，認為他們出錢，程序員或軟件開發(fā)公司就要為它服務，因此客戶對需求變更往往更加肆無忌彈，將需求變更視為兒戲，隨個人喜好隨意變更需求。因此，在需求人員同用戶代表或用戶部門主管人員接觸時，就應該向他們挑明態(tài)度，和他們協(xié)商好，特別是應該讓他們清楚軟件的定價應該與軟件的功能相關(guān)，以及需求隨意變更所帶來的風險的承擔者應該由客戶和項目開發(fā)者共同承擔。通過這樣做，讓客戶在需求分析之前就盡量對他們所需要的功能有個整體的了解和確定的思路，而不是等到程序員開始編碼了，才提出以前原本在需求分析時就可以提出的需求。
　　讓客戶明白減少需求變更的重要性后，需求分析人員應該采取合適的方法同客戶交流，幫助他們明確他們的需求。需求分析人員和客戶的關(guān)系不應該僅僅是記錄人員和需求提供者，他們的關(guān)系應該更多的是戰(zhàn)略合作伙伴關(guān)系。雖然需求分析人員和客戶存在著服務商和顧客的關(guān)系，但是他們有著一個共同的目標：開發(fā)出適合客戶需求的軟件，因此需求分析人員除了記錄客戶提出的需求以外，還應和用戶討論，提出一些建議，使用合適的工具幫助客戶提出需求。在需求分析時，盡量多的召集需求研討會，邀請開發(fā)人員和客戶共同協(xié)商探討，在研討會上允許任意的提出需求，并將這些需求整理成檔后由客戶代表和需求分析人員共同商議可選的功能，這樣能夠盡量使得需求完備。在需求開發(fā)時，開發(fā)人員采用原型的方法啟發(fā)客戶思考功能需求也不失為一個好辦法。
　　雖然需求不可能是完備的、變更不可能沒有的，但是在項目開始設(shè)計時使得需求盡可能完備還是應該的，也是值得的，完備需求的過程也就相應的減少了因為需求不清楚而產(chǎn)生變更的幾率。
　　如何控制需求變更
　　按照現(xiàn)代項目管理的概念，一個項目的生命周期分為啟動、實施、收尾三個過程。需求變更的控制不應該只是項目實施過程考慮的事情，而是要分布在整個項目生命周期的全過程。為了將項目變更的影響降低到最小，就需要采用綜合變更控制方法。綜合變更控制主要內(nèi)容有找出影響項目變更的因素、判斷項目變更范圍是否已經(jīng)發(fā)生等。
　　進行綜合變更控制的主要依據(jù)是項目計劃、變更請求提供了項目執(zhí)行狀況信息的績效報告。為保證項目變更的規(guī)范和有效實施，通常項目實施組織會有以下幾種措施：
　?。?）項目啟動階段的變更預防
　　對于任何項目，變更都無可避免，也無從逃避，只能積極應對，這個應對應該是從項目啟動的需求分析階段就開始了。對一個需求分析做得很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟項目經(jīng)理扯皮的幌子就越少。如果需求沒做好，基準文件里的范圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。如果需求做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費。這個時候千萬不能手軟，這并非要刻意賺取客戶的錢財，而是不能讓客戶養(yǎng)成經(jīng)常變更的習慣，否則后患無窮。相對于需求來說，什么WBS、風險管理、計劃進度都是次要的，只要需求做好了就會一帆風順。
　?。?）項目實施階段的需求變更
　　成功項目和失敗項目的區(qū)別就在于項目的整個過程是否是可控的。項目經(jīng)理應該樹立一個理念——“需求變更是必然的、可控的、有益的”。項目實施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件?？刂菩枨鬂u變需要注意以下幾點：
　　需求一定要

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html