作者 | 毕小烦

如何保障需求质量呢？

可以简单总结为四个要：既要，又要，还要，且要。

既要规避需求的常见问题，又要进行充分地评审，还要保证过程中的风险可控，且要进行度量和持续改进。

具体怎么做呢？
就是最开始我们讲的那 5 个字：防、评、控、量、改

• 防，是问题预防，这个很好理解，就是预防问题的发生。
• 评，就是需求评审，主要是进行审核文档和需求评审。
• 控，是控制风险，要做的就是需求管理，控制需求变更。
• 量，是指需求工程的质效度量，全程记录，统计分析。
• 改，是持续改进，用度量结果辅助持续改进。

1 防：问题预防

我们先看防，怎么做好问题的预防。
主要是做到 5 个有：有原则、有规范、有流程、有分工、有标准。
有原则可以遵循，有规范可以参考，有流程可以跟着走，有分工大家各司其职，有标准能够衡量结果。
来具体看看。

有原则

团队共同制定一些需求相关的原则，让所有人在这套原则的指导下进行工作。

比如：

• 原则 1：不要着急写需求，要先明确定义问题，找到问题的本质。
• 原则 2：要立即修复需求文档中的错误。
• 原则 3：要记录需求为什么被引入，知道了原始需求的动机，在遇到需求变更时才好确认是否可以安全地变更。
• 原则 4：要评审需求。
• 原则 5：要合理地组织需求，这有助于读者理解系统功能，也有助于需求编写者在需求变更时定位章节。
• 原则 6：要给需求排优先级，并非所有需求都是同样重要。
• 原则 7：需求的书写要简洁。 ...

有了这些原则的指导，再来制定规范、流程和标准。

有规范

产品工作是要有规范可以参考的，要让所有人在进行需求相关的工作时，能有据可依，步调统一，减少例外的事情发生。

因此，要用产品规范来约束产品需求的编写、原型设计、视觉设计、交互设计和产品的实现。而开发和测试跟产品相关的规范，则体现在技术分析设计和测试用例的设计上，这是为了对需求的可行性和完整性查漏补缺。

产品规范都包括什么呢？

主要是需求规范、功能规范、原型规范、视觉规范、非功能需求、命名规范等，都是些通用的规则。

有流程

以需求评审为关键节点，我们把需求的流程分为三段：评审前、评审中、评审后。

评审前需要：产品立项（新项目）→ 产品内审 → 需求预审 → 审阅文档
评审中需要：认真且充分的评审需求
评审后需要：需求修订 → 评估工时 → Planning Meeting → 视觉评审 → 技术评审 → 用例评审

在 Planning Meeting 之后，本次迭代的需求就算确定了，这就建立了一个需求基线，后续所有的变更都要走需求变更流程。

需求阶段的流程如下所示：

整个需求阶段的流程大致就是：

项目经理组织 kick off，告诉大家要开始新项目了，讲讲背景，目标啥的，就相当于动员大会。 → 然后产品经理忙着写需求，先产品经理互审，内部达成一致 → 接着跟专家组讨论可行性 → 然后让项目组成员提前熟悉文档（以便评审时有针对性）→ 最后也是最重要的就是正式组会评审需求 → 之后回答&修订评审时记录的问题 → 提供 PRD 终稿 → 开发&测试分析估计 → Planning meeting 确定迭代内容和范围 → 视觉/技术/用例评审对需求进行查漏补缺。

有分工

所有角色都要有明确的分工，大家各司其职，要求是，把自己的工作做到最好；

有标准

要制定需求的准入准出标准，也就是质量卡点，来控制需求的质量。

需求评审准入的原则是：需求文档是完善的，价值是明确的，技术是可行的，拆分是合理的，风险是可控的。

需求评审准出的原则是：需求文档是经过评审的、最新的、完整的，无歧义的，是可以被拆成任务，可评估，可实现的。

具体标准（略）

2 评：需求评审

评审目的

虽然大家都知道为何要需求评审，但很多人被问到「为何要需求评审」时，还是说不清楚，因此，我们先谈谈需求评审的目的。

《软件需求》中说：一些公司每投入 1 小时审查需求文档，可以避免 10 个小时的劳动，1000% 的投资回报率，可不容小觑。

既然投入产出比这么高，那需求评审到底解决了什么问题呢？

① 做什么：需求评审让每个人都清楚地知道自己要做什么。
② 为什么：需求评审指明了团队努力的方向，信念一致才能义无反顾。
③ 要做对：需求评审澄清了需求的内容，是项目成败的关键。
④ 想清楚：需求评审让产品经理想得更清楚，减少无效投入。
⑤ 更完整：需求评审通过不同视角的多方审视，让需求更完整。

评审目标

知道了需求评审的目的，我们再看评审的目标。

要让团队能够：

• 清楚背景：了解为什么要做；
• 认同价值：需求的价值能够被有效传递；
• 明确目标：需求要达成的业务目标是什么，最好能量化；
• 澄清问题：需求的内容、逻辑、影响；
• 清楚影响：需求对关联业务的影响，对用户可能造成的影响等；
• 去除冗余：测试和开发要给出初步可行性和工作量的评估，把不可行的、工作量超大的需求提前砍掉，节省交互和视觉设计的时间。（Planning 时会更细）
• 保障质量：确保产品需求合理、合规、合法；
• 关注体验：性能、易用性等；

测试人员：

• 要知道：谁主导？谁参与？分工是什么？依赖是什么？影响是什么？
• 要了解：需求的背景、价值、规划和目标；
• 要搞懂：需求的逻辑、功能和细节；
• 要关注：评审的流程、进度和结果；
• 要控制：需求文档的质量、级别分布和需求的变更；
• 要提出：产品质量方面的问题，包括性能、安全和体验；

评审形式

以什么样的形式进行需求评审呢？
最常见的也就三种形式：

• 审阅文档：产品经理提前 1 ~ 2 天，把 PRD 发给项目组成员，以便提前熟悉，带着问题参加评审；
• 需求评审：是指需求评审会，一般我们将需求评审就等同于需求评审会，产品经理组会，将项目组成员及跟此项目相关的人员叫在一起，通过产品经理的讲解来对需求进行系统性的评审；这种评审也叫正式评审，是保障需求质量最有效的手段。
• 三方评审：产品、开发、测试三方评审，一般用于需求变更的时候，要的，做的和测的人在一起把需求评了，在坐位上就行，站会也行。

这三种形式在不同的阶段进行，也就是评审前，评审中和评审后，审阅文档是对文档的静态检查，需求评审是对 PRD 的讨论澄清，三方评审通常是需求变更时的快速讨论。

评审策略

通用的清单可参考常见问题来制定。

比如：

• 需求是否有价值？
• 需求是否可测？
• 需求拆分的是否合理？
• 需求是否明确了优先级？分布是否合理？
• 是否需要性能测试？如果要，具体的性能指标是什么？
• 是否需要安全测试？
• 是否涉及埋点需求？
• 是否对其他业务（依赖你的业务）有影响？
• 是否对其他业务有依赖？依赖的服务是现成的，还是要同步开发同步开发的联调和上线时间确认了吗？
• 是否涉及数据迁移？
• 是否有降级开关？
• 是否涉及 AB 测试？
• ...

3 控：控制风险

控制风险主要是管理需求版本、状态和变更，这里主要看变更。

我们从共识、原因、要求、限制、流程、申请、评估、应对这 8 个方面来看。

1/8 共识

团队对于需求变更要有共识。

什么共识呢？

共识 1. 敏捷拥抱变化，但要有限制，要有流程（可以变更，但要控制）。需求变更不一定是坏事，事先将所有需求定义好几乎是不可能的。因为，技术在革新，世界在变化，出现新的市场机遇，政策法规变化以及业务需求过时等等。所以，一个高效的团队是能够灵活应对变化的。

共识 2. 变更总是有代价的， 这个代价团队要能接受。

2/8 原因

要分析引发需求变更的原因是什么？

比如：

• 需求有疑问
• 需求有遗漏
• 需求有错误
• 实现有问题
• 需求有重复
• 需求有变化

3/8 要求

提出需求变更是有要求的，不能随便就提。

比如：

• 要求 1. 提出需求变更前是经过深思熟虑的。
• 要求 2. 审核需求变更要有一个拍板的人。
• 要求 3. 需求变更的信息要通知所有干系人。
• 要求 4. 处理需求变更有一致的变更流程 。

4/8 限制
需求变更是要有限制的。

比如：

• 限制变更的时间窗口，比如，在 Release 之后不允许任何需求变更，除非 CTO 同意。
• 限制需求变更的频率和范围。比如，一个迭代中变更的需求率不能超过多少，或变更的成本不能超过多少。

5/8 流程

需求变更要有明确的变更流程，要能够以一致且有效的方式来处理需求变更。

比如，下面这个变更的基本流程：

6/8 申请

变更申请非常重要，通常会有一个「变更申请模板」来规范申请。

这个模板要能回答什么项目？谁？因为什么原因，在什么时候申请需求变更？谁开发？谁测试？有风险吗？如果有怎么应对？评估依据是什么？谁评审的？谁最终审核的？

所以对模板的要求，基本是：可评估 可追溯 可管理

7/8 评估

对变更影响的评估非常重要，它是审批者/干系人来判断是否同意变更的关键因素。

申请和评估的模板可参考下图：

8/8 应对
既然变更在所难免，那作为测试人员应该如何应对变更呢？

这里主要是应对工作量增加的问题，因为所有的风险、影响最终都会化为工作量。

分两种情况来考虑，面对增加的工作量。

1、如果交付日期不变，则可以考虑：
砍：砍掉优先级低的需求，来减少工作量。
加：增加人力或部分工作外包，来分摊工作量。
降：牺牲部分不重要的质量来保交付，比如只精测优先级高的需求，优先级低的风险低的可以让开发自测，或产品验收测试。

2、如果交付日期可变，这就简单了：
延：延长交付时间。

所以，请记住应对需求变更的四字真言：砍、加、降、延。

4 量：质效度量

接下来我们看量，也就是度量需求相关的质量和效率，目的是为持续改进提供定性或定量的分析依据。

那，度量什么？

第 1 个，度量需求影响（也就是需求质量造成的结果），第 2 个是，度量需求本身（也就是源头），第 3 个，度量需求过程。

1. 度量需求影响（结果）

先看度量需求质量造成的影响，通过结果数据来反推源头和过程的问题。

为什么要从结果来反推呢？

因为通过问题来驱动改进，是最有效的方式。

比如：

• 返工时长：由于需求缺陷或变更造成返工的工作量；
• 延期次数：由于需求缺陷或变更造成项目或迭代延期的次数；
• 延期天数：由于需求缺陷或变更造成项目或迭代延期的总天数；

2. 度量需求本身（源头）
这个可以参考前面讲的需求的问题进行度量，用户故事则可以参考 INVEST 原则进行度量。

3. 度量需求过程（过程）

要跟踪需求的整个流转过程（全生命周期），监控需求的流转过程和状态，记录过程中的数据，比如：需求问题的类型，需求相关的耗时等，以便分析影响，还有后续的统计分析。

基本路径是：记录 -> 归类 -> 统计 -> 分析 -> 改进

接下来我们看看如何改进。

5 改：持续改进

关于持续改进，我们从改进的目标、原则、路线和方法来讲。

首先

确定：改进的目标

改进的目标肯定是降本增效。

比如：

减少因需求错误而导致的返工：

1. 统计在迭代周期的各阶段，因需求问题（错误、遗漏...）造成返工的时长。（需求错误造成的成本浪费）
2. 统计设定基线之后发现的需求问题占比。（评审不充分）

减少开发过程中澄清需求所花的时间：

1. 统计设定基线之后，需求的疑问和争议数量。
2. 统计解决每个疑问和争议所花的时间。

对于选择哪些指标，我们可以遵循一种简单的思考方式：目标 - 问题 - 指标（GQM：Goal-Question-Metric），首先写出改进目标，然后判断团队达成目标必须解决的问题是什么，最后，确定能够为每个问题提供答案的指标。

这些指标能够作为关键绩效指标。

比如：

然后

遵循：改进的原则

过程改进的原则：

• 过程改进是渐进的和持续的；
• 应该通过问题驱动需求过程的改进；
• 过程应该是目标导向的；
• 将改进工作按小型项目处理。

制定：改进的路线

开始前，一定要制定需求过程改进的路线图。

先列出要改进的事项，确定里程碑，然后给每个里程碑安排负责人，再要求负责人写行动计划，最后把这个计划落实到行动上。

可以用 OKR 来制定，然后用甘特图可视化展示。

用好：改进的方法

改进的方法很重要，这里推荐两种方法：

方法 1. 用根因分析法找出根因

比较常用的是 5WHY 分析法，打破沙锅问到底，然后使用鱼骨图展现根因分析的结果。

方法 2. 用过程改进循环持续改进

提高保障效率

如何能提高效率呢？

这里有个基本的节奏：

• 规范化，所有人按规范做事，知道要做什么，怎么做，有参考，有标准，减少例外的发生；
• 模板化，所有写的东西都应该有模板，像 PRD、评审会议纪要、需求变更申请、变更影响评估等等，把经验固化为模板；
• 平台化，把规范、模板、约束等都做到平台上，通过平台降低使用成本；
• 可视化，通过可视化，让质量问题和治理效果更好地传递出来；
• 智能化，利用智能化的手段去分析诊断 PRD 文档，以及研发过程中的风险预警。

总结

一图胜千言

最后，

需求质量的改进无法立竿见影，要项目组所有人所有角色参与其中，不断的度量、纠偏、反思和改进才行。