做項目的時候，我們都有很好的計劃，也在不斷的強化風險承受力等等~~~ 但事實上，Devolpment完了，到了test和UAT的時候了，通常時間處于這個階段的時間都比計劃安排或者領(lǐng)導(dǎo)認為需要的時間要長的多。程序員一次又一次的收到bug report 和new changes。這里面new changes 當然是新添加的修改了，可以要客戶再算錢的，bug不是了。的程序員團隊的code中一般的range異常阿，null異常阿，分支阿，算法阿等等真正的技術(shù)bug是很少的。常見的，也難修改的是logic error和實現(xiàn)情況與真正需求不一致。

　　讓整個團隊懊惱的是實現(xiàn)和真正需求不一致的情況，程序員抱怨：需求文檔明明是這么寫的，我這么做是對的。需求分析人員則抱怨更多，我明明是這么寫的，怎么他們做成了那個樣子。靠蛻舢敵跏沁@么說的啊，怎么現(xiàn)在到測試了，他們說不是這個意思啊，都快變的面目全非了？.......

　　總結(jié)一下個人對于實現(xiàn)與需求不一致現(xiàn)象出現(xiàn)的原因：

　　1、需求文檔表述不明確，這個包含2個意思，一是需求條款含義模糊；二是需求信息不全面。這導(dǎo)致分析人員與設(shè)計人員理解出現(xiàn)較大偏差。而且，一般公司如果有專業(yè)的分析人員和職位，他們做完一個項目的分析后可能馬上接收下一個項目的需求了，這導(dǎo)致在開發(fā)中間需要需求再討論和澄清的時候，分析員可能自己都不能完全確定需求或者表示錯誤了。

　　2、需求挖掘不深，記錄的未能表達客戶真正需要的。這通常表現(xiàn)為將產(chǎn)品拿到客戶那里測試時，客戶沒看完幾眼，說：這個***怎么是這樣的？ 這個報表要加*** ........

　　3、分析人員未能引導(dǎo)客戶那邊決策人員與實際操作人員的需求統(tǒng)一。這表現(xiàn)為時常的，我們按照客戶項目負責人的表述完成了需求分析。后UAT的時候幾乎都是由實際的操作人員參入的，于是很多操作人員開始7嘴8舌的表述自己的要求 ？蛻舻捻椖控撠熑嗽谶@時候表現(xiàn)出極高的尊重下屬意見的素質(zhì)：這個是他們用的，當然他們都說是那樣，當然要改成那個樣子了，不然我買來干嘛~~~~ 云云

　　4、不斷的發(fā)現(xiàn)問題和小修小改，導(dǎo)致后如果要查詢一個部分的終詳細需求，可能需要參考n個相關(guān)文檔.人之常情，即使假設(shè)所有人都知道這些文檔并能獲得，那也不如去找一個人問，所以問下 程序經(jīng)理/分析人員/項目經(jīng)理，而對被改動過的需求，他們（被問者）是否都對修改了然于胸呢？算他/她很明確，他/她的表述力如何？

　　出現(xiàn)test和UAT不斷延期的狀況后影響是極大的，幾乎你見到的每個人都在抱怨.領(lǐng)導(dǎo)開始不滿，怎么拖了這么久阿，原計劃將人馬投入下一個項目的計劃不得不變更了.項目成本不斷增加，而項目的總訂單額倒不一定增加了多少.程序員開始在bug-fix的過程中情緒低落，因為項目拖的久了，修改的東西有沒有新意，而且對所有人都一樣的會催化情緒的是，要做的（實現(xiàn)的）變來變?nèi)?分析人員面對著壓力，但很多人會把責任推到程序員和客戶.項目經(jīng)理為倍受煎熬.一個現(xiàn)象也可能出現(xiàn)了： 加班，加班，再加班.....

　　那么我們應(yīng)該怎樣來減少這種事件的概率呢？這里列舉1，2所想：

　　1、需求表述一定要保留文字描述，不要以為使用了OOA和UML后不寫描述性需求了。

　　2、需求表述每項盡量簡短明確，意思單一，進出。

　　3、分析人員要保管好未整理前的需求調(diào)研材料。

　　4、分析人員對需求的理解盡量要達到與分析人員每一項都一樣，可以采用講解，復(fù)述，確認等手段。

　　5、分析人員好能在詳細設(shè)計文檔初步完成后和設(shè)計人員一起討論確認詳細設(shè)計。

　　6、保持紀錄和維護需求文檔.這一點非常重要。