做事闭环执行能力
# 06.做事闭环执行能力
# 目录介绍
- 1. 案例引入
- 2. 闭环全景图
- 3. PDCA 与 OODA 双循环
- 4. 拿结果的思维模式
- 5. 向上同步的节奏
- 6. 跨部门推进四抓手
- 7. 复盘不甩锅五步
- 8. 烂尾项目救火
- 9. 闭环反模式
- 10. 综合案例串讲
# 1. 案例引入
# 1.1 跨部门项目卡死
张伟支付重构进入生产验证阶段, Higress 网关平台上线需要 4 个部门配合：
业务组 (张伟负责): 支付路由 + 业务集成
架构组 (老陈): Higress 底座 + 基础插件
运维组 (老赵): 生产部署 + 监控告警
安全组 (老钱): 合规审计 + 权限接入
老板 A 总周一晨会拍板："两周搞定, 张伟牵头。"
张伟当天就拉了个 20 人的钉钉群 "Higress 上线冲刺群", 发了个消息：
"各位, Higress 上线冲刺开始! 请大家两周内配合完成如下事项:
- 架构组: Higress 底座部署
- 运维组: 生产环境准备 + 监控接入
- 安全组: 合规审计 + 权限对接
- 业务组: 我负责
有问题群里同步, 加油!"
第 3 天,群里静悄悄。张伟去问：
张伟 @老陈: "老陈, 底座部署进度?"
老陈: "还没启动, 我这边有个 P0 事故要修"
张伟 @老赵: "老赵, 生产环境准备情况?"
老赵: "环境要走流程, 你申请单提了吗? 我没看到"
张伟: "......申请单? 我以为你们自动就能给"
张伟 @老钱: "老钱, 合规审计?"
老钱: "你没发方案给我看, 我怎么审?"
第 7 天 (第 2 周了):
架构组: 底座还没部署 (老陈 P0 事故还没修完)
运维组: 环境审批还没走完
安全组: 拿到方案 3 天, 说要 2 周才能出报告
业务组: 张伟自己代码写完了, 但联调没环境
第 12 天 (预定上线前 2 天), 张伟慌了, 找 Leader 老王:
张伟: "老王, 我这个项目要延期了......"
老王: "我上周就该知道这个消息, 你为什么现在才告诉我?"
张伟: "我一直在推......"
老王: "推是没错, 但你没**闭环**——
你只是在群里@别人, 不叫推进。
你有没有明确谁在什么时候之前必须给你什么?
你有没有识别关键路径?
你有没有每周向 A 总同步进度?
你有没有卡点会议?"
张伟: "......"
第 14 天 (原定上线日), 项目正式宣布延期 3 周。A 总在部门会上不点名批评："这个项目是典型的做事没闭环"。张伟脸红耳赤。
# 1.2 顺藤摸到根因
带着这条线往下挖：
- 假设 1：张伟不努力？——不是,他天天加班
- 假设 2：其他部门不配合？——不是,他们各有优先级
- 假设 3：项目太难？——不是,技术都不难
- 假设 4：那到底问题在哪？——"推进 ≠ 闭环"
- 假设 5：什么叫闭环？——明确责任 + 时间承诺 + 主动跟进 + 拿到结果
- 假设 6：为什么老手能跨 4 部门推进？——他们有一套闭环动作库
- 假设 7：这些动作是什么？——本篇的主线
仔细分析张伟这次翻车的根因：
表象 真实问题
────────────────────────────────────────────
"群里 @ 大家" → 没有点对点承诺 (@张三 = 张三可能没看到)
"两周搞定" → 没拆里程碑, 没识别关键路径
"有问题群里同步" → 没有主动跟进机制
"我以为自动就有" → 没了解上下游流程 (环境审批要多久?)
第 12 天才报告延期 → 向上同步节奏为零
根因：张伟把"我尽力做了"当成"闭环",实际上闭环是 "事情按预期在 deadline 前完成"。只有努力没有结果, 就是 0。
这一段里至少藏着 8 个原理点：
① "闭环"到底指什么? 交付了就算闭环吗? → 第 2 章
② 拿结果和交付作业的差别在哪? → 第 4 章
③ 什么时候用 PDCA, 什么时候用 OODA? → 第 3 章
④ 向上同步该多久一次? 说什么? → 第 5 章
⑤ 跨部门推进的具体动作是什么? → 第 6 章
⑥ 项目翻车怎么复盘不甩锅? → 第 7 章
⑦ 项目烂尾了怎么救火? → 第 8 章
⑧ 常见的"看起来闭环, 其实没闭"陷阱? → 第 9 章
# 1.3 我们要回答什么
这个事故就是本篇的主线案例。带着上面 8 个问号往下走。
本篇路线：
闭环全景图 (第 2 章)
↓
PDCA + OODA (第 3 章) ─→ 解开"双循环"
↓
拿结果思维 (第 4 章) ─→ 解开"结果 ≠ 交付物"
↓
向上同步 (第 5 章) ─→ 解开"3-3-3 节奏"
↓
跨部门四抓手 (第 6 章) ─→ 解开"推进的抓手"
↓
复盘五步 (第 7 章) ─→ 解开"不甩锅"
↓
烂尾救火 (第 8 章)
↓
反模式 (第 9 章)
↓
综合案例 (第 10 章) ─→ 张伟的跨部门救援
📌 本篇定位：闭环力是资深工程师的分水岭。前面所有能力 (方案/演进/讨论/质疑/CR) 都是"点上的"能力,闭环是"线上的"能力——把点串成线, 把线织成结果。
# 2. 闭环全景图
# 2.1 闭环四要素
闭环不是一件事,是四件事的组合：
┌────────────────────────────────────────────────────────┐
│ 闭环四要素 │
├────────────────────────────────────────────────────────┤
│ │
│ ① 目标明确 (Goal) │
│ 结果长什么样? 谁验收? 什么时候? │
│ │
│ ② 责任到人 (Owner) │
│ 每个子任务谁负责? 什么时候完成? │
│ │
│ ③ 主动跟进 (Follow-up) │
│ 不等对方主动, 你主动去问 │
│ │
│ ④ 结果达成 (Delivery) │
│ 实际拿到结果, 不是"我尽力了" │
│ │
└────────────────────────────────────────────────────────┘
对照张伟的翻车:
① 目标明确 ✗ 只有"两周搞定", 没有拆解
② 责任到人 ✗ 群里 @ 不算指定
③ 主动跟进 ✗ 等别人来找他
④ 结果达成 ✗ 延期 3 周
四要素少一个 = 没闭环。
# 2.2 交付物 vs 结果
疑惑：我把功能开发完了不算闭环吗？
论证：交付物 ≠ 结果。
交付物 (Deliverable):
- 代码写完 ✅
- 测试通过 ✅
- 上线了 ✅
结果 (Outcome):
- 用户实际用起来 ✅
- 业务指标达到预期 ✅
- 上下游都能顺利协作 ✅
举例：
张伟视角: "我 Higress 代码写完了, 网关部署了, 我完成了"
业务视角: "支付路由还没通, 我没法验收"
运维视角: "监控没接, 我不敢让流量进"
CTO 视角: "3 个渠道都没跑通一笔交易, 上什么线"
结论：闭环的定义 = 业务价值实际产生——代码上线只是过程, 不是终点。
规矩：每次做事前, 先问自己——"结果的最终形态是什么？谁认可它才算完成？"
# 3. PDCA 与 OODA 双循环
# 3.1 PDCA 的稳态循环
PDCA (Plan-Do-Check-Act) 是稳态项目的循环：
Plan (计划):
- 拆里程碑
- 分配责任人
- 制定验收标准
Do (执行):
- 按计划推进
- 及时同步进度
Check (检查):
- 对比计划与实际
- 发现偏差
Act (改进):
- 调整计划或加速
- 沉淀经验到下一循环
周期：周或双周——适合项目周期 > 4 周的稳态推进。
对照张伟应有的动作:
Week 1 Plan:
- 网关上线拆 5 个里程碑
- 每个里程碑指定 Owner
- 定义"上线成功"的验收标准
Week 1 Do:
- 主动跟每个 Owner 对齐时间
- 每天群里 15 分钟站会
Week 1 Check (周五):
- 里程碑 M1 是否按期?
- 有没有阻塞?
Week 1 Act:
- 有偏差立刻调整
- 向 A 总同步实际进度
# 3.2 OODA 的应急循环
OODA (Observe-Orient-Decide-Act) 是应急项目的循环, 空军战斗机飞行员经典模型：
Observe (观察): 收集当前所有信息
Orient (定向): 分析形势, 判断优先级
Decide (决策): 快速做出选择
Act (行动): 立刻执行
周期：分钟到小时——适合突发/危机场景。
举例：如果 Higress 上线当天发现某个渠道支付失败率飙升到 30%:
O (10min): 观察监控 - Stripe 全链路超时
O (5min): 定向 - 是网络 or Higress 配置 or Stripe 侧?
D (5min): 决策 - 先把流量切回老支付网关 (回滚),
再排查 Higress
A (2min): 执行 - 网关 Feature Flag 立刻切回 Alipay/WeChat 老通道
关键：OODA 强调速度——在信息不完整时, 快速试错。
# 3.3 双循环切换时机
何时用 PDCA, 何时用 OODA？
用 PDCA:
✅ 项目周期 > 2 周
✅ 目标稳定, 变化少
✅ 有充分信息决策
✅ 团队协作稳定
用 OODA:
✅ 突发事件 (故障/上线异常)
✅ 目标模糊, 需要快速探索
✅ 信息稀缺, 边行动边收集
✅ 时间窗口极短 (小时级)
双循环并存：
张伟应有的组合:
- 周维度: PDCA (每周 Plan → Do → Check → Act)
- 上线当天: OODA (每 15 分钟观察 → 决策 → 行动)
- 上线后 1 周稳态: 回归 PDCA
结论：成熟的项目管理 = PDCA 打底 + OODA 应急。只用 PDCA 会僵化, 只用 OODA 会散乱。
# 4. 拿结果的思维模式
# 4.1 结果定义先行
疑惑：什么叫"结果定义先行"？
论证：做事前 3 分钟, 先想清楚"什么样叫完成"：
❌ 张伟原版:
"Higress 上线冲刺"
✅ 结果定义:
"结果: 3 个支付渠道 (Alipay/Stripe/WeChat) 通过 Higress
成功完成 100 笔真实交易,
失败率 < 0.5%, P99 延迟 < 500ms,
A 总认可可全量上线。
时间: 6 月 30 日前
验收人: A 总 (业务) + 老陈 (架构) + 老赵 (运维)"
关键动作：结果定义必须包含：
① 可量化的成功标准
② 具体时间点
③ 具体验收人
三个都写清楚,才算"结果定义"。张伟原版一个都没有。
# 4.2 交付物不等于结果
疑惑：项目验收时不就是看功能开发完了吗？
论证：这个想法是"交付作业式思维" — 交作业只考虑自己做了什么, 拿结果要考虑对方拿到什么。
对比表：
| 项目 | 交付物思维 | 拿结果思维 |
|---|---|---|
| 支付上线 | "代码写完了" | "3 个渠道跑通 100 笔真实交易" |
| 需求评审 | "PRD 讲完了" | "所有关键干系人签字确认" |
| 系统迁移 | "新系统部署了" | "老系统流量切干净, 30 天无回滚" |
| 培训 | "培训做完了" | "70% 参训者能独立完成任务" |
| Bug 修复 | "代码提交了" | "线上 24h 未再复现" |
结论：拿结果思维 = 站在验收者立场定义完成。你自己觉得完成不算完成。
# 4.3 结果反向拆动作
疑惑：结果定义好了怎么落地？
论证：从结果倒推关键动作：
结果: 6/30 前 3 个渠道通过 Higress 跑通 100 笔真实交易
倒推 (从终点往前):
6/28 - 灰度 10% 流量, 观察 2 天
6/25 - 全链路联调通过
6/20 - 3 个渠道分别单跑通
6/15 - 网关部署完成 + 监控接入
6/10 - 安全审计通过
6/5 - 底座部署完成
6/1 - 项目启动
从这个反推可以看到:
- 底座部署是关键路径, 6/5 前必须完成
- 安全审计需要 5-7 天, 6/1 就要送审
结论：结果 → 里程碑 → 关键路径 → 每周动作 → 每日任务——每一步都从结果倒推。
关键动作：在项目启动时,画一张"倒推甘特图"——每个里程碑的 Owner 和 deadline 都锁死。
# 5. 向上同步的节奏
# 5.1 3-3-3 同步法
疑惑：向上同步多久一次? 说什么?
论证：3-3-3 同步法：
每日 (Daily): 3 句话周报文风的日报
每周 (Weekly): 3 段式周报
每 3 周 (Monthly): 30 分钟 1v1
每日 3 句话（钉钉/微信/邮件）：
"@A 总, 今日 Higress 项目:
1. 完成: 底座部署 (老陈交付)
2. 阻塞: 安全审计缺方案文档, 我今晚补齐
3. 明日: 3 渠道单跑通"
每周 3 段式（周五邮件）：
主题: [周报] Higress 项目 Week 3
## 本周进展 (最多 5 条)
1. ✅ 底座部署完成 (Owner: 老陈)
2. ✅ 3 渠道单跑通 (Owner: 张伟)
3. ⚠️ 安全审计延后到下周 (Owner: 老钱)
4. ⚠️ 运维监控接入完成 60%
## 风险与阻塞
- 安全审计比原计划晚 2 天, 我已请老钱周一给出具体日期
- 如果周三未完成, 上线要延期 1 周, 请 A 总周三决策
## 下周计划
1. 6/22 全链路联调 (Owner: 张伟)
2. 6/24 灰度 5% (Owner: 老赵)
3. 6/25 灰度 30% (Owner: 老赵)
每 3 周 1v1（30 分钟）：
议程:
- 15 min: 项目整体进展 vs 计划
- 5 min: 重大风险请老板决策
- 5 min: 资源/人力/预算诉求
- 5 min: 我的成长 (听老板对我的评价 + 反馈)
结论：3-3-3 = 老板永远知道你在干什么, 项目永远不会突然出问题。
# 5.2 好消息坏消息比
疑惑：向上同步只报喜好还是都报？
论证：黄金比例 1:3 — 每报 1 条坏消息, 报 3 条好消息：
❌ 全报喜:
"进展顺利, 一切都好"
(老板心里: 那要我干啥, 你在骗我吧)
❌ 全报忧:
"这里堵, 那里挡, 项目要黄"
(老板心里: 你怎么什么都搞不定)
✅ 1:3 比例:
"进展:
- ✅ 底座部署完成 (提前 1 天)
- ✅ 3 渠道单跑通 (提前 2 天)
- ✅ 团队士气高
- ⚠️ 安全审计比预期慢 2 天 (已跟老钱对齐加速方案)"
老板心里: 项目基本可控, 一个可管理的风险 → 满意
结论：报忧不是坏事,但要"报忧+方案"——报忧本身不扣分, 报忧不给方案才扣分。
# 5.3 让老板不惊喜
疑惑：为什么老板讨厌"惊喜"？
论证：惊喜 = 突然的坏消息 = 老板失控感。
张伟 12 天才报延期 → A 总"惊喜" → A 总: "为什么不早说!"
如果 Week 2 就报:
"安全审计有风险, 可能延期 1 周"
→ A 总: "OK, 我协调加急"
如果 Week 3 报:
"审计 + 部署双阻塞, 可能延期 2 周"
→ A 总: "严重, 我拉几方开会协调"
任何一个"早报"都比 Week 4 才报强
规则：风险信号出现 24 小时内, 必须同步老板。
结论：老板需要的是"没有意外" — 让老板永远比你晚一天知道结果, 就是让他随时"惊喜"的根源。
# 6. 跨部门推进四抓手
# 6.1 抓手一 共同目标
疑惑：4 个部门每个都有自己的 KPI, 凭什么听我的？
论证：跨部门推进的第一动作——建立共同目标：
❌ 张伟原版:
"请大家配合完成 Higress 上线"
(其他部门心里: 你的事, 关我啥事)
✅ 建立共同目标:
"Higress 上线是公司 Q2 OKR 关键项 (KR 3),
A 总周一晨会明确拍板 (@聊天记录截图),
每个部门是共同 Owner:
- 业务组: 用户体验
- 架构组: 平台建设 KR
- 运维组: SLA 保障 KR
- 安全组: 合规 KR
我们不是我拜托你们, 而是我们一起达成 Q2 OKR"
关键：把"我的事"变成"我们的事" — 每个部门都能在里面找到自己的 KPI。
# 6.2 抓手二 关键人识别
疑惑：怎么在别的部门找到能"拍板"的人？
论证：关键人四层识别法：
Layer 1: 决策者 (能拍板)
一般是部门 Leader / Tech Lead
Layer 2: 执行者 (真正干活)
一般是资深工程师
Layer 3: 影响者 (能左右决策者)
一般是老板信任的人
Layer 4: 阻碍者 (可能反对)
一般是有其他优先级的人
动作：为每个部门画一张关键人图：
架构组:
决策者: 老陈 (架构 Leader)
执行者: 小李 (实际部署 Higress 的人)
影响者: 老周 (架构 senior, 老陈信任)
阻碍者: 无
运维组:
决策者: 老赵 (运维 Leader)
执行者: 小张 (环境审批人)
影响者: 老赵直接汇报的运维总监
阻碍者: 小张 (还有 3 个环境审批优先级更高)
结论：跨部门推进要"点对点",不是"群里@"——找到关键人, 1v1 对齐, 效果 10 倍。
# 6.3 抓手三 排期同频
疑惑：其他部门都有自己的排期, 怎么让他们排我这个？
论证：排期同频三步：
Step 1: 主动拿到对方排期
"老陈, 你们组下周有什么优先级项目?"
"我们 Higress 什么时候能进你们排期?"
Step 2: 找到"低冲突时间窗"
"如果 6/12-6/15 你们组有 2 人天空闲,
刚好可以做底座部署"
Step 3: 承诺换承诺
"如果 6/15 前你们完成底座,
我们业务组承诺 6/20 前完成集成测试,
给你们的 Q2 OKR 交付贡献 30 分。"
关键：别指望对方"顺便帮你" — 给对方 KPI 好处, 才能进人家的排期。
# 6.4 抓手四 卡点周会
疑惑：拉个大群不够吗?
论证：大群 = 大家看不见,卡点周会 = 大家不能装看不见。
卡点周会设计（每周三 15 分钟）：
时间: 每周三 16:00-16:15 (钉钉群会议)
参会: 4 个部门各 1 名 Owner + 我 + Leader 老王 (旁听)
议程 (15 分钟严格控):
0-3 min: 张伟同步整体进度 + 关键风险
3-13 min: 逐个部门 2 分钟同步
- 上周完成: xx
- 本周计划: xx
- 阻塞求助: xx
13-15 min: 张伟收口 + 会议纪要 (钉钉发出)
产出:
- 每人本周 Action
- 阻塞点 Owner + Deadline
- 下周同步内容
关键动作：
① 会前 24h 发预备议程 (让每个人做准备)
② 会中严格控时 (超过 2 分钟主动打断)
③ 会后 30 min 内发纪要 (钉钉群 + 邮件)
④ 会中 Action 逐条跟进 (下周会问)
结论：卡点周会 = 跨部门推进的"心跳"——没有它, 项目就是无头苍蝇。
# 7. 复盘不甩锅五步
# 7.1 事实还原
疑惑：项目翻车了怎么复盘不撕破脸？
论证：复盘第一步——只讲事实, 不讲判断：
❌ 判断混淆:
"老陈没重视, 底座部署拖了 3 天"
(引发老陈防御, 复盘变吵架)
✅ 事实还原:
"底座部署原计划 6/5 完成, 实际 6/8 完成, 延后 3 天。
期间老陈组投入了 2 人日, 我方了解到主因是
6/5-6/7 老陈组同时有 XX 系统 P0 故障处理。"
(纯事实, 不带判断, 大家都同意)
关键：用时间线 + 数据 + 客观描述——"谁说了什么, 谁做了什么, 结果是什么"。
# 7.2 5Why 挖根因
疑惑：找到"谁没做好"就够了吗？
论证：不够——要找到"为什么没做好"。5Why 挖根因：
问题: 底座部署延后 3 天
Why 1: 为什么延后?
→ 老陈组同时处理 P0 故障
Why 2: 为什么 P0 故障冲突 Higress?
→ 排期没考虑其他优先级
Why 3: 为什么排期没考虑?
→ 我 (张伟) 没主动了解他们的排期
Why 4: 为什么没主动了解?
→ 我以为"上级拍板了就自动优先"
Why 5: 为什么会有这个错误认知?
→ 我没有跨部门推进经验, 没接受过训练
根因: 我 (张伟) 缺乏跨部门推进方法论
改进: 学习本篇 "跨部门四抓手", 下项目主动应用
结论：5Why 直到"根因是可改变的动作" — 不是"谁不好", 是"该做什么"。
# 7.3 定性不定人
疑惑：复盘会上怎么避免变成"批斗大会"？
论证：定性不定人：
❌ 定人:
"这次延期是因为老陈没重视"
✅ 定性:
"这次延期的根因是'跨部门排期没同频',
涉及:
- 项目发起方 (我) 缺乏方法论 (主责)
- 部门间没有排期共享机制 (环境)
- Higress 优先级信号没有传递到 Owner (流程)"
(把"人"翻译成"事"和"环境", 大家都松一口气)
关键：复盘的目标是"未来不再发生", 不是"追究谁应该背锅"。
Leader 的作用：Leader 主持复盘, 主动把"人的问题"翻译成"系统的问题"。这是 Leader 的核心职责。
# 7.4 改进 Action
疑惑：复盘出结论之后怎么落地？
论证：每个根因必须对应可执行 Action：
根因 1: 我缺乏跨部门推进方法论
Action: 张伟阅读本篇 + 下次项目 kick-off 前主持一次
跨部门排期会 (Owner: 张伟, Due: 下项目启动)
根因 2: 部门间没有排期共享机制
Action: 每周三部门 Leader 排期同步会
(Owner: 老王, Due: 下周三)
根因 3: 项目优先级信号传递不畅
Action: 项目启动会必须有 A 总参加,
他现场跟各部门 Leader 明确优先级
(Owner: 项目发起方, Due: 每次项目启动)
Action 的三要素: Owner + Due + 可验证的完成标志。
# 7.5 全员认领
疑惑：Action 定完了, 怎么保证做？
论证：每个 Action 现场认领, 会议纪要每人一份：
复盘纪要模板:
## 事实还原
[时间线]
## 5Why 挖根因
[根因清单]
## 改进 Action
| # | Action | Owner | Due | 验证方式 |
|---|-------|------|-----|--------|
| 1 | xx | 张伟 | 7/1 | 下次项目应用检验 |
| 2 | xx | 老王 | 6/28 | 首次排期会召开 |
| 3 | xx | A总 | 每次项目 | 项目启动会记录 |
## 承诺
每人签字确认: 张伟 ✍️ 老陈 ✍️ 老赵 ✍️ 老钱 ✍️ 老王 ✍️
关键：签字承诺 = 增加履约压力。不签字 = 复盘等于没开。
结论：复盘 = 事实还原 + 5Why + 定性不定人 + Action + 认领 — 五步都做齐, 才能"从失败中获得经验"。
# 8. 烂尾项目救火
# 8.1 承认烂尾比硬撑好
疑惑：项目已经明显要烂尾了, 怎么办？
论证：承认烂尾比硬撑好 10 倍。
❌ 硬撑:
"还能救! 再给我一周!" (一周后依然烂)
→ 老板从"信任"变"不信任"
✅ 承认烂尾, 主动升级:
"A 总, 项目当前状态:
- 原计划 6/30 上线, 实际评估需要 7/20
- 主因: 安全审计和运维联调都需要延后
- 建议: 缩范围 (只上 2 渠道), 6/30 达成
Q3 再补第 3 渠道"
心理原理：主动承认 = 掌控感 → 老板判定"这人靠谱"。硬撑 = 失控 → 老板判定"这人扛不住事"。
# 8.2 拆最小可交付
疑惑：项目救不回来了, 怎么拆最小可交付？
论证：问自己三个问题：
Q1: 老板/业务方最在乎的一条价值是什么?
(Higress 项目: 3 渠道跑通支持 Q3 海外业务)
Q2: 这条价值的"最小可交付"是什么?
(最小: 1 个渠道 Stripe 跑通)
Q3: 最小可交付需要哪些必须资源?
(业务组 5 人日 + 架构组 2 人日 + 运维组 1 人日)
→ 结论: 6/30 交付 Stripe 单渠道 (完整功能)
Alipay/WeChat 延到 7/20
关键：烂尾救火 = 从"全部做完"变成"最小价值先行"。这不是失败, 是敏捷交付。
# 8.3 争取时间窗口
疑惑：怎么让老板同意"缩范围+延期"？
论证：争取时间窗口的话术：
张伟 vs A 总 (1v1):
张伟: "A 总, 我需要 15 分钟同步一个坏消息和三个方案。"
(先声明信息复杂度, 让老板准备)
A 总: "说。"
张伟: "坏消息: 项目 6/30 上线概率只有 30%。
主因是安全审计需要 5 天 + 运维联调需要 3 天,
比原估多了 5 天。
三个方案我准备好了:
方案 A (推荐): 拆分交付
- 6/30: Stripe 单渠道上线 (支撑 Q3 海外)
- 7/20: Alipay/WeChat 补齐
- 风险: 可控, 30% → 90% 交付概率
方案 B: 全量延期
- 7/20: 全部 3 渠道
- 风险: Q3 海外延期 20 天
方案 C: 硬 6/30 上线
- 减少测试轮次
- 风险: 支付事故概率 40%, 单次事故预计 100 万+
我推荐 A。请您拍板。"
A 总: (30 秒思考) "A。"
结论：争取时间窗口 = 三方案让老板选, 给他决策权 + 让他知道你在为他兜底。
# 9. 闭环反模式
# 9.1 有始无终
症状：项目一半时 KPI 显示"进行中", 半年后没人跟进。
危害：沉没成本累积, 团队信任崩塌。
修复：每个项目必须有明确 Kick-off 和 Close-out——没关闭 = 没算完成。
# 9.2 只做不报
症状：埋头做,老板问才答, 平时不同步。
危害：老板始终不知道你做到什么程度——你的努力 = 隐形。
修复：3-3-3 同步节奏——每天 3 句话, 每周 3 段, 每 3 周 1v1。
# 9.3 交付就完事
症状：代码上线 = 项目完成, 不管业务是否用起来。
危害：做了 = 没做——没人用的功能 = 白做。
修复：交付后 30 天跟踪业务指标——指标达标才算闭环。
# 9.4 报忧不报忧根因
症状："XX 有问题" - 说完就没了。
危害：老板收到风险,但不知道你在做什么应对——只有情绪, 没有动作。
修复：报忧必须 + 3 项——问题是什么 + 影响多大 + 我在做什么 + 需要老板做什么。
# 9.5 复盘变批斗
症状：复盘会上互相指责, 变成"甩锅大会"。
危害：心结种下, 下项目更难协作。
修复：Leader 主持, 定性不定人——"人的问题" → "系统的问题"。
# 10. 综合案例串讲
# 10.1 张伟的跨部门救援
回到张伟, 项目正式延期后, 他做的第一件事不是复盘, 是重启项目：
Day 15 (延期首日):
张伟召集 4 位部门 Owner + Leader 老王, 45 分钟会议:
会议开场:
"项目延期是我的责任, 复盘我们下周做。
今天要做的事:
1. 重新对齐目标
2. 重排里程碑
3. 建立新的推进机制
目标: 3 周内交付, 不再延期。"
议程:
前 15 min - 重新定义结果:
"结果: 7/20 前 3 渠道跑通 100 笔真实交易,
失败率 < 0.5%, P99 < 500ms
验收: A 总 (业务) + 老陈 (架构) + 老赵 (运维)"
中 20 min - 反推里程碑:
"7/20 上线
← 7/17 灰度 30%
← 7/15 灰度 5%
← 7/12 联调完成
← 7/8 安全审计通过
← 7/5 运维环境就绪
← 7/1 底座重新验证
← 6/28 补齐前面遗漏"
后 10 min - 建立心跳:
"从明天起:
- 每天 10:00 站会 15 分钟 (钉钉)
- 每周三 16:00 卡点周会 45 分钟
- 每 3 周向 A 总同步 30 分钟 (老王参加)
我 (张伟) 是 Cost of Failure 的第一责任人。
任何阻塞: 24h 内我必须知道。"
散会前, 每位 Owner 签字:
"我承诺按上述节奏配合完成"
# 10.2 项目闭环全过程
接下来 3 周,张伟严格按四抓手推进：
Week 1 (Day 16-22):
Day 16: 张伟 1v1 老陈
- 拿到架构组下周排期
- 明确 Higress 优先级
- 承诺给架构组 Q2 KR 加分
- 老陈: "行, 我们分配 3 人日给你"
Day 17: 张伟 1v1 老赵
- 拿到运维环境审批流程
- 帮老赵起草了申请单 (省他 30 分钟)
- 老赵: "OK, 我明天就走审批"
Day 18-20: 每天 10:00 站会
- 3 分钟同步进度
- 阻塞立刻记录
- 我 15 分钟内跟进
Day 21: Week 1 卡点周会
- 3 部门进度都符合预期
- 老王旁听, 全程点头
Day 22: 向 A 总同步周报
"本周进度:
✅ 架构组底座重新验证通过
✅ 运维环境审批通过
⚠️ 安全审计比预期慢 1 天, 已跟老钱对齐加速
本周风险: 可控, 老钱周一给出加速方案"
A 总回复: "OK, 继续"
Week 2 (Day 23-29):
Day 24: 安全审计比预期慢 3 天信号出现
张伟: 24 小时内升级
Day 25: 老王 + A 总 + 老钱 (安全 Leader) 会议 30 分钟
张伟提三个方案:
A: 找二级安全审计员并行 (方案通过时间 +1 天)
B: 简化审计范围 (只审关键接口, 3 天完成)
C: 延期 3 天 (7/23 上线)
A 总: "B. 但要让老钱书面确认审计范围。"
张伟当天下午拿到老钱的书面确认。
Week 2 结束, 项目回到轨道。
Day 27-28: 逐渠道联调, 每天晚上 22:00 张伟发进展
Week 3 (Day 30-36):
Day 32 (7/12): 全链路联调完成
Day 33: 灰度 5%
Day 35 (7/15): 灰度 30%
Day 37 (7/17): 灰度 60%
Day 40 (7/20): 全量!
上线当天:
张伟启动 OODA 循环
每 15 分钟观察监控, 3 次微调, 0 次回滚
当天 100 笔真实交易 P99: 380ms, 失败率 0.12%
超出预期
Day 41 (7/21): 复盘会 60 分钟
张伟主持, 按五步复盘法:
Step 1 事实还原: 时间线 + 数据
Step 2 5Why: 原始延期的根因
→ 我缺跨部门推进方法论
Step 3 定性不定人: "跨部门排期机制缺失",
不是"谁不重视"
Step 4 改进 Action:
- 我: 项目启动前主持排期会 (未来所有项目)
- 老王: 部门间月度排期会 (已启动)
- A 总: 项目启动会拉齐关键人 (已承诺)
Step 5 签字承诺
Day 60: A 总在部门大会上点名表扬：
A 总: "张伟这个 Higress 项目值得学习:
虽然延期了, 但延期后的 3 周救援堪称教科书:
- 主动升级
- 分方案让我决策
- 每周节奏清晰
- 上线当天丝毫没乱
- 复盘做到根因
这就是我们要的资深工程师做事方式。"
张伟同期收到 Leader 老王的反馈：
"6 个月前的你, 会因为一个 PR 被 Diss 就慌。
现在的你, 4 个部门都跟你办事。
你已经从'工程师'变成'能扛事的人'。
下季度考虑推你做 Tech Lead。"
# 10.3 闭环哲学回扣
回望张伟这次跨部门救援, 闭环力的本质是：
初级: 努力 (我尽力了)
中级: 交付 (我上线了)
高级: 拿结果 (业务用起来了)
资深: 跨部门推动 (让别人也拿到结果)
大师: 制度化 (让下次不再重现)
闭环的四层修炼：
第一层: 结果思维 (定义 vs 交付)
第二层: 双循环 (PDCA + OODA)
第三层: 跨部门 (共同目标 + 关键人 + 排期 + 卡点会)
第四层: 复盘沉淀 (5Why + 定性不定人 + Action + 认领)
核心命题：你能闭环多大的圈, 就能承担多大的项目。
渐进图：
1 人闭环: 自己写 bug 自己修
5 人闭环: 带小组交付一个模块
20 人闭环: 跨部门做一个项目
100 人闭环: 跨事业部做一个战略
1000+ 闭环: 组织级变革
结论：每次做事都是"闭环等级"的一次修炼——从"我做完了"到"我确认它 work 了", 就是资深工程师的分水岭。
# 10.4 闭环速查
闭环速查表：
| 场景 | 动作 |
|---|---|
| 项目启动 | 结果定义 + 验收人 + 时间点 三要素 |
| 每日推进 | 10:00 站会 15 分钟 |
| 每周复盘 | Week Check → Act → 老板周报 |
| 跨部门 | 共同目标 + 关键人 + 排期同频 + 卡点会 |
| 阻塞出现 | 24h 内升级 (不能压 48h) |
| 老板同步 | 3-3-3 节奏 (日/周/月) |
| 报忧 | 问题 + 影响 + 我在做 + 需要老板做 |
| 上线当天 | OODA 每 15 分钟观察 |
| 上线后 30 天 | 跟踪业务指标 → 才算闭环 |
| 项目烂尾 | 三方案让老板选 (缩范围/延期/硬上) |
| 复盘 | 事实 → 5Why → 定性不定人 → Action → 签字 |
3-3-3 同步模板：
每日 3 句 (钉钉发老板):
1. 完成: ...
2. 阻塞: ...
3. 明日: ...
每周 3 段 (邮件):
## 本周进展
## 风险与阻塞
## 下周计划
每 3 周 30 分钟 1v1:
- 15 min 项目 vs 计划
- 5 min 请老板决策
- 5 min 资源诉求
- 5 min 我的成长
跨部门推进四抓手：
抓手 1: 建立共同目标 (KPI 对齐)
抓手 2: 识别关键人 (决策者/执行者/影响者/阻碍者)
抓手 3: 排期同频 (拿对方排期 + 承诺换承诺)
抓手 4: 卡点周会 (每周 15 分钟, 严控)
复盘五步：
1. 事实还原 (只讲事实)
2. 5Why 挖根因 (直到可改变的动作)
3. 定性不定人 (人 → 系统)
4. 改进 Action (Owner + Due + 验证)
5. 全员签字承诺
下一集预告：Higress 项目全量上线 1 个月后, CTO 找张伟单聊："下季度我准备推你做 Tech Lead, 带 10 人小组, 你准备好了吗？" 张伟激动之余,发现从"独狼工程师"变成"带团队的人"完全是另一个物种——技术判断力从"我怎么写"变成"团队怎么走", 影响力从"说服 5 个 Reviewer"变成"驱动 10 个下属"。**第 07 篇《资深程序员软能力》**告诉他"影响力大过 KPI"。
本篇速查表：
| 维度 | 关键武器 |
|---|---|
| 结果思维 | 定义 + 验收人 + 时间点 |
| 双循环 | PDCA (稳态) + OODA (应急) |
| 向上同步 | 3-3-3 + 1:3 好坏比 + 让老板不惊喜 |
| 跨部门四抓手 | 共同目标 + 关键人 + 排期 + 卡点会 |
| 复盘五步 | 事实 + 5Why + 定性 + Action + 签字 |
| 烂尾救火 | 承认 + 最小交付 + 三方案 |
| 反模式 | 有始无终 / 只做不报 / 交付完事 / 报忧无根因 / 复盘变批斗 |
