在日本开发 SaaS 产品,爱猫、爱读书、爱户外

E010-bugs什么时候修复?features值不值得做?


大家好,欢迎阅读《蒋继发的每周分享》第10期。本期的主题是《bugs什么时候修复?features值不值得做?》。

我叫蒋继发,目前在日本做 HR 领域的 SaaS 产品,爱猫、爱读书、爱大海。所以,我可以分享一些 SaaS 项目工作经验、日本生活体验以及阅读感受等等。《蒋继发的每周分享》会在每周四发送,欢迎大家通过 RSS 或者 Revue 订阅。

我先和各位订阅的读者道个歉,上周我没有更新《每周分享》,因为上周工作太忙了,实在没有力气了,十分抱歉。

bugs 什么时候修复?

这是之前看到的一个图,非常赞同,已在公司内部的分享,也分享给大家。

根据这张图我们可以非常轻松的判断出 bugs 应该在什么时候被修复。

list:

  1. 如果 bugs 影响到超过 30% 用户使用核心功能,Fix Now
  2. 如果 bugs 影响到超过 30% 用户使用基础功能,Fix Now
  3. 如果 bugs 影响到超过 30% 用户,但是不影响使用,Fix Next Spring
  4. 如果 bugs 影响范围在 11% to 30% 用户使用核心功能,Fix Next Spring
  5. 如果 bugs 影响范围在 11% to 30% 用户使用基础功能,Fix Next Spring
  6. 如果 bugs 影响范围在 11% to 30% 用户,即使不影响使用,Fix Next Spring
  7. 如果 bugs 影响 0% to 10% 用户使用核心功能,Fix Next Spring
  8. 如果 bugs 影响 0% to 10% 用户使用非核心功能,Backlog
  9. 如果 bugs 影响 0% to 10% 用户,且不影响使用,Backlog

上面列表是针对 bugs 的,通常情况下如果 issue 已经被确认是 bug 的话,就不存在做不做的问题了,肯定要修复,只是需要确认什么时候做即可。但是如果是针对 features 呢?

features 值不值得做?

我参考上面的图片制作了 features 版本的交叉图

list:

  1. 如果 features 可以为用户提供数量级的收益,如果无法提供将短期内会给公司带来损失,例如:客户解约。Do
  2. 如果 features 可以为用户提供数量级的收益,如果无法提供短期内也不会给公司带来损失,但是公司收益会减缓或停滞。Do
  3. 如果 features 可以为用户提供数量级的收益,从短期角度不会给公司带来损失或受益。Plan
  4. 如果features 是相关行业必备功能,如果无法提供将短期内会给公司带来损失,例如:客户解约。Do
  5. 如果features 是相关行业必备功能,如果无法提供短期内也不会给公司带来损失,但是公司收益会减缓或停滞。Plan
  6. 如果features 是相关行业必备功能,从短期角度不会给公司带来影响。Plan
  7. 如果 features 只会让一部分用户感到开心,即使短期内会给公司带来损失。Do not
  8. 如果 features 只会让一部分用户感到开心,即使短期内会让公司收益减缓或者停滞。Do not
  9. 如果 features 只会让一部分用户感到开心,从短期角度不会给公司带来损失或受益。Do not

80/20 法则

上面的公式也适用于 80/20 法则,实际工作中难免会有一部分工作属于 20% 范畴,希望大家可以随机应变。

我开发了一个简单的网页大家只需要动动鼠标就可以计算出“bugs 什么时候修复?”和“ features 值不值得做?”了,欢迎大家使用 https://priority-matrix.vercel.app/

以上就是本次分享的全部内容,十分感谢你看到这里。

为了方便大家订阅《蒋继发的每周分享》,我也开始使用 Revue 了,大家可以在 https://www.getrevue.co/profile/thaddeusjiang 订阅 Email 推送。分享内容同步在我的个人网站:https://thaddeusjiang.com/weekly

参考: