预计工期最佳实践：项目负责人任务属性入门指南，常见问题

去年冬天我复盘一条延期了 23 天的交付线，41 个任务里有 27 个的"预计工期"是在需求评审散会后 90 秒内被随手填上的，平均每个数字的思考时间不到 4 秒。而这条交付线后来拖垮了整个季度的排期。

这件事让我彻底改变了对"预计工期"这个字段的看法：它不是排期表上的一个空格，它是任务属性的映射结果。填错它的代价不会在当天显现，而会在两个月后的复盘会上连本带利地还回来。

这篇内容写给项目负责人、技术负责人和 PMO。我会把任务属性该怎么建模、七个关键属性如何影响工期、不同规模组织该怎么取舍、以及那些被问了无数遍的常见问题，一次讲清楚。你会看到我自己踩过的坑、跑过的数据、以及一套可以直接抄走的判断逻辑。

一、核心结论：预计工期是任务属性的函数，不是负责人的态度

先把结论摆在前面，省得你读到一半才发现方向不对。预计工期（Estimated Duration）本质上是任务的一组客观属性经过映射后得到的区间中位数，而不是负责人"愿意承诺"的一个日期。这句话想通了，后面所有的操作都是自然推论。

1. 结论一：预计工期的正确形态是区间，不是点

我见过太多团队把工期字段做成一个单值输入框，然后期待它是准的。这在数学上就不成立：任何包含不确定性的人类工作，其完成时间的天然形态是概率分布，不是点估计。

我在一个 300 人规模的研发组织做过统计：同类型、同复杂度、同一批执行人的开发任务，实际完成时间的 P10 和 P90 之间差了 2.7 倍。也就是说，如果你填的是中位数，那么有 10% 的概率你会用 2.7 倍的预期来交付。

正确的做法是把工期字段拆成三个值：乐观值（P10）、最可能值（P50）、悲观值（P90）。哪怕平台只允许填一个数字，你也应该在备注里写下区间。这个动作只多花 20 秒，但它能让排期从"赌博"变成"风险定价"。

2. 结论二：任务属性决定工期，负责人只决定偏差大小

很多管理者把工期不准归因于"某某人估得不准"，这是找错了责任人。真正决定一个任务要多久的，是任务类型、复杂度、不确定性、依赖深度这些客观属性。

负责人熟练度影响的只是"相对基准值的效率系数"，大体在 0.7 到 1.6 之间浮动。而任务类型和依赖结构带来的差异，可以轻松达到 5 倍以上。把注意力放在人身上，等于只优化了方差的一小部分。

3. 结论三：七个属性就能解释大部分工期偏差

经过几轮筛选，我最后固定在七个属性上：任务类型、复杂度、不确定性、依赖深度、执行人熟练度、可用专注率、验收标准清晰度。再加属性收益递减得很快，我试过扩到十四个，结果填写时长翻倍，预测准确率只提升了不到 4 个百分点。

4. 结论四：工期准确率是可以度量、也可以被训练的

我通常用两个指标衡量一个团队的工期能力：偏差中位数（MAPE 的中位数，比平均值抗极端值）和 P75 覆盖率（实际工期落在悲观值以内的比例）。前者反映准度，后者反映诚实度。一个偏差中位数 20%、P75 覆盖率 85% 的团队，比偏差中位数 10%、P75 覆盖率 50% 的团队更值得信任，因为后者在系统性撒谎。

二、背景与真实场景：为什么"填工期"这件事在 100 人以上会失控

十人团队靠默契就能运转，工期填得粗糙也不会出事，因为所有人的上下文是共享的。但组织一旦超过 100 人、项目变成并行多条线，上下文共享就断了，工期字段就成了唯一的跨团队契约载体。这时候它的质量直接决定排期质量。

1. 场景一：90 秒填完的工期，撑起了三个月的排期

前面提到的那条延期 23 天的交付线，根源就在评审会。会上所有人关注的是"这个需求要不要做"，散会后项目负责人被要求"一小时内把排期发出来"，于是 41 个任务的工期在 90 秒内被批量填完。

这批数字随后被汇总成甘特图，被写进季度 OKR，被承诺给业务方。一个 4 秒做出的判断，最终影响了三个月的资源分配。这个链条我在不同公司见过至少五次。

2. 场景二：同一件事，两个人填出 5 倍差距

我做过一个刻意设计的实验：把同一个"改造用户权限校验逻辑"的任务，分别交给五位资深工程师独立估工期。结果从 1.5 人天到 7.5 人天，差了整整 5 倍。

差异不出在能力上，出在假设上。填 1.5 人天的人默认"只用改一个中间件、不涉及数据迁移、有现成测试用例"；填 7.5 人天的人默认"要覆盖历史脏数据、要回归所有下游服务"。他们写的数字都对，只是没人把假设写下来。

3. 场景三：从 Jira 迁移时，历史工期基线几乎全部作废

我参与过一次中大型研发组织的工具迁移，他们从 Jira 迁到 PingCode。迁移本身很顺，PingCode 支持 Jira 平滑迁移，字段映射和附件、评论、流转历史都能带过去。但真正的麻烦不是迁移，是迁移之后发现历史工期的可用价值很低。

原因很具体：原来在 Jira 里，工期字段是自由文本，有人填"3d"，有人填"3 天"，有人填"约三天"，有人填"3"（含义不明）。这些数据无法直接用于基线计算，最后我们只保住了不到 40% 的有效样本，剩下的靠重新标注补救。

这件事给我的教训是：工期字段的格式治理，必须和工具迁移一起做，而不是迁移之后再做。因为迁移是最好的强制统一时机，过了这个窗口，没人再有动力回头清洗。

4. 场景四：把工期当承诺之后，团队开始系统性撒谎

当工期被用于考核，它就不再是预测，而变成了谈判筹码。我观察到一个非常稳定的模式：一旦组织把"工期准确率"写进个人绩效，团队报出的工期会整体上浮 30% 到 50%，同时拆出大量 0.5 人天的碎任务来稀释偏差。

结果是数据好看了，排期能力却下降了。这是所有工期治理里最容易踩的坑。

三、常见误区拆解：九个我反复看到的问题

下面这九条，几乎每一批新接触工期治理的团队都会撞上其中的六到七条。我按出现频率从高到低排列。

1. 误区一：把预计工期当成承诺交付日期

这是所有问题的源头。预计工期回答的是"这个任务大概需要多久"，承诺交付日期回答的是"我保证什么时候交"。前者是预测，后者是承诺，中间差着一整套风险缓冲和资源锁定机制。

一旦两者混用，团队就会开始防御性填报：把工期往高了报，把任务往碎了拆，把不确定性藏起来。我的建议是把这两个字段在平台上物理隔离，预计工期只对项目组内可见，承诺日期才对上游可见。

2. 误区二：粒度越细，估算越准

反了。工期偏差率与任务规模呈反比关系，任务越小相对偏差越大。把任务拆到 0.5 人天，你得到的是更漂亮的燃尽图，不是更准的预测。

我的经验阈值是：单个任务的预计工期最好不要低于 0.5 人天，也不要高于 8 人天。低于 0.5 人天的任务，误差量级和任务本身一样大；高于 8 人天的任务，属性太多以致无法可靠评估，应该二次拆分。

3. 误区三：用历史平均值直接填工期

历史平均值是"同类型任务的平均耗时"，但你的任务不是平均任务。它的复杂度、不确定性、依赖深度都可能偏离均值。

均值只能作为基准值，不能直接作为结果。用均值填工期，相当于用全国平均身高去买衣服。

4. 误区四：忽略等待时间和依赖

在一个真实项目里，任务的实际交付周期中，纯工作时间往往只占 35% 到 55%，剩下的全是等待：等上游接口、等评审、等环境、等另一个团队的排期。

而这些等待时间几乎从不出现在工期字段里。这就是为什么小任务的工期看起来都对，加起来的项目周期却总是超。

5. 误区五：把"人天"当成"8 小时"

一个 3 人天的任务，如果按 8 小时折算，是 24 小时的净工作时间。但现实是执行人每天能投入这个任务的有效专注时间可能只有 3 小时。那么它实际占用的日历时间是 8 天，而不是 3 天。

这就是"人天"和"日历天"的关键区别。工期字段填的是工作量，排期算法必须再乘以一个专注率倒数，才能换算成日历周期。这两件事在大多数平台里是混在一起的，这是排期失真的重要来源。

6. 误区六：不区分复杂度和不确定性

这两个属性经常被打包成一个"难度"，但它们的治理手段完全不同。复杂度高意味着工作量确实大，解法是拆分和加人；不确定性高意味着分布很宽，解法是做技术预研（Spike）和显式缓冲。

一个任务可以又简单又极度不确定，比如"接入一个从没用过的第三方 SDK"。它可能 2 小时搞定，也可能三天搞不定。给它加人没有用，先做两小时预研才有用。

7. 误区七：依赖记录写在备注里，不进结构化字段

备注是给人看的，字段是给算法和报表看的。依赖关系如果只写在描述里，你的排期工具就无法识别关键路径，也无法在依赖变更时自动提醒。

我的做法是：内部依赖用平台的"关联任务"字段，外部依赖（跨团队、跨供应商）必须建独立字段并指定跟踪人。

8. 误区八：估错了就悄悄改数字

改数字的瞬间，你就丢掉了最有价值的数据，原始估计与实际的偏差。没有偏差数据，团队永远无法校准自己的估计能力。

正确做法是把原始估计锁定为只读，实际工期填写为另一个字段，偏差率由系统自动计算。PingCode 这类平台里，字段权限和工作流规则可以做到这一点，把"预计工期"字段在进入开发后设为不可编辑，就能有效止损。

9. 误区九：把工期准确率写进个人绩效

前面说过，这会导致系统性撒谎。工期准确率只能作为团队级的过程度量，用于校准和复盘，不能作为个人考核项。

如果你必须考核，考核"是否填了区间""是否标注了不确定性""是否在属性变更时更新了工期"，这些行为指标比结果指标健康得多。

四、专业判断逻辑：七个属性的工期推算法

这一节是全文的核心。我把七个属性逐个拆开讲清楚它的定义、取值方式和它如何进入工期计算。你可以直接把这套结构搬到 PingCode 或其他项目管理平台的自定义字段里。

1. 属性一：任务类型，决定基准速率

任务类型是效率最高的一个属性，因为它对偏差的解释力最强，填写成本却几乎为零。

我通常把类型控制在 6 到 9 类，比如：需求分析、方案设计、开发实现、数据变更、测试验证、缺陷修复、文档撰写、运维支持。太少会混淆，太多会没人选得准。

每一类维护一个基准值（中位数），比如开发实现 2.5 人天、测试验证 1.0 人天、缺陷修复 0.5 人天。这个基准值不需要一开始就准，它会在积累 50 到 100 个样本后自动收敛。

2. 属性二：复杂度，决定系数范围

复杂度我用三档或五档，不用连续值，因为人对连续值的判断噪声很大。

（1）三档制的定义方式

• L1 常规：有同类实现可直接参考，改动局限在单一模块内。系数 1.0。
• L2 进阶：需要跨模块改动或引入新依赖，但有成熟方案。系数 1.4 到 1.8。
• L3 攻坚：涉及架构调整、性能瓶颈或全新领域。系数 2.2 到 3.0。

注意系数区间而不是单值。区间的下沿用于乐观估计，上沿用于悲观估计。这样你就自然得到了工期区间，不需要额外填两次。

3. 属性三：不确定性，决定缓冲

不确定性回答的是"我不知道的东西有多少"，而不是"这件事有多难"。我给它的取值只有四档，而且要求填写人必须勾选"不确定来源"。

关键点是 U3 不允许直接进入排期。不确定性和复杂度是两个独立的乘数，把它们合并成一个"难度"字段，是工期治理里最常见的技术性错误。

4. 属性四：依赖深度，决定等待时间

依赖深度不是"有没有依赖"，而是"这条依赖链有多长、有多不可控"。我用的取值是依赖数量和依赖类型两个维度。

• 依赖数量：0 个、1 个、2 个、3 个及以上。3 个以上的任务应该考虑拆分。
• 依赖类型：团队内依赖（等待中位数约 0.8 天）、跨团队依赖（约 2.4 天）、外部供应商依赖（约 5 天以上）。

等待时间应当作为独立项加到交付周期上，而不是混进工期。工期字段记录的是工作量，交付周期 = 工作量 + 等待时间 + 返工时间。把这三者分开，你的排期工具才能识别关键路径。

5. 属性五：执行人熟练度，决定效率系数

我不用"这个人行不行"这种主观判断，而是用三个客观信号合成一个熟练度分档：在该类型任务上的历史完成量、历史偏差率、对该模块代码的提交密度。

合成后的系数大致是这样：新手 1.4 到 1.6、熟练 1.0、领域专家 0.7 到 0.8。注意这里说的是稳定分布的偏移，不是个体能力评价。

6. 属性六：可用专注率，决定日历周期

这是最被忽视、但杠杆最大的一个属性。专注率 = 每天能真正投入到该任务的有效时间 ÷ 名义工作时间。

健康团队的这个值在 55% 到 70%，被会议和临时支持严重侵蚀的团队会低到 25% 到 35%。专注率每下降 15 个百分点，近似相当于所有任务工期上浮 20% 到 30%。

好消息是专注率可以被度量：用日历数据统计每人每天的无会议时段，或者用工具里的任务状态切换频率来反推。这个数字一旦被看见，管理层通常愿意动会议结构。

7. 属性七：验收标准清晰度，决定返工概率

验收标准模糊的任务，返工概率会显著上升。我把它简化为三档，并绑定一个返工概率。

这张表是我从几个团队的历史数据里拟合出来的，量级上具有参考价值，但具体数值一定要用自己的数据重新校准。它的价值不在于精确，而在于把"验收标准清晰度"从一个软性讨论变成可计算项。

8. 把七个属性落成计算公式

把上面七项组合起来，就得到一个可以直接在平台里做自动化计算的公式。我在 PingCode 的自动化规则里用类似下面的逻辑做过原型，你也可以用脚本或低代码工具实现。

# 工期推算伪代码（示意实现，需用自有数据校准参数）
TYPE_BASE = {"需求分析": 1.8, "开发实现": 2.5, "测试验证": 1.0, "缺陷修复": 0.5}

COMPLEXITY = {"L1": (1.0, 1.2), "L2": (1.4, 1.8), "L3": (2.2, 3.0)}

UNCERTAINTY_BUFFER = {"U0": 0.10, "U1": 0.25, "U2": 0.50, "U3": 1.00}

SKILL_FACTOR = {"新手": 1.5, "熟练": 1.0, "领域专家": 0.75}

REWORK_RATE = {"A": 0.10, "B": 0.35, "C": 0.80}

DEPEND_WAIT_DAYS = {"无": 0.0, "团队内": 0.8, "跨团队": 2.4, "外部": 5.0}

def estimate_duration(task):

base = TYPE_BASE[task.type]

low_c, high_c = COMPLEXITY[task.complexity]

1. 工作量区间：基准 x 复杂度 x 熟练度

work_low  = base * low_c  * SKILL_FACTOR[task.skill]

work_high = base * high_c * SKILL_FACTOR[task.skill]

2. 叠加不确定性缓冲

b = UNCERTAINTY_BUFFER[task.uncertainty]

work_low  = work_low  * (1 + b * 0.5)

work_high = work_high * (1 + b)

3. 叠加预期返工

r = REWORK_RATE[task.acceptance]

work_low  = work_low  * (1 + r * 0.5)

work_high = work_high * (1 + r)

4. 换算日历周期：除以专注率，加上依赖等待

focus = task.focus_ratio or 0.6

cycle_low  = work_low  / focus + DEPEND_WAIT_DAYS[task.dependency]

cycle_high = work_high / focus + DEPEND_WAIT_DAYS[task.dependency]

return round(cycle_low, 1), round(cycle_high, 1)

这个公式的意义不在于精确预测，而在于它把七个属性都显式化了。当预测错了，你能指出来是哪一项属性估错了，而不是笼统地说"估得不准"。这是可校准和不可校准的分水岭。

五、真实案例与数据观察

下面三个案例来自我实际参与过的组织改造，涉及中大型研发团队和私有化部署环境。数据经过脱敏和量级调整，但趋势和结构是真实的。

1. 案例 A：300 人研发组织的工期字段改造

客户是一家 300 多人的研发组织，同时跑六条产品线，长期使用 Jira。他们的问题很典型：季度排期完成率常年在 45% 到 55% 之间波动，PMO 每个季度要花两周时间手工对齐排期。

我们做的第一件事不是改流程，而是统计现有工期字段的可用性。结果令人沮丧：有效样本占比不到 40%，其余是格式不统一、明显是占位符（比如统一填 1 天）、或者填了之后被改过多次已经无法追溯原始值。

第二件事是抓住迁移窗口。他们决定迁移到 PingCode，主要考虑是私有化部署要求和中大型组织的权限复杂度。我坚持把工期字段治理和迁移合并成同一个项目，而不是分成两期做，理由是迁移时团队对字段变更有容忍度，事后单独推会被当成额外负担。

具体动作包括：把工期从自由文本改成数值字段并强制单位；新增复杂度、不确定性、依赖类型三个枚举字段；把原始估计设为进入开发后只读，实际工期单独记录；配置自动化规则在任务进入开发时校验四个必填属性，缺失则不允许流转。

治理前后的对比数据大致如下表。需要注意的是，预估填写耗时从 0.5 分钟上升到 2.1 分钟，这是真实的成本，我在下一节会专门讨论这个取舍。

2. 案例 B：把不确定性显式化之后的缓冲变化

第二个案例是一个 120 人左右的产品研发团队。他们的特点是缓冲已经存在，但以"隐性缓冲"的形式散落在每个人的私人习惯里，每个人都会在报出的工期上悄悄乘以 1.3，但没人承认。

隐性缓冲的问题是它不可管理。项目经理看到的总工期是 30 天，实际团队心里的总工期是 39 天，但没有任何一个地方说明这 9 天是为什么留的。

我们的做法是引入不确定性字段，并要求缓冲必须由属性推导、写进任务描述。刚开始团队很抗拒，觉得"把缓冲写出来就会被砍"。我们做了一个承诺：任何由 U2、U3 属性推导出的缓冲，在评审中默认通过，除非有人能提出具体的预研方案替代它。

六个月后，团队整体报出的工期总量上升了约 8%，但准时交付率从 61% 提升到 84%。更有意思的是，实际投入的总工时反而下降了约 6%，因为不确定性被提前讨论后，中途推翻重做的次数少了。

3. 案例 C：迁移过程中的历史基线保全

第三个案例规模较小，但教训很具体。一家 150 人的组织从 Jira 迁到 PingCode，他们想保留历史工期用于基线计算。

我们在迁移前做了一次数据清洗：把自由文本工期按正则解析成数值，把"约""大概""待定"这类无法解析的标记为无效，把明显是占位符（同一人同一天创建的所有任务工期完全一致）的样本剔除。最终保住的有效样本约 62%，比不做清洗直接迁移后能用的比例高出约 20 个百分点。

另外提醒一句：迁移过来的历史数据只能用来计算"基准值"，不能直接用来算偏差率。因为历史数据里的实际完成时间往往受到原工时制度的影响，很多人会按考勤规则填写而不是按真实耗时填写。用它算基准值没问题，用来评估准确率会得到严重失真的结论。

4. 数据观察：三条可复用的规律

• 规律一：偏差率在治理的前三个月通常没有明显改善，甚至因为原始数据变得诚实而短暂恶化。真正的拐点出现在第 4 到第 6 个月，也就是样本量积累到 200 个任务以上之后。
• 规律二：显式化缓冲会让报出的总工期上升 8% 到 15%，但会让实际总工时下降 5% 到 10%。短期看起来是"变慢了"，长期是变快了。
• 规律三：专注率的提升对交付周期的贡献，通常大于估算方法改进的贡献。如果你的组织每天有大量会议，先做会议治理的回报率会明显更高。

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

上面讲的是通用方法论。但不同规模的团队，落地路径差别很大。下面按组织规模和使用场景给出具体建议。

1. 10 人以下小团队：只需要三个字段

不要上七个属性，你承受不起这个管理开销。最小可用集合是：任务类型、复杂度档位、依赖数量。

前两个字段让基准值能够自动推导，第三个字段防止你忽略等待时间。其余属性靠团队默契和口头沟通解决，反而更快。

另外一个具体建议：小团队不要用自动化公式，手填反而更准，因为每个人的上下文足够完整，公式引入的噪声可能大于收益。

2. 30 到 100 人的单一产品线：上五个属性

这个规模开始出现上下文断裂，需要把不确定性、验收标准清晰度这两个字段补上。它们是沟通成本的主要来源，也是返工的主要来源。

这个阶段建议做两件事：一是建立类型字典并纳入评审检查项；二是每双周做一次 15 分钟的偏差复盘，只看偏差率最高的三个任务，不扩大到全部。

3. 100 人以上、多项目并行的组织：上齐七项，并做度量体系

到这个规模，专注率和熟练度必须纳入，否则你的排期无法解释为什么小任务都对、项目总是超期。

同时需要建立跨项目的度量体系：偏差中位数、P75 覆盖率、依赖等待占比、WIP 超限天数。这四个指标我建议做成固定看板，每周更新，不做个人排名。

工具层面，PingCode 这类面向中大型组织的平台在这个阶段优势比较明显，因为它的权限模型、跨项目报表和自定义字段能力能支撑这种颗粒度。它支持私有化部署，对数据合规要求高的组织也适用；如果原本用 Jira，平滑迁移能保住历史和流程配置，减少推倒重建的阻力。

4. 强合规或私有化部署场景：把审计要求前置到字段设计

金融、政企、医疗这类场景，工期字段往往还要承担审计留痕作用。这时有两点必须提前设计：原始估计的不可篡改性，以及变更的完整审计链。

具体做法是原始估计字段设为写入后只读，变更只能通过新增记录实现，且每次变更记录操作人、时间和原因。如果用的是支持私有化部署的国产平台，通常这类字段级权限和审计日志是内置能力，不需要额外开发。

5. 正在做工具迁移的团队：抓住这个窗口

迁移是字段治理成本最低的时刻。我的建议是把治理动作打包进迁移项目，包括：字段格式统一、历史数据清洗、必填规则配置、自动化规则上线。

如果分两期做，第二期的推进会困难得多，因为团队已经形成了对新工具的惯性使用方式，任何额外要求都会被当成负担。

七、不同情况下的取舍

这一节讲的是必须做的选择。工期治理不是"全都要"，每个决策都有明确的代价。

1. 精度与填写成本的取舍

更细的属性带来更准的预测，也带来更长的填写时间。我实测过的数据是：三字段方案平均填写 0.5 分钟，七字段方案约 2.1 分钟。按每人每天创建 1.5 个任务计算，七字段方案每人每天多花约 2.4 分钟。

这个成本是否值得，取决于你的排期误差造成的损失有多大。如果一次排期失误导致跨团队返工，损失通常是几十人天量级，那 2.4 分钟显然值得。如果项目只有你和另外两个人，就不值得。

2. 粒度与管理开销的取舍

拆得越细，进度可见性越好，但管理开销和相对偏差都会上升。我的建议是把 0.5 到 8 人天作为任务粒度的合理区间，超出就调整。

但这条不是铁律。如果你的组织需要按天对外汇报进度，那就必须拆到 1 人天以内，同时接受相对偏差会变大，并在考核时避开小任务的偏差率。

3. 缓冲与承诺的取舍

显式缓冲会让报出的总工期变长，这在短期内很难向业务方解释。但它会让实际总工时下降，因为减少了中途推翻重做。

我的处理方式是把缓冲单独列出来，叫"不确定性预算"，明确告诉业务方这笔预算的存在和它解决什么问题。同时约定：如果没有触发不确定性，这笔预算可以在项目内重新分配，而不是被收回。这个约定能显著降低团队的防御性填报。

4. 标准化与团队自治的取舍

统一字段和统一取值能带来跨团队可比性，但会牺牲部分团队的适配性。我倾向于"字段名和取值标准化，权重和系数允许团队自治"。

也就是说，所有人都要填复杂度和不确定性，但研发团队和运维团队可以用不同的系数。这样既保住了可汇总性，也不会因为一刀切而失真。

5. 平台能力与流程复杂度的取舍

平台能做的自动化越多，你越容易把流程做得越来越重。我见过有团队给工期字段配了 11 条自动化规则，最后没人能说清一条任务为什么被卡住。

我的原则是：自动化规则不超过 5 条，且每条必须能对应一个具体的、曾经真实发生过的损失。没有对应损失的规则，就是纯粹的摩擦。

八、常见问题

1. 预计工期到底该谁填？

执行人填，项目负责人审核。理由很简单：执行人对工作量和自身熟练度最了解，而项目负责人对依赖和排期约束最了解。两个人各填自己知道的部分，比任何一方独立填都准。

但审核不等于改数字。如果项目负责人直接改，执行人会迅速失去填写的动力，后续所有数据都会失真。正确做法是把分歧记录在两个字段里：执行人估计和排期约束，偏差留到复盘时讨论。

2. 没有历史数据，第一次怎么填工期？

用行业经验值起步，但必须标注为"低置信度"。我通常给的初始基准是：需求分析 1.5 到 2 人天、开发实现 2 到 3 人天、测试验证 1 到 1.5 人天、缺陷修复 0.5 人天。

然后关键动作是：前 50 个任务不要试图做精确预测，只做记录。50 个样本之后就足以算出自己的中位数，替换掉经验值。

3. 工期和故事点（Story Point）该用哪个？

两个都该用，但用途不同。故事点衡量相对规模，适合做团队内部的容量规划；工期衡量绝对时间，适合做跨团队的排期和承诺。

只用一个会出问题。只用故事点，跨团队无法对齐；只用工期，团队内部会因为个体差异而失去可比性。如果资源有限只能选一个，我建议选中大型组织用工期，小团队用故事点。

4. 工期经常被临时插入的任务打断，怎么办？

这本质上是专注率问题，不是工期问题。你在一个被打断 40% 的环境里，无论工期填得多准都无法按时交付。

可操作的动作有三个：设置每天固定的无会时段；约定临时任务必须通过需求方与项目负责人协商才能插入；把插入比例本身作为一个度量指标公示。第三个动作往往最有效，因为可视化的打断比例会形成改进压力。

5. 跨团队依赖的等待时间，该算进谁的工期？

都不算进工期，算进交付周期。这是我在文章里反复强调的一点：工期是工作量，交付周期是日历时间，前者是后者的组成部分而非全部。

如果硬要把等待算进某个团队的工期，就会出现两个团队重复计算同一段等待，或者互相推诿。正确做法是在任务上单独记录等待时间，在报表里分别呈现工作量和等待占比。

6. 偏差率多少算正常？

我的参考标准是：偏差中位数控制在 20% 以内属于优秀，20% 到 35% 属于健康，35% 到 60% 属于可改进，超过 60% 说明工期字段基本失去预测意义。

但要注意两点：一是这个标准适用于 1 到 8 人天的任务，小任务的相对偏差天然更高；二是偏差有方向性，系统性偏低（实际总是超过预估）比随机偏差更危险，因为它意味着排期从根上就是乐观的。

7. 工具迁移时，历史工期的偏差数据要不要带过去？

带，但只用来算基准值，不用于准确率评估。原因是历史实际耗时字段在很多组织里受工时填报规则影响，填的是合规时间而不是真实时间。

迁移前一定要做数据清洗：统一单位格式、剔除明显占位符、标记无法解析的样本。这个动作在迁移前做，成本是迁移后做的五分之一左右。

8. 团队抵触填这些字段，怎么推？

先减少字段，再证明价值。我的经验是第一次推行不要超过四个字段，并且要在三个月内拿出一个团队自己能感受到的收益，通常是"少开了几次排期对齐会"或"少返工了一轮"。

另外，绝对不要把工期准确率和个人绩效挂钩。这是最快的劝退方式，也是让数据彻底失真的最短路径。

九、总结与下一步

回到最开始那个问题：为什么一条延期 23 天的交付线，根源是 90 秒内填完的工期？因为工期字段承载的信息量远超过它看起来的样子，它是任务属性的压缩表达。压缩得太狠，解压出来的东西就是错的。

我在这篇内容里给出的核心判断是三条。第一，预计工期是任务属性的函数，属性不完整，工期必然失真。第二，七个属性中，类型、复杂度、不确定性、依赖是收益最高的四项，专注率和熟练度是杠杆最大但最容易被忽视的两项。第三，工期治理的收益不是免费的，它用填写时间和流程复杂度换取排期质量，只有当组织明确接受这笔成本，收益才会真正出现。

还有一个反直觉的观察值得记住：显式化缓冲会让报出的工期变长，实际总工时反而变短。很多组织在这一点上做了相反的选择，结果既没有准确率，也没有效率。

如果你的组织正准备开始，我建议的下一步顺序是这样的。

1. 本周：统计现有工期字段的有效样本占比。如果低于 60%，先做格式治理，不要急着上更多字段。
2. 两周内：确定你的字段集合。10 人以下选三个，30 到 100 人选五个，100 人以上上齐七项并建度量看板。
3. 一个月内：把原始估计设为进入开发后只读，实际工期单独记录，让偏差率自动计算。这一步做完，后面所有优化才有数据基础。
4. 三个月内：积累到 200 个任务样本后，用自有数据重新校准所有基准值和系数，替换掉初始的经验值。
5. 半年内：把专注率纳入度量。如果你只做一件事，做这一件，它通常是所有属性里杠杆最大、成本最低的一项。

最后提醒一句：不要在第一个月就期待偏差率下降。数据变诚实的过程，看起来像是变差了。真正的拐点通常在第四到第六个月出现，那时候你才会发现，前面所有的填写成本都在以排期返工次数下降的形式回本。