如何保障需求质量（下）：你应该做到的

欢迎订阅我的新专栏《现代命令行工具指南》，精讲目前最流行的开源命令行工具，大大提升你的工作效率。

上一篇文章我们介绍了保障需求质量需要知道的一些基本内容，接下来，我们看保障需求质量的具体措施。

5. 如何保障需求质量？

如何保障需求质量呢？

我们总结为四个要：既要，又要，还要，且要。

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

具体怎么做呢？

就是最开始我们讲的那 5 个字：防、评、控、量、改

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

5.1 防：问题预防

我们先看防，怎么做好问题的预防。

主要是做到 5 个有：**有原则、有规范、有流程、有分工、有标准。 **

有原则可以遵循，有规范可以参考，有流程可以跟着走，有分工大家各司其职，有标准能够衡量结果。

来具体看看。

有原则

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

比如：

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

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

有规范

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

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

产品规范都包括什么呢？

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

有流程

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

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

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

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

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

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

有分工

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

有标准

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

需求评审准入的原则是： 需求文档是完善的，价值是明确的，技术是可行的，拆分是合理的，风险是可控的。
需求评审准出的原则是： 需求文档是经过评审的、最新的、完整的，无歧义的，是可以被拆成任务，可评估，可实现的。

具体标准（略）

5.2 评：需求评审

评审目的

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

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

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

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

评审目标

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

要让团队能够：

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

测试人员：

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

评审形式

以什么样的形式进行需求评审呢？

最常见的也就三种形式：

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

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

评审策略

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

比如：

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

5.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. 如果交付日期可变，这就简单了：

   • 延：延长交付时间。

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

5.4 量：质效度量

![image.png](https://img-blog.csdnimg.cn/img_convert/af76038eb78fcb0ff79e7fbf849e3d8c.png
接下来我们看量，也就是度量需求相关的质量和效率，目的是为持续改进提供定性或定量的分析依据。

那，度量什么？

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

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

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

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

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

比如：

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

2. 度量需求本身（源头）

这个可以参考前面讲的需求的问题进行度量，用户故事则可以参考 INVEST 原则进行度量。

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

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

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

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

5.5 改：持续改进

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

首先

确定：改进的目标

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

比如：

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

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

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

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

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

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

比如：

然后

遵循：改进的原则

过程改进的原则：

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

制定：改进的路线

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

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

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

用好：改进的方法

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

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

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

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

6. 提高保障效率

如何能提高效率呢？

这里有个基本的节奏：

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

总结

一图胜千言

最后，

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

希望本文对大家有一些启发，也欢迎留言讨论，谢谢。

参考资料

• 参考的书籍有：《软件需求》、《软件开发的201个原则》
• 参考的文章挺多，主要是获取灵感，感谢这些文章。

（完）

如果文章对你有帮助，记得留言、点赞、加关注哦！也可以了解下我的新专栏《现代命令行工具指南》，欢迎品鉴。