"我們決定下個月28號進行驗收"，客戶很輕鬆地在不經意之間和我說了這句讓我朝思暮想的話，這句話使歷時三個月的驗收日期終於定下來了。回顧這三個月，我可是費了不少心力。日期雖然定了，但是和合同規定的日期足足晚了三個月。
我所負責的這個軟件開發項目開始做得還算比較順利，測試工作也早早已經完成。但客戶遲遲不肯驗收，原因是客戶卡在一個小問題上，說此問題查清後再驗收。這個小問題在大多數情況下是不會出現的，只有在特殊的操作下才會出現。由於一直無法找到重現此Bug的規律，故這個小問題一直沒有很好的解決徹底，結果使到項目驗收一次又一次被擱置。再這麼拖下去，我真不知如何給公司交待了。
爲什麼客戶遲遲不肯進行驗收？
一般來說，當軟件開發項目到了具備驗收的各項條件之後，開發團隊就會着手準備驗收階段的工作。但如果這時發生客戶不願意驗收的話，這是一個讓開發團隊很頭痛和很普遍的問題。原因是多方面的，主要有如下幾種情況：
（1）開發團隊沒有擺正心態：這只是小問題嗎?
一個軟件項目完成測試和修正後，但卡在一個小問題上客戶不肯驗收，這就是平時我們經常說的"小問題，大學問"。也許，許多開發人員不明白：不就是一個小小的問題嗎？爲什麼要小題大作？實際上這樣的想法是因爲許多開發團隊只會站在自我利益爲第一位。因此，當出現有小問題時，認爲多一事不如少一事，主要需求和功能能完成就行了。
因此，作爲開發團隊要擺正自己的位置和心態，不是說只要完成了合同中規定的內容，完成了合同書規定的工作，並且按合同測試了就可以驗收了。表面上看是客戶僅僅由於他們發現的一些小小的BUG，小題大作不肯驗收。實際上，當客戶不同意在此時驗收時，他們的判斷往往不是招標書、合同、技術協議、需求規格說明書等文檔。而是開發團隊不能給客戶足夠的信心，客戶不滿意開發團隊對BUG的處理態度，客戶認爲這不是小問題,所以不肯驗收。
（2）沒有抓住領導意圖，客戶滿意度不夠
我們在軟件開發驗收過程中得到很多的經驗教訓，最常見的問題是在開發過程中沒有抓住客戶的關鍵負責人或重要領導的意圖，沒有了解客戶看重的是什麼。而等到開發團隊提出要驗收的時候，客戶又總是覺得這也不滿意那也不滿意，總之是不願意驗收。主要原因是開發過程中與客戶的關係沒有提升，沒有使客戶真正的滿意。例如，對客戶反饋問題時服務不到位，當要求客戶驗收時纔再發現問題仍未得到及時解決，就會讓客戶心存擔憂，或讓客戶失去信任。
（3）開發流程不規範，驗收標準沒有達成一致
在項目開始的時候沒有和客戶在驗收標準達成一致,導致客戶總是拿項目的小問題說事。實際上，驗收標準是很重要的，這需要與客戶進行詳細的溝通，明確驗收前需要完成的工作。驗收標準中不光要有需要完成的工作內容和任務，還需要有一個相對固定的工期，使雙方都能朝着這個方向去努力，防止無限制的拖延。
（4）沒有處理好問題跟蹤記錄
由於許多開發合同上規定的只是一個大概的框架，再加上在開發之前沒有與用戶進行比較具體的交流和討論，沒有清晰的瞭解清楚客戶心目中的產品究竟是什麼樣子。結果是雙方對需求都有不同的理解，例如某些需求並不是客戶真正想要的，而很多潛在的需求在項目初期卻沒有提出來。再由於在開發過程中，沒有寫好備忘錄和問題跟蹤記錄，時間一長，雙方也就忘記了很多承諾和約定，到了驗收的時候就可能重新翻出來。這種事情是最讓開發團隊頭痛的，明明說可以先不做的內容最終驗收的時候又成了必要條件。這樣最後要驗收時，大家就非常容易卡在一些理解差異的問題上了。
（5）客戶因資金原因推遲驗收
有時，客戶遲遲不肯驗收或故意推遲驗收，有可能客戶是以推遲驗收而推遲結算和要支付的款項。對於有這種想法的客戶是最讓開發團隊爲難的了。動用法律吧，擔心破壞了長久建立的關係；不動用法律吧，還真有這麼不客氣的客戶。
什麼是軟件開發項目驗收？
（1）什麼是軟件開發驗收？
項目驗收，也稱範圍覈實或移交。它是覈查項目計劃規定範圍內各項工作或活動是否已經全部完成，可交付成果是否令人滿意，並將覈查結果記錄在驗收文件中的一系列活動。軟件開發項目驗收是每個開發團隊乃至每個開發人員都想要的結果，因爲一旦驗收通過就可以收驗收結算款了，項目也可以告一段落。驗收作爲開發項目的最後一個環節，不但是對軟件開發質量和軟件的可交付性起到"一錘定音"的作用，而且它關係到開發團隊能否收到結算款和實現利潤的標誌之一。
（2）項目驗收的標準和要點
項目驗收看似簡單，但在操作上卻是極其複雜和重要的工作，因爲項目驗收無固定統一的標準。一般來說，項目驗收的標準包括：項目合同書、國際慣例、國際標準、行業標準、國家和企業的相關政策、法規。因此，開發團隊對項目驗收的標準情況瞭解越多，後期項目驗收的難度和風險就越小。因此，細讀項目驗收的標準例如合同書是第一步，必須要先弄清楚這個是什麼項目，項目合同中有那些客戶關注的問題。這樣才能在驗收前，有針對性準備好項目驗收工作。
在項目驗收的時候，對於項目中可能存在的一些問題，不要讓客戶想等系統沒有一點問題或保證以後沒有問題的情況下才驗收。如果客戶這樣想開發團隊就麻煩了，微軟那麼牛，做的操作系統還天天打補丁。開發團隊要讓客戶明白，所謂驗收，就是依照合同需求和能夠滿足企業的需求，結果和預期結果一致就應該算通過了，而且還容許有一些小錯誤留在驗收後改正。
一般來說，現場長時間驗收檢查不太可行。因此，在驗收前準備階段，項目負責人應主動、積極的與客戶密切溝通，及時、準確地收集和理解驗收條件。特別是客戶對即將驗收項目的真實、初步意見和評價，最好是在驗收前就溝通好和形成書面正式的《項目評價報告》。如還留有一些可能影響或暫時不影響項目整體驗收通過的細節、小問題、變更或異議、分歧等，應與客戶協商解決處理好，做到事先溝通、達成共識。強調已經基本上完成項目內容，滿足合同要求。
如何順利地讓客戶進入驗收狀態？
如何才能順利地讓客戶進行驗收是一直困撓開發團隊的一個難題，爲了避免項目驗收遙遙無期的局面，建議加強以下幾方面工作。
（1）及時解決問題，端正處理BUG的態度
既然發現軟件存在問題，就應該盡力去解決，這是開發團隊的責任。客戶不肯驗收，主要是害怕承擔責任，畢竟還有問題沒有解決嘛。如果換做我，我也不會給你驗收的。因此，要想讓客戶方驗收,首先要做好合同的明確規定和服務承諾。並以此爲依據，讓客戶放心,讓客戶方驗收。在開發過程中給客戶感覺是不是用心的做事是很重要的，否則的話後期驗收就會有點困難了。
在項目過程中，需要注意平時承諾的積累，比如要做到講誠信、講原則。主要是三條：做不到的事情千萬別隨意承諾、承諾的事情一定要努力做到、每次做到的事情都要進步一點點。按這三條做事，即使在與與客戶溝通中有這樣或那樣的不愉快和矛盾，客戶也會慢慢接受，也會用更多積極性眼光看存在的BUG問題。當然，項目中如果有關鍵瑕疵，也是客戶忌諱的，開發團隊一定要理解這些瑕疵並解決好。
（2）平衡和識別項目干係人需求
在項目驗收階段前,要儘量識別和關注所有項目干係人的需求和態度，並時刻給客戶灌輸只要完成那幾項工作就代表項目可以驗收了。當客戶不肯驗收時，要與客戶展開深入的交流，明確客戶爲什麼不願意驗收。有時客戶的問題只是藉口，所以要根據客戶的表現判斷出這個背後的問題所在。當找到問題後，協調相關的資源來解決。有時和客戶直接把問題攤開溝通，或許是比較好的解決方法。
總之，開發團隊應要對項目利害關係者進行關注，和關注他們關注的內容，或者他們擔憂的內容。作爲開發團隊要做到儘量做好所能控制的事情，另外一些很難由開發團隊控制的事情則需要借用一些其它的力量去完成。比如關注項目利害關係者的一些祕密需求是否得到了滿足，或請高層領導運用一些商業手段來促成項目的驗收等。
（3）重視階段性成果驗收，提高客戶感知度
其實，軟件開發項目驗收遠非是僅僅對系統的測試和檢驗這樣簡單，它是開發團隊和客戶在開發過程中雙方合作博弈的結果。因此，在項目開發過程之中，與客戶的溝通和績效彙報是非常重要的。客戶之所以遲遲不驗收項目，簡單的說是因爲客戶對開發團隊做的項目不滿意。
一般來說，滿意=感知-期望。因此，客戶不滿意是因爲客戶的感知度非常低，而期望很高。換句話說，是由於開發團隊對項目需求沒有定義好，或者沒有分析好，或在定義需求的時候沒有考慮到客戶的感知和期望，導致現在的項目驗收困難。所以，一方面量化和降低客戶的期望值，另一方面儘量提高客戶的感知度是非常重要的。方法可以是對於每一個階段性的成果，儘量讓客戶可以參與並且驗收，目的是爲了儘可能來提高客戶的感知度。
（4）清晰處理好客戶反饋問題的跟蹤狀態
在一個項目開發週期中，每次客戶的反饋問題都需要認真做好跟蹤記錄。下次工作要根據前次備忘錄的雙方約定或客戶的反饋問題繼續進行，保障項目在雙溝通的基礎上不斷前進，並用備忘錄約束雙方的行爲。
建議在收集項目出現的各種問題時，採用問題跟蹤記錄表的形式，這樣可以一目瞭然地顯示出曾經收集到的各種問題、目前的解決情況、以及還有什麼問題沒有解決，或準備什麼時候解決。這樣客戶和開發團隊就都會對目前的情況非常瞭解，通過不斷地解決出現的問題，來收斂可能出現的問題。當存在的問題越來越少時，也就表示項目開發已經在接近驗收的標準了，也可使客戶在需要驗收的時候不能再找各種各樣的藉口來拖延驗收。