Vue.js

Appearance

On this page

场景4——向领导汇报工作 ​

场景描述 ​

周五下午，领导在群里说：

"下周一开周会，每人准备一下，汇报一下本周工作。"

这是工作汇报场景。

常见的错误做法：

  • 流水账式汇报（"周一做了什么，周二做了什么..."）
  • 只说做了什么，不说结果和价值
  • 说一大堆细节，领导听完不知道重点

正确的做法是结论先行，聚焦结果和价值。

CPERF应用 ​

C - Capture 捕获 ​

第一步：理解汇报的目的

汇报不是为了展示你有多忙，而是让领导：

1. 知道项目进展（控制感）
2. 了解有什么问题需要关注（风险意识）
3. 看到你的工作价值（认可你）

第二步：收集本周工作内容

本周做的事：
1. 完成用户模块的前端开发（100%）
2. 修复了3个线上bug
3. 参加了需求评审会议（2次）
4. 帮新同事review代码
5. 优化了首页加载速度

第三步：筛选重要内容

不是所有事情都值得汇报。

筛选标准：
- 和核心目标相关的
- 有具体结果的
- 领导关心的

筛选后：
1. 用户模块完成（核心工作）
2. 首页优化（有具体数据）
3. 有一个进度风险需要同步

P - Process 处理 ​

组织汇报结构：

结构1：结论先行
先说总体结论，再说细节

结构2：三点式
把内容组织成三个点

结构3：问题导向
哪些完成了，哪些有问题，需要什么支持

选择适合的结构：

周会汇报通常时间有限，用结论先行+三点式：

结论：本周进展顺利，核心任务完成
三点：
1. 用户模块100%完成
2. 首页性能优化完成
3. 有一个风险需要同步

准备具体内容：

markdown
## 本周汇报

### 总体结论
本周工作进展顺利，核心任务完成，有一个风险需要关注。

### 一、用户模块开发（完成100%）
- 完成注册、登录、个人信息三个功能
- 已提测，测试反馈正常
- 计划下周三上线

### 二、首页性能优化（完成）
- 首屏加载时间从3.2秒降到1.5秒
- 优化方式：图片懒加载+接口合并
- 用户反馈的"加载慢"问题已解决

### 三、风险提示
- 支付模块的后端接口还没ready
- 如果下周一还没好，会影响支付功能的开发进度
- 已经和后端沟通，他们说周一应该能完成

E - Express 表达 ​

汇报时的表达：

"我汇报一下本周工作。

总体来说，本周进展顺利，核心任务完成，
有一个风险需要同步一下。

第一，用户模块。
注册、登录、个人信息三个功能全部完成，
已经提测，测试反馈正常，计划下周三上线。

第二，首页性能优化。
首屏加载时间从3.2秒降到1.5秒，
用户反馈的'加载慢'问题已经解决了。

第三，有一个风险要说一下。
支付模块的后端接口还没ready，
如果下周一还没好，会影响我这边的进度。
我已经和后端沟通过，他们说周一应该能完成。

我的汇报完毕。"

关键技巧：

1. 先说结论："总体进展顺利"
2. 用数字："从3.2秒降到1.5秒"
3. 主动说风险：不要等领导问
4. 有闭环："已经和后端沟通过"

R - Review 复盘 ​

会后反思：

领导反应：
- 对用户模块进度满意
- 对性能优化结果很认可，专门表扬了
- 对风险提示表示知道了，会跟进后端

自我评估：
- 结论先行做到了
- 数据支撑做到了
- 风险提前说了

可以改进的：
- 可以准备一页简单的PPT或文档
- 下次可以加上下周计划

F - Form 固化 ​

汇报模板：

markdown
## 周会汇报模板

### 总体结论
一句话说清楚本周整体情况

### 核心工作（2-3项）
每项包括：
- 做了什么
- 结果是什么（最好有数据）
- 当前状态和下一步

### 风险/需要支持的事项
- 有什么风险
- 已经做了什么应对
- 需要领导做什么

### 下周计划（可选）
- 计划做什么
- 预期产出

关键要点 ​

要点1：领导关心什么 ​

领导关心：
1. 项目是否在正轨上？
2. 有什么问题需要我关注？
3. 你的工作有什么价值？

领导不关心：
1. 你每天具体做了什么
2. 技术细节
3. 你有多辛苦

要点2：结论先行 ​

❌ 先说过程，最后说结论
"这周我先做了A，然后做了B，中间遇到一些问题，
后来解决了，总的来说进展还可以。"

✅ 先说结论，再说支撑
"本周进展顺利，核心任务完成。
具体来说，第一是..."

要点3：用数据而非形容词 ​

❌ "性能提升了很多"
✅ "首屏加载从3.2秒降到1.5秒"

❌ "用户反馈变好了"
✅ "投诉从每天10条降到3条"

❌ "进度正常"
✅ "计划完成5个功能，实际完成5个，完成率100%"

要点4：主动说风险 ​

不要等领导问才说风险。
主动说 = 专业、负责
被问出来 = 隐瞒、不靠谱

而且主动说的时候，要说：
1. 风险是什么
2. 你做了什么应对
3. 需要领导做什么（如果需要）

要点5：控制时间 ​

周会每个人5分钟左右，不能讲太久。

准备10分钟的内容，讲5分钟的版本。
如果领导想深入了解，再展开讲。

本场景的CPERF检查清单 ​

markdown
□ Capture
  - 理解了汇报的目的吗？
  - 收集了本周的主要工作吗？
  - 筛选出重要的内容了吗？

□ Process
  - 用了合适的汇报结构吗？
  - 有具体的数据支撑吗？
  - 风险和需要支持的事项列出来了吗？

□ Express
  - 结论先行了吗？
  - 控制了汇报时间吗？
  - 表达清晰有条理吗？

□ Review
  - 领导的反应如何？
  - 哪些做得好，哪些可以改进？

□ Form
  - 形成了自己的汇报模板吗？
  - 下次汇报可以怎么改进？

不同场景的汇报调整 ​

markdown
### 日常周会（5分钟）
- 结论+三点式
- 重点是进度和风险

### 项目里程碑汇报（15分钟）
- 更详细的进展
- 数据对比
- 问题和解决方案

### 向更高层汇报（3分钟）
- 更简洁
- 只说结果和价值
- 不说技术细节

小结 ​

工作汇报的核心方法：

  1. 理解领导关心什么
  2. 结论先行，不要流水账
  3. 用数据而非形容词
  4. 主动说风险
  5. 控制时间

下一章，我们看处理线上事故的场景。

在 GitHub 上编辑此页