实操手册 - BUG

It's not a bug. It's a feature!

对，这一期要说BUG，跟我读“八-阿-哥”。

---

BUG的定义：本意是臭虫、缺陷、损坏、犯贫、窃听器、小虫等意思。现在人们将在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题统称为bug（漏洞）。

在实际的产品设计工作过程中，总会遇到大量的bug，有些可以解有些不能，不能的那部分很可能就流转到了产品人员手中去评估。

目前我们的流程是：

1. QA发现bug-》RD调研bug-》能解的bug解决了-》QA验证是否修复完成，未完成则打回。

2. QA发现bug-》RD调研bug-》不能解的bug进行多方评估（多方至少包含PD、QA、RD，如果和OP、UE相关则要一起评估）-》评估下个版本修复、推动外部修复还是影响不大直接降级，如果又要修复、又有较多工作量（如超过了1人天会影响排期），则要看是否加班、延期等方式解决。

---

对于是否要修复，从以下几个点去判断，数值可以自己摸索、调整：

1. 严重程度：崩溃、内容缺失、功能不可用是最严重的，只要必现就一定修复；低概率复现且低频率使用在灰度阶段可放行，正式上线还是要修复；上线除非是不可修复，其他情况下还是要修复掉。

2. 复现概率：高复现概率的都是好bug，能够比较稳定找到问题原因；稳定复现则是高概率，不稳定复现，如10%的复现概率以下，则是低概率。

3. 使用频率：如果一个功能低于了1%用户使用，可以认为是低频使用的。如果是核心功能、本期主打功能，自动认定为高使用频率。

通过这三点，个人的判断就成为（&&代表且、||代表或关系）：

1. 严重&&（高复现||高使用），一定灰度前修复。

2. 严重&&低复现&&低使用，可灰度测试，正式上线前一定修复。

3. 不严重&&（高复现||高使用），灰度前修复。

4. 不严重&&低复现&&低使用，可尽量修复，无时间或者有外部依赖，流转版本或者降级不修复。

简单来说，严重的发版前一定修复，高复现或高使用的一定灰度前修复。我们的判断应该是基于严重程度、战略目标、用户影响面来进行的。

---

BUG与feature

实际的工作中，BUG和feature的界限其实没那么清晰，可以自己建立一套标准。涉及到新的功能开发、之前需求文档未能描述的部分，都定义为feature，而BUG是之前按照文档的预期应当如何却未能如何。所以我们要求PD写清楚分支逻辑后，与其他角色讨论，由QA完成test case的编写。

也可以唯心的说，PD在设计需求时候，在和RD、QA沟通后未能考虑到的逻辑分支、视觉样式，导致了严重的功能异常，是属于大家的经验不足，这种算bug；而需求设计时，PD和RD、QA沟通不足导致了功能异常，需要增加更改，则属于PD的责任，这种需要新增加需求解决掉的，就是feature了。

比较常见的情况，更多是PD、UE的思考不足，在产品review的阶段发现不符合预期，以bug的名义加了feature，这种情况其实不利于团队和谐。

出现了纰漏应该用于承认，并承认后果，自己挖的坑是要自己填上，而非扔个bug就让人家加班去改了，这是明显在给自己减分的行为。由于PD自己的问题产生的需求变更、feature增加，都应该主动承担，找解决方案，例如协调QA人力、延长排期或者加班解决，在不同阶段的解决方式不同，开发前期协调即可，如果排期不死而工作量大就应该延长排期，如果排期已经明确只能陪伴跟随解决，请RD、QA吃鸡翅跪舔吧。