Quality means doing it right when no one is looking.
— Henry Ford
雖然當年福特這句話的語境不太一樣，但是對品質這件事的描述，也可以說是回到最核心的定義，就是把事情做對，這麼多年的管理經驗中，我們會下意識地在一個專案中找尋足以代表品質的指標或事物，用來快速衡量我們所面對的挑戰，但不一定適用每一個場景，我們這次只談大部分情況下都還算好用的那些。
問題追蹤制度
你一定會有疑問，這不是所有專案都會有的嗎？我們談的不是制度本身，是一些執行上的關鍵行為。
客服收到的問題與研發團隊沒同步
說沒同步其實是客氣的，非軟體產品的團隊，大部分客戶問題是沒有進到PM視野的，就算有也是過濾後的，畢竟在組織架構中，研發團隊與客服團隊通常會由不同部門負責，對應的管理指標也會不同，有沒有"完全"同步肯定不會在這個指標當中。
這帶來的後遺症，就是當一些小問題的趨勢沒有辦法被有效掌握時，客戶對品質的體感也會與研發團隊不同，時間拉長來看，面對的就是研發的流程與規劃，與品質就有一定程度的脫鉤，或多或少。
嚴重性評估
有沒有過這種經驗？客戶覺得「完全不能用」，客服覺得「每天都有人打電話來」，PM 說「應該只是個小 bug」，研發卻回「這個要大改架構，沒那麼快」。同一件事，聽起來每個人的描述都不一樣，嚴重程度也天差地遠。
問題就在於，缺少一個大家共同的「標尺」。當沒有統一的方式去看待嚴重性時，小事可能被放大，大事卻被忽略。長久下來，不僅會讓團隊內部溝通失焦，也會讓外部的品質感受和內部的判斷越來越脫節。
很多專案裡一定都會有「優先級」，但優先級更多是排程用的：先做什麼、後做什麼。而問題本身如果沒有嚴重性評估，優先級就容易被誤用來代表「嚴重不嚴重」。其實這兩件事完全不同，混在一起只會讓大家越講越亂。
有經驗的SQA在團隊裡都會引入嚴謹的嚴重性定義，目的除了不要讓優先級誤導品質的判斷外，通常拿來評估軟體品質是否在往好的方向收斂，如果沒有嚴重性評估不代表不好，只是評估品質這件事大概只能靠感覺。
不能重現就不紀錄(或關閉)
這應該很多人都遇過：客服或使用者回報了一個狀況，結果研發試了一下，沒辦法重現，就直接標註「無法重現」然後結案。看似合理，但實際上卻很危險。
因為「不能重現」並不等於「不存在」，有時只是條件難以觸發，或是在特定環境下才會出現，有時候，只是研發用的環境跟大部分客戶不同。當這些紀錄都消失在系統裡，團隊就失去了觀察趨勢的機會。很多零散的小問題，如果能被保留下來，往往能在數量累積後，幫助大家看出趨勢並投入在這些還沒有大規模發生的問題。
所以，真正要避免的不是「紀錄下不能重現的問題」，而是「讓它們被忽略」。就算暫時解不開，也應該先留下線索，未來才有機會拼湊出更完整的畫面。
紀錄分散
雖然已經比較少見了，但最近這一年的客戶中還是有近1/4的團隊是用Excel(或其他試算表)在管理問題，每每看到，我都得佩服一下這個團隊，這樣的管理難度其實是很高的，更不用多長期的品質保證，但是，的確也有PM能用Excel把整個專案掌握得非常好，不過這麼多年也就遇過一個，大部分用這種方法管理的專案，都是在一堆表格中游走，團隊的共同意識也比較弱，當然品質就不容易保證了。
開發流程
如同前面說的，這篇不是要你懂開發流程，我們只談可以快速判斷的方法，所以不用擔心，繼續讀下去。
明確的起點與終點
有些專案在進行時，團隊其實不太知道「這個版本到底要做什麼？」、「什麼時候算做完？」。如果沒有一個清楚的起點（要做哪些功能）和終點（這次交付了哪些東西），那品質的檢查就變得模糊，因為根本不知道該檢查什麼。
一個簡單的方法就是：有沒有對內部公開的發版計劃(Release Plan)，發版之後有沒有發版紀錄(Release Note)可以追蹤。這些東西不是只寫給研發的，而是要讓所有人知道專案的節奏和邊界。
有始有終，圈定範圍後，我們至少知道是問題是發生在範圍內還是範圍外，範圍內，我們就解決發版前驗證的事，範圍外，我們就解決研發流程與規範的問題。
發版前後的驗證
發版就像搬新家，總要有人檢查燈能不能開、水有沒有流。很多團隊會做開發內部的測試，但發版前後的「驗收」如果沒有透明流程，最後只能用「客戶投訴」來驗證，所以如果你們一發版就會收客戶投訴，先考慮添加一個簡單有效的發版前或發版後驗證吧。
非研發人員其實也可以參與這個驗證，只要問兩個簡單的問題：
1. 發版前，有沒有一份檢查清單？
2. 發版後，有沒有確認過關鍵功能還能正常使用？
只要這兩步能被固定下來，品質感受就會差很多。
固定節奏的回顧(Retro)
很多團隊在專案結束或發版之後，就急著進入下一輪工作，回顧往往被跳過。但沒有回顧，代表團隊永遠只能「解決眼前的 bug」，卻很難真正改善長期的品質問題。
回顧的價值不是形式，而是提供一個固定的時間，讓大家把這次遇到的問題、好的做法、甚至客戶的回饋拉到檯面上。只有這樣，團隊才有機會調整流程，而不是永遠在同樣的坑裡跌倒。
簡言之，回顧不是浪費時間，它其實是讓品質能「越做越好」的保險。
最後..
品質從來不只是研發團隊的責任，它其實反映在整個組織怎麼收集問題、怎麼判斷問題、以及怎麼驗證交付的成果。對非研發人員來說，不需要會寫程式，也能透過「問題追蹤制度」和「開發流程」這些簡單的觀察點，快速判斷專案的品質是否在正確的方向上。
換個角度想，品質不是一組數字或報表，而是你能不能清楚看到問題被記錄、被理解、被改善。當這些環節都能持續收斂，品質才會真正穩定下來。
還是不知道該怎麼做的話，找我們聊聊吧！
https://forms.gle/SpugbMsHQ4JgNfix8