> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.
# 信心決定速度與品質
> 信心決定速度與品質是指：對問題重要性與方案正確性的把握，決定產品該求快還是求精。了解其起源、用法與邊界。
**類別**: 原則
**類型**: 決策原則
**起源**: Brandon Chu，《Product Management Mental Models for Everyone》，2018
**別名**: 速度與品質權衡、置信度決定速度與品質
**快速回答** — **信心決定速度與品質**（Confidence Determines Speed vs. Quality）是一條關於「該求快還是該求精」的決策規則。Brandon Chu 在 2018 年提出：你對問題是否重要、方案是否正確的把握，應當決定速度與品質的配比。實務上的啟示很直接。若還不確定問題是否真實存在，就先求快、先學習；若問題和方案都已經站得住，就不要再走捷徑。
## 什麼是信心決定速度與品質？
**信心決定速度與品質**（Confidence Determines Speed vs. Quality）是一條決策原則：你對問題和方案有多大把握，應當決定這次是最佳化速度，還是最佳化品質。
> 你對以下兩點的信心——（1）所解問題的重要性，（2）所構建方案的正確性——應當決定你在產品構建中願意在速度與品質之間做多大權衡。 —— Brandon Chu，2018
可以把它想成做飯。一道從沒做過的菜，先買普通食材、小鍋試味。已經做過五十次、要上婚宴的蛋糕，就不要現場即興。[產品思維](/zh-hant/thinking/product-thinking) 問的是「這個結果值不值得做」；本原則接著問：以你現在知道的為準，這一次應該做到多精？
Chu 給的是一隻氣壓計，不是「永遠求快」或「永遠不許將就」的口號。這條譜上有三種基本姿態：若對問題是否重要把握很低，就側重速度；若對問題和方案都有把握，就側重品質；若確信問題重要、卻還不確信方案對，就兩者兼顧——短週期迭代，證據上來後再抬高標準。
### 信心決定速度與品質的三層理解
* **入門**：動手之前先問一句「我有多確定這個問題是真的？」若誠實的答案是「不太確定」，就把第一版做得又便宜又快，好用來學習。
* **實踐**：給兩個分數打 1 到 5，並寫下證據：問題重要性、方案正確性。問題分低，就先做測試；兩分都高，就抬高品質門檻；問題高、方案低，就走短週期的[迭代改進](/zh-hant/principles/iterate-and-improve)，直到其中一個分數真正移動。
* **進階**：這裡權衡的是**這一次賭注的工藝**，不是整條交付系統的品質。測試鬆、回滾慢的團隊，並沒有資格在功能上「選擇品質」。還要看二階後果：在未驗證的問題上把工藝做滿，會養出一個不願被替換的既有方案。
## 起源
**信心決定速度與品質**由當時在 Shopify 擔任產品負責人的 **Brandon Chu** 命名。2018 年 8 月，他在文章《Product Management Mental Models for Everyone》裡把思維模型寫成建造者可用的格子架，而不只給職稱為產品經理的人。其中第 6 條就是這條規則。
一年前他已經畫過同一條譜。2017 年 3 月的《Ruthless Prioritization》裡，他主張速度與品質的配比應跟著產品假設走：可能是問題本身還是假設，可能是方案還是假設，也可能兩者都已不是假設。2018 年的文章給這隻氣壓計定了現在這個名字，並把兩條軸都接到「經使用者驗證的信心」上。
它有更早的親戚。極限編程在 1990 年代末由 Kent Beck 等人推廣的 [YAGNI](/zh-hant/principles/yagni-principle)（You Aren't Gonna Need It）提醒人們：不要為用不上的彈性預支工藝。Eric Ries 的《精益創業》（2011）把最小可行產品變成學習裝置：當關鍵假設還沒被檢驗，第一版的任務是證據，不是拋光。Chu 的貢獻是把信心拆成兩個問題——問題和方案——並明確說出每一對分數對應哪種配比。
同一篇 2018 年文章裡，Chu 還區分了實驗、功能與平台：實驗可以粗糙，因為它的工作是學習；平台必須穩，因為別人會蓋在它上面。
## 核心要點
這條原則有四個活動部件：兩個信心問題、三種預設姿態、一條證據規則，以及一句警告——不要把這一次賭注和整條交付系統混為一談。
不要問含糊的「我們有信心嗎？」要分開問。第一，你有多確定這個問題對所服務的人足夠重要？第二，你有多確定當前方案就是對的？團隊完全可能痛點找對了、解法找錯了。學生完全可能確定一項技能有用，卻仍在猜哪門課真能教會。把兩個分數寫下來，免得它們悄悄合成一個感覺。
對問題是否重要把握很低：最佳化速度。Chu 舉過的例子是：給一個還不存在的功能做登陸頁，只用來測量興趣。對問題和方案都有把握：不要走捷徑，因為使用者會長期與這件作品相處。問題把握高、方案把握低：速度與品質兼顧，短週期推進，讓證據去抬高標準。信心是刻度，不是開關，所以產出是配比，不是口號。
心情不是信心。Chu 的高品質一端要求信心「經過使用者驗證」，所以分數要落在證據上，而不是感覺上。創辦人「就是知道」市場要這個功能，那是願望。五筆付費預購、等待名單暴漲，或一次失敗的假門測試，才是證據。每次測試後改分數。[快速失敗](/zh-hant/principles/fail-fast) 在這裡很有用：弱問題儘快殺掉，好把工藝花在強問題上。
在未驗證的賭注上選擇速度，並不等於可以不做測試、備份和回滾。Nicole Forsgren、Jez Humble 與 Gene Kim 在《Accelerate》（2018）中總結：表現最好的技術組織，往往交付更快、系統也更穩。DORA 2019 年的 *Accelerate State of DevOps Report* 裡，精英組部署頻率是低績效組的 208 倍，變更失敗率卻低 7 倍。用本原則去設定**這一次賭注**的工藝；用工程紀律去保證快的賭注仍然可逆。
## 應用場景
當你發現一個團隊、一個家庭或一個公共機構把「更快」和「更好」當成身分、而不是分數在吵時，就該啟用信心決定速度與品質。
啟動會上把問題重要性和方案正確性打 1 到 5 分，並寫出證據。問題分只有 2，就做假門測試、人工代勞或一週原型，而不是先改平台。支付流程若是 5/5，就該有設計打磨、壓力測試，並且不許說「第二版再修」。
還不確定轉行是否適合自己？先別交兩年學費。去夜校、做小專案、做一次志願實踐——這是速度姿態。若三個月真實接觸後這件事仍然重要，再提高下一筆投資的品質。
新的課後班、新的飲食安排、新的照護節奏，常常是低把握的問題：你還不知道它適不適合這個家。先用便宜版本試兩週。把昂貴、難以撤回的版本——換學校、大裝修、醫療設備——留給需要和匹配都已經清楚的情況。這也符合[可逆性原則](/zh-hant/principles/reversibility-principle)的建議。
一座城市若還不確定公車專用道是否有用，應先刷臨時標線、測量客流，而不是憑直覺重建路緣。一旦證明問題重要，品質就應該進入永久設計：排水、標識與無障礙。社區計畫同理：先做六週試點，再變成有編制的服務。
## 經典案例
### Dropbox 的演示影片（2011 年記述）
2000 年代末，Drew Houston 正在做 Dropbox：一個容易讓人想要、卻很貴才能做完的檔案同步產品。跨裝置同步、衝突處理、無感資料夾，若一上來就按高品質來做，往往是好幾年的工程。當時真正開放的問題不只是「我們能不能做成」，還有「是否有足夠多人在意這個問題，值得我們把它做好？」
Houston 的團隊沒有等一個打磨完的公開產品來回答。據 Eric Ries 後來在《精益創業》以及 2011 年 10 月 19 日 TechCrunch 摘錄中的記述，Houston 做了一段約三分鐘的影片，展示產品「應當如何工作」。影片對準 Digg 上的早期採用者，並塞進只有那群人會心一笑的彩蛋。
> 它給網站帶來了成千上萬的造訪。我們的內測等待名單從 5,000 人變成 75,000 人，幾乎是一夜之間。我們完全驚呆了。 —— Drew Houston，轉引自 Eric Ries，2011
Houston 還說，24 小時內這段影片獲得了超過 10,000 個 Digg。這兩個數字——等待名單 75,000、一天 10,000 Diggs——證明問題的重要性達到了焦點小組看不出的規模。此後，把工藝砸進高品質同步引擎，不再是對需求的猜測，而是給一個已經把人拉過來的問題做精。
這正好對應信心決定速度與品質。對問題重要性的信心當時仍在累積，所以第一件公開作品最佳化的是學習速度，而不是生產級完成度。邊界也要說清：Houston 當時已有可執行的原型；影片能檢驗「看得見」的價值假設，卻檢驗不了只在真實使用中才出現的問題，比如平台信任或規模化物流。
## 邊界與失效場景
信心決定速度與品質是針對**某一次賭注**的工藝規則。它不是可以普遍偷工的藉口，也不保證速度與品質永遠反向運動。
1. **殺傷半徑很大時，「速度分」讓路。** 若一次實驗可能傷害病人、兒童安全、薪資發放或城市供水，就不能因為問題尚未驗證就交付劣質版本。把測試放進沙箱、志願者或極小切片。[艱難選擇模型](/zh-hant/models/hard-choice-model) 在這裡有用：即使信心低，影響也可以很高，而高影響仍然要求謹慎。
2. **交付系統的品質，不是同一筆權衡。** 《Accelerate》與 DORA 的研究發現，精英團隊往往既更快、也更穩。若流水線本身脆弱，功能上的「選擇速度」會漏成故障。先把系統修到快的賭注可以回滾，再把 Chu 的氣壓計用到賭注本身。
常見誤用是**姿態凍結**。曾經必須求快學習的團隊，在問題和方案都已證明之後，仍把結帳、身分、隱私做得很糙。另一類團隊則相反：把路演稿打磨幾個月，因為「品質」是他們的身分，而問題仍是猜測。請按日曆重新打那兩個分數，而不是只在專案啟動時打一次。
## 常見誤區
人們第一次聽到「速度對品質」時，下面三個錯誤最常見。
在單次賭注上，它們常常此消彼長：更多打磨通常更耗時。在系統層面，它們並不總是如此。DORA 的研究是這裡的提醒。小批次、自動化測試、快速回滾，往往能同時提高部署速度和穩定性。Chu 的規則管的是：以你現有的證據為準，這一次問題和方案該投入多少工藝——而不是工程紀律可有可無。
高把握證明你該抬高品質門檻，並不等於地圖可以凍結。市場會動，昨天已驗證的問題也可能變淡。即使是 5/5 的賭注，也留一隻便宜的探針：用量資料、客服工單、對相鄰任務的小實驗。信心是當前分數，不是獎盃。
這裡的速度，是指降低「猜錯」的成本，不是侮辱使用者。登陸頁、人工代勞、窄原型，都可以清晰、誠實、安全。你跳過的是用不上的架構、投機性的拋光，以及尚未掙來的規模。若第一版具有欺騙性或傷害性，你並沒有在用這條原則，你是把它丟掉了。
## 相關概念
下面這些概念與信心決定速度與品質相鄰：有的告訴你該做什麼，有的告訴你第一版該多可逆、多簡單。
從值得創造的使用者結果出發。本原則接著決定下一次嘗試該做到多精。
不要構建你不會用到的東西——問題和方案把握仍低時，你該省下的那部分品質。
立刻暴露錯誤的問題或錯誤的解法，這正是速度姿態的目的。
問題已真實、方案尚未掙到時的預設動作。
優先走雙向門，好讓快的賭注能撤回；門是單向時再抬高標準。
先給決策分類再選流程——在信心不高但影響很大時尤其有用。
## 一句話總結
**先給「問題是否重要」和「方案是否正確」打分，再讓這兩個分數決定配比：還在猜的時候求快學習，已經知道的時候拒絕捷徑。**
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.