产品价值 vs Bug 数量

Bug 数量也可以说是产品质量，产品的价值，可以说是产品代表的用户价值，最吸引客户的地方。到底哪个更重要呢？有人会说都重要，既要又要的关系。有的会说质量都不合格如何能实现客户的价值呢？下面是最近一个小伙伴发来的感受。很有启发，今天就来聊聊这个话题。

上面说到了产品价值，也就是说我们的产品是否能够得到客户的认可，抓住了用户的心，解决了用户的痛点。这些也是一个产品的立命之本，产品的使命和愿景指明的方向。对话里另一个有意思的词“没有 bug 的垃圾”，体现了一个“完美”产品的无奈。没有任何 bug 但是就是没有人用，这个产品的作用是什么呢？（这里讨论的产品抛开某些特殊背景或者政绩目的产品） 我们身边是否有这样”好质量，但没有用“的产品呢？

有些小伙伴可能会说，“既要又要”是我们的常态呀，老板或者客户都希望这样，不过面对现实其实客户、企业、产品经理、团队还是要做出取舍的，毕竟时间有限、资源有限的情况下，最大化我们的投入产出是避不开的话题。

说到这，我想到了另外一句话“完成比完美更重要”。第一次听这句话的时候，第一感觉是这岂不是对自己要求太低了，糊弄吗？不过仔细想想，我们在追求不断接近完美的路上，一步一步的完成迭代才是严谨的前提。否则永远停留在第一步不敢行动。那更谈不上实现完美了，因为都没开始。那这个完成首先是在正确方向上的完成。那如何能选对方向呢？找准价值就是关键。

接下来说说不够“完美”，最明显的 Bug 算一种不完美的因素，不过它也存在几种类型：

• 功能实现错误

  这种属于实现写错了代码，通过充分的测试可以避免。例如：计算器功能某些计算功能某些情况不准确。

• 业务理解错误

  这种属于没有理解业务需求，也就是没有抓住价值导致做错了方向。

• 实现业务不全

  这种场景是说明确了业务方向，也知道存在若干个业务需求，不过由于时间等因素，我们先实最关键的几条，之后再逐步补全其他的业务。

综上，确认产品方向正确+有效优先级排序，适当的取舍，要比追去 0 Bug 更有意义。下面有几个好用的小工具，小伙伴们可以在需要的时候使用：

• 用于找准价值，谈说用户需求类的

影响地图，用户故事地图，用户旅程地图

• 用于优先级编排类。

MoSCoW，Kano，WSJF

我们一直在追求高效的端到端交付价值，并不是期待一直低头做功能，期待一次成功；而是需要持续抬头看这着前进方向是不是偏离了，及时调整。

践行敏捷实践，让工作去繁从简。欢迎留言，交流落地经验。

【关注我的个人博客】