談到驗收，相信很多實施同事都是一個頭兩個大，覺得項目最麻煩的工作莫過于此，盡量模糊化，規避正式的驗收。

客戶場景A：

我們要推廣的是8個公司，不是8個項目，你們都還沒做完，怎么就能驗收了呢？

客戶場景B：

我們試點上線以后又提出了一些優化需求，你們給我們處理完了，再給你們試點驗收吧？

客戶場景C：

這個驗收報告不能只是我簽字啊，還有我們試點項目的用戶和集團相關業務部門的老總都要簽字的，讓他們也看看評估下吧。

客戶場景D：

工作流你們前期調研了嗎，文檔都沒有啊，流程都沒有穩定固化下來，怎么就能驗收了呢？

客戶場景E：

沒錯，你們的工作是做完了，可是我們現在通過系統什么都還看不到，不好跟老板交代啊，怎么給你們驗收呢？

大家在看到上面幾個場景的時候是不是有種似曾相識的感覺？作為實施人員，我們是否需要好好的思考一下，為什么客戶驗收難？找到問題的原因后，才能在后續的工作中有效的改進規避，不再陷入項目驗收的泥沼。

1、項目目標及范圍不清晰：

項目一啟動就急忙開展了業務調研工作，對于項目的目標與范圍未能與客戶做清晰界定。實施過程中也沒有進行確認，導致后期雙方理解差異，產生爭議。這也是很多同事不關注不重視實施任務書的結果，直接模板套用，前期風險評估不足，任務書也就失去了其意義。

2、驗收標準明確時間過晚，對于客戶需求未建立有效評估處理機制：

有些項目到了試點上線之后甚至正式驗收之前，才與客戶明確驗收標準。殊不知驗收標準與客戶確認的時間越晚，對自身越加不利。很多工作都做完了，客戶的想法肯定是你要把我的所有需求和問題都解決了，才能給你驗收。上線之后冒出來的應用優化需求就作為了驗收標準談判的籌碼，尤其是在前期沒有跟客戶明確建立問題評估處理機制的前提下，大部分情況下，我們都只能被動接受客戶的要求。

3、驗收責任不明確：

有了驗收標準，可是找誰驗收不明確，要么就是找客戶項目經理，要么和項目相關的就全是責任人。前面在驗收標準里面只界定了驗收的范圍及方式方法，但對于驗收責任人沒有清晰界定，就容易出現正式驗收時相互推諉扯皮的情況。在藍圖方案階段，與客戶明確驗收標準時必須明確各類驗收工作的責任人，尤其是二次開發需求驗收，一定是本著誰提出誰驗收的原則。責權對等，一定程度上也可以規避減少部分優化需求。

4、項目成果文檔不齊備：

一個項目做下來，文檔沒幾份，很多工作都是通過口頭確認，到了驗收的時候口說無憑，驗收工作的推進自然也就不靠譜了。其實讓客戶養成實施過程工作文檔確認簽署的習慣，你的正式驗收也就成功了一大半，因為很多工作都已經階段性確認驗收過了，到最后的正式驗收只是一個水到渠成的工作。

5、客戶未看到應用價值，不滿意：

最關鍵的一點，售前階段是給客戶畫餅、提升期望值的階段。可是如果到了實施階段，如果客戶發現前期傳遞的價值什么都沒有兌現的話，肯定心里是不爽的，還會給你驗收嗎？當然，這里要說的不是要實施人員完全去兌現售前階段傳遞的價值藍圖。一方面信息化系統的成功實施，一定不是實施方單方面可以實現的，一定是IT+管理的結合，系統成功落地，客戶自身也是需要管理配套的。在這一點上，我們要做的就是勇于向客戶提出管理改善建議及應用落地保障要求。另一方面在實施階段我們解決的核心業務問題，展現核心應用價值，向客戶灌輸隨著系統深入應用及管理提升，價值分階段兌現的觀點，也可以給后續服務的應用提升埋下伏筆。在這一點上，我們要關注的是系統的應用價值展現與輸出，不能光有數據錄入，沒有輸出，那么客戶就會把系統定位成一個基礎數據錄入應用系統，而非一個管理平臺。

一家之言，歡迎大家拍磚，也希望實施同事對于驗收問題能有更加深入的思考與認識，并有效改進過程方法，以促進各自項目驗收順利推進。

總結

以上是生活随笔為你收集整理的浅谈软件项目验收（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。