第一段：口径与样本
先花时间把核心指标写成字典，并收集真实提问样本。这段无法压缩，因为争议要靠业务部门当面确认。准出条件是字典评审通过、样本覆盖高频与边缘两类，之后才允许进入数据开发。
第二段：数据打通
按指标推进而不是按系统推进：每接通一个指标，就验证一次与台账的差异。准出条件是该指标可复现、可追溯、更新时效达标。按系统推进常出现接口全通、指标仍算不出的局面。
第三段：问答与权限
问答在语义层稳定后接入，权限在统一身份就绪后配置，两件事并行但互不阻塞。准出条件是越权测试通过、拒答规则生效、回答附口径。这一段最容易被压缩，压缩后问题会在试运行时集中出现。
第四段：试运行与交接
用两到四周让真实用户带着真实问题使用，记录无法回答的问题与口径争议，逐条归入整改或需求池。准出条件是运营负责人到位、复审节奏确定、运维手册交付。跳过这段，上线日就是争议开始日。
适用与不适用
适合谁
- 需要在立项会上给出排期承诺的项目负责人
- 已被要求压缩工期、想说明风险的实施团队
不适合谁
- 单部门单数据源的小型看板，可按周排期
- 只想尽快看到界面、不设准出条件的项目
典型场景
某零售企业原计划两个月上线驾驶舱，按四段拆解后发现口径评审就要三周。项目组把范围从四十个指标压到十二个，数据打通按指标推进，问答延后一个迭代。最终三个月交付，试运行期收集的争议问题比预期少，因为字典提前冻结。
可执行步骤
- 按四段列里程碑，为每段写准出条件而不是只写日期与工期
- 先估口径评审需要几轮，再据往返次数倒推开发与试运行排期
- 把指标数量作为可调范围，工期紧时优先减指标而不是压测试
- 试运行期固定收集问题，按缺陷与需求两类分别登记并归档
- 交接前确认运营负责人与复审节奏已经落实到人并写入移交单
常见坑
- 按页面数量排期，忽略口径评审的往返次数，开发阶段反复改语义层，返工吃掉全部缓冲。
- 把试运行当验收，用户第一次上手就是上线日，问题与投诉同时到达，团队只能被动救火。
- 里程碑只写日期不写准出物，延期时无法界定责任，也判断不了能否进入下一阶段。
自检与验收清单
- 每段里程碑是否都有可验证的准出条件
- 指标数量是否作为可调范围写进方案
- 试运行期是否设问题收集与分类机制
- 运营负责人是否在交接前到位并签字
常见问题
能不能一个月上线？
单部门、单数据源、指标不超过十个时可以，前提是口径已统一、权限模型简单。跨部门驾驶舱一个月通常只能到原型阶段，强行上线会把口径争议留到运营期处理。
里程碑按日期还是按交付物？
建议按交付物，日期只作参考。以交付物为准出条件，延期时能说清卡在哪一层；只按日期考核，团队会优先保证界面可见，把数据与权限问题往后拖。
试运行要多久？
两到四周较常见，取决于用户数量与指标争议程度。试运行不是演示，要覆盖月结、季末等特殊时点，否则迟到数据与口径切换的问题发现不了，上线后仍需返工。