臭蟲管理之二

感謝同事老友的指正，M 社所使用的 resolution 還有 postponed (是指知道是個問題，但是基於許多原因暫不修正)以及 external (跟 dup 類似，但連到其他產品的 bug 資料庫)。特此補充。

上一篇描述了管理 bug 的大致流程架構，這裡就來聊聊它的一些延伸。

首先還是要強調一下機制功能再多，運作的順暢還是要仰賴人的互信與當責的態度。可能有人會好奇，M 社處理 bug 的人那麼多，應改有很多自動機制提醒這提醒那的吧? 雖然有些團隊的確會設計一些提醒機制，但是基礎系統並沒有這些東西。以我自己為例，進了公司沒幾個月，就跟其他人一樣養成每天早上開系統檢查 assign 給自己的 bug 的習慣；如果不這樣做，會耽誤到很多人的工作進行。倒也不是怕人罵，總覺得當天沒有把 bug 清乾淨會有很深的罪惡感。 而許多功能小組的 stand up meeting，大多也是討論如何處理各自手上的 bug。長久下來，這件事就成了大家的 "肌肉記憶"，成了一種習慣。

當這些 bug 資料累積下來，就可以提供給工程管理的經理人作為快速掌握開發進度以及品質狀況的武器。之前曾經提到過，Office 每個版本的開發，都會有一個產品團隊兼任開發管制的工作；它們的其中一個任務，就是設計出各種與研發相關的統計指標 metrics，例如 bug 的平均年齡、fix rate 或是 active bug 的總數與人均數，並從 bug 資料庫中撈出實際的統計值，提供給各產品組檢視並追蹤可能的問題，而這些統計資料也會即時反應在內部的網頁上。每個產品團隊，通常也有自己常看的指標，我們都會無師自通成為 Excel 的 power user，每天都在翻來覆去檢查資料庫的統數字，生怕漏掉了甚麼潛在的問題。

有些團隊甚至將 bug 管理擴充成議題 issue 管理，把 planning 相關的工作也當成 bug 丟上資料庫，用同樣的觀念來協作，效果也很不錯。我們的團隊就用這個來追蹤規格制訂的流程，並確保必要的團隊成員都能參與 spec review，也將所有的代辦事項 (action items) 都用這個來管理。

最後無可避免的，資料庫中的數字也會影響人的績效考核。當然我們很小心不會直接引用數字直接來評斷人，那樣就會犯了 KPI 常看到的毛病 - 本來只是手段反而成了目的；但是我們倒是常常引用數字做為佐證，尤其是那些前段班 (或是後段班) 單獨被拿出來討論的情況。

M 社的工程管理使用數字算是很厲害的了 (不否認有些 Excel 的功能是依這些需求設計出來的)。不過工具沒有好與壞，也有被誤用的時候， 之後有機會會聊一些慘痛的教訓。