# 汇报成果别只说“我做了哪些事”：把它翻译成对方在意的“什么变了”

从产出与结果的区分说起：连问两次“所以呢”抬到有证据的那一层，补上基线和时间，再处理结果还没到、本来没有结果、结果不全由自己掌控这三种工作

> 向上沟通 · 信息结构 · 受众分析 · 约 7 分钟 · 10 月 10 日

## 本篇要点

1. 汇报成果时真正要交付的不是动作清单，而是“什么变了”，因为对方要拿这条信息判断这块工作值不值得继续投入。
2. 产出是团队实际交出来的东西（模块、文档、迁移），几乎完全在自己掌控内；结果是做完之后世界真正发生的变化，部分取决于别人怎么反应。
3. 判断一个数字是产出还是结果的实用判据：如果它变好而其他一切不变，对方是不是真的更好。
4. 从动作走到变化，方法是连问两次“所以呢”，但只能抬到自己拿得出证据的那一层，再往上就是虚报。
5. 说“变了”必须带上基线和时间范围，写成“从 X 到 Y，在多长时间内”，否则“提升 30%”不构成信息。
6. 结果还没出现的工作，报领先指标（多少人真的在用），并说明最终盯哪个结果、什么时候能看到。
7. 本来就不产生直接结果的工作（合规、基础设施、救火），报消除掉的风险和解除掉的阻塞，避免的损失也是变化。
8. 结果不全由自己掌控时，把贡献拆成三段：哪部分能追到自己的动作、还有哪些因素同时在起作用、做了什么来确认不是巧合；全揽下来会因为不可信而毁掉整段汇报。
9. 一段成果汇报可以压缩成三句：变了什么（带基线和时间）、归因边界、下一步盯哪个数。
10. 边界：进度同步类汇报报动作就够，硬抬价值反而显得虚；同时不要省略成本和坏消息，可信度是所有汇报的共用本金。

---

季度复盘会，你这块进展顺利。轮到你，你说：完成了 A 模块重构，支持了三个项目上线，写了 12 篇文档，处理了 40 多个线上问题。

对方点点头，说“挺好”。到了谈资源的时候，你发现没人替你说话。

问题不在你说得不清楚——每一句都很清楚。问题在于你报的全是动作，而对方要拿这些信息去做另一个判断：这块工作值不值得继续投人投时间。动作回答不了这个问题。前面几篇讲过汇报先说结论，这篇往下走一步：结论里该装什么东西。

## 产出和结果，不是一回事

先分清两个词。

**产出（output）**是你实际交出来的东西：一个模块、一篇文档、一场培训、一次系统迁移。它几乎完全在你自己掌控之内，所以最好说，也最好测。

**结果（outcome）**是这件事做完之后，真正变了的东西：返修率降了、客户处理一次问题的时间短了、某类故障不再发生了。它取决于别人和环境怎么反应，所以不在你手里。

这个区分来自目标管理（OKR）的实践，但跟 OKR 没关系，任何一次汇报都能用上[1][4]。一条很好用的判据是：拿任何一个数字问自己一句——**如果这个数字变好了，别的一切都不变，我们是不是真的更好了？**[2][3]

比如“关闭工单数从 300 涨到 500”：如果客户只是因为同一个原因提了更多工单呢？关得更快就不算变好，这是产出。而“同一原因的返修率从 12% 降到 4%”，别的都不变时确实更好，这是结果。

所以“我上线了审批流程”和“审批平均从 5 天变成 1 天”是两件事。第一句说你干了什么，第二句说什么变了。对方要的是第二句，第一句只是它的来路。

![输入、产出与结果的关系示意](https://images.ctfassets.net/mu244eycyvsr/3febCfaNJte5xnjPgWqE1e/bf450d3894ab7ae906f5ab1bc7f9c6d0/Inputs-vs.-outputs.-vs.-outcomes---OKRs.png.jpg?w=1600&q=50&fm=webp)

## 怎么把动作抬成变化：连问两次“所以呢”

从动作走到变化，靠的是一个很笨但有效的问法：做这件事，所以呢？然后再问一次[5]。

还是以上线审批流程为例：

1. 我上线了审批流程。（动作）
2. 所以呢？——原来要等 5 天的审批，现在平均 1 天走完。（变了的东西）
3. 所以呢？——因为等审批而拖过截止时间的项目，从每季度 4 个降到 1 个。（更能说明为什么要关心）

两次通常够了。抬第三次就容易出事：“所以公司效率提升了”——这层你没有证据，对方一句“你怎么知道”就把你问住了。**抬到你拿得出证据的那一层就停**，再往上就是虚报。

## 说“变了”，必须带基线和时间

“提升了 30%”这句话单独存在时没有信息量。从多少提升到多少？多久之内？

能用的说法是这种形状：**从 X 到 Y，在多长时间内**。Weekdone 举过一个例子：不是“上线了新的销售流程”，而是“从线索到成单的平均时间，从 14 天缩短到 10 天”[4]。有了基线和时间，对方才能判断这个变化是大是小、值不值得再投一年。

## 一时看不出结果的工作，报什么

这类工作很多，而且往往正是你在做的那一类。它们分三种，报法不一样。

**第一类：结果会来，只是还没到。**你刚改完的流程，效果要两三个月才显出来。这时能报的是一组**领先指标**——在结果出现之前，能预示它会不会出现的那些量：多少人真的在用、用了多少次、覆盖了多少条流程。同时必须补两句：我盯的最终结果是哪个，什么时候能看到。这两句一补，对方就知道你不是在拿“已经上线了”当挡箭牌。

**第二类：这类工作本来就没有直接结果。**合规、基础设施、技术债、安全加固、常年救火，都属于这种。硬给它们编一个业务结果，多半就变成虚报。这时报两样东西：

- **消除掉的风险。**你挡住了什么。“以前从来没有验证过备份能不能恢复，现在每次发布都跑一遍恢复演练”——它变好不是体现在某个指标上，而是体现在灾难发生的概率上。避免掉的损失也是变化，只是它没有发生过，所以更需要你主动说出来。
- **解除了谁的阻塞。**谁因为这件事才能开始做什么。基础设施工作的价值常常不体现在自己身上，而体现在别人身上，那就直接这么报：“这次迁移做完，A 团队才能上多环境部署。”

**第三类：结果变了，但不全是你干的。**市场、别的团队、时机都在起作用。最常见的错误是全揽下来：“我让留存提升了 8 个点。”这句话垮掉的原因不是不谦虚，而是**不可信**——对方会立刻想到“那别的因素呢”。而他一旦怀疑这一句，你前面说的全都会被打折。

正确的做法是把贡献拆成三段：

1. 哪部分变化能追到我的动作（把首次配置从 6 步压到 2 步）；
2. 还有哪些因素同时在起作用（同期的新手引导改版）；
3. 我做了什么来确认不是巧合（小范围试点、回滚对比、前后数据）。

还有一个问法能帮你找到自己的边界：**如果我没做这件事，现在会是什么状态？** 说不清的地方就直说“这部分我判断不了”。可信度就是这么攒的。

## 一套可以直接套用的三句话

把上面合起来，一段成果汇报常常三句就够：

> 过去一个季度，新用户从注册到第一次成功操作的时间，从平均 3 天降到半天。（变了什么，带基线和时间）
> 这里面主要是把首次配置从 6 步压到 2 步带来的；同期的新手引导改版也在起作用，这两者我没法完全分开。（归因边界）
> 我接下来盯次月留存。如果下个月底还是没动，说明卡点不在配置上。（下一步看哪个数）

第三句不是客套。它告诉对方：你是在为结果负责，不是为任务清单负责。

```mermaid
flowchart LR
  A["对方要判断：这块值不值得继续投"] --> B["先看清自己报的是动作"]
  B --> C["连问两次：所以呢？"]
  C --> D["抬到拿得出证据的那一层：什么变了"]
  D --> E{"这个数变好，别的都不变，是否真的更好？"}
  E -- "不是" --> F["还是产出，继续往上抬一层"]
  E -- "是" --> G["补上基线和一个时间范围"]
  G --> H{"结果现在看得到吗？"}
  H -- "还没到" --> I["报领先指标，并说明盯着哪个结果、何时能看到"]
  H -- "本来就没有直接结果" --> J["报消除的风险和解除的阻塞"]
  H -- "到了，但不全是你的功劳" --> K["拆三段：我的动作 / 其他因素 / 怎么排除巧合"]
```

## 两条边界

**不是所有汇报都要抬到结果。**日报、周会同步、进度对齐，报动作就够了；对方只是想知道“这事在不在动”。硬把所有内容都说成价值，反而显得虚。判断标准还是那句：对方要拿这条信息做什么决定？

**别为了好看省略代价。**一个只讲变化、不讲成本和坏消息的汇报，第一次听着漂亮，第二次就没人信了。可信度是你所有汇报的共用本金，一次夸大就可能赔掉。

前面几篇讲的是顺序和结构，这一篇说的是内容本身。结构再好，装进去的还是“我做了 A、B、C”，对方听完依然判断不了什么。把动作翻译成变化，再标出这个变化里哪一段属于你，你交出去的才是一份能被用来做决定的材料。

## 术语表

- 产出（output）：你实际交出来的东西，比如一个模块、一篇文档、一次迁移；几乎完全在你自己掌控内，所以最好说、也最好测。
- 结果（outcome）：工作做完之后真正变了的东西，比如某类问题的处理时间变短、返修率下降；它取决于别人和环境怎么反应，所以不在你手里。
- 基线与时间范围：变化之前的状态和数值，以及这个变化发生在多长的时间里；没有它们，“提升了 30%”无法被判断。
- 领先指标与滞后指标：在最终结果出现之前预示它会不会出现的量（比如有多少人真的在用）叫领先指标，那个最终要看的变化叫滞后指标。
- 归因边界：说清哪部分变化能追到自己的动作、哪部分另有原因；说清边界比全部揽下来更可信。
- 反事实问法：问“如果我没做这件事，现在会是什么状态”，用来界定自己的贡献到底在哪一段。

## 来源

1. [What Matters: Output vs. outcome with OKRs — 区分动作型与结果型目标，说明产出只是过程里程碑](https://www.whatmatters.com/faqs/outputs-vs-outcome-okr)
2. [KPI Tree Explained: Outcome vs Output Metrics and OKRs — 给出“它变好而其他不变，组织是否真的更好”这条判据](https://okrinstitute.org/kpi-tree-explained-outcome-vs-output-metrics-and-okrs/)
3. [Outcome vs Output: measure the result, not the activity — 用“达成了它，客户或业务真的有什么不同吗”检验指标是不是结果](https://www.serendly.com/en/academy/okr-lexicon/outcome-vs-output)
4. [Weekdone: Outputs vs. Outcomes — The Key Differences — 举出“从线索到成单平均时间 14 天降到 10 天”这类带基线的结果写法](https://weekdone.com/resources/articles/outputs-vs-outcomes)
5. [Features vs. Benefits in B2B Messaging — 提供“连问所以呢”把功能描述逐层翻译成对方处境的改写步骤](https://discover.gtmplaybook.co/features-vs-benefits-messaging)

---

原文：https://pangzhengboyin.com/articles/report-outcomes-not-activities-f44d1546

> **庞征博引** · 想学的，慢慢都会
>
> 庞征博引是把想学的东西写成连载的 AI 学习工具。说出想学什么，它会先了解你的基础，再把主题写成一篇篇 5–10 分钟能读完的文章；边读边问，接下来学什么跟着你走。这篇就是这样写出来的。
>
> 开始你自己的连载 → https://pangzhengboyin.com