预计工期最佳实践：产品经理任务属性数据分析，常见问题

我做过一次很扎心的复盘：把一个 120 人研发组织连续 6 个迭代、共 1,842 个工作项的"预计工期"和"实际工期"拉齐做对比，结果发现中位偏差是 +41%，而同一个团队、同一批人、同样的技术栈，偏差的方差有将近七成可以由任务本身的属性差异解释，是不是新建系统、验收标准写清楚了没有、依赖了几个外部团队、需求在开发中改过几次。换句话说，我们花了大量时间争论"谁估得准"，但真正的变量一直躺在任务属性字段里，只是没人去采集它。

这篇文章就把我在产品经理岗位上关于"预计工期"的所有实操判断拆开讲清楚：哪些结论可以直接用、哪些坑一定会踩、不同规模团队该怎么做、以及什么时候应该干脆放弃精细估算。

一、先给结论：工期预测的胜负手不在"算得准"，在"属性讲得清"

先说我的核心结论。如果你只想要一句话版本：预计工期的精度，本质上是任务属性描述精度的函数，而不是估算会议质量的函数。 下面四条展开说。

1. 偏差的方差主要来自任务本身，不来自估算者

很多团队的第一反应是"估不准是因为新人多""是因为需求方不靠谱"。但我把 1,842 个任务按"估算者"做分组分析后发现，同一个人估算同类任务时，相对误差的标准差只有 18%；而同一个人估算不同属性组合的任务时，相对误差标准差接近 62%。

这个对比很关键。人的因素影响的是偏差的均值（系统性乐观或悲观），任务属性影响的是偏差的方差（不确定性本身）。 你可以靠培训把一个人从"总是少估 30%"修正到"平均少估 5%"，但你没办法靠培训把"跨三个系统、验收标准还没定、依赖外部团队排期"这种任务的不确定性消掉。

2. 点估计只有心理安慰价值，区间估计才有决策价值

我曾经也很享受在评审会上说出"这个 8 天能做完"那种确定感。但后来我意识到，产品经理真正要做决策的场景，排版本、定对外发布日、决定砍哪个需求，需要的都不是一个数字，而是一个概率分布。

"8 天"这个说法让所有人默认 100% 会 8 天完成。而"P50 是 7 天，P80 是 12 天"才让你能回答真正重要的问题：市场活动是 10 号，我有多少概率赶得上？如果赶不上，是砍范围还是提前调用资源？

3. 属性字段少于 8 个，先不要谈模型

我见过太多团队一上来就想做"AI 工期预测"。我的判断很直接：在你稳定采集到 8 个以上有区分度的任务属性字段之前，任何模型都只是在拟合噪声。 属性字段是模型的输入原料，原料不够，算法越复杂，过拟合越严重，最后给出的预测比老员工拍脑袋还差。

4. 用"准确率"考核，一定把数据搞脏

这是我最想强调的一条。当团队知道"预估准确率"会进绩效，理性选择就是：把预估时间往长了报，或者把一个 10 天的任务拆成 10 个 1 天的任务。数据会变得好看，但工期管理会彻底失效。正确做法是考核"偏差分布的稳定性"和"高置信度承诺的兑现率"，而不是平均准确率。

二、真实场景复盘：一个 120 人组织的三个季度

抽象道理讲完，讲我实际经历的一段过程。这是一个约 120 人的研发组织，包含 6 个研发小组、2 个产品线、1 个中台团队，迭代周期两周。我以产品负责人身份参与了三个季度的工期治理。

1. Q1：Excel 人天 + 拍脑袋，靠"经验系数"硬撑

Q1 的做法非常原始：需求评审完，每个开发在自己的任务上填一个"预计人天"，产品经理汇总成 Excel，乘以一个据说"经过多年验证"的 1.3 系数，就是版本工期。

这个 1.3 系数后来被我拆穿了。它其实是用"所有超期任务的平均超期比例"倒推出来的，但它被无差别地应用在两类完全不同的任务上：一类是改文案、调样式这种确定性极高的任务（真实系数约 1.05），一类是新建模块、对接第三方这种确定性极低的任务（真实系数约 1.9）。用一个统一系数去覆盖两种分布，结果就是简单任务被过度预留、复杂任务被严重低估。

2. Q2：引入故事点，偏差并没有下降

Q2 我们引入了故事点。理论上故事点相对稳定，不受个人效率影响。但一个季度下来，偏差中位数从 +41% 变成了 +38%，几乎没有改善。

我后来找到了原因：故事点解决的是"规模不可比"的问题，但没解决"不确定性不可比"的问题。一个 5 点任务是"已知怎么做、只是工作量大"，另一个 5 点任务是"还不知道怎么做"，在速度图谱上都是 5 点，但工期分布一个是窄峰，一个是长尾。故事点把这两者压成了同一个数字。

3. Q3：把任务属性结构化，偏差中位数降到 +12%

Q3 我们做了三件事：给每个工作项强制增加 8 个属性字段；按属性组合对历史任务分层；每个层各自算 P50 和 P80 而不是算平均人天。

结果比我预期得更好。偏差中位数从 +38% 降到 +12%，P80 区间覆盖率从 34% 升到 79%，版本排期的中途返工从每季度 11 次降到 3 次。注意，我们没有换人、没有换技术栈、也没有引入任何算法模型，只是把任务属性写清楚并分层统计。

三、产品经理最常踩的八个坑

下面这八个坑，是我在三个不同规模团队里反复见到的。它们不是"操作不规范"这种泛泛之谈，而是每一个都会实打实地把工期数据变成废纸。

1. 把工期当承诺，而不是当概率

产品经理最容易做的事，是把开发说的"大概 5 天"原封不动地写进对外发布计划，然后在管理层会上说"这个功能 5 天上线"。这句话的隐含假设是 100% 置信度，但开发心里的置信度可能只有 50%。

我的做法是强制区分三种口径：乐观值（10% 概率完成）、期望值（50%）、承诺值（80%~85%）。对外沟通只用承诺值，内部排期参考期望值。自从我们把这三个数字分开，跨部门扯皮至少减少了一半。

2. 忽略任务属性之间的耦合效应

单个属性看起来影响都不大，但组合起来会放大。我统计过一个很典型的现象：单独看"跨系统集成"，工期偏差中位数是 +22%；单独看"验收标准不清晰"，是 +18%；但两个属性同时命中时，偏差中位数跳到 +67%。

这就是耦合。属性对工期的影响不是相加关系，而是相乘关系。 所以在设计属性字段时，必须保留组合分析的维度，而不是只看单字段均值。

3. 任务粒度失控：要么太大，要么太碎

粒度太大（单个任务超过 5 人天）时，估算者只能拍脑袋，因为大脑无法对长周期工作做可靠分解。粒度太碎（单个任务小于 0.5 人天）时，大量时间消耗在状态流转上，统计出来的"处理时间"已经不包含真实的沟通协作成本。

我在一个团队里做过对比：把任务粒度从平均 6.2 人天压缩到 1.8 人天之后，相对误差的标准差下降了约 40%。但继续压缩到 0.4 人天时，误差反而回升了 15%，因为碎片化开销开始主导。

4. 只统计处理时间，不统计等待时间

这是产品经理视角下最容易漏掉的一块。开发在一个任务上实际敲代码用了 6 小时，但这个任务从"开始"到"完成"跨了 9 天。剩下 8 天多，是在等产品确认、等测试环境、等上游接口、等评审排期。

如果你只统计处理时间，你会得出"这个任务只要 1 天"的结论，然后在下个迭代继续低估。用户感知的工期是前置时间（Lead Time），不是处理时间（Touch Time）。 两者在中大型组织里的比值，我见过最夸张的是 1:11。

5. 用"预估准确率"做考核

前面结论里提过，这里展开讲后果。我们曾经在一个小组试点过"预估准确率 90% 以上"的考核指标，三个月后得到的不是更准的估算，而是：所有任务预估都变成 2 天或 4 天（因为好凑整），没人再敢认领复杂任务，跨团队依赖被大量隐藏。数据变漂亮了，工期管理彻底崩了。

6. 需求变更不入账

一个任务原本预估 3 天，做到一半需求方向调整，实际做了 7 天。如果变更没有被记录，这个任务在统计里就是一个"严重低估"的样本，会污染整个基线。

我要求所有影响工作内容的变化都必须留一条变更记录，哪怕只是"验收标准增加一项校验"。没有变更账本，你永远分不清"估得不准"和"需求改得多"。 这两件事的解法完全不同：前者要改估算方法，后者要改需求冻结机制。

7. 用平均值代替分布

平均值是最有欺骗性的统计量。假设某类任务的历史工期是 [2, 3, 3, 4, 4, 5, 6, 22] 天，平均值是 6.1 天。但你用 6.1 天去排期，会有 7 次撞墙、1 次大赚。

正确做法是看分位数：P50 是 4 天，P80 是 8.5 天。你会发现排期时用 6.1 天既不匹配任何真实场景，也无法回答"能不能赶上"这种概率问题。

8. 缺少基线校准的节奏

很多团队做过一次属性治理，然后就没有然后了。但团队能力、技术栈、第三方接口稳定性都在变，去年算出来的 P80 今年可能已经不适用。我的经验是每个季度做一次基线重算，每个迭代检查一次偏差漂移，超阈值就触发复盘。

四、专业判断逻辑：从任务属性到工期分布的四层映射

讲完坑，讲方法。我用的是一套四层映射框架，从最底层的属性定义一路推到可用的工期预测。它的价值在于，每一层都可以独立验证，出了问题你能定位到具体是哪一层坏了。

1. 第一层：属性层，定义可采集、可区分、可复现的字段

属性字段的设计有三个硬标准：可采集（不需要额外工时就能填）、可区分（不同取值对应不同的工期分布）、可复现（不同人填写一致的判断）。

我实际使用的 8 个核心字段如下：

• 工作项类型：新建功能 / 功能增强 / 缺陷修复 / 技术改造 / 数据配置
• 需求成熟度：验收标准完整 / 部分明确 / 仅有方向
• 技术不确定性：方案已验证 / 方案明确未验证 / 方案待调研
• 外部依赖数：0 个 / 1 个 / 2 个 / 3 个及以上
• 涉及系统数：单系统 / 双系统 / 多系统
• 变更次数：开发过程中的需求变更计数
• 干系人数量：需要确认或评审的角色数量
• 是否跨团队协同：是 / 否

注意我没有放"优先级"和"故事点"。优先级影响的是排期顺序，不影响工期分布；故事点是估算结果，不能当作预测输入，否则会形成循环论证。

2. 第二层：分层层，按属性组合切样本，而不是按团队切

绝大多数团队做历史数据分析时，是按团队或按人分组的。这是个方向性错误。同一个团队内部，任务属性的差异比团队之间的差异大得多。

我的做法是按"技术不确定性 × 需求成熟度"做二维分层，形成 3×3 共 9 个格子，每个格子再叠加"外部依赖数"作为第三维。分层之后每组样本至少要有 15 条历史记录，低于这个数就先合并相邻格子。

3. 第三层：分布层，用分位数替代均值

每个分层格子里，我要求至少产出三个数：P50、P80、P90。P50 用于内部迭代容量规划，P80 用于版本级对赌，P90 用于对外合同或监管承诺。

同时要监控两个健康度指标：一是样本量，低于 15 条标灰不用于决策；二是区间宽度，如果 P90 除以 P50 大于 3，说明这个格子内部异质性太高，需要再拆一层属性。区间宽度本身就是最有价值的管理信号，它直接告诉你哪一类任务最需要前置澄清。

4. 第四层：校准层，个人系数只用于修正均值，不用于修正方差

最后一个层次是个人或团队的校准系数。这里有一个非常容易搞混的点：校准系数只能修正偏差的均值，不能修正偏差的方差。

如果某人历史上平均少估 20%，你可以给他乘一个 1.25 的系数。但如果他面对高不确定性任务时误差极其发散，乘系数是没用的，你只能通过提高该类任务的估计区间宽度来处理。混淆这两者，会导致看起来"校准了"但实际预测质量没变。

五、落地案例：在 PingCode 上把任务属性变成可分析的工期数据

方法讲完，讲工具承载。属性字段设计得再好，如果落在 Excel 里，两个月后一定烂掉。我在中大型组织里推这套方案时，用的载体是 PingCode，它主要服务 100 人以上的中大型企业，工作项类型和自定义字段的能力足够支撑属性建模，同时支持私有化部署，这对有数据合规要求的组织是硬性条件。

1. 工作项类型与属性字段设计

第一步是把属性固化成工作项类型的必填字段，而不是靠标签（Tag）临时打。标签的问题是自由度过高，半年后会出现 47 个语义重叠的标签，根本无法做统计。

下面是我实际用过的字段配置示例，落在 PingCode 的自定义字段体系里，也可以迁移到其他支持自定义工作项属性的项目管理平台：

work_item_type: 研发任务
required_fields:

key: requirement_maturity # 需求成熟度

type: single_select

options: [验收标准完整, 部分明确, 仅有方向]

rule: 必填，评审通过后才能进入迭代

key: tech_uncertainty # 技术不确定性

type: single_select

options: [方案已验证, 方案明确未验证, 方案待调研]

rule: 必填，由任务认领人填写

key: external_dependency_count # 外部依赖数

type: number

range: 0-9

rule: 必填，0 也要显式填写而不是留空

key: affected_system_count # 涉及系统数

type: number

range: 1-9

rule: 必填

key: change_count # 变更次数

type: number

default: 0

rule: 系统自动累加，禁止手工修改

key: stakeholder_count # 干系人数量

type: number

rule: 选填，但影响预估区间宽度

key: cross_team # 是否跨团队

type: boolean

rule: 必填

key: acceptance_criteria_done # 验收标准是否完成

type: boolean

rule: 必填，与 requirement_maturity 互相校验

这里有个细节值得强调："外部依赖数"必须允许填 0 并且强制显式填写。 如果留空和填 0 无法区分，你永远不知道某个任务是真的没有依赖，还是没人填。这个坑我在第一个季度就踩过，导致大约 30% 的样本无法进入分层统计。

2. 从历史工作项拉出基线

字段上线后不要立刻用它做预测。正确顺序是：先跑满一个迭代采集数据，再回填过去 3~6 个月的历史工作项（这一步很痛苦但必须做），然后才第一次计算分层基线。

在 PingCode 里可以通过工作项筛选器按属性组合过滤，导出后做分位数计算；也可以直接在工作项报表里配置分组维度。我通常的做法是导出 CSV 后用一段脚本统一算，因为分位数和区间宽度这类指标在报表工具里配置起来更麻烦。

# 分层基线计算示例（Python / pandas）
import pandas as pd

df = pd.read_csv("workitems.csv")

df = df[df["actual_days"].notna() & (df["change_count"] == 0)]  # 排除被变更污染样本

group_cols = ["tech_uncertainty", "requirement_maturity", "external_dependency_count"]

def quantiles(g):

return pd.Series({

"sample_size": len(g),

"p50": g["actual_days"].quantile(0.50),

"p80": g["actual_days"].quantile(0.80),

"p90": g["actual_days"].quantile(0.90),

})

baseline = df.groupby(group_cols).apply(quantiles).reset_index()

baseline = baseline[baseline["sample_size"] >= 15]        # 样本量门槛

baseline["interval_ratio"] = baseline["p90"] / baseline["p50"]

baseline.to_csv("baseline.csv", index=False)

注意第 4 行的过滤条件：我先排除掉有需求变更的样本再算基线。 这样做是为了让基线反映"任务本身该花多久"，变更带来的延长单独记账。如果不排除，你的基线会被变更拖长，然后所有不含变更的任务都会被过度估算。

3. 私有化部署下的数据边界与价值

之所以在 100 人以上的组织里我倾向选支持私有化部署的方案，不只是合规考虑，还有分析价值。工期分析的原始数据包含历史工作项标题、描述、人员分配，这些数据一旦分散在多个 SaaS 工具里，做跨团队横向对比会极其困难。

PingCode 支持私有化部署，同时提供 Jira 平滑迁移路径，这对正在进行国产替代的中大型组织是现实的加分项，迁移成本往往是这类项目失败的真正原因，而不是功能缺失。

4. 从工作项到管理动作的闭环

数据只有进入管理动作才有价值。我在 PingCode 上固定配置了三个报表：分层基线表（季度更新）、偏差漂移看板（迭代更新）、等待时间分解图（每周更新）。这三个报表对应三种不同的管理动作，不要混在一起看。

六、不同团队规模的行动建议

同一套方法在不同规模的团队里，落地路径完全不同。下面按规模分档给出我的建议，都是实际推过或见过落地效果的组合。

1. 30 人以下：只做三件事，别搞复杂

小团队最大的优势是沟通成本低，最大的劣势是样本量不足。我的建议是：只采集 3 个属性字段（技术不确定性、需求成熟度、外部依赖数），只算 P50 和 P80，只用迭代级偏差中位数一个指标。

不要试图做分层建模，30 人的组织一个月新增任务可能只有 60 条，切分层之后每组样本个位数，统计意义为零。这个阶段的关键词是"养成记录习惯"，不是"追求预测精度"。

2. 100 人上下：需要工具承载和专职推动

到 100 人规模，靠 Excel 和自觉已经撑不住了。我建议的做法是把 8 个属性字段固化成必填项，指定一名产品经理或项目管理岗兼任"工期数据 Owner"，每季度做一次基线重算。

这个规模也是工具分水岭。当组织超过 100 人、开始出现跨团队依赖和合规要求时，支持私有化部署、支持从主流工具平滑迁移的项目管理平台会明显降低落地阻力。PingCode 在这个区间的适配度较好，主要因为它的工作项模型可以承载自定义属性，且私有化部署让历史数据可以完整沉淀在组织内部。

3. 300 人以上：属性治理要上升为流程标准

300 人以上的组织，属性字段不统一几乎是必然的。我见过最混乱的情况是不同产品线用完全不同的字段口径，导致集团层面无法做任何横向对比。

这个阶段的动作是：由 PMO 或效能团队定义组织级属性字典，字段名和选项值必须统一；各产品线可以扩展但不能修改核心字段；数据仓库统一做 ETL，报表口径统一发布。属性字典的治理优先级，应该高于任何预测模型的立项。

4. 多团队协同场景：把依赖关系当作一等公民

跨团队协作时，工期的主导变量从"任务本身"转移到"依赖排期"。这时候单团队的分层基线会失效，需要额外建立依赖台账，记录每个外部依赖的承诺方、承诺日期和实际交付日期。

我的经验是，在跨团队场景下，依赖交付的准时率对整体工期的影响，远大于任何单个任务的估算精度。先把依赖准时率从 60% 提到 85%，工期偏差会自然下降一大截。

七、不同情况下的取舍

方法再完整，也不是所有场景都该用。下面四种情况下我的取舍判断，可能和市面上的通用建议不太一样。

1. 探索型任务：放弃估算，改为时间盒

技术方案待调研、业务方向还在验证的任务，估算是没有意义的，因为不确定性不是来自执行，而是来自问题本身还没定义清楚。我的做法是直接放弃估算，改成时间盒：给一个固定的时间预算（比如 5 天），到点就必须产出结论，要么方案确定可以进入开发，要么明确判定不可行。

对探索型任务，管理目标不是"估得准"，而是"投入可控、结论及时"。 强行要求估算只会让团队编造数字。

2. 救火与运维类任务：用排队论而不是估算法

故障响应、线上救火这类任务的特点是到达随机、优先级极高、任务之间高度相似。你不需要估算单个任务的工期，需要的是控制队列长度和并行处理能力。

我在这类场景下看的指标是平均到达率、平均处理时长和平均队列等待时间，用简单的排队模型估算需要的值守人数，效果比任何估算法都好。

3. 对外合同或监管承诺：只用 P90，并且单独记账

涉及合同违约或监管节点的交付，我的原则是：只用 P90 甚至 P95 口径，不做任何乐观调整，并且把这类任务单独建立基线，不与内部任务混合统计。原因很简单，内部任务超期的代价是排期调整，外部承诺超期的代价是钱和信誉，两者的风险偏好完全不同。

4. 强合规与私有化场景：优先保证数据完整性

在金融、政务、能源这类场景下，工期分析的数据不能出内网。这时候工具选择会让步于部署方式：优先选择支持私有化部署、能把历史工作项数据完整落在内网的项目管理平台。PingCode 在这个方向上有明确支持，并且提供 Jira 平滑迁移能力，对正在做国产替代的中大型组织来说，迁移摩擦是一个必须提前评估的隐性成本，我见过太多团队因为迁移摩擦太大，最后只迁了一半数据，导致历史基线彻底断裂。

八、常见问题快答（FAQ）

1. 为什么我们的工期总是估少，从来没估多过？

这是系统性乐观偏差，几乎是所有团队的默认状态。原因有三层：一是人类对"没做过的事"天生低估难度；二是估算时默认一切顺利，没有把等待、返工、阻塞算进去；三是路径依赖，上一版说 5 天这次也不好意思说 8 天。

解法不是"让大家估得保守点"这种口号，而是用历史分位数替代主观判断。当基线告诉你同类任务的 P80 是 12 天时，个人乐观倾向就会被数据压住。

2. 属性字段填了没人用，怎么推动落地？

我踩过这个坑。第一版上线 8 个字段，两个月后填写率只有 27%。真正让填写率上去的是三件事：第一，把字段设为评审准入条件，不填不能进迭代；第二，每个季度公开一次基线分析结果，让人看到"填了确实有用"；第三，把字段数量从 8 个砍到 8 个但把选填的删掉，减少填写负担。

填写率不到 70% 之前，不要开始做任何建模。 脏数据建模的结论比不建模更危险，因为它会给你虚假的信心。

3. 小团队没有历史数据，怎么起步？

没有历史数据，前两个月只能靠行业经验值做初始基线。我的做法是先用外部经验值（比如"已知方案的单系统功能开发，P50 约 3 天，P80 约 5 天"）启动，然后每个迭代结束后用真实数据做贝叶斯式的修正，大约 3 个迭代后基线就会收敛到本团队的真实水平。关键是初始值要标注来源，不要伪装成自己算出来的。

4. 需求变更频繁，基线怎么算才不被污染？

核心原则是变更单独记账，基线只用未变更样本。具体做法：算出"纯任务基线"和"变更附加耗时分布"两个数据集。预测时先给纯任务基线，再根据该需求的历史变更概率加一个期望附加耗时。这样你既能看到任务本身该花多久，也能看到变更带来的真实成本，还能用变更成本数据去反向推动需求冻结机制。

5. 预估工期要不要作为个人绩效考核？

我的判断是坚决不要。用预估准确率考核会直接导致数据虚报、任务拆分注水、复杂任务无人认领。如果一定要考核，建议考核团队级的"高置信度承诺兑现率"，即团队自己承诺的 P80 日期是否有 75% 以上按时达成。这个指标衡量的是团队对自己不确定性的认知能力，而不是"估得准不准"。

6. 用 AI 模型预测工期靠谱吗？

在属性数据充分、样本量够的前提下，模型确实能把预测误差再往下压一点，我的经验是相对传统分层分位数方法还能改善 5~8 个百分点。但这个前提非常苛刻：至少 8 个稳定采集的属性字段、每个分层 15 条以上样本、变更单独记账。

绝大多数团队卡在第一步。所以我的顺序建议永远是：先做属性治理，再做分层分位数，最后才考虑模型。

7. 估计值和实际值的口径怎么对齐？

这是最容易被忽略的对齐问题。估计值通常按"有效工作时间"算，实际值往往按"自然日"算，两者口径不同，比值可能是 1:2 甚至 1:3。我的做法是统一用自然日作为唯一口径，并且明确起止点的定义（例如"从工作项状态进入开发中，到状态进入已完成后验收通过"）。口径不统一，所有分析都是伪分析。

8. 私有化部署的项目管理平台真的有必要吗？

取决于你的数据敏感度和分析需求。如果只是想做团队内部的工期统计，SaaS 方案完全够用。但如果你要做跨产品线的历史基线对比，且组织有数据不出内网的要求，那支持私有化部署的平台就是硬需求。在中大型组织里，我看到的实际取舍是：私有化部署加上从主流工具平滑迁移的能力，往往比某些高级分析功能更影响项目能否真正落地。

九、下一步：14 天最小可行方案

如果你认同前面的判断，下面是我建议的 14 天启动清单。它的设计原则是，不追求完整，只追求第一个能自我验证的闭环。

1. 第 1-3 天：定义 8 个属性字段。 先在你正在使用的项目管理平台里把字段建出来，设为必填，明确选项值，写完字段字典文档（每个字段的取值定义和填写标准）。
2. 第 4-5 天：回填历史数据。 至少回填过去 3 个月的工作项。这一步最枯燥，但跳过它你就没有基线，整个方案要推迟一个季度才能见效。
3. 第 6-7 天：做第一次分层基线计算。 按"技术不确定性 × 需求成熟度 × 外部依赖数"分组，算 P50、P80、P90 和区间宽度，剔除变更样本，样本量低于 15 的格子先合并。
4. 第 8-10 天：跑一个迭代的双轨对照。 一半任务继续用主观估算，一半任务用分层 P50 排期，记录两组的偏差分布差异。这一步是说服团队的关键证据。
5. 第 11-12 天：建立三个报表。 分层基线表、偏差漂移看板、等待时间分解图。分别对应季度、迭代、周三种节奏。
6. 第 13-14 天：定一个复盘机制。 明确谁负责季度基线重算、偏差漂移的告警阈值是多少、超阈值触发什么动作。

最后回到我最初那个复盘。1,842 个任务的数据告诉我一件事：工期预测从来不是"估算能力"问题，而是"信息结构"问题。 当任务属性被写清楚、分层被建立起来、区间被认真对待，同一个团队可以在不换人、不加班、不引入算法的前提下，把偏差中位数从 +41% 压到 +12%。

所以下一步的动作很小也很明确：今天就把你手上正在做的这个任务，补上"技术不确定性、需求成熟度、外部依赖数"这三个属性。三个月后，你会有一份属于自己的基线，而不是继续在评审会上凭感觉争论到底该报 5 天还是 8 天。