[{"data":1,"prerenderedAt":51},["ShallowReactive",2],{"article-zh-simply-check-product-quality":3},{"article":4,"related":19,"prevArticle":41,"nextArticle":45,"availableLocales":49},{"id":5,"slug":6,"image":7,"date":8,"published":9,"created_at":10,"updated_at":11,"title":12,"excerpt":13,"content":14,"custom_css":15,"keywords":16,"meta_description":17,"og_image":15,"image_width":18,"image_height":18,"category":15},"08e92d96-ea14-4bff-ab89-ec0d37ab9fd4","simply-check-product-quality","https://cdn.sqa.tw/blog_pictures/quality_puzzle.jpg","2025-09-20T09:18:00+00:00",true,"2025-09-22T09:36:46.668073+00:00","2025-09-22T14:22:32.313+00:00","怎麼簡單地檢查專案或產品品質？","如果不是軟體研發人員，我們其實很難評估目前專案跟產品的品質，我們這次不談太專業的內容，就從一般非研發人員也能簡單操作的方法，讓大家能夠評估自己的專案或產品","\u003Cblockquote>\n  \u003Cp>\u003Cem>Quality means doing it right when no one is looking.\u003C/em>\u003C/p>\n  \u003Cp style=\"text-align:right; margin-right:10px;\">— Henry Ford\u003C/p>\n\u003C/blockquote>\n\n\u003Cp>雖然當年福特這句話的語境不太一樣，但是對品質這件事的描述，也可以說是回到最核心的定義，就是把事情做對，這麼多年的管理經驗中，我們會下意識地在一個專案中找尋足以代表品質的指標或事物，用來快速衡量我們所面對的挑戰，但不一定適用每一個場景，我們這次只談大部分情況下都還算好用的那些。\u003C/p>\n\n\u003Ch2>問題追蹤制度\u003C/h2>\n\u003Cp>你一定會有疑問，這不是所有專案都會有的嗎？我們談的不是制度本身，是一些執行上的關鍵行為。\u003C/p>\n\n\u003Ch3>\u003Cem>客服收到的問題與研發團隊沒同步\u003C/em>\u003C/h3>\n\u003Cp>說沒同步其實是客氣的，非軟體產品的團隊，大部分客戶問題是沒有進到PM視野的，就算有也是過濾後的，畢竟在組織架構中，研發團隊與客服團隊通常會由不同部門負責，對應的管理指標也會不同，有沒有\"完全\"同步肯定不會在這個指標當中。\u003C/p>\n\n\u003Cp>這帶來的後遺症，就是當一些小問題的趨勢沒有辦法被有效掌握時，客戶對品質的體感也會與研發團隊不同，時間拉長來看，面對的就是研發的流程與規劃，與品質就有一定程度的脫鉤，或多或少。\u003C/p>\n\n\u003Ch3>\u003Cem>嚴重性評估\u003C/em>\u003C/h3>\n\u003Cp>有沒有過這種經驗？客戶覺得「完全不能用」，客服覺得「每天都有人打電話來」，PM 說「應該只是個小 bug」，研發卻回「這個要大改架構，沒那麼快」。同一件事，聽起來每個人的描述都不一樣，嚴重程度也天差地遠。\u003C/p>\n\n\u003Cp>問題就在於，缺少一個大家共同的「標尺」。當沒有統一的方式去看待嚴重性時，小事可能被放大，大事卻被忽略。長久下來，不僅會讓團隊內部溝通失焦，也會讓外部的品質感受和內部的判斷越來越脫節。\u003C/p>\n\n\u003Cp>很多專案裡一定都會有「優先級」，但優先級更多是排程用的：先做什麼、後做什麼。而問題本身如果沒有嚴重性評估，優先級就容易被誤用來代表「嚴重不嚴重」。其實這兩件事完全不同，混在一起只會讓大家越講越亂。\u003C/p>\n\n\u003Cp>有經驗的SQA在團隊裡都會引入嚴謹的嚴重性定義，目的除了不要讓優先級誤導品質的判斷外，通常拿來評估軟體品質是否在往好的方向收斂，如果沒有嚴重性評估不代表不好，只是評估品質這件事大概只能靠感覺。\u003C/p>\n\n\u003Ch3>\u003Cem>不能重現就不紀錄(或關閉)\u003C/em>\u003C/h3>\n\u003Cp>這應該很多人都遇過：客服或使用者回報了一個狀況，結果研發試了一下，沒辦法重現，就直接標註「無法重現」然後結案。看似合理，但實際上卻很危險。\u003C/p>\n\n\u003Cp>因為「不能重現」並不等於「不存在」，有時只是條件難以觸發，或是在特定環境下才會出現，有時候，只是研發用的環境跟大部分客戶不同。當這些紀錄都消失在系統裡，團隊就失去了觀察趨勢的機會。很多零散的小問題，如果能被保留下來，往往能在數量累積後，幫助大家看出趨勢並投入在這些還沒有大規模發生的問題。\u003C/p>\n\n\u003Cp>所以，真正要避免的不是「紀錄下不能重現的問題」，而是「讓它們被忽略」。就算暫時解不開，也應該先留下線索，未來才有機會拼湊出更完整的畫面。\u003C/p>\n\n\u003Ch3>\u003Cem>紀錄分散\u003C/em>\u003C/h3>\n\u003Cp>雖然已經比較少見了，但最近這一年的客戶中還是有近1/4的團隊是用Excel(或其他試算表)在管理問題，每每看到，我都得佩服一下這個團隊，這樣的管理難度其實是很高的，更不用多長期的品質保證，但是，的確也有PM能用Excel把整個專案掌握得非常好，不過這麼多年也就遇過一個，大部分用這種方法管理的專案，都是在一堆表格中游走，團隊的共同意識也比較弱，當然品質就不容易保證了。\u003C/p>\n\n\u003Ch2>開發流程\u003C/h2>\n\u003Cp>如同前面說的，這篇不是要你懂開發流程，我們只談可以快速判斷的方法，所以不用擔心，繼續讀下去。\u003C/p>\n\n\u003Ch3>\u003Cem>明確的起點與終點\u003C/em>\u003C/h3>\n\u003Cp>有些專案在進行時，團隊其實不太知道「這個版本到底要做什麼？」、「什麼時候算做完？」。如果沒有一個清楚的起點（要做哪些功能）和終點（這次交付了哪些東西），那品質的檢查就變得模糊，因為根本不知道該檢查什麼。\u003C/p>\n\u003Cp>一個簡單的方法就是：有沒有對內部公開的發版計劃(Release Plan)，發版之後有沒有發版紀錄(Release Note)可以追蹤。這些東西不是只寫給研發的，而是要讓所有人知道專案的節奏和邊界。\u003C/p>  \n\u003Cp>有始有終，圈定範圍後，我們至少知道是問題是發生在範圍內還是範圍外，範圍內，我們就解決發版前驗證的事，範圍外，我們就解決研發流程與規範的問題。\u003C/p>\n\n\u003Ch3>\u003Cem>發版前後的驗證\u003C/em>\u003C/h3>\n\u003Cp>發版就像搬新家，總要有人檢查燈能不能開、水有沒有流。很多團隊會做開發內部的測試，但發版前後的「驗收」如果沒有透明流程，最後只能用「客戶投訴」來驗證，所以如果你們一發版就會收客戶投訴，先考慮添加一個簡單有效的發版前或發版後驗證吧。\u003C/p>\n\n\u003Cp>非研發人員其實也可以參與這個驗證，只要問兩個簡單的問題：\u003Cbr>\n1. 發版前，有沒有一份檢查清單？\u003Cbr>\n2. 發版後，有沒有確認過關鍵功能還能正常使用？\u003Cbr>\n只要這兩步能被固定下來，品質感受就會差很多。\u003C/p>  \n\n\u003Ch3>\u003Cem>固定節奏的回顧(Retro)\u003C/em>\u003C/h3>\n\u003Cp>很多團隊在專案結束或發版之後，就急著進入下一輪工作，回顧往往被跳過。但沒有回顧，代表團隊永遠只能「解決眼前的 bug」，卻很難真正改善長期的品質問題。\u003C/p>\n\n\u003Cp>回顧的價值不是形式，而是提供一個固定的時間，讓大家把這次遇到的問題、好的做法、甚至客戶的回饋拉到檯面上。只有這樣，團隊才有機會調整流程，而不是永遠在同樣的坑裡跌倒。\u003C/p>\n\n\u003Cp>簡言之，回顧不是浪費時間，它其實是讓品質能「越做越好」的保險。\u003C/p>\n\n\u003Ch2>最後..\u003C/h2>\n\u003Cp>品質從來不只是研發團隊的責任，它其實反映在整個組織怎麼收集問題、怎麼判斷問題、以及怎麼驗證交付的成果。對非研發人員來說，不需要會寫程式，也能透過「問題追蹤制度」和「開發流程」這些簡單的觀察點，快速判斷專案的品質是否在正確的方向上。\u003C/p>\n\n\u003Cp>換個角度想，品質不是一組數字或報表，而是你能不能清楚看到問題被記錄、被理解、被改善。當這些環節都能持續收斂，品質才會真正穩定下來。\u003C/p>\n\n\u003Cp>\u003Cem>還是不知道該怎麼做的話，找我們聊聊吧！\u003C/em>\u003Cbr>\u003Ca href=\"https://forms.gle/SpugbMsHQ4JgNfix8\" target=\"_blank\">https://forms.gle/SpugbMsHQ4JgNfix8\u003C/a>\u003C/p>",null,"軟體品質, 品質管理, 問題追蹤, 開發流程, 非研發人員, 專案管理, release note, retro回顧","非研發人員也能快速看懂專案或產品的品質狀況！從問題追蹤制度到開發流程，我們分享幾個簡單好用的觀察點，幫助你判斷品質是否在正確方向上。",1024,[20,27,34],{"id":21,"slug":22,"title":23,"excerpt":24,"image":25,"date":26,"category":15},"deb70edd-ff7f-4b6e-b230-fa1c83dc0afa","qaptly-v0175-codex-support","Qaptly Desktop 開始支持 Codex","Qaptly Desktop 的 AI Assistant 從 v0.17.5 開始正式開放 Codex 支持。如果你本來就是 ChatGPT 訂閱用戶，現在可以直接讓 AI Assistant 使用 Codex，在日常測試設計與自動化調整上節省成本。","https://cdn.sqa.tw/blog_pictures/qaptly_support_codex.jpg","2026-05-16T13:01:00+00:00",{"id":28,"slug":29,"title":30,"excerpt":31,"image":32,"date":33,"category":15},"eebc38be-6eec-4e68-af7f-e5dd6c611a0f","ai-agent-workflow-critical-things","AI 協作進入 workflow 之後，那些最容易被低估、卻最關鍵的幾件事","過完年後，基本上都在幫幾間新創與大公司內部的開發部門導入 agentic development。這段時間看了不少團隊的做法，也有一些很直接的感受，想趁這個機會整理一下。","https://cdn.sqa.tw/articles/ai-workflow.jpg","2026-03-24T16:10:00+00:00",{"id":35,"slug":36,"title":37,"excerpt":38,"image":39,"date":40,"category":15},"1092dc59-4718-4902-809c-74cfdfc5fffd","from-tool-to-process-challenges","從單點工具到流程閉環的虛實與挑戰","探討2026年AI在軟體開發生命週期中的實踐，從單點工具普及化到流程閉環協作的轉變，以及QA自動化的真實與虛假繁榮。","https://cdn.sqa.tw/blog_pictures/from_tool_to_process.png","2026-03-02T03:06:00+00:00",{"slug":42,"title":43,"date":44},"qaptly-supports-macos-windows-desktop-app","Qaptly支持macOS 10.15+與Windows 10/11的Desktop App自動化了","2025-09-06T07:57:00+00:00",{"slug":46,"title":47,"date":48},"dont-build-you-own-ec-platform-team","為什麼我們不建議自建或委外開發電商網站","2025-10-30T06:44:00+00:00",[50],"zh",1786461720561]