测试管理 如何保障需求质量(下):你应该做到的

TesterHome小助手 · 2022年04月29日 · 7002 次阅读

作者 | 毕小烦

如何保障需求质量呢?

可以简单总结为四个要:既要,又要,还要,且要。

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

具体怎么做呢?
就是最开始我们讲的那 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 文档,以及研发过程中的风险预警。

总结

一图胜千言

最后,

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

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册