以有限应对无限-互联网产品研发过程中的 5 种等级

一个互联网产品的生命周期大概可以分为需求阶段,研发阶段,运营阶段。 在需求阶段,通常我们会有需求优先级; 在研发阶段,会有转测 BUG 等级,BUG 的严重程度; 在运营阶段,会有线上 BUG 等级,线上事故等级。

为什么会有等级或者优先级?其背后的根本原因是资源是有限的。 在有限的资源内,如何更好地完成需求,修复线上问题,处理线上事故是我们在研发管理过程中要反复面对的问题。 而这个要反复面对的问题,业内通用的解决方式是定优先级,也就是我们常说的 P0,P1……

1. 需求优先级

需求优先级,指产品需求的优先级,哪些需求先做,哪些需求后做,哪些需求不做,其关注的是业务价值或者要解决问题的价值。

需求优先级一般有 3 个,P0,P1,P2 在资源有限的前提下,P0 是必须要做的,P1 是在 P0 做完后有空余人力可以去做,P2 现阶段基本可以不做。

当业务方问为啥我们:“这个需求没有咋没有排上,我都提了这么久了,你们是怎么评估优先级的?” 我们需要有一些相对客观的逻辑或方法来回复业务方。

需求的评估可以分两步:

第一步:从需求的角度来看,任何一个需求一定服务于某个战略 / 某个目标 / 某个场景,需要根据其服务的目标来做第一次的优先级评估。

  • 如果是服务于战略,根据战略的级别和影响范围来评估,比如是公司级的战略项目优先级肯定要高一些;
  • 如果是服务于某个目标,这里的目标可能是合同或者营收,根据合同的金额,合同的客户以及营收的大小来评估,比如一个合同金额为 500 万和一个合同金额为 5 万的需求,会有比较明显的优先级区别;
  • 如果是服务于某个场景,那这个场景一定有对应的目标人群,根据目标人群的特征、数量和其影响范围来评估,比如有些需求在业务关键链路上,优化可以影响的用户量比较多,又或者某些影响核心链路可用性的技术建设需求,当核心链路不稳时,所有用户都会受影响,此时需要评估为最高优先级;

在以上评估的基础上,还需要基于具体的实现做第二步的评估:

  • 参考需求实现的成本和难度,对于开发成本低,周期短,但价值高的需求,需要给予更高一些的优先级,其实就是看一下性价比;
  • 对于存在关联关系的需求,可能适当地调整优先级,比如某个需求 A 优先级高,另一个需求 B 优先级低,但是在做需求 A 的时候,再加点点人力就可以顺便把需求 B 给做了,此时可以适当调整,这里主要考虑的是事情的完整性,基于减少了认知成本和沟通成本的出发点;
  • 对于存在依赖关系的需求,可以适当调整优先级,比如在开发某个产品时,可以先把 MVP 版本的需求先做了,实现主体流程先跑通,或者某些需求在前后端上有依赖,可能需要后端先行等等。

以上只是我们评估的逻辑,换成更高大上的说法有如下一些方法:

  • 卡诺模型( KANO 模型):必备需求 > 期望需求 > 超出预期需求 > 无差异需求
  • 维格斯法:分为四个纬度进行评估:收益(Benefit)、损害(Penalty)、成本(Cost)、风险(Risk)。收益和损害是从客户角度出发,而成本和风险则从实现角度出发。
  • 波士顿矩阵:由用户价值维度和公司价值两个维度将需求分成了 4 个象限:明星需求,问题需求,金牛需求,瘦狗需求。
  • RICE 方法:包含 覆盖率,影响,信心和努力 4 个部分。对要素进行排名并根据这 4 个因素计算得分,以确定优先级。
  • WSJF 优先级:加权最短作业优先,项目成本 = 用户商业价值 + 时间成本 + 降低风险 / 新机会
  • 工作量和影响矩阵:也称为「价值与复杂性」矩阵,将工作量和影响组合分为 4 个象限
  • MoSCoW 方法:必须具备 > 应该具有 > 可能具有 > 非必要
  • 艾森豪威尔矩阵(时间管理四象限):马上要做(重要紧急) > 计划要做(重要不紧急) > 备选(紧急不重要) > 不需要做(不重要不紧急)

2. 转测 BUG 等级

转测 BUG 等级关注的是对测试执行的影响,这里之所以叫转测 BUG,是为了和线上运营时的线上 BUG 做区别。

转测 BUG 在 CMMI5 标准中可以分为 3~5 个等级,在实际研发过程中,我们常常将其分为 4 个等级,这里的等级属于处理的优先级,即对我们处理的时间和先后顺序有要求,如下:

等级 说明
P0 马上解决,表示 BUG 需要马上解决,否则就无法达到预期,测试执行完全没法操作
P1 急需解决,表示 BUG 的修复很紧要,关系到系统主要功能模块是否正常,严重影响测试执行
P2 高度重视,表示 BUG 有时间就要马上解决,否则系统偏离需求较大或预定功能不能正常实现,对测试执行有影响,但是可接受
P3 正常处理,表示 BUG 按个人计划解决,不影响需求的实现,在需求上线发布前需要确认解决或确认可以不予解决,对测试执行影响较小

以上是 BUG 的处理优先级,但是我们在确认 BUG 时还有一个维度是严重程序,如下:

严重性 说明
致命(非常严重) 在流程、数据或安全方面存在重大问题,导致软件不具可用性,或核心功能项无法使用,如系统崩溃、无法启动、实现和需求严重不符等导致测试无法进行
严重 由于设计的缺陷,导致软件使用中存在较明显的障碍,或者局部功能错误,但可以采取其他变通的操作实现,如功能未实现、功能错误,通讯错误等
一般 由于编码不够完善,使某个小功能无法使用,或者对特殊的操作与要求不能支持
提示 存在某些细微的缺陷,但不影响程序正常应用或该功能在下次升级版本中可以实现

对于转测 BUG 的优先级和严重性,有如下一些注意事项:

  1. 优先级和严重性并不总是一对应。有时候严重性高的 BUG,优先级不一定高,甚至不需要处理,而一些严重性低的 BUG 却需要及时处理,具有较高的优先级。如界面单词拼写错误,但是如果是系统名称或公司名称的拼写错误,则必须尽快修正,因为这关系到系统和公司的市场形象;
  2. 修复 BUG 不是一件纯技术问题,有时需要综合考虑项目周期、质量风险和修复成本等问题。例如如果某个严重的 BUG 只在非常极端的条件下产生,则可能没有必要马上解决,又或者修复一个 BUG 需要重新修改系统的整体架构,可能会产生更多潜在的 BUG,而且产品由于市场的压力必须尽快发布,此时即使缺陷的严重性很高,需要通盘考虑后,以确认是否需要修正。

3. 产品模块等级

在讲线上 BUG 等级前我们需要先讲一下产品模块或产品链路等级。因为不管是线上 BUG 还是线上事故,其优先级的判定都依赖于产品模块的等级,在产品模块等级的基础上叠加影响范围 / 影响时长之类的因素才能构成线上 BUG 等级和线上事故等级。一般我们将产品模块等级分为以下 3 个等级:

等级 说明
P0 核心功能流程,是一个产品安身立命的根本,最最基础的功能,如电商场景下的浏览商品、商品详情、支付购买等
P1 非核心流程,却是重要的业务模块,如电商的优惠劵兑换、商详页里面的用户评论,在系统遇到问题时,可以降级的部分
P2 非核心流程,当不可用时,用户可以接受晚点再来,如一些运营活动,个人信息的展示等

基于产品模块等级我们讲一下在运营阶段常见的线上 BUG 等级和线上事故等级。

4. 线上 BUG 等级

线上 BUG 是指在线上环境中发现的 BUG,是相对于转测 BUG 来说,其关注点是对用户使用的影响,其优先级的评定也是根据用户影响范围及程度来决定的。 在实际执行中我们通常会根据客服的反馈和 BUG 所在的业务的重要程度来决定处理优先处理。

等级 说明 反应时长 处理周期
P0 因程序导致的 P0 级业务流程不可用,影响所有用户或大面积用户,或对用户/公司造成了实际经济损失,闪退 5分钟 1 小时内
P1 因程序导致的 P0 级业务流程不可用,但只影响部分用户正常操作,或 P1 级业务流程不可用,但影响所有用户 / 大面积用户 10 分钟 24 小时内
P2 因程序导致的 P1 级非核心业务流程异常,若持续故障将可能大面积影响用户体验 1 小时 1 周内
P3 因程序导致的 P1 / P2 非核心业务流程异常,影响少量用户使用体验 2小时内 两到三周内

5. 线上故障等级

线上 BUG 专指由于程序的问题导致的线上问题,而线上故障是对所有对线上业务产生了一定范围影响的线上问题。

线上故障和线上 BUG 不相同,线上 BUG 不一定会产生线上故障,而线上故障也不一定是由线上 BUG 造成的。如 DDoS 攻击,机房断网,域名到期等等都有可能产生线上故障。

线上故障等级关注的是对业务的影响范围和持续时长,实际应用中我们用可用性 SLA(Service-level Agreement)来描述和约束线上故障。其优先级如下:

等级 说明 反应时长 处理周期
P0 P0 级业务流程不可用,影响所有用户或大面积用户,或对用户/公司造成了实际经济损失 5分钟 1 小时内
P1 P0 级业务流程不可用,但只影响部分用户正常操作,或 P1 级业务流程不可用,但影响所有用户 / 大面积用户 10 分钟 12 小时内
P2 P1 级非核心业务流程异常,若持续故障将可能大面积影响用户体验 30 分钟 1 周内
P3 P1 / P2 非核心业务流程异常,影响少量用户使用体验 1 小时内 两三周内

6. 后记

优先级是我们以有限应对无限的策略,在没有办法的情况下可以这样用,但是如果人力充足是否就不需要优先级了?

答案是:依旧需要。

对于优先级更深层次的思考是 ROI,如何让研发投入产生更大的价值,是我们要不停思考的问题。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注


*

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>