三段式排期
准备阶段定判据、找样本、对齐口径；运行阶段只做观察与修缺陷；复盘阶段出一页结论。为什么三段不能重叠：一边改口径一边收数据，任何结论都会被质疑；三段写进日历，比口头约定可靠。
观察期要跨业务周期
选观察期先看业务日历：是否跨月末结算、是否撞上大促、是否遇到排班轮转。为什么这么说：只覆盖低谷期，指标会显得轻松；只覆盖高峰期，又会把压力当成常态；跨过一个完整周期，结论才有迁移价值。
依赖一：样本授权
真实样本往往涉及客户信息，需要业务与法务共同确认可用范围与脱敏方式，这一步常被忽略却最耗时。怎么做：准备阶段第一周就提出申请并附脱敏方案，等运行开始才申请通常顺延两周。
依赖二：人员排班
使用者的时间来自排班表，不是负责人的一句招呼。怎么做：提前四周把参与时段写进班组排班并安排替班；靠临时抽调会让观察期数据断档，断档超过一周，前后对比就不成立，只能延长试运行。
依赖三：接口与环境
试点常需只读接口、测试环境与脱敏数据副本，这些都要走 IT 流程。边界在于：环境与权限由客户方 IT 提供并负责，我方列出清单与时间要求；在启动会上逐项确认，避免运行中途才发现缺权限。
适用与不适用
适合谁
- 排期已定、需要按时给出结论的试点
- 涉及客户数据、需走法务与安全确认的场景
- 跨部门抽调人员、协调成本较高的企业
不适合谁
- 不受时间约束、不需要对外给出结论的纯技术验证
- 样本与使用人员完全由项目组自行掌握的小范围试用
典型场景
某连锁零售企业计划在四月做门店补货建议试点。排期时发现四月下旬有大促、五月上旬有盘点，观察期最终定在五月中旬到六月下旬，跨过一次月末结算；样本授权在三月初就提交，接口申请与排班同步推进。虽然启动晚了两周，六月底仍按原计划给出了结论。
可执行步骤
- 按业务日历标出大促、月末结算与盘点期，先排除不适合观察的时段
- 把准备、运行、复盘三段的起止日期写进共享日历，同时向相关方公布
- 在准备阶段的第一周就提交样本使用申请，同时附上脱敏与留存方案
- 提前四周把参与时段写进班组排班表，并为每个时段安排一名替班人员
- 启动会上逐项确认接口、环境与权限清单，并写明各自的最晚到位日期
- 复盘单独留出一周，不与上线、评审或其他里程碑重叠，确保有人到场
常见坑
- 观察期只覆盖业务低谷，指标看起来很漂亮，扩围后一遇高峰问题集中暴露，结论被彻底推翻。
- 样本授权拖到运行前一周才申请，脱敏方案返工两次，观察期整体顺延，错过了预算评审窗口。
- 参与时段没有写进排班表，使用者被临时调去支援，数据断档两周，前后对比彻底失去意义。
- 准备阶段与运行阶段重叠，一边改判据一边收数据，复盘时谁也说不清结论依据的是哪一版口径。
自检与验收清单
- 观察期是否跨过一个完整业务周期并避开大促
- 三段排期是否已写进共享日历，并通知到相关方
- 样本授权与脱敏方案是否在准备阶段首周提交
- 参与时段是否已进入排班表，并安排替班人员
- 接口、环境与权限清单是否逐项写明到位日期
常见问题
观察期能不能压缩到两周？
可以，但结论强度会明显下降。两周通常只能覆盖一次业务波动，无法判断稳定性；如果确实时间紧，建议缩小场景范围换取更长的观察期，而不是压缩观察期本身，因为结论一旦失真，后续决策成本更高。
样本迟迟批不下来怎么办？
先拆成两级：用完全脱敏或历史样本跑通流程，验证技术可行性；涉及客户信息的样本另行审批，用于验证真实分布。这样既不让项目停摆，也不违反数据要求，但两级结论要分别写清适用范围。
试点能否与正式建设并行？
不建议完全并行，可以有限重叠：试点结论确定后再启动开发，但环境准备与接口申请可以提前。完全并行意味着一边验证一边承诺交付，一旦试点被证伪，前期开发投入基本无法回收。