首次建立交付预测准确率机制，关键是把“预测什么、在哪个时点预测、以哪一版为准、多久复盘一次”这四件事固定下来。本文按对象、时点、版本、复盘、示例和验收的顺序，给出一套可以直接落地的规则，适合从零起步、希望先跑通一个层级的团队参考。
要点总览（TL;DR）
- 预测对象选可独立验收、有明确完成定义的交付单元，首次建立从版本或需求批次这类单一层级起步，全机制统一口径。
- 基准时点固定在交付节点前一个稳定提前量上，同一对象只取一个基准时点，提前量按对象周期和变更频率确定。
- 准确率以基准时点冻结的那版预测为准，冻结后的变更单独留痕、不覆盖原预测，实际结果按同一完成定义取值。
- 复盘节奏与预测周期对齐，周期做偏差归因、按月汇总趋势，前两到三个周期只统计不考核，用于校准口径。
- 机制可用的判断标准是对象、时点、版本、复盘四项全部固定，且任取一个历史周期能复现准确率计算过程。
先定预测对象：选哪一层交付单元来预测
预测对象决定准确率的分母和口径。选取原则有两条：这个单元能独立验收，交付完成与否不依赖其他单元；它有明确的完成定义，团队能对“做完了”达成一致判断。满足这两条，预测结果才能被核对，准确率才有比较意义。
常见候选层级的特点差异较大，可以按下表对照：
| 层级 | 典型形态 | 适用条件 | 主要风险 |
|---|---|---|---|
| 需求批次 | 一组关联需求打包交付 | 需求拆分稳定、批次边界清晰 | 批次频繁调整时口径易变 |
| 版本 | 一次发布包含的范围 | 有固定发布节奏、范围可冻结 | 范围蔓延导致预测失真 |
| 里程碑 | 阶段性目标节点 | 阶段划分明确、验收标准清楚 | 周期长，偏差归因跨度大 |
| 项目 | 整体交付项目 | 项目边界稳定、周期可预期 | 粒度过粗，难以定位偏差来源 |
首次建立建议从单一层级起步，优先选择版本或需求批次这类周期适中、边界可冻结的单元。整个机制只用一个层级，所有预测都按同一口径统计，准确率才具备可比性。等这一层跑稳、数据积累到能看出规律，再考虑扩展到其他层级。
对象粒度与准确率可比性直接相关。粒度越粗，单个偏差被平均掉，准确率看起来平稳但指导价值有限；粒度越细，波动大，需要更长周期才能看出趋势。首次建立时选中间粒度，既能暴露问题，又不至于被噪声淹没。
在工具层面，预测对象需要对应到可追踪的工作项或版本记录上。ONES 支持以需求、版本等工作项承载交付范围，预测时可以直接引用同一批工作项作为对象清单，避免预测表和实际执行各用一套口径。
预测时点怎么定：基准时点与提前量
基准时点是每次预测的固定发起点，应设在交付节点之前一个稳定的提前量上。提前量太短，团队已经知道结果，预测失去意义；提前量太长，信息不足，预测接近猜测。合适的提前量让团队在掌握足够信息、结果又尚未确定的位置给出判断。
提前量按对象周期和变更频率确定，可参考以下规则：
- 对象周期为两周左右，基准时点可设在周期开始后第2天，此时范围基本清楚、执行尚未展开。
- 对象周期为一个月或一个版本，基准时点可设在封版前一周，范围冻结与预测同步完成。
- 变更频率高的对象，提前量适当缩短，减少预测后被变更推翻的概率；变更频率低的对象，提前量可以放长。
同一对象只取一个基准时点。这一点是机制可信度的底线：如果允许在不同时点各做一次预测、事后挑一个最接近实际的版本上报，准确率就失去约束力。基准时点应在周期开始前就写进规则，对所有对象一致执行。
时点漂移指实际预测日偏离既定基准时点，口径变更指提前量规则本身被调整。两种情况都要记录：漂移记录实际预测日期和原因，口径变更记录生效日期和适用范围，新旧口径的数据分开统计，不混在同一趋势里比较。
预测版本与变更：以哪一版为准
准确率计算以基准时点冻结的那一版预测为准。冻结动作包括：确认对象清单、记录每个对象的预测完成状态或交付日期、标注冻结时间和责任人。冻结之后，这一版预测进入只读状态，作为后续核对的唯一依据。
冻结后发生的范围调整、排期变化单独记录，形成变更条目，注明变更内容、时间和原因。变更记录用于解释偏差，不覆盖原预测。这样在复盘时能区分两类偏差：预测本身判断不准，还是执行过程中条件发生了变化。两类问题的改进方向完全不同。
实际交付结果的取值口径也要事先定好。建议以对象是否按完成定义通过验收为准，记录实际完成日期；部分完成的对象按未完成计，不按完成比例折算，避免口径模糊带来的争议。取值口径与预测口径使用同一套完成定义，两边才能对齐。
版本留痕的作用在于可追溯。每个周期结束后，任何人都能回看当时冻结的预测、期间的变更和最终结果，复核准确率的计算过程。缺少留痕，准确率只是一个数字，无法支撑归因和改进。
ONES 的版本与工作项状态记录可以承担冻结与留痕的载体作用：基准时点的工作项状态构成预测快照，后续状态变化和范围调整留在同一批工作项的历史中，复盘时按时间点回溯即可还原当时的预测口径。
复盘节奏与角色分工：谁在什么时候做什么
复盘节奏与预测周期对齐，每个预测周期结束、实际结果确认后做一次偏差归因，按月汇总准确率趋势。周期复盘解决单个对象的偏差原因，月度汇总观察机制整体是否稳定，两者承担不同任务，不合并成一次会议。
| 角色 | 周期内动作 | 交付物 |
|---|---|---|
| 产品 | 确认对象范围与完成定义，参与基准时点冻结 | 冻结的对象清单与验收标准 |
| 研发 | 在基准时点给出完成状态或日期预测，记录执行中的变更 | 预测数据与变更记录 |
| 项目管理 | 组织冻结与复盘，汇总准确率，维护口径文档 | 周期复盘记录与月度趋势报告 |
首次运行期建议安排一次校准：前两到三个周期只统计不考核，重点检查对象边界是否清楚、基准时点是否可执行、变更记录是否完整。校准期发现的口径问题及时修订，修订后重新起算，不把校准期数据与正式运行数据混在一起比较。
示例：一个版本级预测机制的完整跑法
以下为演示情景，用于说明规则如何串联，数据为示例设定。
某团队选择版本作为预测对象，发布周期为四周，规则确定基准时点为封版前一周的周三。第一个周期，产品在基准时点确认版本范围共12个需求，研发对每个需求给出预测：10个预计按期完成，2个预计延期。项目管理冻结这一版预测，记录时间和责任人。
冻结后第二周，客户提出一项范围调整，新增1个需求并替换原有1个需求。变更条目记录了这一调整，原预测保持不变。版本发布后核对实际结果：原12个需求中9个按期完成，1个延期，2个被替换的需求按变更记录单独处理。
复盘会上，团队对偏差做归因：1个预测延期的需求实际也延期，判断准确；1个预测按期但实际延期的需求，原因是联调依赖的外部接口延迟，属于预测时未识别的依赖风险；被替换的需求不计入本期准确率，在变更记录中说明。会议产出两条改进项：基准时点增加外部依赖确认环节，对象清单标注依赖方。
首月准确率按“按期完成数除以冻结预测中的对象数”计算，示例中为9除以12。解读时注意两点：这个数字反映的是基准时点判断的可靠程度，不评价团队努力程度；单月数据样本小，应结合后续月份趋势看，不急于下结论。
完成检查：机制可用的判断标准
首次建立后，用以下清单验收机制是否可用：
- 对象层级已固定为单一层级，每个对象都能独立验收、有明确完成定义。
- 基准时点和提前量已写入规则，所有对象按同一时点预测，漂移有记录。
- 预测版本在基准时点冻结，变更单独留痕，实际结果取值口径与预测口径一致。
- 复盘节奏与预测周期对齐，角色和交付物已明确到人。
- 任取一个历史周期，能复现准确率的计算过程，口径可追溯。
四项中任一项未固定，机制就处于不可用状态：对象不固定则数据不可比，时点不固定则预测可被事后挑选，版本不留痕则偏差无法归因，复盘缺失则机制无法自我修正。不达标时先补齐该项再进入下一周期，不带着缺口累积数据。
首轮运行后需要校准的常见项包括：提前量是否合适、完成定义是否有歧义、变更记录是否覆盖了主要调整类型。校准完成后，机制进入稳定运行，后续只需按周期执行和按月观察趋势。
常见问题
首次建立时，能不能同时对版本和需求批次两个层级做预测？
技术上可以，但首次建立不建议这样做。两个层级的对象边界、完成定义和提前量往往不同，同时运行会让准确率数据混在一起，难以判断偏差来自机制设计还是层级差异。更稳妥的做法是先固定一个层级跑两到三个周期，等口径稳定、数据能看出规律后，再评估是否扩展到第二个层级。扩展时新旧层级的数据分开统计，不合并成一条趋势。
基准时点定好之后，遇到紧急插单或范围大改，预测还算数吗？
算数。基准时点冻结的那版预测仍然是准确率计算的依据，紧急插单和范围大改作为变更条目单独记录，注明内容、时间和原因。复盘时把这类偏差归到“条件变化”一类，与“预测判断不准”分开分析。如果某类变更反复出现，说明提前量或对象边界需要调整，这时按口径变更处理：记录生效日期和适用范围，新旧口径数据分开统计，不直接修改已冻结的历史预测。
提前量设多长比较合适，有没有通用数值？
没有通用数值，提前量取决于对象周期和变更频率。对象周期两周左右，基准时点可设在周期开始后第2天；周期一个月或一个版本，可设在封版前一周。判断标准是团队在这个位置掌握的信息足以做出判断、结果又尚未确定。首次建立时可以先按经验设一个值，运行两三个周期后看偏差分布：如果预测普遍过于乐观或悲观，说明时点偏早或偏晚，再作调整并记录为口径变更。
准确率低是不是说明团队执行有问题？
不能这样理解。准确率反映的是基准时点判断的可靠程度，衡量的是预测能力，不评价团队努力程度。偏差归因时要区分两类原因：预测时信息不足或依赖未识别，属于预测方法问题；执行中条件发生实质变化，属于变更问题。两类问题的改进方向不同，前者调整基准时点或增加确认环节，后者完善变更记录和范围管理。单月数据样本小，应结合后续月份趋势看，不急于下结论。
复盘会由谁组织，需要哪些人参加？
建议由项目管理角色组织，产品和研发参加。产品负责确认对象范围与完成定义、参与基准时点冻结；研发在基准时点给出完成状态或日期预测、记录执行中的变更；项目管理维护口径文档、汇总准确率并输出周期复盘记录和月度趋势报告。周期复盘只讨论单个对象的偏差原因，月度汇总观察机制整体是否稳定，两者分开进行，避免一次会议承担两个任务而流于形式。
