我想表達的品質的分級，并不是品質分級管理政策，而且在面對不同規模的品質團隊的時候，跟蹤品質采取的政策不一樣。
- 作為部門體系建設者，40-100人規模，疊代中的産品很多的情況下
- 品質資料，品質資料分為幾個方面，一個是prod bug，一個是prod bug逃逸率，比較分為，橫向比較和縱向比較，橫向是不同的時間段，自己和自己比；縱向，是同一個時間段，部門内部産品對比。比較的意義在于，形成探讨和争議的氛圍，進而激起大家的品質意識。并通過此，制定合理的品質目标。付出行動。我覺得我的團隊在此上做的并不好，品質資料放在那裡就在那裡了，沒有起到應有的效果。落實還是需要高層支援的
- prod bug納入問題管理，如果想以點帶線帶面，将問題厘清楚，那麼需要prod bug的5why分析法，分析到組織架構和品質體系優化層面
- 關注成本和效率。時間和人員都是企業的資源，縮短品質回報時間，控制人員成本，如何去做，需要全局評估
- 注意：不可以一個名額去評價某個産品的品質，需要多個品質資料協助分析
2. 一系列有關聯性的産品的品質負責人（10-20人）
- 有些品質，是可以通過品質資料的綜合分析進行擷取，有些是通過品質資料察覺不到的。比如，開發人員未按照架構設計去實作産品，因為産品需求的緊急性，在存儲資料方面，尤其在跨系統內建上，就近存儲進而避免和其他團隊的溝通；又比如前後端設計上， 業務邏輯放在前端做處理。這些是JIRA，或則bug中無法察覺的點，需要深入技術細節才能發現。這就需要品質負責人敏銳的嗅覺，産品意識，架構思維同時又能深入一線
- 問題定位，同問題管理，一個生産事故和prod bug往往都是品質體系不完善的很好的切入點。我目前發現的品質問題，很多根本原因都是組織架構不合理導緻，比如，産品人員，來自不同的部分，彼此産品有緊密關聯的情況下，大家會從自己最友善的角度考慮，而缺乏全盤的産品架構的設計；比如，同一類型的産品，技術架構分屬于不同的團隊，技術缺乏統籌此類的問題
3. 一線測試人員
- 測試覆寫率
- 有無合理的測試政策進行全部覆寫并且能快速給出回報
- 能否基于真正使用者的角度去考慮，測試使用者産品。這點很多測試人員十分缺失，我們更多追求測試的花樣性，而缺乏對于産品價值的認真思考。我們有出現過為了追求新技術的應用，影響使用者基礎功能的情況
