前言

說完了在 項目開發階段 我的一些個人體會和經驗總結，最後我們聊聊在 項目驗收階段 我們需要關註哪些方面的內容……

項目驗收階段

系統開發告一段落後，就進入客戶培訓、系統驗收階段，這個階段，我一般會註意以下幾個問題：

1. 給客戶做培訓前，多註意一些錶面功夫

大多數客戶其實並不太關心功能內部是如何實現的，他們一般比較重視產品的功能是否完整可用，外觀是否美觀 大氣等等，但在絕大多數技術人員心中，恰好是相反的，系統的邏輯核心是否正確才是關鍵，至於界面如何，界面上的用詞是否準確，他們是覺得那是無關緊要的問題，而且在培訓的時候也是信手拈來，想到哪裡說到哪裡，下麵聽講的人不知所云，雲山霧罩，培訓效果自然可以想象。

我的體會是，給客戶做培訓的版本，一定要在界面上多花一點功夫，註意每個界面的佈局、用詞、鏈接的正確性等等。在培訓的時候，每個功能的先後順序和講解內容，一定要事先排練，如果你在做多次測試以後仍然不能確定邏輯是否合乎要求的功能可以少講一些，總之不要讓客戶看到一些他不該看到的東西。

另外，你最好對項目產品的整體架構設計瞭然於胸，通常客戶高層領導對這個比較感興趣，如果一旦被問到，回答的時候如果猶豫不決磕磕碰碰地就比較尷尬了。

2. 文檔準備要齊全

首先至少要有兩個文檔：用戶手冊和培訓手冊。

這兩個文檔的內容很多都是一致的，但是角度完全不同。

用戶手冊往往是站在系統設計者的角度，按照自己的思路，分模塊講解系統的操作和功能；

而培訓手冊，一定要站在客戶業務人員的角度，根據每個角色面對不同業務的辦理，如何通過使用本系統的一系列功能來實現目標。

所以，第一次培訓以前，系統界面是否完整正確、培訓文檔是否完備都是很關鍵的因素，第一炮打不響，以後就麻煩很多。

除了這兩個文檔之外，系統整體架構、系統整體設計方案，系統測試報告等文檔最好也備上，有些客戶比較認真，可能會要求提供這些文檔。如果有條件，這些文檔最好都按照國標或者通用標準進行編寫，曾經在一次項目驗收報告會上，客戶方的專家一開始就要求要看這些文檔，還好當時都帶了，要不就很尷尬了。

3. 規範驗收標準和流程

在制定項目管理計劃的時候，千萬不要忘記要針對項目的驗收做相關的規劃，並設置階段檢查點。比如項目的驗收標準，驗收清單，驗收決策人，驗收的開始時間，驗收必須什麼時候結束等事宜。

我對驗收最大的體會就是舉證問題，即千萬不要讓客戶這麼想：你必須有證據證明你的系統是沒問題的。這樣你就沒戲了，微軟那麼多天才，做個 XP 還天天打補丁，要你的程式沒問題，既不可能，你也沒辦法拿出證據。你要讓客戶明白，認為系統完美了才能驗收的想法是錯誤的，所謂驗收，就是我按照測試文檔的測試用例跑一遍，結果和預期結果一致就應該算通過了，而且還容許有一些小錯誤留在驗收後改正，他可以對測試用例提意見。所以，驗收前雙方要確認測試計劃和測試用例，如果他認為系統不符合要求，那麼他應該舉證，證明這個系統和最初設計相背離的。所以，參考法律概念，千萬不要舉證倒置。

4. 打消客戶的後顧之憂

有時候項目順利交付上線，運行平穩，並沒有什麼紕漏，但當你提驗收的時候，對方給你提出非常嚴格的驗收標準，要求項目每個過程文檔都要提供，缺少了文檔無法開始驗收流程；或者每次催客戶簽驗收報告時，就拿項目的缺陷或小部分沒被滿足的需求來說事，拒絕驗收。這些客戶之所以常常拖延驗收，有很大一部分其心理主要還是怕一旦簽署驗收報告了，萬一後面還有問題找不到人來維護，所以最好在軟體開發合同里註明驗收以後維護期等問題，給客戶吃一顆定心丸，這樣客戶在簽署驗收報告時就會比較爽快了。當然，也有一些客戶遲遲不簽署驗收報告，是因為客戶目前的資金周轉有問題，所以希望能晚一天算一天，這就只能具體情況具體解決了，或延長款項交付期限，或適當讓步，主動減少一些費用換取客戶快速付款等等。

寫在最後

作為項目經理，其實腦子裡就是幾樣東西：做哪些事情、做到什麼程度、怎麼交貨、手上的資源以及各個事情的優先順序。所謂多快好省那是人類的夢想，這四個方面都是相互矛盾的，屬於典型的又要馬兒跑，又要馬兒不吃草的類型。考慮問題的輕重緩急方面，往往是把快放在第一位，各方領導都會給你最後期限，所以保進度是第一位的；省是第二位的，企業的根本目的是盈利，如果收入不能增加的話，至少費用要控制住；好是第三位的，沒辦法，誰都想精益求精，但是，沒有強大的資源保障，質量只好先犧牲了；最後是多，客戶的要求源源不斷，如何降低客戶的期望值，讓他們從理想回到現實也是項目經理的分內工作。

全文完