防患于未然

软件项目工程中，一直以来我们习惯于在项目阶段性目标完成或整体目标完成时进行验收，这也是瀑布式开发中的过程管控方法。但随着 2000 年后敏捷方法的推广，IT 精英们对于验收提出了新的解释。

验收一定要在所有产品功能开发完成后才能进行吗，验收一定要在最后交付时进行吗？验收的目的是什么？

下面结合自己的一些项目经验，谈一点浅见拙识。

有分析报告说，2000 年以后没有简单的 IT 项目，因为市场变化加快，用户需求多样化，从而对于产品交付速度和交付频率提出了很高要求。我个人觉得任何 IT 项目都不能用简单来定义，因为产品和项目都有进化属性，再简单的产品或项目也可能随着市场的发展和用户需求的变化而演变为复杂项目。所以做任何 IT 项目我们都要保有敬畏之心，保持对于市场，用户和环境变化的审慎态度，尽最大力量确保我们做出来的产品或项目是市场需要，用户需要，是足以应对于时下环境变化挑战的。要做到这一层显然难之又难。现在我们尝试从产品或项目验收的视角来看看是否有办法可以帮助我们减少一些这言面的担忧，避免“Garbage in, Garbage out” 的尴尬。

对于验收，我个人有以下几点思考：

1.    什么时候进行验收最合适

 2.    验收的频率

 3.    验收的目的是什么

 4.    如何来做验收

首先，什么时候进行验收最合适。在敏捷开发领域里并没有对此给出明确说明，唯一提到是的在迭代结束前要进行演示验收，以收取客户反馈，避免需求遗漏或偏差。但在实际操作中，我觉得还可以再激进一点，验收可以天为单位来进行，当然前提条件是每天都有完整的端到端的功能交付，这个交付可以是很小的一个功能拆分，或一个独立的小功能。如果条件不允许，无法做到每天交付，至少也做到一旦有完整的功能拆分或功能点交付，就可以马上进行演示和验收。需要强调的是，演示或验收的是功能可用，质量达标的产品，而不是仅完成开发，没有通过测试的半成品。

其次，如果条件许可，要尽可能针对每次交付进行验收，并收集反馈。

那么为么要这么做呢，我们可以通过后两个问题来解答一下。项目验收是产品上线前非常重要的环节，很多重大问题需要我们在上线前做好把控。产品经理在上线前会投入很多的精力，确保按时保质地完成目标，在最后1公里失败，就非常可惜了。但这样验收往往无法解决以下几个问题：

1.    集中验收造成问题集中暴露，上线前压力剧增。

2.    验收时才发现需求不完整或出现遗漏，而团队却已没有太多调整余地。

3.    验收成了产品经理或项目经理一个人的事情，团队只是被动接受验结果，缺乏主动参与优化的动力和机会。

4.    容易造成产品经理和测试团队及开发团队的对立情绪，毕竟这个时候不是甩锅，就是背锅。

如果要解决以上四个问题，我们就需要弄清楚验收的全部目的，及验收的具体方式。验收不仅仅是为了保证质量和确保交付，它还有一个隐藏的目的 -- 验证需求。通过验收来证实需求是否正确，是否满足市场，满足用户。而我们前所鼓励的尽早验收和频繁验收正是为了把验证需求这个环节尽可能提前，进而及时收获用户反馈，修正偏差和弥补疏漏。这样一来我们要以通过提前暴露问题，小幅微调，减少更大的返工风险，也可以为团队争取更多缓冲，避免将压力集中到上线前最后一分钟。故每天验证一点点，问题解决一点点，分摊风险，平均压力，有利于团队保证开发质量，确保按照正确的需求，产出正确的产品。

再则，鼓励团队（主要指开发）一同参与验收，和产品经理一起验收，甚至主动承担产品演示任务向产品经理演示交付功能。这样通过视角转换，有利团队更好的验证实际交付和需求的匹配度，并潜意识激发团队的优化改进欲望，刺激团队主动参与到产品的优化过程中。如果在整个开发过程中，开发团队完全按照原始需求工作，而没有提一点更好的建议或主张，我们至少可以基本认定这个产品不算太成功，因为产品方案中完全没有看到团队的参与和贡献。

产品验收前置，对于验证需求，优化需求，细化需求可以起到很好的作用，所谓防患于未然也就是这个意思。