交付品質 Baseline 與缺陷歸因

1 · 重點結論

• 最該處理的一件事是 CFR 100%。2026 至今 8 次正式版上線，沒有一次不需要後續 hotfix，平均每版 2.7 次。O1 策略文件記載的現況是「平均每次上線 0.9 次 hotfix（過高）」——實測比認知的還嚴重約 3 倍。
• 缺陷根因以邏輯實作為主（40%），其中「判斷條件錯誤」17 張為單一最大細項，加上「null／邊界值」11 張，兩項合計 20%——都是不需要環境就能測的類型。
• 但 13% 是「測不到」（效能、第三方設備、特定裝置）。這批再多測試也擋不住，要靠監控與灰度，應先從「測試沒做好」的檢討中移除，否則會導出錯誤結論。
• 兩個缺陷最多的模組，該做的事完全相反——預約與會員等級權益各 23 張，但一個要補監控、一個要補測試（見矩陣）。
• hotfix 的根因分佈與一般逃逸不同：迴歸類在 hotfix 佔 23%、在整體只佔 7%。會被緊急修的最大宗是「改動打壞既有功能」，不是新功能本身有問題。

2 · 交付頻率（DF）與變更失敗率（CFR）

資料源為 CNCY 的 [Infra] 上線卡。版本上線日只認卡片標題——Jira version 物件的 releaseDate 一律不採用（實測 BOB_2.99 標 06-04、實際 07-01，差近一個月），resolutiondate 亦不可用（卡片常晚關）。

• DF：8 次正式版上線，節奏每 4–5 週一版，極穩定。連 hotfix 計入則 27 次。
• CFR ＝ 100%：8 個版本全部產生後續 hotfix。2.100 也不例外——上線隔天就出 hotfix（5 張卡：三個管道的預約取消失效＋會員中心 QRCode）。

3 · 逃逸率

定義：某一版的缺陷中，沒有在該版修掉、隨該版出到客戶端的比例。

逐卡分類規則

① fixVersion 是 hotfix 版本                  → PROD 逃逸
② Version主版 == fixVersion主版（非 hotfix）  → UAT 攔截
③ Version主版 <  fixVersion主版               → PROD 逃逸（歸屬 Version 那一版）
④ 無 Version：建立日在官方 UAT 窗口內          → UAT 攔截，否則 → PROD 逃逸

Version 取自 CNCY 卡描述的 Version：{元件} v{版號}（覆蓋率 63%）；官方 UAT 窗口取自開發時程表（迄日以上線日截斷）。信度驗證：Version == fixVersion 的 195 張中有 190 張（97%）確實落在官方 UAT 窗口內。

可比的三版：49% → 62% → 40%。2.98 最差，2.99 明顯改善且優於 2.97。不可比的原因：2.96 的 CS 回報板 2026-05 才啟用、2.100 在線窗口未結束。

三個訊號

• 2.98 是明顯的壞版本——UAT 只攔到 25 張（四版最少），上線後逃了 40 張。UAT 沒測到東西，跟上線後爆掉，是同一件事的兩面。
• 2.99 確實改善了（62% → 40%），UAT 攔截從 25 張回升到 67 張。
• 2.100 的訊號跟 2.98 前夕一模一樣——UAT 只攔到 16 張（比 2.98 那次還少），上線當天就出現逃逸（三個管道的預約取消同時失效），隔天 hotfix。

4 · CS 回報有效率

超過一半的 CS 回報不是缺陷，但判定很快——不是流程卡住，是進來的東西本身就有一半不該進來。

5 · 處置時間分段

樣本＝與逃逸率分子相同的 74 張 CS 回報缺陷（已結案 51、在途 23）。已結案者從建立到修完的中位數 22.4 天、平均 24.7、P90 56.4。

四個結論

• 實作幾乎不花時間（中位數 0.0 天）。修問題不難，難的是排進去、審完、驗完。
• 等上版不是瓶頸（2.7 天）。因為 hotfix 太頻繁，不必等整個 4–5 週週期，隨時有車可搭——CFR 100% 這個品質問題，副作用竟是讓修復能快速上線。
• 真正的問題是長尾，不是中位數。各階段中位數合計僅 8.6 天，實際總時長中位數卻是 22.4 天——差距全在少數卡的極端停留（等安排版本最長 40.4 天、等 CS 判斷最長 29.9 天）。定期掃「某階段停留超過 7 天」的卡，比壓縮平均值有效。
• 「等正式站驗證」是被忽略的一段——平均 7.5 天為各階段最高。卡已修好上線卻長時間沒人回頭確認，這段對客戶零價值。

6 · 缺陷根因分佈

樣本 168 張逃逸缺陷，扣除環境問題 6 張、RCA 判定非缺陷 7 張、待歸因 17 張（多數仍在分析中）→ 已歸因 138 張。分類標準整合自團隊既有的後端與前端 Bug 定義，前後端共用一套。

「判斷條件錯誤 17」＋「null／邊界值 11」＝ 28 張（20%），這兩項是最典型的單元測試守備範圍，也是最不需要環境就能測的。

逃逸關卡：本來應該在哪一關被擋下

七成（97／138）落在單元／整合／UAT 三關，可靠測試改善。對照 O3 記載的「測試自動化 0%、80% 手動測試」，這裡是 O1 與 O3 最直接的交會點。

7 · 模組 × 逃逸關卡矩陣

這張表回答的是「哪個模組該補哪一種測試」——比單看模組缺陷數更能直接派工。

兩個並列第一的模組，該做的事完全相反

金流／發票（9 張）與第三方 POS（11 張）——整合測試各 7、6 張，根因皆以第三方整合為主。對策單一：第三方整合測試補異常回應的 mock（5xx、憑證失效、回傳結構變更）。這兩個模組的缺陷有共同模式：①存憑證沒驗證 ②第三方 5xx 沒重試 ③失敗被靜默吞掉。

8 · hotfix 子集分析（22 張）

hotfix ＝ 計畫外上線 ＝ 嚴重到不能等下一版。這批的根因分佈與整體明顯不同。

三個結論

• 會被 hotfix 的，最大宗是「改動打壞既有功能」。最典型的是 2.100：新增「取消原因收集」功能後，跨境預約網頁／Dashboard／APP 三個管道同時無法取消預約——三張卡同一天建立，是共用邏輯被改壞，不是三個獨立 bug。
• 整合測試與迴歸測試合計 13／22（59%）。hotfix 級缺陷的守備位置集中在「模組之間」與「改動的影響面」，不在單一函式內。單元測試只佔 2 張——寫再多單元測試也擋不住這批。
• 權限類在 hotfix 佔比翻倍，其中一張是門禁系統跨店開門（預約 A 店卻能開 B 店），屬實體安全事件。權限缺陷一旦逃逸，後果等級與其他類不同，應與商業邏輯錯誤分開處理。

9 · 行動清單

10 · 工時資料品質

• 總量沒有衰退——清洗後四個月落在 292–382h 區間，平盤。（先前「工時記錄正在崩壞」的判斷是收集端 bug 造成的假象，已作廢。）
• 四人團隊實際只有三人在記——一位成員自 5 月起完全沒有記錄。
• 「執行版本」欄位填寫率僅 33–57%，因此版本軸生產力量度判定為不採用（投入側覆蓋率不足，交付側卡數因切分大小不可比）。刻意不產出數字，而非漏做。

11 · 已知限制

• Jira 是活資料。同一條查詢隔天結果就會變，任何數字必須連快照日期一起引用。
• 逃逸率只看趨勢、只做版本間比較。已拍板不追「引入版本」（判定一個問題是哪一版引入本質上太難，很多是更早存在但沒被發現，硬標會逼出亂填），因此客戶在某版期間回報的舊問題會全算到該版頭上。不對外承諾絕對值、不當 KR 驗收門檻。
• Version 欄位覆蓋率僅 63%，其餘 37% 靠「建立日是否落在官方 UAT 窗口」判定。2.98 那一輪只有 3 張填了 Version，是最脆弱的一版，其 62% 要打折看。
• 17 張待歸因（12% 樣本）多數仍在根因分析中，各類張數為下限。
• 開發板側的 RCA 密度低於 CS 回報板，部分卡片依標題與描述判斷，精度較粗。
• 「逃逸關卡」需人為判斷，單元／整合、迴歸／UAT 之間有灰色地帶。
• 未區分「本版引入」與「長期潛伏」——需 RCA 補追 git 歷史才能做（行動清單第 7 項）。
• 所有指標只比版本、不比人。跨人比較必然被個人記錄習慣與切卡習慣污染。