作者 | 毕小烦
可以简单总结为四个要：既要，又要，还要，且要。
既要规避需求的常见问题，又要进行充分地评审，还要保证过程中的风险可控，且要进行度量和持续改进。
具体怎么做呢？
就是最开始我们讲的那 5 个字：防、评、控、量、改
我们先看防，怎么做好问题的预防。
主要是做到 5 个有：有原则、有规范、有流程、有分工、有标准。
有原则可以遵循，有规范可以参考，有流程可以跟着走，有分工大家各司其职，有标准能够衡量结果。
来具体看看。
团队共同制定一些需求相关的原则，让所有人在这套原则的指导下进行工作。
比如：
有了这些原则的指导，再来制定规范、流程和标准。
产品工作是要有规范可以参考的，要让所有人在进行需求相关的工作时，能有据可依，步调统一，减少例外的事情发生。
因此，要用产品规范来约束产品需求的编写、原型设计、视觉设计、交互设计和产品的实现。而开发和测试跟产品相关的规范，则体现在技术分析设计和测试用例的设计上，这是为了对需求的可行性和完整性查漏补缺。
产品规范都包括什么呢？
主要是需求规范、功能规范、原型规范、视觉规范、非功能需求、命名规范等，都是些通用的规则。
以需求评审为关键节点，我们把需求的流程分为三段：评审前、评审中、评审后。
评审前需要：产品立项（新项目）→ 产品内审 → 需求预审 → 审阅文档
评审中需要：认真且充分的评审需求
评审后需要：需求修订 → 评估工时 → Planning Meeting → 视觉评审 → 技术评审 → 用例评审
在 Planning Meeting 之后，本次迭代的需求就算确定了，这就建立了一个需求基线，后续所有的变更都要走需求变更流程。
需求阶段的流程如下所示：
整个需求阶段的流程大致就是：
项目经理组织 kick off，告诉大家要开始新项目了，讲讲背景，目标啥的，就相当于动员大会。 → 然后产品经理忙着写需求，先产品经理互审，内部达成一致 → 接着跟专家组讨论可行性 → 然后让项目组成员提前熟悉文档（以便评审时有针对性）→ 最后也是最重要的就是正式组会评审需求 → 之后回答&修订评审时记录的问题 → 提供 PRD 终稿 → 开发&测试分析估计 → Planning meeting 确定迭代内容和范围 → 视觉/技术/用例评审对需求进行查漏补缺。
所有角色都要有明确的分工，大家各司其职，要求是，把自己的工作做到最好；
要制定需求的准入准出标准，也就是质量卡点，来控制需求的质量。
需求评审准入的原则是：需求文档是完善的，价值是明确的，技术是可行的，拆分是合理的，风险是可控的。
需求评审准出的原则是：需求文档是经过评审的、最新的、完整的，无歧义的，是可以被拆成任务，可评估，可实现的。
具体标准（略）
虽然大家都知道为何要需求评审，但很多人被问到「为何要需求评审」时，还是说不清楚，因此，我们先谈谈需求评审的目的。
《软件需求》中说：一些公司每投入 1 小时审查需求文档，可以避免 10 个小时的劳动，1000% 的投资回报率，可不容小觑。
既然投入产出比这么高，那需求评审到底解决了什么问题呢？
① 做什么：需求评审让每个人都清楚地知道自己要做什么。
② 为什么：需求评审指明了团队努力的方向，信念一致才能义无反顾。
③ 要做对：需求评审澄清了需求的内容，是项目成败的关键。
④ 想清楚：需求评审让产品经理想得更清楚，减少无效投入。
⑤ 更完整：需求评审通过不同视角的多方审视，让需求更完整。
知道了需求评审的目的，我们再看评审的目标。
要让团队能够：
测试人员：
以什么样的形式进行需求评审呢？
最常见的也就三种形式：
这三种形式在不同的阶段进行，也就是评审前，评审中和评审后，审阅文档是对文档的静态检查，需求评审是对 PRD 的讨论澄清，三方评审通常是需求变更时的快速讨论。
评审策略
通用的清单可参考常见问题来制定。
比如：
控制风险主要是管理需求版本、状态和变更，这里主要看变更。
我们从共识、原因、要求、限制、流程、申请、评估、应对这 8 个方面来看。
1/8 共识
团队对于需求变更要有共识。
什么共识呢？
共识 1. 敏捷拥抱变化，但要有限制，要有流程（可以变更，但要控制）。需求变更不一定是坏事，事先将所有需求定义好几乎是不可能的。因为，技术在革新，世界在变化，出现新的市场机遇，政策法规变化以及业务需求过时等等。所以，一个高效的团队是能够灵活应对变化的。
共识 2. 变更总是有代价的， 这个代价团队要能接受。
2/8 原因
要分析引发需求变更的原因是什么？
比如：
3/8 要求
提出需求变更是有要求的，不能随便就提。
比如：
4/8 限制
需求变更是要有限制的。
比如：
5/8 流程
需求变更要有明确的变更流程，要能够以一致且有效的方式来处理需求变更。
比如，下面这个变更的基本流程：
6/8 申请
变更申请非常重要，通常会有一个「变更申请模板」来规范申请。
这个模板要能回答什么项目？谁？因为什么原因，在什么时候申请需求变更？谁开发？谁测试？有风险吗？如果有怎么应对？评估依据是什么？谁评审的？谁最终审核的？
所以对模板的要求，基本是：可评估 可追溯 可管理
7/8 评估
对变更影响的评估非常重要，它是审批者/干系人来判断是否同意变更的关键因素。
申请和评估的模板可参考下图：
8/8 应对
既然变更在所难免，那作为测试人员应该如何应对变更呢？
这里主要是应对工作量增加的问题，因为所有的风险、影响最终都会化为工作量。
分两种情况来考虑，面对增加的工作量。
1、如果交付日期不变，则可以考虑：
砍：砍掉优先级低的需求，来减少工作量。
加：增加人力或部分工作外包，来分摊工作量。
降：牺牲部分不重要的质量来保交付，比如只精测优先级高的需求，优先级低的风险低的可以让开发自测，或产品验收测试。
2、如果交付日期可变，这就简单了：
延：延长交付时间。
所以，请记住应对需求变更的四字真言：砍、加、降、延。
接下来我们看量，也就是度量需求相关的质量和效率，目的是为持续改进提供定性或定量的分析依据。
那，度量什么？
第 1 个，度量需求影响（也就是需求质量造成的结果），第 2 个是，度量需求本身（也就是源头），第 3 个，度量需求过程。
1. 度量需求影响（结果）
先看度量需求质量造成的影响，通过结果数据来反推源头和过程的问题。
为什么要从结果来反推呢？
因为通过问题来驱动改进，是最有效的方式。
比如：
2. 度量需求本身（源头）
这个可以参考前面讲的需求的问题进行度量，用户故事则可以参考 INVEST 原则进行度量。
3. 度量需求过程（过程）
要跟踪需求的整个流转过程（全生命周期），监控需求的流转过程和状态，记录过程中的数据，比如：需求问题的类型，需求相关的耗时等，以便分析影响，还有后续的统计分析。
基本路径是：记录 -> 归类 -> 统计 -> 分析 -> 改进
接下来我们看看如何改进。
关于持续改进，我们从改进的目标、原则、路线和方法来讲。
首先
改进的目标肯定是降本增效。
比如：
减少因需求错误而导致的返工：
减少开发过程中澄清需求所花的时间：
对于选择哪些指标，我们可以遵循一种简单的思考方式：目标 - 问题 - 指标（GQM：Goal-Question-Metric），首先写出改进目标，然后判断团队达成目标必须解决的问题是什么，最后，确定能够为每个问题提供答案的指标。
这些指标能够作为关键绩效指标。
比如：
然后
过程改进的原则：
开始前，一定要制定需求过程改进的路线图。
先列出要改进的事项，确定里程碑，然后给每个里程碑安排负责人，再要求负责人写行动计划，最后把这个计划落实到行动上。
可以用 OKR 来制定，然后用甘特图可视化展示。
改进的方法很重要，这里推荐两种方法：
方法 1. 用根因分析法找出根因
比较常用的是 5WHY 分析法，打破沙锅问到底，然后使用鱼骨图展现根因分析的结果。
方法 2. 用过程改进循环持续改进
如何能提高效率呢？
这里有个基本的节奏：
一图胜千言
最后，
需求质量的改进无法立竿见影，要项目组所有人所有角色参与其中，不断的度量、纠偏、反思和改进才行。
