如何兼顾 产品开发 与 品质维护

软件开发中，最怕遇到的就是前面有新功能的开发在赶，後面有线上的 bug 在等着处理，呈现蜡烛两头烧的状况，到底要如何同时兼顾开发和维护产品品质呢？今天就要来和大家分享一下自己的做法。

所处的公司，研发团队组织的方式是用产品功能来做切分，每一个大产品功能会有一个专责的产品团队，团队成员除了产品经理，还会有设计师、工程师、品管师，产品团各自背负着需要达到的商业目标，自己基於专案管理的角度，会希望功能赶快开发完赶快上线，因为功能上线都需要一段时间才会开始发酵，若是上线後成效不好无法有效推升目标，至少还有时间能够继续迭代优化。

在产品团队开发的同时，团队自己也要维护好产品品质，因此当功能上线後有 bug，需要请原本开发的产品团队协助修正，修正 bug 这件事其实会排挤掉工程开发的资源，但是又不可能放着用户不管，不管的话可能会造成客服营运成本增加，或是用户的使用率下降等，目前所处公司的执行方式是会定义 bug 的严重程度，用此严重程度做为修正的优先级排序，往下再评估不同严重程度的 bug 应该要何时做修正。

bug 的严重程度主要会分成下列四个等级：

红色警戒

表示此 bug 严重影响到用户的日常操作，而且会影响到多数的用户，此 bug 完全没有其他 workaround 的方式，会导致有很多店家同时进线反应。

为了避免公司营运爆炸，会请工程师立即停下手上的工作协助修正，理想是在 1-2 天内可以快速修正。

橘色警戒

表示此 bug 会影响到有特定操作习惯的店家，且此 bug 难以 workaound，反应的家数会随时间慢慢增长。

因为对用户来说使用上还是很不方便，因此会和请工程师评估看看修正是否需要花很多时间，若是可以快速修正，理想是在 1-2 周内可以进快修正。

黄色警戒

表示此 bug 只会影响到少部分的用户，或是有其他简单的 workaround 方式可以操作。

这个等级稍微比较缓和一些，通常我会在工程师开发到一个段落时才提出来请他们修正，除非工程师说修正非常容易，不影响开发才会请他们直接修正。

绿色警戒

非常小的 bug ，不至於影响到用户操作，e.g 字词错误、UI 跑版等。

这个等级其实和黄色等级的处理方式一样，主要还是看修正需要花费的时间，不希望影响到主要开发的内容。

另外，还有一种特殊状况的 bug 是暂时不会被修正的，目前没有任何用户反应，修正成本非常的高，因为不影响用户的使用，目前不修也不会有大问题，因此会暂时存在已知 bug 的 backlog 里，并且备注暂时不修正的原因，存起来的目的是让其他人也知道这个 bug 的存在，避免其他人又重工做了一样的事重新追查一次。