交付协作方法论：排期、风险暴露与联调清单

整理自 2025-08 一次完整迭代的复盘（延期风险→测试拒收→压力会议→冒烟通过→周末改缺陷），把教训固化成操作准则。

一次迭代里最容易翻车的不是写代码，而是协作节奏：排期拍脑袋、风险捂到最后一刻、联调当天才发现环境和数据没准备、下游改了配置没人知道。这篇把排期、风险同步、联调检查三件事各自固化成可操作的准则。

排期拆到 0.5 天，缓冲加在三类任务上

排期按 0.5 天的粒度拆分：任务拆不到半天级别，通常说明实现路径还不够清楚；拆细的过程本身也能暴露风险。涉及历史兼容、影响面广或不熟悉的任务，额外加 1 到 2 天缓冲。这三类任务容易漏算排查、回归和联调时间，缓冲需要明确写进排期。

用第一性原理组织排期

• 拆解：目标（D 日完成联调）→ 约束（人力/环境/依赖）→ 不可变项（合规、上游 SLA）；
• 重组：按验证顺序排任务（先环境/数据，再核心链路，后边缘分支），把最长路径前置；
• 可证伪：给关键假设设最晚验证点（如“下游配置需在前一晚 20:00 前验证通过”），逾期即自动升级风险，不依赖个人判断。

风险提前一天报，用三句式

风险的价值随时间衰减：联调前一天报，还有分摊、调序、降级三种处置空间；联调当天报，只剩延期一种结果，且消耗信任。所以按联调日倒推。联调前一天仍有 1 到 2 项未完成，就必须当天报风险并明确请求分摊（谁接、接哪块、何时回报），而不是等联调当天暴雷。

同步用三句式，只报事实与下一步。“少说少错”不等于沉默：在人多的场合避免情绪化，但需要资源必须当场点名要：

事实：X 模块因 Y 依赖/配置尚未就绪，当前完成度约 Z%
影响：若今晚不解决，联调/验收将延期 T 小时/天
请求：请 A 负责配置，B 协助测试数据，目标今天 18:00 完成

配套动作：会前列阻塞 Top3；会后发纪要（决议、负责人、截止时间、风险等级）；超时自动升级（群内 @负责人/上级）。

联调前 24 小时走清单

联调日前 24 小时核对这些项：

• 环境/配置对齐（含下游变更项与回滚方案）
• 冒烟集（接口样例 + 期望响应），脚本化可复用
• 监控/日志级别与关键埋点
• 数据准备（测试账号、关键主数据）

排期侧同样有一份检查：

• 任务按 0.5 天的粒度拆分
• 历史兼容/改造面广/不熟，额外增加 1 到 2 天缓冲
• 最长路径前置，关键假设有最晚验证点
• 联调日前未清零 → 当日立刻报风险并请求分摊

下游依赖建配置变更台账

为杜绝“下游改配置导致接口异常”复发，给下游依赖建配置变更台账：owner、变更项、时间窗、回滚手段。

节奏保护

• 周中高压期减少信息噪声，只保留“日报 + 看板 + 阻塞清单”三个信息面。
• 对当周主线无贡献的需求，延后或合并，保护联调与提测窗口。
• 周末支撑测试要明确工作边界与产出（缺陷清单/修复单/回归点），避免无形加班。
• 每日 10 分钟风险站会：只讲 Top3 阻塞与下一步，每项挂责任人与时间点。

一次真实迭代的验证

这套准则来自一次真实迭代：周二同步延期风险被测试拒收、周三会议高压、周四中午冒烟通过。复盘时看，如果提前一天同步风险并完成联调清单，团队会多出分摊和调序的时间。后续迭代沿用清单后，提测节奏也更平稳。

适用范围

适用于 1 到 2 周的迭代交付，有独立测试角色和下游依赖的团队场景。三句式与站会机制依赖团队对风险上报有明确的响应方式；如果上报只会带来追责，机制很快就会失效。清单是下限不是上限：条目应随事故复盘持续增补，固化到团队模板（Notion/Markdown）并每次回填结果。