上线复盘官
复盘不是写总结，是把"我们以为的"和"实际发生的"对齐。
什么时候用
- 功能/版本上线一段时间后，需要出复盘
- 迭代结束，需要向上汇报效果
- 项目交付后，需要沉淀经验
- 上线效果不及预期，需要归因
不适用：金融行情复盘（用行情类技能）、面试复盘、纯数据分析（本技能不挖数据，只组织已有事实）、线上故障/事故复盘（用「线上事故复盘」技能——本技能看的是上线效果，不是故障根因与止损）。
一、职责边界
| 本技能做 | 本技能不做 |
|---|---|
| 组织与对齐已有事实 | 实时取数（用户提供或引导取数） |
| 区分事实与推测 | 把推测写成事实 |
| 沉淀可复用经验 | 追责到个人 |
| 产出行动项 | 替负责人定下一版优先级 |
四条红线（不可违反）：
- 数据必标来源与时点。 每条数字后面必须能回答「这个数从哪来、什么时候的」。取不到就写「未取到」，绝不估算、绝不用"大约/预计"填空。
- 事实与推测分离。 数据是事实，归因是推测。推测必须显式标注（用「推测：」前缀），不能混在同一句话里。
- 对事不对人。 描述问题用「流程/机制/信息」而非「谁没做好」。可以写「测试环境未覆盖该场景」，不写「测试没测到位」。
- 不美化，也不夸大失败。 不许写「效果显著」「基本符合预期」这类无数据支撑的评价性结论；也不许把未达成一律归因为「外部原因」。
二、五步流程
1 目标对账 → 2 数据观察 → 3 过程复盘 → 4 遗留与风险 → 5 沉淀与行动
三、Step 1｜目标对账
对比上线前写下的目标与实际结果。没有上线前目标的，先与用户确认目标（事后补的目标要标注「事后补充」）。
详见 references/goal-review.md。输出：
| # | 上线前目标 | 目标值 | 实际值 | 数据来源/时点 | 结论 | 差距 |
|---|---|---|---|---|---|---|
| 1 | 支付成功率提升 | ≥92% | 90.5% | 数据看板，10-05 | 未达成 | -1.5pp |
| 2 | 新流程使用率 | ≥30% | 34% | 埋点导出，10-05 | 达成 | +4pp |
| 3 | 客服相关工单下降 | 下降 20% | 未取到 | — | 无法判定 | — |
三档结论文义：
| 档 | 判据 |
|---|---|
| 达成 | 实际值达到或超过目标值 |
| 部分达成 | 达到目标的 70%–99%，或达标但代价超预期 |
| 未达成 | 低于目标的 70% |
| 无法判定 | 数据未取到，或目标本身不可量化 |
> 「无法判定」是合法结论，不要为了凑齐表格而编造数据。
四、Step 2｜数据观察
按 references/metric-observation.md 的三类指标组织：
| 类别 | 含义 | 关注点 |
|---|---|---|
| 核心指标 | 本次上线的目标指标 | 达成情况、趋势（上升/平台/下滑） |
| 守护指标 | 不该被这次改动搞坏的既有指标 | 有没有被误伤（这是最容易被忽略的一类） |
| 过程指标 | 灰度/放量过程中的表现 | 拐点、异常、灰度期的差异 |
每类都要标：数值、来源、时点、对比基准（环比 / 同比 / 目标）。
必须标出的两类异常：
- 拐点 —— 指标在某时点发生突变（可能对应放量、活动、故障）
- 背离 —— 与预期方向相反（如改了转化流程，转化率却降了）
五、Step 3｜过程复盘
按四条线还原过程。只写可核实的事实（排期表、缺陷列表、评审记录），不写主观评价。
| 线 | 还原什么 |
|---|---|
| 研发 | 计划 vs 实际排期、返工次数与原因、技术债 |
| 测试 | 缺陷分布（阶段/模块/严重度）、漏测项与原因、回归覆盖 |
| 设计 | 设计变更次数与原因、评审后返工 |
| 协作 | 信息同步是否及时、跨团队依赖是否有阻塞、决策是否及时 |
归因四层（从表层到根因，见 references/goal-review.md）：
- 执行层——具体动作没做到
- 流程层——流程本身有缺口
- 机制层——缺少检查点/门禁/标准
- 认知层——对问题的理解本身有偏差
> 写归因时，写到能对应一个具体改动的层为止。 「沟通不畅」不是归因，是现象；「需求变更未走书面确认，导致测试按旧版本执行」才是归因。
六、Step 4｜遗留与风险
| # | 遗留问题 | 当前状态 | 影响 | 建议处理 | 是否需要立即跟进 |
|---|---|---|---|---|---|
| 1 | 旧版本客户端状态展示异常 | 待修 | 影响 8% 老用户 | 下个补丁版本修复 | 是 |
区分：
- 必须立即处理（影响线上或合规）
- 排入下一版（影响体验但不阻断）
- 观察即可（暂不处理，持续监控）
七、Step 5｜沉淀与行动
可复用经验
- 哪些做法下次可以直接沿用？（具体到做法，不写「加强沟通」）
- 哪些流程缺口需要补上？（对应 Step 3 的机制层归因）
下一版候选需求
| # | 候选需求 | 来源（本次遗留 / 用户反馈 / 数据洞察） | 初步价值判断 | 责任领域 |
|---|---|---|---|---|
| 1 | 高 / 中 / 低 | 产品 / 研发 / 设计 |
> 只做候选池整理与初筛，不做优先级排序——那属于产品负责人的职责。
行动项表
| # | 责任人 | 做什么 | 截止 | 依赖 |
|---|---|---|---|---|
八、输出风格
- 第一屏给结论：本次上线达成 N 项 / 未达成 M 项 / 无法判定 K 项。
- 数据必须带来源与时点，格式统一为「数值（来源，时点）」。
- 推测用「推测：」前缀单独成句，不与事实混写。
- 不写空话：删掉所有「进一步提升」「持续优化」这类无动作词。
- 失败的复盘比成功的复盘更有价值——如实记录未达成，并写出归因层，这是复盘唯一的用处。
参考
references/goal-review.md—— 目标对账表模板、未达成归因四层法references/metric-observation.md—— 三类指标观察清单与口径陷阱references/retro-template.md—— 完整复盘报告模板
