軟體開發中，最怕遇到的就是前面有新功能的開發在趕，後面有線上的 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 的存在，避免其他人又重工做了一樣的事重新追查一次。