> ## 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/thinking/product-thinking) 问的是“这个结果值不值得做”；本原则接着问：以你现在知道的为准，这一次应该做到多精？
Chu 给的是一只气压计，不是“永远求快”或“永远不许将就”的口号。这条谱上有三种基本姿态：若对问题是否重要把握很低，就侧重速度；若对问题和方案都有把握，就侧重质量；若确信问题重要、却还不确信方案对，就两者兼顾——短周期迭代，证据上来后再抬高标准。
### 信心决定速度与质量的三层理解
* **入门**：动手之前先问一句“我有多确定这个问题是真的？”若诚实的答案是“不太确定”，就把第一版做得又便宜又快，好用来学习。
* **实践**：给两个分数打 1 到 5，并写下证据：问题重要性、方案正确性。问题分低，就先做测试；两分都高，就抬高质量门槛；问题高、方案低，就走短周期的[迭代改进](/zh/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/principles/yagni-principle)（You Aren't Gonna Need It）提醒人们：不要为用不上的灵活性预支工艺。Eric Ries 的《精益创业》（2011）把最小可行产品变成学习装置：当关键假设还没被检验，第一版的任务是证据，不是抛光。Chu 的贡献是把信心拆成两个问题——问题和方案——并明确说出每一对分数对应哪种配比。
同一篇 2018 年文章里，Chu 还区分了实验、功能与平台：实验可以粗糙，因为它的工作是学习；平台必须稳，因为别人会盖在它上面。
## 核心要点
这条原则有四个活动部件：两个信心问题、三种默认姿态、一条证据规则，以及一句警告——不要把这一次赌注和整条交付系统混为一谈。
不要问含糊的“我们有信心吗？”要分开问。第一，你有多确定这个问题对所服务的人足够重要？第二，你有多确定当前方案就是对的？团队完全可能痛点找对了、解法找错了。学生完全可能确定一门技能有用，却仍在猜哪门课真能教会。把两个分数写下来，免得它们悄悄合成一个感觉。
对问题是否重要把握很低：优化速度。Chu 举过的例子是：给一个还不存在的功能做落地页，只用来测量兴趣。对问题和方案都有把握：不要走捷径，因为用户会长期与这件作品相处。问题把握高、方案把握低：速度与质量兼顾，短周期推进，让证据去抬高标准。信心是刻度，不是开关，所以产出是配比，不是口号。
心情不是信心。Chu 的高质量一端要求信心“经过用户验证”，所以分数要落在证据上，而不是感觉上。创始人“就是知道”市场要这个功能，那是愿望。五笔付费预购、等待名单暴涨，或一次失败的假门测试，才是证据。每次测试后改分数。[快速失败](/zh/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/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/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.