查看原文
其他

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

毕小烦 毕小烦 2022-07-13

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


如何保障需求质量呢?


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


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


具体怎么做呢?


就是最开始我们讲的那 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. 审阅文档产品经理提前 1 ~ 2 天,把 PRD 发给项目组成员,以便提前熟悉,带着问题参加评审;

  2. 需求评审是指需求评审会,一般我们将需求评审就等同于需求评审会,产品经理组会,将项目组成员及跟此项目相关的人员叫在一起,通过产品经理的讲解来对需求进行系统性的评审;这种评审也叫正式评审,是保障需求质量最有效的手段。

  3. 三方评审产品、开发、测试三方评审,一般用于需求变更的时候,要的,做的和测的人在一起把需求评了,在坐位上就行,站会也行。


这三种形式在不同的阶段进行,也就是评审前,评审中和评审后,审阅文档是对文档的静态检查,需求评审是对 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. 如果交付日期不变,则可以考虑:

    • 砍:砍掉优先级低的需求,来减少工作量。

    • 加:增加人力或部分工作外包,来分摊工作量。

    • 降:牺牲部分不重要的质量来保交付,比如只精测优先级高的需求,优先级低的风险低的可以让开发自测,或产品验收测试。


  1. 如果交付日期可变,这就简单了:

    • 延:延长交付时间。


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

4 量:质效度量

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


那,度量什么?


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

1. 度量需求影响(结果)


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


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


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


比如:

  • 返工时长:由于需求缺陷或变更造成返工的工作量;

  • 延期次数:由于需求缺陷或变更造成项目或迭代延期的次数;

  • 延期天数:由于需求缺陷或变更造成项目或迭代延期的总天数;


2. 度量需求本身(源头)


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



3. 度量需求过程(过程)


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


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


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

5 改:持续改进


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


首先

确定:改进的目标


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


比如:

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

1. 统计在迭代周期的各阶段,因需求问题(错误、遗漏...)造成返工的时长。(需求错误造成的成本浪费)

2. 统计设定基线之后发现的需求问题占比。(评审不充分)


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

1. 统计设定基线之后,需求的疑问和争议数量。

2. 统计解决每个疑问和争议所花的时间。


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


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


比如:


然后

遵循:改进的原则


过程改进的原则:


  1. 过程改进是渐进的和持续的;

  2. 应该通过问题驱动需求过程的改进;

  3. 过程应该是目标导向的;

  4. 将改进工作按小型项目处理。

制定:改进的路线


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


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


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

用好:改进的方法


改进的方法很重要,这里推荐两种方法:


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


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


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


提高保障效率


如何能提高效率呢?

这里有个基本的节奏:


  1. 规范化,所有人按规范做事,知道要做什么,怎么做,有参考,有标准,减少例外的发生;

  2. 模板化,所有写的东西都应该有模板,像 PRD、评审会议纪要、需求变更申请、变更影响评估等等,把经验固化为模板;

  3. 平台化,把规范、模板、约束等都做到平台上,通过平台降低使用成本;

  4. 可视化,通过可视化,让质量问题和治理效果更好地传递出来;

  5. 智能化,利用智能化的手段去分析诊断 PRD 文档,以及研发过程中的风险预警。

总结


一图胜千言




最后,


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


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

参考资料

  • 参考的书籍有:《软件需求》、《软件开发的201个原则》

  • 参考的文章挺多,主要是获取灵感,感谢这些文章。


如果文章对你有帮助,记得留言、点赞、加关注哦!

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存