【干货】互联网产品的生命周期，如何评估优先级？
- - 掘金 架构一个互联网产品的生命周期大概可以分为需求阶段，研发阶段，运营阶段. 在需求阶段，通常我们会有需求优先级；
在研发阶段，会有转测 BUG 等级，BUG 的严重程度；
在运营阶段，会有线上 BUG 等级，线上事故等级. 其背后的根本原因是资源是有限的. 在有限的资源内，如何更好地完成需求，修复线上问题，处理线上事故是我们在研发管理过程中要反复面对的问题.
【干货】互联网产品的生命周期，如何评估优先级？
标签：
干货
互联网
产品
| 发表时间：2022-05-21 08:31 | 作者：潘锦
出处：https://juejin.cn/tag/%E6%9E%B6%E6%9E%84
一个互联网产品的生命周期大概可以分为需求阶段，研发阶段，运营阶段。 在需求阶段，通常我们会有需求优先级； 在研发阶段，会有转测 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 的优先级和严重性，有如下一些注意事项：
- 优先级和严重性并不总是一对应。有时候严重性高的 BUG，优先级不一定高，甚至不需要处理，而一些严重性低的 BUG 却需要及时处理，具有较高的优先级。如界面单词拼写错误，但是如果是系统名称或公司名称的拼写错误，则必须尽快修正，因为这关系到系统和公司的市场形象；
- 修复 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，如何让研发投入产生更大的价值，是我们要不停思考的问题。
相关 [干货 互联网 产品] 推荐：
互联网“产品经理”和“创新”
- 盛开 - 月光博客 在2011年1月11日，在清华大学举办的2010中国互联网创新产品评选的颁奖盛典上，有几个著名的互联网领袖针针对“产品经理”以及“创新”这个话题展开了一些主题演讲，内容很有意思，以下是部分演讲的整理和在线视频. 创新工场CEO李开复的演讲：“互联网的产品精神”. 李开复从九个方面来谈一个好的互联网的产品精神：.
什么是互联网产品经理
- - Page to Page这篇最初级最初级的扫盲文，只讲一件事情：什么是互联网产品经理. 之所以谈这么浅薄的话题，是因为业内对此的定义混淆之极，以至于我无论写什么产品经理的话题，都有人反对. 我一看，他也没说错，但语境全然不同. 对“产品经理”职位的理解多变，以至于1000个人眼里有1000个产品经理……. 我自己转型做产品，是在2008年初，那时的产品经理还没有被普遍简称为PM，产品经理时髦受追捧也才刚刚开始.
2011中国互联网创新产品评选获奖产品
- - 《商业价值》杂志获奖理由：知乎通过社会化的方式将问答重新组织起来，对话题、用户、领域的三维关注使其成为一个优秀的知识交流和讨论社区. 通过一年的发展，知乎吸引到了各行各业的众多专业人士和广大普通用户的积极参与，积累了大量的高质量内容. 知乎的价值将随着其内容的不断沉淀得到更大的释放. 获奖理由：作为国内最大的女性时尚及电子商务社区，美丽说每天的PV超过3000万.
【干货力荐】传统企业玩转互联网的19条法则
- - @i黑马传统企业正在经历这样的一个时代：不玩互联网一定会死，玩互联网可能会立刻死. 所以，对于传统企业而言到底该如何玩转互联网. i黑马昨天与一位互联网圈资深创业者交流时说到这样一个关键点：就是传统企业到底该如何去玩互联网，是不是只把互联网当做工具来使用. 当i黑马抛出这个问题的时候，这位资深人士说：最重要的一点一定是要从顶层设计上具备互联网思维.
2010最值得关注的10款小众互联网产品
- 韩叙 - 动点科技-CN.TechNode.com2010年还有几天就要结束了，和往年一样，在每年的这个时候都会由我从过去365天诞生的若干互联网产品中，精挑细选出10款也许最值得大家跟我一起去回味和关注的创新并且小众互联网产品. 感谢这些值得尊敬和信赖的创业者和团队丰富了我们的互联网生活. 卷豆网 是一家致力于为站长用户提供适合在线社区的电子商务解决方案的服务性站点，淘金链（LinkMiner）是其发布的第一个产品.
如果香奈儿是互联网产品设计师
- 章明 - 36氪同时尚产业一样，互联网只有为数不多的创新者和众多的模仿者. 并不是说创新者创造出新功能而模仿者模仿复制他们，因为一切都是再混合（或者古人说的“无一字无来处”）. 在时尚界，区分这两个群依据的是品味层次的差异. 创新者设计的产品优雅而值得玩味，而模仿者的产品执行都很糟糕 – 混搭不佳以至毫无特色. 在时尚界，有一个传奇式的创新者拥有无法比拟的好品味.
Gamification：互联网产品的游戏化设计思路
- 刘潇 - 最新文章 - UCD大社区在2011年的GDC大会上，Gamification（游戏化）作为一个热门新词被提出来. 简单来说就是将游戏的思维和游戏的机制运用到其他的领域，来引导用户互动和使用的方法. 它能在互联网、医疗/健康、教育、金融等领域中影响到用户使用时的心理倾向，进而促进用户的参与与分享. 简单的说，它可以用来鼓励人们做一些通常认为“无聊”的事， 例如完成调查、购物或者阅读网页等.
李开复：互联网的产品精神
- medal - 《商业价值》杂志互联网时代的产品生产方式已经发生了巨大的变化，这些改变都有哪些. 在今天日益重视自主创新的中国，谈创新其实已经不再是技术、科研、发明，然后产学研结合这些概念了. 谈这些概念的很多人，完全忽视了一个问题，即一个产品构思的第一天就一定要融合技术、用户和商业模式三者，而每一个公司的每一个产品背后的灵魂人物──扮演着将三者融合角色的就是产品经理.
如何设计出“有趣”的互联网产品？
- Guan - 所有文章 - UCD大社区儿童类网站及软件设计师 Deb Gelman 曾在《A List Apart》杂志上曾刊登了一篇《Designing Fun》文章，详细讲述了如何设计出有趣的互联网产品. 文中从定义、研究、构建以及评测等多了角度阐述了这个问题. “当我看见具体东西后，我才能知道说清楚”. 1964 年，在 Jacobellis v.