预计工期最佳实践：产品经理任务属性制度设计，常见问题

2023 年我接手过一个 180 人研发组织的工期治理项目。第一次拉数据时，一个季度里有 372 条"已完成"的研发任务根本没填预计工期，另有 200 多条填的是"3 天""1 周""两周内"这类口语化描述。研发负责人跟我解释："估时本来就是拍脑袋，填了也不准。"三个月后，同一批人、同一套业务，任务粒度受控之后的工期偏差中位数从 +127% 降到 +31%，中间没有做过一次估算培训，也没有换过任何一个开发。

这个反差说明：预计工期不准，绝大多数时候不是"人不会估"，而是"制度没让你估得准"。任务属性制度是产品经理能直接插手、也最容易看到效果的一环。它决定了工期数据是能拿来排期、做容量规划、做交付承诺，还是只能当摆设填在系统里。

下面我按"结论，场景，误区，判断逻辑，案例数据，行动建议，取舍"这条线，把这套东西讲透，包括我在几个中大型团队里趟过的坑，以及产品经理在制度设计上到底该管什么、不该管什么。

一、先给结论：预计工期不准，绝大部分是制度问题

1. 三条可以直接拿去执行的结论

先把判断放在前面，后面的所有论证都是为这三条服务的。

• 结论一：预计工期必须以"任务属性"的形式存储，而不是以"计划日期"的形式存在。很多团队把预计工期填成了"预计完成日期"，一旦排期变动，这个字段就彻底作废，历史数据无法复用，统计口径每个月都在漂移。
• 结论二：产品经理定"估算什么"，研发定"估多少"。产品经理的职责是定义任务类型、粒度上限、估算单位、完成定义（DOD）和责任人；至于某个接口要写 2 天还是 3 天，产品经理不该越界。越界的结果是研发随便填个数字应付你。
• 结论三：度量工期要看"偏差方向 × 偏差幅度"，而不是只看准确率。一个团队 70% 的任务低估、30% 的任务高估，和 50/50 双向偏差，虽然"准确率"可能相同，但前者意味着系统性风险，后者才是正常的估算噪声。

2. 一个反常识判断：不要考核"估算准确率"

我见过至少四个团队把"估算准确率"写进研发的绩效指标，结果全部走向同一个结局：研发把工期往长了估。因为估准了没奖励，估短了要背锅，最理性的策略就是给所有任务加 30% 缓冲，然后实际用时刚好落在时间内，"准确率"看起来很漂亮。

这种数据比不填还糟糕。你后面基于它做的所有容量规划、交付承诺、资源申请，全部是建立在浮沙上的。我的做法是把估算准确率从考核里拿掉，换成两个观察指标：偏差中位数和偏差离散度（P90 与中位数的差距）。这两个指标只用于诊断，不用于奖惩，团队才敢填真实数字。

3. 一个产品经理五分钟就能做的自检

如果你的团队符合下面任意两条，那基本可以确认问题出在制度而不是人：

1. 任务里没有"任务类型"字段，需求和运维支持混在一起统计。
2. 存在超过 5 人天的单个任务，且没有强制拆分机制。
3. 预计工期字段存在多种单位（人天、人时、自然日）混填。
4. 任务没有完成定义，研发认为"代码写完"就算完，测试认为"验收通过"才算完。
5. 预计工期只在建单时填一次，实际完成后没有任何反馈动作。

这五条对应的是同一件事：工期不是被"估"坏的，是被"存"坏的。字段设计、粒度约束、单位统一、完成定义、数据回流，这五件事都属于制度层，都不需要研发提升任何估算能力，但能立刻改变数据的可用性。

二、真实场景：工期是在哪一刻开始失控的

1. 一个 180 人研发组织的真实片段

那家公司的产品线有三条，产品经理 14 人，研发 120 人左右，测试 30 多人。需求从产品经理手里进入系统时，走的是这样一个流程：产品经理在项目里新建一个任务，标题写"XX 功能开发"，然后在预计工时字段填一个数字，指派给研发负责人，剩下的就不管了。

我抽查了 60 条任务的字段填写情况，结果是这样的：

• 有 23 条任务的"预计工时"填的是自然日，比如"5 天"，但研发理解的是工作日。
• 有 11 条任务填的是"1 周""半个月""一个月内"这类模糊描述。
• 有 17 条任务的粒度超过 10 人天，最大的一个需求从建单到关闭跨了 47 天。
• 只有 9 条任务在完成后回填了实际耗时。

这意味着什么？意味着任何基于这些数据做的排期，误差都会是数倍级别的。更麻烦的是，团队已经形成了"工期数字不用当真"的共识，新人进来看一眼周围的填法，两个月内就会被同化。

2. 工期失控的四个断裂点

我把这个链条拆成四段，每一段都是一个可以独立治理的断裂点。

3. 为什么产品经理必须亲自管这三个字段

很多团队把这件事交给研发负责人或项目管理办公室，我觉得方向是反的。原因很直接：输入断裂和属性断裂，发生的时刻都在产品经理建单的那几分钟里。研发负责人不参与建单，他能做的只有事后抱怨需求不清楚。

产品经理真正需要的是三件东西：需求拆分能力、任务属性设计意识，以及对项目管理平台字段配置的发言权。前两件是软技能，第三件经常被忽略，但恰恰是第三件决定了制度能不能落地。字段配不上去，制度就只是一份文档。

三、八个高频误区拆解

1. 把"预计工期"当成承诺日期

这是最普遍也最致命的一个误解。预计工期的本质是区间估计，承诺日期的本质是对外契约，两者在数学上是完全不同的东西，但在很多团队的字段里被合并成了一个。

后果是双向的。研发看到这个数字会被当成承诺，于是倾向于往长了填、加缓冲；产品经理看到这个数字会直接拿去跟业务方沟通上线时间，然后发现每次都失约。正确的做法是拆成三个字段：预计工期（区间）、计划开始时间、计划完成时间。前一个由研发估，后两个由产品经理排期，职责分明。

2. 自然日和工作日混用，还没人发现

"这个需求 5 天能做完"，这 5 天是自然日还是工作日？如果中间跨一个周末，两种理解能差出 40%。在一个有排班、有值班、有跨时区协作的中大型组织里，这种模糊会被放大成几周的误差。

我的建议是内部统一用"人天"作为唯一单位，并把自然日换算规则写进制度。产品经理对外沟通时再换算成日期，但系统里存的永远是标准化的数值。

3. 估算单位不统一，统计层面就废了

我在一个团队见过这样一组数据：某个季度的总预计工时统计出来是 2,180，看起来很正常。拆开一看，其中 1,600 是"人天"，480 是"人时"，还有 100 是有人把"2 周"直接填成了 2。这三部分加在一起，得到的数字没有任何业务含义。

单位不统一还会带来一个隐蔽后果：跨角色无法比较。前端的 1 人天和测试的 1 人天，在经过了任务类型区分之后才具备可比性；如果连单位都不统一，任何一个"研发效率排行榜"都是假的。

4. 没有任务类型字段，导致工期不可比

需求开发、缺陷修复、技术债清理、生产运维支持、技术预研，这五类任务的工期分布完全不同。需求开发通常有较长的链路，技术债任务容易低估，运维支持则是高频短任务。把它们塞进一个平均值里，你得到的是个数学玩具。

更现实的问题是：当研发说"估不准"时，他指的往往是运维支持和技术债这两类。需求开发其实估得不错。加一个任务类型字段，这个问题立刻就定位清楚了。

5. 没有完成定义（DOD），"提前完成"是假的

我做过一次专门核查，把某团队一个月内"提前完成"的任务全部翻出来看流转记录。结果 68% 的任务在标记完成后，又被测试打回或者开发补充提交了代码。这不是研发在造假，而是"完成"这个动作本身没有被定义。

产品经理在这一环上的职责非常明确：把完成标准写进任务模板，而不是留在口头约定里。比如需求类任务的 DOD 至少包含：代码合并、单测覆盖率达标、接口联调通过、可回滚方案、测试验收通过。写清楚之后，"提前完成"这个假象会自动消失。

6. 粒度失控：单个任务超过 5 人天就该强制拆分

粒度是所有误区里影响最大、也最容易量化的一条。一个任务的粒度越大，工期估算的相对误差就越大，而且误差方向几乎总是低估。因为大任务里包含了未被识别的依赖、未暴露的技术风险、未协调的跨团队沟通，这些东西在估算时天然被忽略。

我观察到的经验规律是：

• 粒度在 0.5～2 人天的任务，偏差中位数通常在 ±30% 以内。
• 粒度在 3～5 人天的任务，偏差中位数扩大到 ±60% 左右。
• 粒度超过 10 人天的任务，偏差中位数普遍超过 +150%，且 P90 经常突破 +300%。

所以我给产品经理的第一条硬性制度就是：任务粒度上限设为 5 人天，超过必须拆；拆分动作由产品经理在建单阶段完成，不留给研发。

7. 跨角色任务共用一套估时刻度

产品、设计、前端、后端、测试，这五个角色的"1 人天"完全不是一回事。设计的 1 人天可能包含 3 轮改稿，测试的 1 人天包含环境准备，后端的 1 人天可能被一个线上问题切走一半。

如果制度上不做区分，汇总出来的数字会让排期严重失真。我的做法是在估算字段上绑定角色的默认置信区间：后端任务默认 ±40%，测试任务默认 ±25%，设计任务默认 ±60%。这样即使数值相同，系统也能告诉你哪些任务的工期更"软"。

8. 只统计偏差率，不看偏差方向

偏差率是个典型的合成指标。一个团队有 40 条任务偏差 +100%、60 条任务偏差 -40%，平均偏差率算出来是 +16%，看起来还不错，实际上这个团队存在严重的系统性低估。

正确的拆法是画一张"低估任务占比 vs 高估任务占比"的分布图，再看各自的幅度。如果低估任务占比超过 65%，那就是制度问题，加缓冲是治标；如果把粒度压下来之后占比降到 55% 以内，才说明团队进入了正常的状态。

四、任务属性制度的五层模型与字段设计

1. 五层属性模型

讲完误区，接下来是可执行的部分。我把任务属性制度拆成五层，每一层解决一个具体问题，产品经理可以按顺序推进，不必一次全上。

1. 粒度层：解决"一个任务有多大"的问题，包含粒度上限、拆分规则、父子任务关系。
2. 类型层：解决"这个任务是什么"的问题，包含任务类型枚举、类型对应的流程模板。
3. 估算层：解决"用谁的刻度、填什么单位"的问题，包含估算单位、估算刻度、估算责任人、置信区间。
4. 约束层：解决"什么时候必须做完、什么算做完"的问题，包含完成定义、依赖关系、阻塞标记。
5. 度量层：解决"数据怎么回流、怎么用"的问题，包含实际耗时回填、偏差归因标签、复盘节奏。

这五层的推进顺序不能乱。先做粒度层和类型层，再做估算层。我见过有团队一上来就折腾估算刻度，用斐波那契数列、T 恤尺码、扑克牌估算搞了两轮，结果因为任务粒度还是十几人天，所有方法都失效了。

2. 必填字段清单与填写规则

下面这张表是我在几个团队里反复迭代后的字段设计，可以直接拿去参考。核心原则是字段数量控制在 8 个以内，每个字段都要有明确的填写责任人和校验规则。

注意最后两个字段：实际耗时和偏差归因标签是所有工期制度里最容易被砍掉、但价值最高的两个。没有它们，你的数据永远停在"预计"层面，团队永远不会变得更准。

3. 估算单位与刻度怎么定

我的建议非常明确：单位统一用人天，刻度用 0.5 / 1 / 2 / 3 / 5 五档，超过 5 就拆。理由有三点。

第一，人天是最容易理解、跨角色最容易对齐的单位。人时太细，容易陷入无意义的争论；故事点太抽象，产品经理和业务方看不懂，无法参与排期沟通。

第二，刻度越细，估算成本越高，收益越低。1.5 和 1.7 的差别在真实执行中会被各种干扰抹平，但在讨论中会消耗大量时间。

第三，5 档上限与粒度制度天然咬合。当研发发现"这个任务估出来是 8"的时候，制度和刻度的组合会推动他主动去拆，而不是填一个 8 了事。

4. 估算责任人矩阵

谁填工期，这个问题在跨职能团队里经常扯皮。我的划分原则是"谁执行谁估算，谁定义谁校验"。

• 需求类任务：由承接的开发负责人估，产品经理校验粒度是否合理。
• 设计类任务：由设计师估，产品经理确认改稿轮次上限。
• 测试类任务：由测试负责人估，产品经理确认验收范围。
• 技术债与预研类任务：由提出方和承接方共同估，允许给出区间而非单值。
• 运维支持类任务：不强制估算单值，改用"SLA 响应时长"作为替代指标。

最后一条特别重要。不要试图给所有任务都套一个工期数字，运维支持类任务本身就是不可预测的高频短任务，强行估算只会污染整体数据。用不同的指标去度量不同性质的工作，才是制度成熟的表现。

5. 制度落地的三个机制

（1）模板机制

把任务类型、DOD、估算刻度打包成任务模板，产品经理建单时选模板而不是填空白表单。这一步能把"遵守制度"的成本降到接近零。在大多数项目管理平台里，这个能力叫工作项类型配置或模板配置，配置一次长期生效。

（2）校验机制

关键字段做成必填，粒度上限做成硬校验，偏差超过阈值时强制填写归因标签。制度只有变成系统约束才算真正存在，写在文档里的制度在第一个冲刺就会被绕过。

（3）复盘机制

每两周看一次偏差中位数和归因标签的分布，只做诊断不做排名。这个节奏比季度复盘有效得多，因为误差还没被遗忘，归因更准确。

task_template:
name: 需求开发标准模板

fields:

task_type: feature # 必填，枚举

granularity_limit: 5.0 # 单位：人天，超过触发拆分提示

estimate_unit: person_day # 统一单位，禁止混填

estimate_scale: [0.5, 1, 2, 3, 5]

estimate_owner: dev_owner

dod:

代码已合并主干

单元测试覆盖率 ≥ 70%

接口联调通过

具备回滚方案

测试验收通过

validation:

actual_hours_required_on_close: true

deviation_tag_required_over: 0.5

五、案例与数据观察：180 人团队如何把偏差从 +127% 压到 +31%

1. 案例背景与迁移过程

回到开头那家 180 人的企业。它的情况在中大型组织里很有代表性：三条产品线、跨两个城市办公、研发与测试分离、有明确的合规要求（代码和交付数据不出内网）。原来的项目管理工具是团队早期自己选的一款国外工具，用了四年，字段已经乱到没人敢动。

治理分三步走。第一步是数据勘察，用两周时间导出近半年的任务数据，做粒度分布、单位分布、偏差分布的交叉分析，把问题定位到具体字段上。第二步是制度设计，产出前文那张字段表和 DOD 模板。第三步是平台落地，把制度变成系统里的硬约束。

第三步是关键，也是最容易被低估的一步。团队最终选择的是 PingCode。做出这个判断的原因有三个，都不是功能层面的花哨点，而是中大型组织的硬需求。

• 工作项类型可以深度自定义。任务类型、粒度上限校验、DOD 模板、字段级必填规则都能配出来，制度不需要靠人的自觉去维持。
• 支持私有化部署。这家公司的交付数据不允许出内网，私有化部署是硬门槛，直接排除了大部分 SaaS 方案。
• 支持从 Jira 平滑迁移。他们用四年的历史数据要整体搬过来，包括自定义字段映射、附件、评论和流转记录，迁移工具链的成熟度决定了这个项目能不能在计划周期内完成。

从实际执行看，迁移阶段用了大约三周，其中两周是字段映射规则的梳理和验证，真正跑数据只用了几天。最耗时的从来不是工具迁移，而是"什么字段对应什么字段"的决策过程。这个过程反过来还帮团队把字段体系重新梳理了一遍。

2. 治理前后的关键指标对比

下面是治理前后各一个季度的对比数据，样本为同一组织、同一批项目。所有数字都来自平台导出的任务数据。

需要说明的是，这组数据里最容易被误读的是"工期偏差中位数从 +127% 降到 +31%"。它不是估算变准了，而是粒度变小之后，每个任务包含的未知量变少了。这是制度收益，不是能力收益。理解这一点很重要，因为它决定了你该投入在哪里。

3. 我们踩过的三个坑

（1）一次性上全量字段，导致两周内被集体绕过

第一版制度我们一次性上了 14 个必填字段，结果建单时间从 2 分钟变成 6 分钟，产品经理开始批量跳过。后来砍到 8 个，其中 5 个必填，才稳定下来。字段数量的边际收益递减得非常快，超过 10 个基本就变成形式主义。

（2）把偏差数据用于绩效，导致数据污染

第二个月我们犯了个错误，把偏差率发给了各研发小组的负责人做对比。之后两周的偏差数据突然变得异常"漂亮"，接近 0。核查后发现大家开始统一往长了估。我们立刻停掉了这个用法，改成只做诊断不下发排名，数据才恢复真实。

（3）忽略运维类任务，污染整体数据

运维支持类任务在治理初期被强制要求填写工期，结果这类任务的平均偏差是 +280%，直接把整体数据拉歪。后来把它们从工期统计里剥离出来，改用响应时长和解决时长两个指标，整体数据立刻干净了。

4. 为什么这个场景更适合私有化部署平台

这一节我不绕弯子。对于 100 人以上、且对数据主权有要求的中大型企业，工具选型的判断标准其实很清晰。

• 私有化部署是准入门槛，不是加分项。研发过程中的代码片段、需求文档、交付排期，都属于核心资产，能否部署在自己的服务器上，直接决定方案能不能进入选型清单。
• 迁移能力决定实施周期。用了四年的历史数据不可能重新录入，字段映射、附件迁移、流转记录还原，缺一样都会导致迁移后数据断层，工期治理就失去了历史基线。
• 字段与工作流的自定义深度决定制度能否落地。如果平台只能改字段名称、不能配置字段级校验和模板联动，那制度设计得再好也只能停在文档里。

PingCode 在这三点上都对得上：主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，是国产替代路线里比较成熟的一个选择。当然，工具只是承载，制度才是内核，这一点在任何平台上都成立。

六、不同情况下的行动建议

1. 20 人以下团队：只做三件事

小团队最大的优势是沟通成本低，最大的风险是过度设计。这个阶段不要上复杂的字段体系，只做三件事就够了：

1. 给每个任务加一个"任务类型"字段，枚举控制在 4 个以内（需求、缺陷、技术债、其他）。
2. 粒度上限设为 3 人天，超过就拆，靠习惯而不是靠校验。
3. 每周花 15 分钟看一次偏差最大的三个任务，口头复盘，不写文档。

这三件事能覆盖小团队 80% 的工期问题。剩下的 20% 投入产出比极低，不值得在小团队阶段做。

2. 20-100 人团队：把制度变成系统约束

这个规模是制度最容易崩塌的区间。团队已经过了靠喊话就能对齐的阶段，但还没到需要专职流程团队的程度。这时候必须把制度固化到系统里。

• 粒度上限 5 人天，做成硬校验。
• 估算单位统一为人天，刻度 5 档，不允许自由填数字。
• DOD 按任务类型做成模板，建单时自动带入。
• 关闭任务时必须回填实际耗时，偏差超过 50% 必须选归因标签。

这个阶段的一个关键判断是：如果你的项目管理平台不支持字段级校验和模板联动，制度落地成本会高出一个数量级。这也是很多团队在这个规模上开始重新做工具选型的原因。

3. 100 人以上组织中大型企业：分三条线并行推进

到了这个规模，工期治理不再是产品经理一个角色能推的事，需要三条线并行。

第一条线是制度线，由产品负责人牵头，定义任务类型、粒度上限、DOD 标准、估算责任人矩阵，产出一份不超过三页的制度文档。

第二条线是平台线，由研发效能或项目管理办公室牵头，把制度配置到平台上，包括字段设计、工作流、模板、校验规则、报表。这一条线的复杂度通常被严重低估。

第三条线是度量线，由数据分析或效能团队牵头，建立偏差中位数、P90、准点率、回填率几个核心指标的月度看板，只做诊断不做排名。

三条线的节奏是：制度线先行两周，平台线跟上，度量线在制度上线后一个月开始产出报告。顺序颠倒会出现两种典型失败：先上平台导致配置了没人用的字段，先上度量导致团队觉得被监视而抵触制度。

4. 有合规与数据主权要求的企业：先解决部署形态，再谈制度

金融、政企、大型制造业这类组织，工期治理的第一步往往是选一个能私有化部署的项目管理平台。这不是技术偏好问题，而是合规前置条件。

在这类场景里，我的建议是先锁定两三个满足私有化部署要求的候选平台，再在其中比较字段自定义深度和迁移能力。顺序不能反，否则你会在制度设计做完之后才发现方案用不了，返工成本极高。

七、不同情况下的取舍

1. 精度与制度成本的取舍

很多人默认"工期越准越好"，这是个错误前提。精度是有价格的，价格就是填写成本和维护成本。把偏差从 ±40% 压到 ±20%，需要投入的字段、校验、复盘成本可能是压到 ±40% 的三倍，而这 20 个百分点的精度对你的业务决策可能毫无影响。

我的判断标准很简单：看工期数据会被用在什么决策上。如果只用于团队内部排期，±40% 完全够用；如果要用于对外承诺、合同交付、资源采购，那才值得追求 ±20%。先用最小制度跑起来，需要更高精度时再加字段，这个顺序不能反。

2. 制度刚性与团队自治的取舍

制度太松，数据不可用；制度太紧，团队会绕过它。我踩过的坑是前者，但见过更多团队死在后者。

比较可行的折中是：把字段分成"硬约束"和"软建议"两类。粒度上限、估算单位、任务类型做硬约束，系统层面不允许违反；估算刻度、置信区间、归因标签做软建议，提供默认值但不强制。这样既保证了数据的基本可用性，又给了团队呼吸空间。

3. 度量深度与信任成本的取舍

度量做得越深，越容易让团队产生被监视感。这不是矫情，是有现实基础的，数据一旦被用于考核，理性人就会优化指标本身而不是真实工作。

我的原则是：度量可以深，但出口要窄。后台可以算十几个指标，但对外只发三个：偏差中位数、准点率、返工率。而且这三个指标只发给团队自己，不跨团队排名。这一条在多个团队验证过，是维持数据真实性的关键。

4. 平台统一与工具多样性的取舍

中大型组织里，不同业务线常常有自己的工具偏好。统一到一个平台，好处是数据可汇总、口径可对齐；坏处是有迁移成本和团队适应成本。

我的判断是：如果一个组织要认认真真做工期治理，那就必须统一到一个平台上。工期数据一旦分散在多个系统里，汇总口径就无法保证一致，任何跨业务线的容量规划都会失真。迁移成本是一次性的，数据口径不一致的成本是持续性的。

在需要统一且对部署形态有要求的场景下，支持私有化部署和从 Jira 平滑迁移的平台会是更务实的选择，因为历史数据能连续，度量基线才不会断。

八、高频问答

1. 产品经理到底该不该定预计工期？

不该定数值，必须定规则。产品经理的职责是定义任务类型、粒度上限、估算单位、完成定义和责任人，至于某个任务具体是 2 天还是 3 天，由执行方判断。产品经理越界定数值，会导致研发把工期当成"你说了算"，估算责任感消失。

一个更准确的表述是：产品经理是制度的制定者，研发是制度的执行者，两者共同承担数据质量的责任。

2. 研发拒绝填写估时怎么办？

先别急着讲道理，先看拒绝的真实原因。我遇到过的原因大致有三类：一是字段太多，填起来烦；二是担心被用来考核；三是觉得填了没人看，属于纯浪费。

三类原因对应三种解法。字段太多就砍到 5 个必填以内；担心考核就公开承诺数据只做诊断不下发排名；觉得没人看就把数据用起来，比如在迭代规划会上展示偏差分布，让研发看到自己的输入真的影响了排期决策。第三类原因最难解决，也最常被忽略。

3. 预计工期和计划时间有什么区别？

预计工期是研发对"这个任务需要多少工作量"的估计，单位是人天；计划开始时间和计划完成时间是产品经理对"什么时候做、什么时候交付"的安排，单位是日期。两者的责任人、单位和调整频率都不同。

把两者合并成一个字段，会导致每次排期变动都污染工期数据，历史基线彻底失效。正确的做法是在系统里保留成三个独立字段。

4. 敏捷团队还需要预计工期吗？

需要，但形态会变。敏捷团队更常使用故事点或者相对估算，但如果组织层面需要做跨团队的容量规划和交付承诺，就仍然需要一个统一的可比单位。

我的实践经验是：团队内部可以用故事点，但对外汇报时必须有一个换算成人天的锚点。这个锚点不需要每个任务都精确，只需要在迭代层面保持一致即可。

5. 制度上线后多久能看到效果？

过程指标一到两周就能看到，比如字段填写率；结果指标需要四到八周，比如偏差中位数；下游指标如准点率需要十二周以上，因为排期节奏的调整要跨多个迭代才能验证。

我建议第一个月只看一个指标：实际耗时回填率。这个指标上去之后，其他数据才有意义；这个指标上不去，后面所有报表都是空的。

6. 任务粒度上限设多少合适？

3 到 5 人天是一个经验区间。低于 3 人天，拆分成本会超过收益，产品经理会被拆任务这件事淹没；高于 5 人天，估算误差会快速放大，从数据上看，粒度超过 10 人天的任务偏差中位数普遍在 +150% 以上。

如果团队刚开始做粒度治理，建议先设 5 人天作为上限跑一个季度，等数据稳定后再考虑降到 3 人天。

九、把工期当成一种组织语言

写到这里，我想把整篇文章的判断收束成一句话：预计工期不是研发的私事，它是产品、研发、测试、业务之间沟通的一种公共语言。一种语言要想被准确使用，靠的不是每个人天赋异禀，而是有一套所有人都认的语法。

这套语法就是任务属性制度。它包含五个部分：任务该多大（粒度）、这个任务是什么（类型）、用谁的尺子量（单位与责任人）、什么算做完（DOD）、数据怎么回来（回流）。这五件事里，产品经理至少要负责三件，而且这三件都不需要你懂技术。

我见过太多团队把工期问题归因于"研发不会估"，然后花大力气做估算培训、引入估算方法、请外部教练，最后一无所获。而真正有效的做法往往很朴素：把粒度压下来，把单位统一，把类型分清楚，把完成定义写明白。这些动作的投入产出比，远高于任何估算技巧的提升。

如果你准备开始，我建议下一步只做一件事：从你的项目管理平台里导出最近一个月的已完成任务，统计一下"粒度超过 5 人天的任务占比"和"实际耗时回填率"这两个数字。第一个数字告诉你制度有多松，第二个数字告诉你数据能不能用。这两个数字出来之后，你就知道自己该从哪里动手了。