最近做了一个活动：春节活动，从整个开发的过程来看，最初的需求和最后完成的实际需求，在一些地方是有变动的：
- 在微信中点击分享按钮，需要添加一个引导图，引导用户通过浏览器打开（开发人员开发时提出）。
- 如果用户使用微信打开拿去花广告业，用户在点击分享按钮的时候，应该唤起app（测试人员测试阶段提出）
- 用户在赏金互动页面分享的时候，可以以片+二维码的形式分享出去（产品在开发阶段时提出）
- 用户兑换赏金后，需要能够跳转到优惠券列表页查看优惠券（产品在开发阶段提出）
- 用户兑换赏金后，查看优惠券的功能应该改回“知道了”，不然用户没有回到活动页的途径了（UI设计人员在联调阶段提出）
需求变动是避免不了的，需求变化越早提出来，花费的时间成本就越少：
目前的开发流程，是很容易产生一些比较靠后的需求变更的：
之所以会有这些靠后的需求变更点，是因为产品、开发、测试在prd需求会议之后，对产品形态有着各种不同的认识：
因为不一样的视角和理解，在开发、联调、测试阶段产生了一些不同的意见，要么发现了一个潜在的bug，要么提出了一个优化点，那些被产品经理认可接纳的，就变成了需求变更。
如果有办法能够将这些需求变更的大部分提前发现（比如在联调之前，或在开发之前），就能够一定程度的减少时间成本。
为了尽快的消除这些理解上的偏差，有必要在prd联调之前，进行一次理解上的统一，具体可以以评审checkList测试点的方式，开发、测试、产品逐个对checkList文档中的测试点进行评审，各方提出异议，产生修改点或者补充点，最终形成比较一致的需求理解：
评审最终会产生一个比较全面的checkList，有了这个checkList文档后，各方的收益是：
- 对于开发人员来说，不仅知道要开发哪些功能，而且知道功能当中的一些细节，这些细节往往是测试和产品知道的，但是是开发未想到的。
- 对于产品来说，很多潜在的需求缺陷以及优化点通过讨论被及时的发现，不会等到测试或者上线后才被发现。
- 对于测试人员来说，在checkList评审阶段就可以根据自己的经验将自己的一些看法提出来，避免了测试阶段在发生一些需求变更。
另外的一个好处是，通过checkList，开发、测试的想法会部分融入到产品中，开发和测试更具有参与感，也更容易激发人员的创新能力。
