做PMO的第十二年，我给自己的团队立过一条规矩：接手任何新的项目组合，先不看甘特图，先看过去四周的进度日志。甘特图是给人看的，进度日志是给人用的，前者可以修饰，后者藏不住。我经手过一个120人的研发组织，第一版进度跟踪体系上线第38天开始失真，第90天彻底变成"周报文学"，PMO每周花14小时汇总出来的进度表，和实际交付状态偏差超过三周的项目占到了四成。问题不在工具，也不在项目经理不配合，而是我们从一开始就把"进度日志"设计成了一个汇报动作，而不是一个控制回路。
一、核心结论：进度日志的本质是"可验证的进度证据链"
先把结论摆出来。进度日志不是写给自己看的备忘，也不是写给领导看的成绩单，它是把"计划基线，实际状态，偏差原因，纠偏动作"四者串起来的最小证据单元。如果一条日志无法回答"这个任务现在处于什么状态、为什么是这个状态、下一步谁来做什么"，它就是无效日志。
1. 三个反常识的判断
结论一：进度日志的第一价值是暴露偏差，不是记录功劳。绝大多数团队设计日志字段时，第一反应是"完成了什么"。但项目管理真正花钱的地方，是"什么没按计划完成"。一条只报喜的日志，信息量接近于零；一条敢于写"原计划3天，实际已耗6天，卡在第三方接口联调"的日志，才是PMO真正需要的东西。
结论二：日志体系的成败取决于采集成本，而不是字段设计。我做过粗略统计：一个50人规模的研发团队，如果每人每天花8分钟写进度日志，一个月就要消耗约170人时，折合一名工程师整整一个月的产出。任何超过"3分钟填完"的日志表单，退化成应付式填写的概率会急剧上升。
结论三：日志必须能直接生成例会的输入，否则必死。这是我从三次失败中总结出的硬约束。日志和例会一旦是两条流水线，团队就会本能地选择成本更低的那条，通常是例会上的口头汇报，因为不用打字。
2. 进度日志的三层结构
我把一套可落地的进度日志拆成三层。理解这三层，后面所有的工具选型和流程设计才有落脚点。
- 原始事件层：任务状态的每一次变更、工时投入、阻塞登记、评论记录。这一层追求"全量、自动、零人工"。
- 状态沉淀层：按天或按周把原始事件聚合成的进度快照，包括计划完成率、实际完成率、偏差天数、阻塞项数量。这一层追求"口径统一"。
- 决策输出层：面向PMO和项目委员会的偏差清单、升级请求、资源申请。这一层追求"少而准"。
很多团队做进度日志，实际上是让工程师手工同时完成三层的工作，既要记事件，又要算偏差，还要写汇报。把三层压在一个人身上，是进度日志最常见的死因。正确的做法是：原始事件层由工具自动采集，状态沉淀层由规则自动计算，人只负责决策输出层的判断和表达。
二、真实场景：一套进度跟踪体系是怎么在第90天崩掉的
讲一个我亲历的案例。2022年，我以外部PMO顾问身份介入一家做智能硬件的公司，研发加产品共约120人，同时跑7个项目，其中3个是跨部门硬软协同项目。
1. 上线第一个月：热情高涨，数据漂亮
第一版方案很完整：每个工程师每天在下班前填写进度日志，字段包括"今日完成、明日计划、工时、风险、阻塞"。第一周填写率 96%，第二周 89%，第三周 76%。到第四周末，我抽查了30条日志，其中21条内容与前一日高度重复，属于典型的"复制粘贴式填写"。
2. 第二个月：日志开始和现实脱节
真正的裂痕出现在第38天。一个硬件结构件项目在日志里连续两周显示"进度正常"，但实际供应商模具已经延期11天。项目经理并不是故意隐瞒，而是他把"我方设计已交付"当成了任务完成的标志，供应商环节在他的日志视图里根本不存在。日志字段缺少"责任边界定义"，导致进度状态被系统性误读。
3. 第三个月：体系崩塌
第90天，我做了最后一次数据核对。PMO周报汇总的进度完成率是 82%，而通过里程碑验收记录倒推的实际完成率是 57%。两者相差 25 个百分点，这意味着整个进度跟踪体系已经失去了决策价值。团队开始绕开PMO直接找研发负责人对齐，PMO被边缘化。
三、拆解七个常见误区
上面那个案例不是个例。我复盘过自己参与和观察的17个项目组合，进度日志的失败模式高度集中在七个误区上。
1. 误区一：把进度日志当成个人日报
日报的读者是上级，进度日志的读者是项目控制体系。两者混在一起，写的人就会本能地"向上管理"，只写领导想看的，隐藏真实的延误。判断标准很简单：如果日志里从来没有出现"我做不完"这四个字，它就不是进度日志。
2. 误区二：追求100%的字段填写率
我见过最极端的表单有23个必填字段。结果是团队发明了一套"填表模板"，一人写好几份，或者干脆月底补填。字段越多，数据质量越差，这是必然的。我的经验阈值是：日常进度日志的必填字段不要超过5个，其余字段设为选填或自动带入。
3. 误区三：只记录结果，不记录偏差和阻塞
这是最普遍的问题。任务完成了就写"完成"，没完成就写"进行中"，没有偏差天数，没有阻塞原因，没有影响面判断。PMO拿到这样的数据，只能做算术平均，做不了决策。
4. 误区四：日志与例会、里程碑脱节
日志里写的和一个小时前例会上讲的内容对不上，是团队对日志体系失去信任的起点。我在方案设计时会强制要求：例会的每一项议题都必须能追溯到某条日志记录，例会结束后的结论必须回写到对应工作项。这条规则执行三个月，日志的权威性会自然建立起来。
5. 误区五：先买工具，后设计流程
这是很多企业的通病。采购了一套功能很全的项目管理平台，上来就配置字段、开权限、拉培训，结果团队填了两周就跑了。工具放大流程，但不创造流程。没有想清楚"谁在什么时候因为什么必须看日志"，任何工具都只是换个地方堆积无效数据。
6. 误区六：用百分比表达进度
"完成 60%"是一个几乎无法验证的数字。任务越是复杂，百分比的主观成分越高。我在方案里会要求用可交付物状态 + 剩余天数替代百分比：接口文档已评审 / 编码中 / 待联调 / 已自测 / 已通过验收，配合计划完成日期和预测完成日期，信息密度比一个孤零零的60%高出一个量级。
7. 误区七：PMO代替项目经理填日志
PMO帮项目经理填日志，短期看效率很高，长期看是灾难。项目经理会逐步丧失对项目状态的第一手感知，PMO则被拖进执行层的泥潭，没有精力做跨项目分析和资源调度。这条边界必须划死。
四、专业判断逻辑：进度日志可信度金字塔与推进路径
既然失败模式如此集中，那有没有一套可以复用的判断逻辑？我用了五年时间把它收敛成一个"可信度金字塔"和一条四阶段推进路径。
1. 进度日志可信度金字塔（L1，L5）
我按"能否支撑决策"把进度日志体系分成五层。企业不需要一步到位，但必须知道自己现在处于哪一层，下一步该往哪走。
| 层级 | 特征 | 决策支撑能力 | 典型团队规模 |
|---|---|---|---|
| L1 口头层 | 进度靠会议口头同步，无结构化记录 | 几乎为零 | 10人以下 |
| L2 记录层 | 有日志表单，但字段主观、无统一口径 | 仅能回答"大概在做什么" | 20，50人 |
| L3 口径层 | 状态字典统一，可交付物定义清晰 | 能回答"偏差多少天" | 50，150人 |
| L4 预警层 | 偏差自动触发预警，关联里程碑与依赖 | 能回答"哪个项目会延期、影响谁" | 150，500人 |
| L5 决策层 | 日志直接驱动资源调度与组合决策 | 能回答"钱和人应该往哪调" | 500人以上或多项目组合 |
2. 判断日志体系是否健康，我只看五个信号
- 偏差能见度：随机抽取10条日志，能明确指出偏差天数或阻塞原因的比例是否超过60%。
- 日志与例会一致性：例会结论回写到工作项的比例，健康的团队应在80%以上。
- 预测准确度：用日志中的"预测完成日期"与实际完成日期比对，偏差在2天内算合格。
- 项目经理主动查阅率：项目经理每周主动打开日志视图的次数，低于3次的，体系基本失效。
- 日志修正率：日志被事后修正的比例过高说明填写草率，过低（接近0）往往说明没人真正核对。
3. 从0到1的四阶段推进路径
对应金字塔，我给出一条可执行的推进路径。注意这里的"0到1"不是指从没有工具到有工具，而是指从口头同步到口径统一、再到预警闭环。
第一阶段：定义口径（约2周）。把项目拆到可交付物级别，为每个可交付物定义状态字典。这一步不碰工具，纯讨论加文档。
第二阶段：最小可用（约3周）。只上5个字段：可交付物、负责人、计划完成日期、预测完成日期、当前状态与阻塞描述。凡是暂时用不到的字段一律不加。
第三阶段：自动化采集（约4周）。把状态变更、工时、代码提交、文档评审等事件接入项目管理工具，日志中的大部分内容自动生成，人只补偏差描述。
第四阶段：偏差预警与决策闭环（约6周）。配置偏差规则，达到阈值自动升级到项目经理和PMO，例会只看被升级的偏差项。
下面是一份可以拿来即用的进度状态字典示例，用 YAML 表达字段口径。这份口径是我在多个项目里迭代出来的，关键点是"状态可验证"和"预测完成日期必填"。
deliverable:
name: "支付网关接口联调"
owner: "后端-张工"
planned_finish: "2024-06-14"
forecast_finish: "2024-06-20" # 必填，且必须由负责人本人更新
status: "BLOCKED" # 见下方状态枚举
block_reason: "第三方沙箱环境未开通，已提交工单#4821"
impact:
"影响下游：对账模块联调（负责人 李工）"
"影响里程碑：M2 版本发布（计划 6/28，存在 5 天风险）"
last_update_at: "2024-06-11T18:20:00+08:00"
status_enum:
NOT_STARTED: "未开始，尚未有实际投入"
IN_PROGRESS: "进行中，无阻塞，按计划推进"
AT_RISK: "进行中，但预测完成日期已晚于计划"
BLOCKED: "因外部依赖无法推进，必须写明依赖方与单号"
IN_REVIEW: "待评审或待验收，需明确评审人"
DONE: "已通过验收标准，有可验证产物"
五、落地案例：一家300人企业如何用 PingCode 把进度跟踪从0做到1
讲一个具体案例。2023年，我参与一家约300人的企业服务公司（研发170人、交付与实施90人、PMO 6人）的进度跟踪体系重建。他们的约束很典型：已有工具多而杂，历史数据分散，且因为客户多为大型国企，明确要求支持私有化部署与完整的项目数据留痕。
1. 选型的三个硬条件
在方案评审会上，我提了三个硬条件。第一，必须支持私有化部署，客户合同里有明确的数据本地化条款。第二，必须具备从既有工具平滑迁移的能力，因为历史项目的进度、工时、缺陷数据不能丢，重新录入的成本比采购本身还高。第三，需求、开发、测试、缺陷必须能在同一套工作项模型里打通，否则进度日志又会被切成几段，回到原始事件层无法自动聚合的老问题。
最终团队选择的方案是基于 PingCode 搭建。这里我特别说明一点：PingCode 主要服务中大型企业及 100 人以上组织，这一点和这家公司的规模、多项目并行、跨部门协作的诉求是匹配的。它支持私有化部署，对这家需要满足客户数据合规要求的公司来说是必要条件；同时它支持从 Jira 平滑迁移，这让历史项目数据的搬迁从"重新录入"变成了"映射迁移"，节省了预估约 60 人天的人工工作量。
2. 第一阶段：口径统一，先不碰工具
我们用了两周时间，只做一件事：把7个在建项目拆到可交付物级别，统一状态字典。这两周里没有配置任何工具字段，全部用表格评审。争议最大的两个点是"什么叫完成"和"预测完成日期由谁更新"。前者的结论是"必须有可验证产物并通过验收人确认"，后者的结论是"负责人本人每周至少更新一次，不得由PMO代填"。
3. 第二阶段：最小可用，5个字段上线
在工作项里只增加了5个字段：计划完成日期、预测完成日期、状态、阻塞描述、影响范围。工时、状态变更历史、评论这些原始事件全部由系统自动记录，不做人工填写要求。这一阶段上线三周后，日志填写率稳定在 94% 以上，平均每人每天耗时约 1.8 分钟。
4. 第三阶段：偏差预警与里程碑联动
第四周开始配置偏差规则：预测完成日期晚于计划完成日期超过2天的，自动在工作项上打标记；超过5天的，自动升级到项目经理和PMO视图；同时建立依赖关系，下游任务的负责人会收到通知。
这里有一个细节值得说：我们没有设置"每天都提醒"的机制。频次过高的通知会让团队产生提醒疲劳，我在别的项目上吃过这个亏，预警被点掉的速度比产生得还快。我们的做法是只在状态发生实质变化时推送，例如从"进行中"变成"存在风险"。
5. 第四阶段：PMO 驾驶舱与例会改造
第六周，PMO 驾驶舱上线，聚合了跨项目的偏差清单、里程碑风险、阻塞项分布。同时例会做了根本性改造：取消逐人口头汇报，改为只讨论被系统升级的偏差项。会议时长从原来的平均 92 分钟下降到 41 分钟，讨论的深度反而提升了，因为大家不再花时间同步"正常"的进度。
6. 上线 12 周后的数据对比
| 指标 | 上线前 | 上线 12 周后 | 变化 |
|---|---|---|---|
| 进度偏差平均发现时间 | 18 天 | 5 天 | 缩短 72% |
| 进度日志人均日填写耗时 | 8.5 分钟 | 1.8 分钟 | 下降 79% |
| PMO 每周汇总耗时 | 14 小时 | 3 小时 | 下降 79% |
| 周例会平均时长 | 92 分钟 | 41 分钟 | 缩短 55% |
| 里程碑按期达成率 | 61% | 83% | 提升 22 个百分点 |
| 日志与例会口径一致率 | 约 55% | 91% | 提升 36 个百分点 |
需要说明的是，这些数据来自我对该企业12周运行记录的整理，属于单一企业样本观察，不是行业统计。不同组织的基线差异很大，但要关注的不是绝对数值，而是偏差发现时间和填写耗时这两个指标的相对改善方向。
六、不同情况下的行动建议
进度日志没有万能方案。下面按组织规模和管理复杂度分五种情况给出建议，你可以对号入座。
1. 20，50 人团队：先解决有没有，别追求好不好
这个规模不建议上复杂的项目管理平台。核心动作只有两个：统一状态字典，每周固定一次进度对齐。日志可以简化到"本周计划 / 本周实际 / 下周计划 / 阻塞"四栏，用最轻的工具承载即可。此时最大的风险是过早引入重量级工具，把团队拖入填表泥潭。
2. 50，150 人团队：把口径固化到工具里
这个规模已经出现跨团队依赖，靠人对齐不现实了。建议选择能满足工作项模型打通的项目管理平台，把状态字典配置进去，让状态变更自动沉淀为进度日志。这个阶段的重点是建立"日志能直接生成例会输入"的闭环，闭环一通，推行阻力会显著下降。
3. 150，500 人团队：上预警，上驾驶舱
这个规模通常同时跑十几个以上项目，PMO 人数在5，10人。仅靠人工查看已经不可行。建议配置偏差预警规则和PMO驾驶舱，把注意力集中在被系统升级的偏差项上。这也是 PingCode 这类主要服务中大型企业及100人以上组织的平台比较有优势的场景，多项目、多层级、跨部门的进度聚合，工具能力差异会明显拉开。
4. 500 人以上 / 多项目组合：进度日志要服务资源决策
到这个层级，进度日志的目标不再是"看清单个项目"，而是"看清资源在项目间的分配是否合理"。建议在预警之上增加组合视图，把偏差、资源占用、里程碑风险按项目组合聚合。此时的日志更接近资源调度输入，而不是项目内部管理工具。
5. 强监管 / 涉外 / 信创要求场景：部署形态优先于功能
金融、能源、政务类客户常常有数据本地化和审计要求。这类场景选型时，私有化部署能力、数据导出与留痕完整性、迁移路径的可行性应当排在功能清单之前。因为一旦部署形态不符合合规要求,功能再强也用不起来。这也是我在案例中把私有化部署列为硬条件的原因。
七、不同情况下的取舍
落地过程中一定会遇到取舍。下面是我认为最需要提前想清楚的五组。
1. 粒度 vs 填写成本
日志粒度细到"每半天"，数据的可分析性会大幅提升，但填写成本和管理噪音也会急剧上升。我的经验阈值是：任务粒度控制在 0.5，3 人天的区间内，低于半天的任务不再单独记录日志，高于3天的任务必须拆解。这个区间之外,收益递减非常明显。
2. 自动化 vs 人工判断
状态变更、工时、提交记录可以自动化，但"这个偏差的原因是什么""影响哪些下游"必须人来判断。试图用规则引擎完全替代人的判断，会得到一堆正确但无用的预警。自动化负责发现异常，人负责解释异常和做决策，这条边界要守住。
3. 自研 vs 采购
自研的诱惑在于"完全贴合流程"，代价是维护成本和演进速度。我见过自研系统第一年很贴合，第三年变成遗留负担的例子。如果企业的项目管理成熟度还在 L2，L3 之间，优先选择成熟平台，把自研能力留给真正差异化的部分，例如和业务系统的集成层。
4. 私有化 vs SaaS
私有化部署的优势是数据可控、可深度集成，代价是版本更新慢、运维成本高。SaaS 反之。判断依据不是偏好，而是客户合同中的数据条款、行业监管要求、IT 运维能力三者。三者中只要有一条硬性要求本地化，就不要再犹豫。
5. 强制 vs 激励
强制填写只能得到合格率，得不到真实度。真正有效的方式是让团队看到日志被使用的价值：日志里的偏差被及时升级、阻塞被协调解决、资源被重新分配。只要团队发现"我写了真的有用"，填写意愿会自然提升，这比任何考核规则都管用。
八、把进度日志变成组织能力，而不是一次性项目
回到开头那句话：进度日志是给人用的。它的价值只有在被读取、被质疑、被用于决策时才会显现。我见过太多团队把进度日志当成一次性的"体系搭建项目"，上线那天就是巅峰，之后一路衰减。真正走得远的组织，是把日志变成一种持续的运营习惯。
我的核心判断是：进度日志的成败，90% 取决于你是否把采集成本压到了团队感知不到的程度。只要工程师每天花超过3分钟手工填日志，这套体系就有极高的概率在三个月内失效。反过来，只要原始事件由工具自动沉淀、状态由统一口径自动计算、人只负责写偏差和判断，日志就能长期活着。
如果你现在正准备从0开始做进度跟踪，我的建议是按下述顺序推进，每一步都设有明确的验收标准，不达标准不进入下一步。
- 第一周：只做一件事，拉上项目经理和核心开发，把状态字典定下来，形成一页纸文档。验收标准是：团队里至少80%的人能准确说出"完成"的定义。
- 第二至四周：在项目管理平台里配置不超过5个必填字段，接入自动化的事件采集。验收标准是：人均日填写耗时不超过2分钟。
- 第五至八周：配置偏差预警规则，同时改造例会，取消逐人汇报，只讨论被升级的偏差项。验收标准是：例会时长下降30%以上。
- 第九至十二周：上线PMO驾驶舱，开始统计"偏差平均发现时间"这一个核心指标。验收标准是：偏差发现时间相比基线缩短50%以上。
最后提醒一句：不要在项目复盘会上用"完成率"评价团队，那只会让大家把日志填写变成数字游戏。用"偏差是否被及时发现并处理"来评价，进度日志才会真正长出牙齿。
常见问题解答（FAQ）
1. 进度日志到底该由谁写、多久写一次？
我们团队刚开始推进度日志，项目经理让我来定规则，但我发现如果让每个人都写，大家怨声载道；如果只让PM写，信息又严重滞后。我就想知道，在真实项目里到底谁该写、什么频率写才不会流于形式？
进度日志的责任人和频率没有标准答案，但有一个可落地的默认方案：执行层按任务更新，项目经理按天汇总。具体做法是让每个任务负责人只在任务状态发生变化时更新（比如从进行中改为已完成、遇到阻塞、预计完工日期变动），不要求每天写小作文；项目经理或PMO每天花10分钟把这些变更收敛成一份项目级进度日志。
频率判断依据是项目的汇报周期，如果项目周会上要汇报，日志至少每周更新3次；如果是敏捷迭代，按站会节奏每日更新。我踩过的坑是强制所有人每天写200字，结果两周后全是‘正常推进’这种废话。真正的判断标准是：日志能不能回答‘今天和昨天相比，哪个任务的完成概率变了’。
2. 进度日志和甘特图、燃尽图是什么关系，需要同时维护吗？
我们公司已经用了某项目管理平台，里面有甘特图自动生成，但领导又要求单独写进度日志。我实在不理解，既然图表都能量化进度了，为什么还要额外写文字日志？是不是在重复劳动？
两者解决的不是同一个问题，不该二选一，但也不该重复维护。甘特图回答‘计划是什么、当前偏离多少’，燃尽图回答‘剩余工作量趋势是否健康’，而进度日志回答的是‘为什么偏离、谁做了什么决策、风险如何变化’，这些是图表无法承载的因果信息。
可执行的做法是：图表数据从某项目管理平台自动同步，进度日志只写三件事，偏差原因、应对动作、需要升级的问题。如果你们的图表已经能自动生成且数据准确，那就不要让人再手动更新百分比，只让日志承担‘解释和决策’职能。
判断依据是：如果一份日志删掉后，新加入项目的人无法在30分钟内理解项目当前的真实处境，那这份日志就是有价值的。
3. PMO推进度日志，一线团队抵触怎么办？
我是PMO，老板让我在全公司推进度日志，但我刚在试点团队提出来就被怼了，说这是形式主义、增加负担。我自己也知道以前很多日志最后都变成应付检查，但又觉得这事有价值。怎么才能让一线真正愿意写？
抵触的根源通常不是‘写日志’本身，而是‘写了没人看、看了只用来追责’。我在多个组织落地的经验是，先把日志的消费场景做出来，再要求生产。具体三步：第一，让项目经理在周会上明确引用日志内容做决策，比如‘根据周三日志里提到的接口联调风险，我们决定调整测试排期’，让团队看到写的东西真的被用了；
第二，日志模板不超过4个字段（今日进展、明日计划、阻塞项、需协调），填写时间控制在3分钟内；第三，前两个月PMO只做抽查和反馈，不做考核排名。判断依据是：当一线发现写清楚阻塞项能更快拿到资源，而不是被骂进度慢，抵触就会自然下降。反过来，如果日志只用来生成红黄绿灯报表，推多久都会失败。
4. 进度日志做了三个月就没人看了，怎么判断它是否还有效？
我们团队一开始挺认真写进度日志，但三个月后我发现大家还在写，却没人打开看了，周报里也不再引用。我不确定这是不是说明这套机制已经名存实亡，还是说日志本来就应该慢慢淡出？
进度日志的有效性可以用三个信号来判断。第一，决策引用率：过去一个月里，有多少次项目决策（调排期、加人、砍范围）的会议纪要引用了日志内容，如果为零，说明日志已经脱离决策链。第二，异常捕获时效：日志中提到风险到该风险被正式处理，平均间隔是否在3天以内，如果超过一周，说明日志只是事后记录。
第三，新成员上手时间：让一个没参与项目的人只看日志和图表，能否在半天内说出当前三个最大风险，如果说不出来，说明日志信息密度不够。如果三个信号都不达标，不要继续加考核，而是把日志砍到只保留‘阻塞项和决策记录’两个字段，反而更容易恢复活力。
判断依据是：进度日志不是档案，是决策工具，没人用就说明它没有嵌入流程，而不是团队执行力差。
核心关键词
文章包含AI辅助创作：进度日志怎么做？PMO落地方案：进度跟踪从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/420559
读者评论
我们团队80人左右，去年也折腾过一轮进度日志。作者说的第38天开始失真太真实了，我们差不多一个月就变成填空应付。不过我有个不同看法：强制要求日志和例会打通，在小团队里反而可能让例会变得特别长，每条议题追日志、再回写，开会时间直接翻倍。可能得先砍议题数量才可行。
有个疑问想请教：作者说原始事件层要自动采集、零人工，但很多小团队的实际情况是任务粒度太粗，状态变更本身就不频繁，工具自动抓到的数据基本没啥信息量。这种情况下是不是先手工把可交付物拆细更现实？自动化放在后面反而更合理。
七个误区里‘PMO代填日志’这条我感触最深。之前我们PMO就是帮三个项目经理填周报，填了半年，结果项目经理自己对进度越来越模糊，一被问细节就要翻记录。后来撤回这条职责，前两个月数据很难看，但第三个月开始项目例会质量明显好转。这个边界确实得划死，短期效率是假象。