生命週期、指標與四種反模式
一句話總結：MVP 階段追求完美是浪費，Maturity 階段不追求品質是自殺。用對指標衡量、避開四種反模式，你的產品才能活得久。
結論先講：在 MVP 階段不需要 100% 測試覆蓋率，在 Maturity 階段不能沒有 SLO。品質標準是動態的，不是固定的。而且，當指標變成目標，它就不再是好指標——Goodhart’s Law。
產品生命週期：每個階段的品質標準不同
產品不是靜態的。它會經歷 MVP → Growth → Maturity → Sunset，而每個階段「品質」的定義完全不同。
| 面向 | MVP 階段 | Growth 階段 | Maturity 階段 |
|---|---|---|---|
| 核心目標 | 驗證 PMF | 快速獲取用戶 | 穩定營運 |
| 技術品質 | 能跑就好 | 解決效能瓶頸 | 全面監控 + SLO |
| 測試 | 核心流程 E2E | 補 integration test | 全面覆蓋 |
| 文件 | README 就好 | 補 API docs、ADR | 完整文件體系 |
| 技術債容忍度 | 高（有意識地承擔） | 中（邊做邊還） | 低（嚴格管控） |
| 部署頻率 | 隨時 | 每天多次 | 有節奏地（每週） |
| 團隊規模 | 2-5 人 | 5-20 人 | 20+ 人 |
不要用 Maturity 階段的標準來要求 MVP。三人團隊花一個月建完整的 observability 系統，然後產品還沒驗證有人要用——這是資源的極大浪費。反過來，百人團隊的成熟產品還在用「能跑就好」的標準——那是在玩火。
DORA Metrics：最被認可的交付效能指標
DORA 的四個指標是業界衡量軟體交付效能的標準：
| 指標 | Elite | High | Medium | Low |
|---|---|---|---|---|
| 部署頻率 | 一天多次 | 每天~每週 | 每週~每月 | 每月~每半年 |
| Lead Time | < 1 天 | 1 天~1 週 | 1 週~1 月 | 1-6 個月 |
| MTTR | < 1 小時 | < 1 天 | < 1 週 | > 6 個月 |
| Change Failure Rate | 0-15% | 16-30% | 16-30% | > 45% |
DORA 研究最反直覺的發現：部署頻率高的團隊，失敗率反而更低。 這打破了「部署越多越容易出事」的想法。原因很簡單：頻繁部署 = 每次變更量小 = 問題更容易發現和定位 = 回滾風險更低。
SLI / SLO / SLA：怎麼量化「夠不夠好」
| 概念 | 白話翻譯 | 誰設定 |
|---|---|---|
| SLI（Service Level Indicator） | 量化服務品質的指標 | 工程團隊 |
| SLO（Service Level Objective） | 那個指標的目標值 | 工程 + 產品 |
| SLA（Service Level Agreement） | 對外承諾，達不到要賠錢 | 業務 + 法務 |
設定 SLO 的建議：從使用者體驗出發（不是技術限制）、不要設太高（99.999% 的代價是巨大的）、留 Error Budget（99.9% 的 SLO 意味著每月有 43 分鐘可以用來部署和實驗）、每季 review。
大多數產品 99.9% 的可用性就夠了。你真的需要 99.99% 嗎？每月只能停 4.3 分鐘，你連一次正常的部署都不能做。
NPS 和客服工單：使用者怎麼想
NPS（Net Promoter Score） 問一個問題：「你會推薦這個產品嗎？0-10 分。」9-10 是推薦者，7-8 是被動者，0-6 是批評者。NPS = 推薦者% - 批評者%。
| NPS | 評價 |
|---|---|
| > 70 | 世界級 |
| 50-70 | 優秀 |
| 30-50 | 良好 |
| < 0 | 有嚴重問題 |
客服工單量 是另一面鏡子。工單類型反映了產品問題：「不知道怎麼用」= UX 問題、「功能壞了」= 可靠性問題、「太慢」= 效能問題、「資料不見」= 資料可靠性問題。每 1000 活躍使用者的月工單數如果持續上升，產品品質在惡化。
四種反模式
反模式一：技術完美主義
追求 100% 覆蓋率但產品還沒有使用者。花三週設計完美的 DB schema 但需求還在變。重構已經運作良好的程式碼只因為它「不夠優雅」。
自我檢測： 如果花在 refactoring 上的時間超過交付使用者價值的時間，你中了。
解方：設明確的品質基線，用「使用者會不會受影響」來判斷優先級。Perfect is the enemy of good。
反模式二：快速交付陷阱
每週 ship 5 個新功能，但 bug 增長速度比功能還快。沒測試、沒 code review、沒文件。「之後會回來修」——才怪。
自我檢測： 如果修 bug 的時間超過做新功能的時間，你中了。
解方：設品質門檻（每個 PR 必須 review + 測試）、每個 sprint 留 20% 給技術債、追蹤「修 bug 時間佔比」超過 30% 要亮紅燈。
反模式三：指標遊戲
為了覆蓋率寫 expect(true).toBe(true)。為了降低 MTTR 調低告警嚴重等級——不告警就沒有 incident！為了 DAU 用煩人的 push notification 拉人回來。
Goodhart’s Law：當指標變成目標，它就不再是好指標。
自我檢測： 如果所有指標都在改善但使用者回饋沒有變好，你中了。
解方：用多個互相制衡的指標（同時看部署頻率和 failure rate）、關注趨勢不是絕對數字、鼓勵質疑指標的文化。
反模式四：英雄文化
每次出問題都是同一個人半夜起來修。某個「10x developer」寫了系統最核心的部分，只有他看得懂。「沒有 XXX 我們不行。」
自我檢測： 如果某個人休假時大家會特別緊張，你中了。
解方：英雄的知識文件化、強制 code review（包括英雄的程式碼）、on-call rotation 每個人都要參與。不要獎勵「救火」，要獎勵「防火」。
務實建議：平衡而非最大化
沒有產品能在所有維度做到完美。關鍵是在你的情境下做對的 trade-off：
| 情境 | 優先的維度 | 可以暫時犧牲的 |
|---|---|---|
| 新創 MVP | 商業價值、UX | 可維護性 |
| 企業軟體 | 可靠性、安全性 | 部署速度 |
| 消費者 App | UX、效能 | 內部程式碼品質 |
| 金融系統 | 安全性、可靠性 | 開發速度 |
每次做技術決策時問自己：影響範圍多大？改動成本會隨時間增加嗎？使用者會受影響嗎？影響範圍大且改動成本會增加的事情——現在就做好。影響範圍小且成本不變的——之後再做，Good enough for now。
系列總結
好產品是在特定階段、特定資源限制下，對五個維度做出最適當的平衡：
- 使用者體驗：好不好用
- 技術品質：效能、可靠性、安全性
- 可維護性：能不能持續進化
- 商業價值：有沒有人要
- 團隊與流程：能不能持續交付
最終標準只有一個：在使用者需要的時候，穩定地、可靠地、愉快地為他們解決問題。
系列文章：
- 好產品的定義（一）：好專案 vs 好產品
- 好產品的定義（二）：技術品質
- 好產品的定義（三）：可維護性
- 好產品的定義（四）：商業價值與團隊
- 你在這裡 → 好產品的定義（五）：生命週期、指標與反模式
延伸閱讀：
「好產品的標準只有一個——使用者需要你的時候你在，使用者不需要你的時候你不煩。」