目录
周一 10:00，站会。
「你那个导出功能怎么样了？」
「快了。」他说，「就差联调了。」
产品经理点点头，在表格里写下「进行中」。你看着白板，心里算了一下：这个「快了」已经持续了两周，而联调的另一方，上周才刚排期。
一、「快了」不是时间，是一个句号
「快了」有三个语法特征。
第一，它没有数值。「快了」可以和三天、三周、下个季度同时成立。你没法用日历去核对它，因为日历上根本没有这个刻度。
**第二，它没有宾语。**快了什么？是代码写完了，是测试通过了，还是能上线了？这三件事之间，通常隔着一个和「快」无关的距离。
**第三，它不可证伪。**你无法在当下证明它错，只能等。等到没有快，它已经自动变成了另一句话——「遇到点问题」。而「遇到点问题」同样没有数值，也同样是一个句号。
语言学家把这类句子叫「施为句」：说它，不是在描述世界，而是在做一件事。说「快了」，做的这件事是——结束这次对话。它和「改天一起吃饭」「我看看」属于同一个语用家族。
所以，与其说「快了」是一份进度，不如说它是一种方言。这种方言不是某个人发明的，而是组织在一次次站会里，把「说真话的成本」调高之后，大家慢慢学会的。
二、六种常见句法
1. 百分比黑箱
「整体完成了 90%。」
字面意思：还剩 10%。通常含义：90% 的分母，没有人定义过。
如果分母是代码行数，那 90% 的行数可能只对应 10% 的功能；如果分母是功能点，那「写完」和「能用」之间还隔着集成、异常路径、权限、监控和一堆没人写进需求文档的边界条件。90/90 法则说的就是这件事：前 90% 的代码用掉 90% 的时间，剩下 10% 的代码，再用掉另一个 90% 的时间。
重点不是那个数字，而是：当分母会变时，百分比就只是一个修辞。 它能让人安心，但没法让人排期。
2. 条件前置
「理论上跑通了。」「本地是好的。」「单元测试都过了。」
这些句子都带一个隐形的「如果」：如果数据是干净的，如果环境是一致的，如果只走正常路径。
「理论上」是进度汇报里信息量很高的三个字。它相当于承认「我没有在真实条件里验证过」，但语气上仍然维持了接近完成的印象。至于「本地是好的」，它的问题不在本地，而在「本地」和「线上」之间那些从来不一致的东西：时区、时钟、字符集、网络超时、别人的服务。
3. 剩余工作外置
「就差联调了。」「现在就等后端。」「等设计稿。」
这是把自己的剩余工作，描述成别人的前置条件。
联调不是「差一点」。联调是把两个各自「完成」的东西放到一起，一次性暴露所有没对齐的假设：字段类型、空值语义、错误码、重试策略、谁先超时。它经常是项目里第二长的一段，仅次于「一开始以为很快」的那一段。
4. 趋势替代位置
「比上周好多了。」「基本没问题了。」
这是在用斜率回答位置。上周 20 分，这周 40 分，确实好多了，但离 60 分及格还差一半。进步快和快到了，是两件事。
「基本」则是中文里弹性很大的一个限定词：基本能跑，意思是能跑，但会挂；基本对齐，意思是主流程对齐了，分支还没看。
5. 阶段名替代工作量
「在做收尾。」「在补测试。」「在改 bug。」
收尾、补测试、改 bug，都是没有边界的容器。一个 bug 可以改十分钟，也可以改三天；测试可以从 60% 覆盖率补到 80%，也可以补到「看起来够了」。阶段名让人听到「接近终点」，却没告诉你终点线画在哪。
6. 动作预支
「明天就能提测。」「周五应该能上。」
这是在用未来的动作，作为当下的证据。
这类句子的可信度，取决于一个经常被省略的变量：提测之后还有多久。提测不是上线，测试通过也不是上线，上线之后还有一轮只有真实流量才能触发的问题。把「明天提测」说出口的那一刻，听的人很容易自动把它换算成「快好了」，而说话的人心里想的可能只是「明天终于可以开始验证了」。
三、逐条翻译
| 原话 | 字面意思 | 更可能的含义 | 该问什么 |
|---|---|---|---|
| 完成了 90% | 还剩 10% | 分母没定义，或者分母刚变过 | 分母是什么？谁定义的？ |
| 理论上跑通了 | 逻辑上可行 | 没在真实数据和环境里验证过 | 哪个环境、什么数据、跑过哪条失败路径？ |
| 就差联调了 | 剩下对接 | 双方假设还没对齐，工作量未知 | 对方什么时候给环境？联调的验收标准是什么？ |
| 比上周好多了 | 有进展 | 有进展，但位置不明 | 离「能交付」还差哪几项？ |
| 在做收尾 | 接近结束 | 收尾清单还没列出来 | 收尾包含哪几件事？每件的完成标准？ |
| 明天提测 | 明天交给测试 | 测试、修复、回归都还没开始 | 测试要多久？发现问题怎么回滚？ |
四、为什么我们都这样说
把这六种句法串起来看，会发现它们共享同一个功能：把不可证伪的模糊，包装成可以点头的进展。
这不是人品问题，是激励结构问题。
先说披露成本。早说延期，你要当场解释、被质疑判断力，甚至可能被换人；晚说延期，如果后来赶上了，没人记得；如果没赶上，那也只是一次「意外」。在多数组织里，推迟披露坏消息的即时期望成本更低，于是每一次站会，理性的选择都是再往后推一点。
再说层级。每个人向上汇报时加一点乐观，三层之后，「有风险」会变成「正常」，「正常」会变成「超前」。这不叫撒谎，叫汇总乐观。信息每经过一层，就被磨掉一点棱角，等到决策者看到的时候，已经是一块圆润的鹅卵石。
还有认知层面的原因。Kahneman 和 Tversky 在研究「计划谬误」时指出，人做预测时习惯用内部视角：盯着这次任务的特殊性，忽略同类任务过去实际花了多久。被问「这个功能要多久」时，脑子里放映的是顺利路径的那部电影，而不是过去十个功能的真实耗时分布。
Flyvbjerg 在研究大型工程时，进一步区分了两种低估：一种是乐观偏差，真诚地相信事情会顺利；另一种是策略性失实，知道不顺利，但为了拿到资源、保住位置，仍然报出一个好看的数。日常站会里，两种都有。有人真的相信「快了」，也有人知道不快，只是不想在周一上午十点说。
还有一层容易被忽略：说「快了」的人，往往自己也在等。等接口、等审批、等一个不确定的答复。把不确定性说成「快了」，是给自己留一点继续等的空间。
顺带一提，如果延期已经发生，加人通常不是解药。Brooks 在《人月神话》里那句话已经被引用了五十年：向进度落后的项目增加人手，只会让它更落后。沟通成本和培训成本会先于产出到达。
五、怎么问出真话
追问的目的不是抓谎，而是把不可证伪的句子，换成可证伪的句子。以下是五个可以直接用的问题，各自对应一种句法。
- 「这个 90% 的分母是什么？」 对应百分比黑箱。先定义「完成」，再谈比例。
- 「上次站会到现在，合并了哪些提交？下一步动哪个文件或接口？」 对应趋势替代位置。用最近的实际动作校准速度，比听形容词可靠。
- 「如果今天必须交付，你会砍掉哪一块？」 对应阶段名替代工作量。强制排序，会把真实剩余挤到桌面上。
- 「什么情况下会延期？触发条件是什么？」 对应条件前置。把风险变成可监控的信号，而不是等它变成事故。
- 「现在卡在谁那里？需要他做什么、什么时候做？」 对应剩余工作外置。把被外置的工作重新拉回这次对话。
问法上有两个细节。
其一，不要问「能不能按时完成」。这是一个只能回答「能」的问题，对方说「不能」的代价太高，于是你得到的答案没有信息量。
其二，安全出口要说在前面，并且真的兑现：「现在说延期，比上线前一天说，代价小得多。」如果第一个说真话的人被当众批评，那么下一次站会，所有人都会重新学会说「快了」。
六、怎么汇报才不心虚
如果你就是那个要说进度的人，可以把汇报换成四格：
- 已完成：写可验证的东西，比如合并的 PR、跑通的用例、能点开的 demo，而不是「写完了」。
- 下一步：具体到动作和对象，比如「把导出接口的分页改成游标」，而不是「继续开发」。
- 阻塞：卡在谁或什么，需要什么，什么时候需要。
- 风险：触发条件、影响范围、备选方案。
三个习惯能让这四格更有用。
给区间，不给点。「3 到 5 天，取决于联调对方什么时候给沙箱」比「4 天」更诚实，也更有用，因为它把不确定性放在了明面上。
报剩余清单，不报完成百分比。 百分比需要一个稳定的分母，而软件项目的分母一直在变；清单不需要分母，只需要逐项打勾。
坏消息用三句话。 原计划是什么，新事实是什么，影响和选项是什么。比如：
原计划周五提测；现在发现导出在十万行数据下会超时；影响是提测顺延到下周二，若要保持上线时间，需要砍掉分批导出。我建议先上单批、分批下个版本补，需要你在周三前拍板。
结构是：原计划 → 新事实 → 影响 → 选项与决策点。它没有把「快了」换成「慢了」，而是把「慢了」换成了一个可以讨论的选择。
一句判据：好的进度汇报，让听的人知道接下来该担心什么；坏的进度汇报，让听的人以为没什么可担心的。
七、五个检查项
下次听到一份进度汇报，可以快速过一遍：
- 有数值吗？数值的分母定义了吗？
- 有可验证的最近动作吗？
- 剩余工作列成清单了吗？
- 风险有触发条件吗？
- 坏消息传到决策者那里，要经过几层？
五条里过不了三条，那份汇报大概率还停留在修辞阶段。
写在最后
「快了」不完全是谎言。它是说话人和听话人共同维护的一小段缓冲区：说的人争取一点时间，听的人暂时不必做艰难的决定。在真实的工作里，这种缓冲有它的用处。
但缓冲区有成本，而且成本会转移——转移到上线前那一周，转移到凌晨的告警，转移到下一个接手的人。
真正专业的团队，不是从不延期，而是让延期尽早可见。毕竟，早了是风险，晚了是事故。
参考来源
- Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975（Brooks 定律，第 2 章）
- Daniel Kahneman & Amos Tversky, “Intuitive Prediction: Biases and Corrective Procedures,” TIMS Studies in Management Science 12 (1979), 313–327（计划谬误）
- Bent Flyvbjerg, “What You Should Know About Megaprojects and Why: An Overview,” Project Management Journal 45(2), 2014, 6–19（乐观偏差与策略性失实）
- Tom Cargill 的 90/90 法则，见 Jon Bentley, Programming Pearls, Addison-Wesley, 1986