“bug管理”應該是所有互聯網企業必不可少的工作內容之一，但是同行們針對這項工作的解決方案各不相同，我經歷或見過如下幾種：
1、小團隊日常使用產品過程中遇到bug，直接找開發人員溝通、確認，然后開發人員記錄，視bug緊急程度馬上或稍后集中處理；
2、稍大點中小團隊往往讓技術人員開發一套異常簡陋的“bug管理”系統，按照通用的bug管理流程進行系統設計，忽略UI、交互等等一切“次要”元素，保證順暢使用基本職能；
3、購置一套“bug管理”軟件進行bug管理。
第一種情況并不常見，是小團隊在技術力量不足、資源不足情況下的無奈妥協，弊端當然也最多：降低技術人員開發效率、不可回溯、易遺漏等等。
第二種源于我親身經歷，這套內部的bug管理系統如果不考慮用戶體驗要素，基本上能夠滿足正常流程：紀錄、審查、跟蹤、分配、修改、驗證、關閉、整理、分析、匯總以及刪除。自己開發bug管理系統雖然投入成本相對較高，但可以根據團隊工作習慣定制化。
不過有一點麻煩：這個bug管理系統并不是團隊每個成員經常登錄的系統，這就導致遇到bug時，需要經過“找出收藏的網址→登陸→依照指標輸入詳情→階段性查看最新進展”，如果遇到這個bug是用戶向你反饋而后你輸入到bug系統時，你還需要等幾天后給出反饋。
這冗長的環節和時間等待，讓我有點失去耐心，等到后來遇到用戶反饋的bug我往往直接找技術反饋、處理而繞過bug管理系統。這樣做肯定會影響到技術人員的開發效率，打斷其思路，是非常不好的工作習慣。
第三種我倒沒經歷過，嚴格來講，現在市面上“bug管理系統”也算是SaaS同行，但是這塊業務前景真的很小，一是互聯網公司開發bug管理系統并不困難，二是其未來的延展性并不大，所以市面上并沒有非常知名的“bug管理系統”。
購置“bug管理系統”還是會遇到和第二種一樣的境況，不經常提bug的人往往會繞過管理流程而直接找技術人員反饋。
那有沒有一種解決方案相較于上面三種方案：
1、節省企業成本；
2、降低“bug管理系統”使用門檻；
3、照顧技術人員處理方式；
4、照顧提bug人員、處理bug的技術人員、甄別bug的產品經理使用體驗？
我們日事清團隊目前所用的bug管理流程相較于上面三種解決方案就具備這四個優勢。我們把bug管理流程分為如下幾個狀態：收集→確認→其他→暫緩bug→開發中→測試中→已解決→發布并通知用戶→重復問題→提醒問題。
處理流程為：提bug人員將bug輸入到“收集”狀態，不需要像“bug管理系統”一樣篩選多種標簽，由產品助理/產品經理集中處理，視bug具體情況將bug拖拽到其他集中狀態。如果拖拽到“確認”，在該bug下添加相應技術人員讓其處理，技術人員會在日事清協作系統內收到通知并且bug同步到其收納箱，方便技術人員集中處理，解決后由技術人員拖拽到“已解決”狀態卡片。
相比上面三種解決方案，利用日事清計劃模塊進行bug管理具備如下優勢：
1、日事清是團隊成員辦公平臺，不存在增加團隊成員使用成本問題；
2、由產品助理/產品經理集中甄別bug并和技術人員延時溝通，杜絕其他成員直接聯系技術人員詢問打擾其工作；
3、如果bug狀態發生改變，比如“已解決”、“評論溝通”等，提bug人員會收到通知，可以實時跟進bug狀態，提bug人員更可階段性點擊“bug管理”模塊查看實時狀態；
4、無需單獨購置一套bug管理系統，直接在辦公平臺流暢解決；
5、相比獨自開發的bug管理系統，具備更優秀、順暢的使用體驗。
PS：昨天其實寫了一半去開會了，然后早上打開簡書發現被很多人看到，趕緊補充了剩下的一半。
