前言

说完了在 项目开发阶段 我的一些个人体会和经验总结，最后我们聊聊在 项目验收阶段 我们需要关注哪些方面的内容……

项目验收阶段

系统开发告一段落后，就进入客户培训、系统验收阶段，这个阶段，我一般会注意以下几个问题：

1. 给客户做培训前，多注意一些表面功夫

大多数客户其实并不太关心功能内部是如何实现的，他们一般比较重视产品的功能是否完整可用，外观是否美观 大气等等，但在绝大多数技术人员心中，恰好是相反的，系统的逻辑核心是否正确才是关键，至于界面如何，界面上的用词是否准确，他们是觉得那是无关紧要的问题，而且在培训的时候也是信手拈来，想到哪里说到哪里，下面听讲的人不知所云，云山雾罩，培训效果自然可以想象。

我的体会是，给客户做培训的版本，一定要在界面上多花一点功夫，注意每个界面的布局、用词、链接的正确性等等。在培训的时候，每个功能的先后顺序和讲解内容，一定要事先排练，如果你在做多次测试以后仍然不能确定逻辑是否合乎要求的功能可以少讲一些，总之不要让客户看到一些他不该看到的东西。

另外，你最好对项目产品的整体架构设计了然于胸，通常客户高层领导对这个比较感兴趣，如果一旦被问到，回答的时候如果犹豫不决磕磕碰碰地就比较尴尬了。

2. 文档准备要齐全

首先至少要有两个文档：用户手册和培训手册。

这两个文档的内容很多都是一致的，但是角度完全不同。

用户手册往往是站在系统设计者的角度，按照自己的思路，分模块讲解系统的操作和功能；

而培训手册，一定要站在客户业务人员的角度，根据每个角色面对不同业务的办理，如何通过使用本系统的一系列功能来实现目标。

所以，第一次培训以前，系统界面是否完整正确、培训文档是否完备都是很关键的因素，第一炮打不响，以后就麻烦很多。

除了这两个文档之外，系统整体架构、系统整体设计方案，系统测试报告等文档最好也备上，有些客户比较认真，可能会要求提供这些文档。如果有条件，这些文档最好都按照国标或者通用标准进行编写，曾经在一次项目验收报告会上，客户方的专家一开始就要求要看这些文档，还好当时都带了，要不就很尴尬了。

3. 规范验收标准和流程

在制定项目管理计划的时候，千万不要忘记要针对项目的验收做相关的规划，并设置阶段检查点。比如项目的验收标准，验收清单，验收决策人，验收的开始时间，验收必须什么时候结束等事宜。

我对验收最大的体会就是举证问题，即千万不要让客户这么想：你必须有证据证明你的系统是没问题的。这样你就没戏了，微软那么多天才，做个 XP 还天天打补丁，要你的程序没问题，既不可能，你也没办法拿出证据。你要让客户明白，认为系统完美了才能验收的想法是错误的，所谓验收，就是我按照测试文档的测试用例跑一遍，结果和预期结果一致就应该算通过了，而且还容许有一些小错误留在验收后改正，他可以对测试用例提意见。所以，验收前双方要确认测试计划和测试用例，如果他认为系统不符合要求，那么他应该举证，证明这个系统和最初设计相背离的。所以，参考法律概念，千万不要举证倒置。

4. 打消客户的后顾之忧

有时候项目顺利交付上线，运行平稳，并没有什么纰漏，但当你提验收的时候，对方给你提出非常严格的验收标准，要求项目每个过程文档都要提供，缺少了文档无法开始验收流程；或者每次催客户签验收报告时，就拿项目的缺陷或小部分没被满足的需求来说事，拒绝验收。这些客户之所以常常拖延验收，有很大一部分其心理主要还是怕一旦签署验收报告了，万一后面还有问题找不到人来维护，所以最好在软件开发合同里注明验收以后维护期等问题，给客户吃一颗定心丸，这样客户在签署验收报告时就会比较爽快了。当然，也有一些客户迟迟不签署验收报告，是因为客户目前的资金周转有问题，所以希望能晚一天算一天，这就只能具体情况具体解决了，或延长款项交付期限，或适当让步，主动减少一些费用换取客户快速付款等等。

写在最后

作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。

全文完