《人人都是产品经理》读书笔记13：需求文档3（评审）

今天是3.3节的结尾啦，主要是各种文档写完之后的各方评审，目的是为了保证产品的质量。

---

项目中的需求阶段，通常会围绕着“写作→评审→修改→评审”循环展开。往简单了说，评审就是项目中相关的几个小团队坐在一起，一方讲，另外几方听并确认，统一认识，消除误解，及时发现偏差，防止问题随时间放大。不做评审，当时看似省了时间，但往往隐藏了问题，待到其爆发的时候会耽误更多事，而且会在谁负责的问题上纠缠不清。与其亡羊补牢不如尽早在流程上预防，所谓“防病优于治病”。

作者经历的项目中，最重要的三种角色就是PD、开发人员、测试人员，所以派生出三次评审——需求评审、设计评审、测试评审，它们按照项目阶段依次为：

需求评审

是PRD评审、UC评审、Demo评审的统称。于需求的相应部分完成以后进行，评审会上PD把PRD和UC说给开发、测试听，Demo评审则由UE的同学主讲。

一般会在做出比较大粒度的PRD之后马上安排一次评审，当然也会有UC和Demo的半成品，以期尽早发现问题，比如业务规则的不合理，产品界面太丑陋，某功能技术上无法实现等等。PRD评审会重点关注偏商业的内容，强烈建议叫上老板、营销人员、服务人员，甚至用户一起来听。

PRD通过以后，PD们会和UE的同学一起细化UC和Demo，而开发的同学也会同步进行一些开发前的准备工作，比如细化和修正项目计划，部分系统的设计，等等。接下来的Demo评审，决定了产品的外观，项目干系人最好都来把一下关，而UC评审更偏重技术实现，商业团队的成员可以选择参加。

需求评审的过程如下图所示，当然，实际操作中没这么复杂，简化的方法作者后面会有描述，到时候再分享。

需求阶段的工作内容

设计评审

在概要设计与详细设计完成之后进行，由开发工程师把对需求的理解以设计文档的形式说给PD、测试听。

测试评审

俗称TC评审，在TC编写完成，测试开始执行之前进行，由测试工程师把对需求的理解以TC的形式说给PD、开发听。

每一种评审都可能有多轮，会上没问题就快速地通过，有小问题当场确认，大问题带回去，原则是“改动较多的话必须再次评审，异议不大可以通过”。评审会议的组织者，可以考虑都由QA（quality assurance，质量保证人员）担任，作为项目过程管理的一部分，也可以考虑由每次评审的主讲人发起。

需求评审会的组织过程中，特别要注意两种容易漏掉的参与者，大家可以扩展应用到各种评审会上：一是能做决定的人，因为评审的时候各方不可避免地会对需求有不同理解，从而出现争论，而很多问题都是“公说公有理，婆说婆有理”，谁也说服不了谁，这时候就需要有人能拍板，有人能负责；二是与此项目有关的产品接口人，他的参与可避免太晚发现与其他系统有冲突，修改起来措手不及。

再看需求的生老病死

第2.5节里聊过“一个需求的生老病死”，当时是从某个需求本身的状态变化来看的，现在我们把它融入项目，再次审视。下图是一个简化版的项目流程，也是一个需求从提出到发布的流水账，对于小型团队应该比较实用。

日常需求发布流程

除纯技术项目外，PD是产品不断改进的源动力，所以项目前期PD主导的环节比较多，而一个需求就在这些环节中生老病死了。作者用几个会议来概括，项目大小有不同，这里的会议可能是严格的会议室里一群人正襟危坐，也可能是两三个人围在电脑前的几分钟交流。

项目开始之前。在产品团队内部分析需求商业价值的需求讨论会、多个产品间的产品会议上，PD们带着自己的需求参与讨论，为开发和测试资源PK。人性的本能让每个人都极力地维护自己提出的需求，并设法反驳别人，当然出发点都是为了用户，最终也会达成一致。“活下来的”需求会确定需求负责人，状态变为“需求中”。

项目中的需求阶段。项目启动之后，PD就得抓紧时间完成需求的开发，不时召集需求评审会，大家一起讨论这样做有哪些问题。PD收集到意见反复修改需求，直至最后一次评审通过，需求得以确认，状态变为“开发中”。当然，之后的需求微调总是无法避免，但“需求冻结”的里程碑要求我们在这之后就不要轻易改动了。

项目中的需求阶段之后。进入开发之后，PD需要不断地和开发、测试人员确认各种细节。我们一直想在早期环节中考虑到所有的细节，以期减少这种费时费力的确认，但事实证明细节总是多到无法预计，有的甚至要发布后才被发现。在开发提交测试之后，PD需要在测试环境中代表产品的用户做功能验收，确认一下产品与自己的设计是否相符，顺便也可以发现一些可用性问题。当然如果能让真实用户来验收则更好，通常会组织一次功能评审会，让项目干系人来确认这些功能是不是大家想要的，如果有问题还可以补救。最后功能上线，Feature List中的相应需求改为“已发布”。

显然，需求发布之后仍然会有改动，可能是客户反馈了问题，或者自己想到了更好的解决方案。我们的做法是把它视为一个新的需求或当作一个Bug，重新进入流程。