解分歧
　　當客戶向需求分析人員提出需求的時候往往是通過自己的想法用自然語言來表達的，這樣的表達結(jié)果對于真實的需求來說是一種描述（甚至只是某個角度的描述），遠遠不能保證這樣的描述可以得到百分之百的正確理解，也許在同客戶交流的第一時刻就埋下了理解分歧的種子，打一個比方說客戶說我要的是大象，身子象一堵墻，耳朵象扇子，四條腿象四根柱子，尾巴象繩子，分析人員想，哦，墻、扇子、柱子、繩子這些我都知道，但是真的畫出來的時候客戶當然會跳起來了！這是理解分歧的問題，一般跟分析員的知識、背景，還有客戶表述的標準程度、雙方的交流情況有關(guān)。
　?。?）系統(tǒng)實施時間過長
　　一個大中型系統(tǒng)的建設(shè)可能要延續(xù)一段時間，當客戶提出要求之后，他當時并不能看到系統(tǒng)的運行情況，當雙方認為理解大概沒有分歧的時候（事實上還會有個Deadline ），開發(fā)方就開始工作了。當客戶拿到差不多可以試用的產(chǎn)品時他可以實際操作，這時候他就會對系統(tǒng)的界面、操作、功能、性能等有一些切身的體會，有可能提出需求變更要求。

3、用戶業(yè)務需求改變
　　當前客戶的運營情況不確定，有可能客戶行業(yè)的競爭度高，需要隨時作出調(diào)整和反應，那么他們自然會經(jīng)常提出需求變更的要求；也有可能客戶所在的行業(yè)操作不規(guī)范，本身存在很多人為因素，這時候開發(fā)方更是需要隨時準備應變。
　　4、系統(tǒng)正常升級
　　有可能是來自開發(fā)方自身版本升級或性能改進、設(shè)計修正的要求出現(xiàn)需求變更，這時更是無法繞開這個問題的了！
　　所以說就算分析人員和客戶之間不存在理解分歧，客戶對于實際的系統(tǒng)還是會提出一些個人意見，就算沒有個人意見，他們自己的業(yè)務會變化或環(huán)境發(fā)生變化，這些都是無法避免的，所以不要夢想那么理想的需求分析，當你開始一個項目的時候就應該意識到，客戶需求變更一定會有的，那么對于這樣的現(xiàn)狀，我們該怎么辦呢？客戶是上帝，難道我們就象以前一樣，跟著客戶的需求不停地修改軟件，到最后工期延長，員工疲憊，成本成倍增長，客戶滿意度降低，原來的設(shè)計也會改變得支離破碎，系統(tǒng)難以維護？ 進行綜合變更控制的主要依據(jù)是項目計劃、變更請求提供了項目執(zhí)行狀況信息的績效報告。為保證項目變更的規(guī)范和有效實施，通常項目實施組織會有以下幾種措施：  
　?。?）項目啟動階段的變更預防
　　對于任何項目，變更都無可避免，也無從逃避，只能積極應對，這個應對應該是從項目啟動的需求分析階段就開始了。對一個需求分析做得很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟項目經(jīng)理扯皮的幌子就越少。如果需求沒做好，基準文件里的范圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。如果需求做得好，文檔清晰且又有客戶簽字，那么后期客戶提出的變更就超出了合同范圍，需要另外收費。這個時候千萬不能手軟，這并非要刻意賺取客戶的錢財，而是不能讓客戶養(yǎng)成經(jīng)常變更的習慣，否則后患無窮。相對于需求來說，什么WBS、風險管理、計劃進度都是次要的，只要需求做好了就會一帆風順。
　?。?）項目實施階段的需求變更
　　成功項目和失敗項目的區(qū)別就在于項目的整個過程是否是可控的。項目經(jīng)理應該樹立一個理念——“需求變更是必然的、可控的、有益的”。項目實施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件?？刂菩枨鬂u變需要注意以下幾點：
　　需求一定要與投入有聯(lián)系，如果需求變更的成本由開發(fā)方來承擔，則項目需求的變更就成為必然了。所以，在項目的開始，無論是開發(fā)方還是出資方都要明確這一條：需求變，軟件開發(fā)的投入也要變。需求的變更要經(jīng)過出資者的認可，這樣才會對需求的變

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

    http://m.vanceur.cn/pmqhd/index.html