6.做事闭环执行能力
# 6.做事闭环执行能力
# 目录介绍
- 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 顺藤摸到根因
带着这条线往下挖：糖果充不努力？不是，他天天加班；其他部门不配合？不是，他们各有优先级；项目太难？不是，技术都不难；那问题在哪？"推进 ≠ 闭环"；什么叫闭环？明确责任 + 时间承诺 + 主动跟进 + 拿到结果；为什么老手能跨 4 部门推进？他们有一套闭环动作库——这就是本篇主线。
翻车现场的表象与真实问题：
表象 真实问题
────────────────────────────────────────────
"群里 @ 大家" → 没有点对点承诺 (@ 大家 = 谁都没看到)
"两周搞定" → 没拆里程碑, 没识别关键路径
"有问题群里同步" → 没有主动跟进机制
"我以为自动就有" → 没了解上下游流程 (环境审批要多久?)
第 12 天才报告延期 → 向上同步节奏为零
根因：糖果充把"我尽力做了"当成"闭环"，实际上闭环是 "事情按预期在 deadline 前完成"。只有努力没有结果，就是 0。这一段藏着 8 个原理点：① "闭环"到底指什么、交付了就算闭环吗？→ 第 2 章；② 拿结果和交付作业的差别？→ 第 4 章；③ 什么时候用 PDCA / OODA？→ 第 3 章；④ 向上同步该多久一次、说什么？→ 第 5 章；⑤ 跨部门推进的具体动作？→ 第 6 章；⑥ 项目翻车怎么复盘不甩锅？→ 第 7 章；⑦ 项目烂尾怎么救火？→ 第 8 章；⑧ "看起来闭环、其实没闭"的陷阱？→ 第 9 章。
# 1.3 我们要回答什么
这个事故就是本篇的主线案例。本篇路线：闭环全景图（第 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 双循环
PDCA（Plan-Do-Check-Act）是稳态项目的循环（周或双周，适合 > 4 周稳态推进）；OODA（Observe-Orient-Decide-Act）是应急项目的循环（空军战斗机飞行员经典模型，分钟到小时级，适合突发/危机）。两者对比：
| 循环 | 阶段 | 关键动作 | 周期 | 适用 |
|---|---|---|---|---|
| PDCA | Plan 计划 | 拆里程碑、分配责任人、制定验收标准 | 周 / 双周 | 目标稳定、有充分信息、协作稳定 |
| Do 执行 | 按计划推进、及时同步进度 | |||
| Check 检查 | 对比计划与实际，发现偏差 | |||
| Act 改进 | 调整计划或加速，沉淀经验 | |||
| OODA | Observe 观察 | 收集当前所有信息 | 分钟 / 小时 | 突发、目标模糊、信息稀缺、窗口极短 |
| Orient 定向 | 分析形势，判断优先级 | |||
| Decide 决策 | 快速做出选择 | |||
| Act 行动 | 立刻执行 |
举例：Higress 上线当天发现 Stripe 支付失败率飙升到 30%——O 观察监控 10 min（全链路超时）→ O 定向 5 min（是网络 / 配置 / Stripe 侧？）→ D 决策 5 min（先切回老网关，再排查）→ A 执行 2 min（Feature Flag 切回 Alipay/WeChat 老通道）。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 同步法——每日 3 句话周报文风的日报、每周 3 段式周报、每 3 周 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 抓手二 关键人识别
怎么在别的部门找到能"拍板"的人？关键人四层识别法：决策者（能拍板，一般是部门 Leader / Tech Lead）+ 执行者（真正干活，一般是资深工程师）+ 影响者（能左右决策者，一般是老板信任的人）+ 阻碍者（可能反对，一般是有其他优先级的人）。
动作：为每个部门画一张关键人图：
架构组: 决策者 老陈 (架构 Leader) 执行者 小李 (实际部署)
影响者 老周 (架构 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 分钟同步 (上周完成 / 本周计划 / 阻塞求助)
13-15 min: 糖果充收口 + 会议纪要 (钉钉发出)
产出: 每人本周 Action + 阻塞点 Owner + Deadline + 下周同步内容
关键动作:
① 会前 24h 发预备议程 (让每人做准备)
② 会中严格控时 (超过 2 分钟主动打断)
③ 会后 30 min 内发纪要 (钉钉群 + 邮件)
④ 会中 Action 逐条跟进 (下周会问)
结论：卡点周会 = 跨部门推进的"心跳"——没有它，项目就是无头苍蝇。
# 7. 复盘不甩锅五步
项目翻车了怎么复盘不撕破脸？五步复盘法：
Step 1 · 事实还原（只讲事实、不讲判断）：
❌ 判断混淆: "老陈没重视, 底座部署拖了 3 天"
(引发老陈防御, 复盘变吵架)
✅ 事实还原: "底座部署原计划 6/5 完成, 实际 6/8 完成, 延后 3 天。
期间老陈组投入了 2 人日, 我方了解到主因是
6/5-6/7 老陈组同时有 XX 系统 P0 故障处理。"
(纯事实, 不带判断, 大家都同意)
用时间线 + 数据 + 客观描述——"谁说了什么，谁做了什么，结果是什么"。
Step 2 · 5Why 挖根因：直到"根因是可改变的动作"：
问题: 底座部署延后 3 天
Why 1: 为什么延后? → 老陈组同时处理 P0 故障
Why 2: 为什么 P0 冲突 Higress? → 排期没考虑其他优先级
Why 3: 为什么排期没考虑? → 我 (糖果充) 没主动了解他们的排期
Why 4: 为什么没主动了解? → 我以为"上级拍板了就自动优先"
Why 5: 为什么会有这个错误认知? → 我没有跨部门推进经验, 没接受过训练
根因: 我 (糖果充) 缺乏跨部门推进方法论
改进: 学习本篇 "跨部门四抓手", 下项目主动应用
5Why 直到"根因是可改变的动作"——不是"谁不好"，是"该做什么"。
Step 3 · 定性不定人：
❌ 定人: "这次延期是因为老陈没重视"
✅ 定性: "这次延期的根因是'跨部门排期没同频', 涉及:
- 项目发起方 (我) 缺乏方法论 (主责)
- 部门间没有排期共享机制 (环境)
- Higress 优先级信号没有传递到 Owner (流程)"
(把"人"翻译成"事"和"环境", 大家都松一口气)
复盘的目标是"未来不再发生"，不是"追究谁应该背锅"。Leader 主持复盘，主动把"人的问题"翻译成"系统的问题"——这是 Leader 的核心职责。
Step 4 · 改进 Action：每个根因必须对应可执行 Action，含 Owner + Due + 可验证的完成标志：
根因 1: 我缺乏跨部门推进方法论
Action: 糖果充阅读本篇 + 下次项目 kick-off 前主持一次跨部门排期会
(Owner: 糖果充, Due: 下项目启动)
根因 2: 部门间没有排期共享机制
Action: 每周三部门 Leader 排期同步会
(Owner: 老王, Due: 下周三)
根因 3: 项目优先级信号传递不畅
Action: 项目启动会必须有 A 总参加, 现场跟各部门 Leader 明确优先级
(Owner: 项目发起方, Due: 每次项目启动)
Step 5 · 全员认领：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. 闭环反模式
闭环链路最常见的五种死法：
| 反模式 | 症状 | 危害 | 修复动作 |
|---|---|---|---|
| ① 有始无终 | 项目一半时 KPI 显示"进行中"，半年后没人跟进 | 沉没成本累积、团队信任崩塌 | 每个项目必须有明确 Kick-off 和 Close-out——没关闭 = 没算完成 |
| ② 只做不报 | 埋头做，老板问才答，平时不同步 | 老板始终不知道你做到什么程度——你的努力 = 隐形 | 3-3-3 同步节奏——每天 3 句话，每周 3 段，每 3 周 1v1 |
| ③ 交付就完事 | 代码上线 = 项目完成，不管业务是否用起来 | 做了 = 没做——没人用的功能 = 白做 | 交付后 30 天跟踪业务指标——指标达标才算闭环 |
| ④ 报忧无根因 | "XX 有问题"——说完就没了 | 老板收到风险但不知道你在做什么应对——只有情绪没有动作 | 报忧必须 + 3 项——问题是什么 + 影响多大 + 我在做什么 + 需要老板做什么 |
| ⑤ 复盘变批斗 | 复盘会上互相指责，变成"甩锅大会" | 心结种下，下项目更难协作 | 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 句 (钉钉发老板): 完成 / 阻塞 / 明日
每周 3 段 (邮件): 本周进展 / 风险与阻塞 / 下周计划
每 3 周 1v1: 项目 15 min + 请老板决策 5 min
+ 资源诉求 5 min + 我的成长 5 min
【跨部门四抓手】
1. 建立共同目标 (KPI 对齐)
2. 识别关键人 (决策者/执行者/影响者/阻碍者)
3. 排期同频 (拿对方排期 + 承诺换承诺)
4. 卡点周会 (每周 15 分钟, 严控)
【复盘五步】
1. 事实还原 (只讲事实)
2. 5Why 挖根因 (直到可改变的动作)
3. 定性不定人 (人 → 系统)
4. 改进 Action (Owner + Due + 验证)
5. 全员签字承诺
【烂尾三方案模板】
A (推荐): 拆分交付 (最小价值 + 补齐)
B: 全量延期
C: 硬上 (承担事故风险)
下一集预告：Higress 项目全量上线 1 个月后，CTO 找糖果充单聊："下季度我准备推你做 Tech Lead，带 10 人小组，你准备好了吗？"糖果充激动之余，发现从"独狼工程师"变成"带团队的人"完全是另一个物种——技术判断力从"我怎么写"变成"团队怎么走"，影响力从"说服 5 个 Reviewer"变成"驱动 10 个下属"。**第 07 篇《资深程序员软能力》**告诉他"影响力大过 KPI"。
本篇速查表：
| 维度 | 关键武器 |
|---|---|
| 结果思维 | 定义 + 验收人 + 时间点 |
| 双循环 | PDCA（稳态）+ OODA（应急） |
| 向上同步 | 3-3-3 + 1:3 好坏比 + 让老板不惊喜 |
| 跨部门四抓手 | 共同目标 + 关键人 + 排期 + 卡点会 |
| 复盘五步 | 事实 + 5Why + 定性 + Action + 签字 |
| 烂尾救火 | 承认 + 最小交付 + 三方案 |
| 反模式 | 有始无终 / 只做不报 / 交付完事 / 报忧无根因 / 复盘变批斗 |
