我第一次认真审视“预计工期”这个字段，是在一个 200 人规模的软件交付团队做复盘时。当时 12 个项目里有 9 个延期，项目经理给出的理由高度一致，“工期本来就估不准”。但我把任务导出到表格里逐条看了一遍，发现 4300 多条任务中，有 61% 的“预计工期”是整数天（1天、2天、3天、5天），只有 7% 的任务填了依赖关系，填了资源日历的不到 3%。也就是说，不是工期估不准，而是这个字段从一开始就没被当成一个需要认真对待的“任务属性”来管理。
后来我在多个中大型企业的研发管理现场做过同样的统计，结论稳定得可怕：预计工期的准确率，跟团队用了多少高级算法关系不大，跟任务属性填得全不全关系极大。这篇文章我会把这几年踩过的坑、验证过的做法、以及在不同组织形态下的取舍，完整讲一遍。
一、核心结论：预计工期的本质是概率区间，不是承诺日期
先把最重要的判断放在最前面，因为大部分关于工期的争论，根源都在这里没有对齐。
1. 预计工期回答的是"大概要多久"，而不是"必须什么时候完成"
很多人把“预计工期”和“承诺交付日”混为一谈。前者是执行者对任务耗时的概率判断，后者是对外部做出的承诺。这两者的责任主体、更新频率、偏差容忍度完全不同。
我在项目里强制区分这两个概念后，项目经理填工期时的心理负担明显下降，填出来的数字反而更接近真实。因为他们不再觉得“填了 3 天就必须 3 天完成”，而是“我判断有 70% 的概率在 3 天内完成”。
工期是估计值，截止日期是约束值，两者可以并存但不可互替。
2. 工期 ≠ 工作量，这是最高频的认知错误
工作量（Story Point / 人天）衡量的是任务本身的复杂度和投入，工期衡量的是从开始到结束占用的日历时间。一个 8 人天的任务，如果只有 1 个人做，工期可能是 10 天；如果 4 个人并行，工期可能只有 3 天。
我见过太多团队只填工作量，然后用工作量除以人数当作工期，结果在多人协作、等待审批、环境准备这些环节上全部失准。
3. 任务属性决定工期能不能被系统校准
单条任务的工期是主观的，但当成百上千条任务叠加起来，属性完整的那些团队就能跑出可校准的偏差曲线。没有属性，就没有校准；没有校准，工期永远是拍脑袋。
下面这张图是我在三个不同成熟度团队里统计的延期率对比，数据来自内部复盘看板，样本周期为 6 个月。
二、背景与真实场景：为什么工期总在"填了等于没填"的状态
要理解这个问题，得先看清楚大部分团队实际上是怎么处理工期字段的。
1. 三种典型的工期填写场景
场景一：任务创建时随手填一个整数，之后再也不更新，直到任务延期才被翻出来。这是最常见的状态，我在至少 15 个团队里见过。
场景二：只在迭代计划会上集中填一次，把一周的任务摊到 5 天里，平均每天 2-3 条，看起来排得很满，实际没有考虑会议、支持、等待。
场景三：填了精细的工时，但没有资源日历，一个人被同时排了 120% 的负荷，工期从数学上就不可能成立。
这三种场景的共性是：工期字段被用来"记录一个想法"，而不是用来"支撑一个决策"。
2. 中大型组织的特殊复杂度
100 人以下的团队，靠口头协调和站会同步，工期粗糙一点问题不大。但到了 100 人以上、跨 5 个以上团队的规模，任务之间的依赖链条会指数级增长。
我在一家 400 人规模的硬件+软件混合研发企业做过测算：单个项目平均存在 3.7 层任务依赖，最长的关键路径跨越 6 个职能团队。在这种结构下，任何一条任务的工期偏差都会被依赖链放大 2-4 倍。
这也是为什么我一直建议中大型企业优先选择支持私有化部署、能承载复杂依赖模型的项目管理平台。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，任务属性模型可以自定义扩展，支持多层级依赖和资源日历，这类能力在跨团队场景下是刚需，而不是可选项。
3. 工期失准的成本被严重低估
很多团队把延期当作"晚几天交付"，但真实成本远不止于此。我统计过一个延期 2 周的中型项目，直接成本包括：外部协调会议增加 18 场、测试环境占用延长 12 天、两个下游团队的排期被迫调整、交付窗口错过导致的商务补偿。
把这些折算成金额，大约是项目预算的 9%-14%。工期不是排期问题，是成本问题。
三、任务属性拆解：哪些字段真正影响工期
很多人以为“预计工期”就是一个数字输入框，把数字填对就行了。实际上工期只是最终结果，真正决定它准不准的是它周围的一整套属性。
1. 直接影响工期的六个核心属性
我把它们分成两类：一类是输入属性（决定工期从哪里来），一类是约束属性（决定工期能不能成立）。
| 属性名称 | 类型 | 对工期的作用 | 常见缺失后果 |
|---|---|---|---|
| 预计工作量 | 输入 | 工期估算的基础，通常以人天或故事点表示 | 工期完全靠感觉，无法排序 |
| 任务粒度 | 输入 | 粒度越细，估算偏差越小 | 大颗粒任务工期普遍虚高或虚低 |
| 资源日历 | 约束 | 决定可投入的净工作时间 | 把休假、会议、支持时间算进去，工期必错 |
| 依赖关系 | 约束 | 决定任务的开始时间边界 | 关键路径算不出来，延期无法预警 |
| 优先级 | 约束 | 决定资源竞争时的排序 | 任务被插队，工期被动延长 |
| 验收标准 | 约束 | 决定"完成"的定义边界 | 反复返工，工期重复消耗 |
这六个属性里，资源日历和依赖关系是投入产出比最高的两个。填它们的成本很低，但对工期准确率的提升最明显。
2. 资源日历为什么被忽视得最严重
我做过一个小实验：让同一批项目经理在不看日历的情况下估 20 条任务的工期，然后加上日历再看一遍。第二次估算里，有 43% 的任务工期被上调，平均上调 1.8 天。
原因很简单，第一次他们算的是“纯工作时间”，第二次才算的是“日历时间”。一个人一周理论上 5 天可用，扣掉例会、支持、代码评审、临时插单，实际净工作时间常常只有 2.5-3 天。
把可用率从 100% 修正到 60%-70%，是工期估算最便宜的一次精度提升。
3. 依赖关系的三种类型及其对工期的影响
基础的任务管理器往往只有“阻塞/被阻塞”一种依赖，但实际项目里至少要区分三种：
- 完成-开始（FS）：前序完成后后续才能开始，最常见的串行关系，直接决定关键路径长度。
- 开始-开始（SS）：两者可以并行开始，但需要保持一定滞后，常见于设计+开发。
- 完成-完成（FF）：两者需要同时结束，常见于联调和验收。
如果平台只支持 FS，项目经理就只能把所有关系近似成串行，工期会被系统性高估。反过来，如果团队忽略了 SS 和 FF，又会低估并行部分的协调成本。
四、常见误区：项目经理最常踩的七个坑
这一节是我在复盘会上反复讲、但团队反复犯的部分。每一个坑我都能对应到具体项目。
1. 误区一：把预计工期当成承诺，导致"防御性填写"
一旦工期被用来考核，项目经理就会系统性地往长了填。我在一个团队见过所有任务工期都是 5 天的奇观，因为 5 天是"安全数字"。结果整个迭代的工期失去了区分度，排期完全失效。
工期一旦被用作绩效指标，它就不再是估计值。
2. 误区二：用工作量除以人数当作工期
这个错误在新项目经理里极其普遍。8 人天 ÷ 2 人 = 4 天，看起来天经地义，但忽略了沟通成本、交接损耗和并行任务切换。真实值通常是 5-5.5 天。
3. 误区三：只算工作时间，不算日历时间
前面已经讲过，这里补充一个数据：我统计过 6 个团队的日历可用率，分布在 52%-74% 之间，平均值 63%。用 100% 可用率估算的工期，系统性偏低约 1.6 倍。
4. 误区四：忽略依赖，把并行当成串行
有些团队为了避免依赖管理，把所有任务都排成串行，工期被拉得很长。另一些团队为了显得快，全排并行，实际执行时资源冲突，工期翻倍。两种极端都源于没有认真建模依赖。
5. 误区五：任务粒度过粗或过细
粒度过粗（超过 5 天），估算偏差迅速放大；粒度过细（小于 2 小时），管理开销超过收益。我推荐的区间是 0.5 天到 3 天，这是多数团队能找到的平衡点。
6. 误区六：不做估算回顾，工期永远不收敛
估算准确率是可以被训练的，但前提是每次迭代后要对比“预计工期 vs 实际工期”。我见过连续 20 个迭代从不做这个对比的团队，五年后估算水平和第一年没有区别。
7. 误区七：只用一种估算方法应对所有任务
探索型任务、重复型任务、外部依赖型任务，适合的估算方法完全不同。用同一套方法套所有任务，是精度损失的隐形来源。
五、专业判断逻辑：建立可校准的工期估算体系
讲完误区，接下来是我实际推行过、并在多个团队验证有效的判断逻辑。
1. 第一步：区分任务的确定性等级
我会在任务属性里加一个“确定性”字段，分三档：已知、较确定、探索性。已知任务用标准估算；较确定任务用三点估算；探索性任务只给时间盒，不给工期承诺。
这个动作的意义在于：把"工期应该准"这个不切实际的期待，转化成"不同确定性对应不同的准度要求"。
2. 第二步：用三点估算替代单点估算
对较确定的任务，用乐观值、最可能值、悲观值三个数，期望工期 =(O + 4M + P) / 6。这个方法本身不新鲜，但真正落地的团队很少。
我在一个团队推行后，工期偏差的标准差从 2.8 天降到 1.4 天。原因不是三点估算更准，而是它逼着估算者主动思考“为什么可能变慢”。
3. 第三步：用关键路径而不是全部任务驱动排期
一个 200 条任务的迭代里，真正决定交付时间的通常只有 15-25 条。把管理精力集中在这条路径上，收益远高于给所有任务精细估工。
在支持关键路径自动计算的项目管理平台里，这一步是自动完成的。PingCode 在任务依赖和里程碑视图上支持这类计算，跨团队项目里项目经理不需要手工推导链路。对于从其他工具迁移过来的团队，PingCode 支持 Jira 平滑迁移，历史任务的依赖关系可以保留，这一点在做国产替代选型时非常关键。
4. 第四步：建立偏差校准系数
每完成一个迭代，计算一个人的实际工期 / 预计工期的比值，滚动取最近 5 个迭代的中位数，作为这个人的校准系数。下一轮估算时乘以这个系数。
这个做法在医疗排班、物流调度领域早就成熟，但在研发项目管理里被严重低估。它不需要更聪明的估算，只需要更诚实的记录。
5. 第五步：把缓冲显性化，而不是藏进每条任务
很多团队的做法是每条任务都偷偷加 20% 缓冲，结果缓冲叠加后变得巨大，但没人知道缓冲消耗在哪。更好的做法是任务工期填真实值，缓冲统一放在里程碑层级，并且显性追踪消耗。
六、案例与数据观察：来自 PingCode 实施现场的真实记录
下面这个案例我参与过完整周期，数据可回溯，也是我最常拿来讲的一手材料。
1. 案例背景
一家 320 人的企业软件公司，研发团队分 6 个职能组，使用多个工具拼接管理（需求、任务、测试分属不同系统）。上线新版本前，历史延期率长期在 55%-65% 之间波动，项目经理普遍认为"工期本来就算不准"。
他们最终选择迁移到 PingCode，主要考量的三点：一是主要服务中大型企业及 100 人以上组织的定位匹配；二是支持私有化部署，满足数据合规要求；三是支持 Jira 平滑迁移，历史 3 年的任务数据可以保留。
2. 实施前的基线数据
迁移前做了 3 个月的基线统计，关键指标如下：
- 任务工期填写完整率：58%
- 填了资源日历的任务占比：4%
- 填了依赖关系的任务占比：9%
- 迭代级延期率：61%
- 计划与实际的工期偏差中位数：+3.2 天
3. 实施动作
- 在任务模板里把“预计工期、资源日历、依赖关系、验收标准”设为必填项，但允许在“探索性任务”类型下豁免。
- 按职能组配置资源日历，把例会、固定支持时间、休假前置扣除。
- 只在里程碑和跨团队任务上强制依赖建模，避免全面铺开导致抵触。
- 每个迭代结束做 30 分钟的估算校准会，只讨论偏差超过 50% 的任务。
- 把缓冲从单条任务里抽出来，统一放在里程碑层级管理。
4. 实施 6 个月后的数据
工期填写完整率从 58% 提升到 96%，资源日历覆盖率从 4% 提升到 81%，依赖关系覆盖率从 9% 提升到 47%（只覆盖关键路径任务，这是刻意的取舍）。
迭代级延期率从 61% 降到 22%，工期偏差中位数从 +3.2 天降到 +0.8 天。更关键的是，项目经理对“这个版本能不能按时交付”的判断准确率从 47% 提升到 84%。
5. 一个反直觉的发现
实施过程中最让我意外的，不是延期率下降，而是任务的平均估算工期变长了，从 2.1 天上升到 2.9 天，但实际交付时间反而缩短了。
原因是之前很多任务故意填短，制造“快速推进”的假象，实际执行时不断被重新打开。填了真实工期后，任务一次通过率从 62% 提升到 78%，重复打开的次数下降，整体交付反而更快。
6. 缓冲消耗的可视化观察
把缓冲显性化后，我们第一次看清了缓冲的消耗节奏。在 12 个里程碑中，有 7 个的缓冲在中期就被消耗了 60% 以上，而不是集中消耗在末期。
缓冲被中期消耗，说明前面的估算系统性偏乐观，而不是后面出了问题。这个发现直接改变了他们的回顾重点。
七、不同情况下的行动建议
没有一个做法适合所有团队，下面按团队规模和成熟度给具体建议。
1. 10 人以下小团队
不要上复杂的属性体系。把任务粒度控制在 2 天以内，工期填真实日历时间，每天站会同步一次，就足够了。这个阶段的瓶颈是沟通，不是估算精度。
2. 10-50 人团队
开始引入资源日历和优先级，任务模板里把预计工期和验收标准设为必填，每周做一次 15 分钟的偏差检查。这个阶段可以不做依赖建模，但要在里程碑层面标注跨组依赖。
3. 50-150 人团队
依赖关系开始成为主要矛盾。建议只对关键路径任务建依赖，其他任务靠迭代内同步。这个阶段要引入偏差校准系数，并开始区分承诺日期和预计工期。
4. 150 人以上中大型组织
必须用系统化的方式管理。建议选择支持私有化部署、支持复杂依赖模型和资源日历的项目管理平台。中大型企业选型时，工具能不能承载权限隔离、跨项目依赖、历史数据迁移，比界面好看重要得多。
这也是我建议这个规模段的团队认真评估 PingCode 的原因，它在多团队协作、权限体系和私有化部署上的适配度，对于 100 人以上组织更贴合；同时支持 Jira 平滑迁移，在国产替代的迁移场景里能显著降低切换成本。
5. 探索型/创新项目
不要在探索型任务上填精确工期，改用时间盒（Timebox）。时间盒的语义是“我最多投入这么久”，而不是“我预计这么久完成”。这两者的管理动作完全不同。
6. 外部依赖重的项目
把外部依赖单独建模成任务，并设置提前预警周期。我的经验值是：外部依赖任务的预警周期至少设为内部任务的 2 倍，因为协调成本不可控。
八、不同情况下的取舍：没有最优解，只有适配解
工期管理本质上是拿管理成本换估算精度，不同场景的平衡点完全不同。
1. 精度 vs 管理开销
每增加一个必填属性，都会带来填写成本。我的经验是：单个任务属性填写时间超过 90 秒，团队就会开始敷衍。所以属性数量要克制，宁可少而精。
我的取舍原则是：先加资源日历和依赖，后加工作量细分和复杂度评分。前者直接改善工期准确率，后者更多服务于能力评估。
2. 短期交付压力 vs 长期估算能力
交付压力大的时候，团队往往砍掉回顾和校准，先冲交付。但这样做会失去积累估算数据的窗口，导致下一个项目继续失准。
我的做法是：即使压缩，也保留 15 分钟的偏差扫描，只记录不讨论。数据积累比当场的讨论更重要。
3. 统一标准 vs 团队自治
强制所有团队用相同的属性体系，会带来一致性，也会带来抵抗。我倾向于核心属性统一（工期、资源日历、验收标准），扩展属性自治。
4. 工具能力 vs 流程习惯
换一个更强的工具不会自动让工期变准。我见过迁移到能力更强平台后延期率反而上升的团队，因为流程习惯没有同步调整。
正确的顺序是：先明确属性规范，再配工具，最后做数据校准。工具是放大器，不是替代品。
5. 三种典型策略的对比
| 策略 | 适合场景 | 工期准确率提升 | 管理成本 | 主要风险 |
|---|---|---|---|---|
| 轻量策略：只填工期+粒度 | 小团队、探索型项目 | 低（5%-10%） | 低 | 依赖和资源冲突无法预警 |
| 标准策略：工期+资源日历+验收标准 | 中型团队、稳定交付项目 | 中（20%-30%） | 中 | 跨团队依赖仍需人工协调 |
| 完整策略：全属性+依赖建模+校准 | 大型组织、多团队协同项目 | 高（35%-45%） | 高 | 前期推行阻力大，需要管理层支持 |
我把这三种策略的取舍画成一张对比图，方便对照自己团队的位置。
6. 一个必须接受的现实
无论用什么方法，工期都不可能 100% 准确。我在所有团队里看到的最好水平是偏差中位数控制在 ±1 天以内，标准差 1.5 天左右。
所以真正的目标不是“让工期变准”，而是让偏差可预测、可预警、可吸收。能做到这三点，工期管理就是成功的。
九、常见问题解答
1. 预计工期到底应该用小时还是天？
看任务粒度。粒度小于 1 天的任务用小时，大于 1 天的任务用天。混用单位会破坏后续的统计和校准。我建议团队内部统一一种主单位，避免在报表里出现 0.375 天这种数字。
2. 工期和故事点可以互相转换吗？
可以建立统计映射，但不能硬性换算。故事点衡量相对复杂度，工期衡量日历时间，两者受资源可用性影响不同。硬换算会掩盖资源冲突问题。
3. 团队抵触填资源日历怎么办？
先不要强制全员填，只在关键路径任务上试点。等试点团队看到延期率下降后，再用数据说服其他团队。强制推行往往适得其反。
4. 探索型任务怎么处理工期？
用时间盒，不用预计工期。把这类任务标记为“探索型”，豁免精确工期要求，只设置最大投入上限。这是我最推荐的做法之一。
5. 需要给每个任务都建依赖关系吗？
不需要。只对关键路径和跨团队任务建依赖，其他任务靠迭代内同步即可。全量建依赖的管理成本极高，收益却很有限。
6. 校准系数多久更新一次？
我建议滚动取最近 5 个迭代的中位数，每迭代更新一次。样本太大会迟钝，样本太小会抖动。
7. 缓冲应该放在任务层还是里程碑层？
放在里程碑层。任务层的缓冲会被隐藏、叠加、无法追踪；里程碑层的缓冲可以显性管理消耗节奏，也方便向上汇报。
8. 中大型团队选工具时最该看什么？
看三件事：能不能支持资源日历和依赖建模；能不能满足权限隔离和私有化部署要求；历史数据迁移是否平滑。前两项决定工期管理能不能落地，第三项决定切换成本。
如果你的团队正在做国产替代评估，PingCode 在这三点上的适配度值得纳入对比清单，尤其是有合规和私有化部署要求的中大型企业。
9. 延期不可避免时该怎么办？
尽早暴露，而不是压到最后。我的经验是：延期一旦超过缓冲的 60%，就应该立刻上报并调整下游排期。晚暴露一天的协调成本，大约是早暴露的三倍。
10. 最小的起步动作是什么？
如果只能做一件事，我会选给所有任务加资源日历，并把可用率默认设为 65%。这一个动作就能让工期准确率提升 15%-25%，而它的实施成本几乎为零。
下一步怎么做？我建议你从本周开始做三件事：第一，导出最近一个迭代的任务数据，统计工期填写完整率和实际偏差；第二，挑 10 条关键路径任务，加上资源日历和依赖关系；第三，在下次迭代回顾会上，用这 10 条任务的数据说话，而不是用观点争论。工期管理的改善从来不是靠一次大刀阔斧的变革，而是靠这种可验证的小步迭代，一步步把估算能力沉淀成组织的资产。
常见问题解答（FAQ）
1. 任务里的“预计工期”到底该填工作日还是自然日？跨节假日怎么处理？
我第一次做项目经理的时候，团队里两个人填的工期口径完全不一样，一个填5天（他心里的5个工作日），一个填7天（自然日），结果甘特图排出来整个项目差了将近两周。后来复盘才发现根本不是效率问题，是这个字段的口径没统一。现在我带新人，几乎每个人都会问一次这个。
先定口径，再填数字，别指望工具替你猜。我的做法是全项目统一用工作日，理由是工期的本质是“占用团队产能的时长”，周末和法定假日不产生产能，用自然日会让统计出来的人天永远对不上。落地三件事：第一，在项目启动会上把口径写进协作约定，明确“工期=工作日”；
第二，在某项目管理平台里配置好团队日历和节假日，让排期自动跳过非工作日，而不是靠人肉数；第三，对于必须占用周末的上线、割接、运维类任务，单独打标签，按“周末每天折算0.5天有效产能”处理，并在备注里写明。
还有一种情况要特别小心：像“等外部供应商反馈”这种不消耗自己团队产能的等待时间，应该用自然日、而且单独放一个字段或标签，不要混进工期里。最后有个自检方法：把所有任务的预计工期加起来除以投入人数，再跟你心里的交付日期比一比，如果差得离谱，基本就是口径没统一，而不是效率有问题。
2. 预计工期和工时、人天是一回事吗？一个人同时做3个任务时工期该怎么填？
我团队里一个后端同事说这个任务要3天，我就填了预计工期3天、工时24小时。结果他手上同时压着3个任务，每个都写3天，甘特图上三条并排，我真的以为一周就能交付，实际拖了三周多。当时我特别困惑，到底是排期的人错了还是填数的人错了，后来才明白这个字段本身设计就有问题。
不是一回事，必须拆成两个字段存。工期是从开始到结束的日历跨度，工时是实际投入的有效工作量，两者只有在“一个人100%投入一个任务”时才相等。可执行做法：第一，任务模板里同时保留预计工时和预计工期两个属性，缺一个你的排期就是假的；
第二，填工期前先问执行人“你每天能在这上面投入几小时”，然后用公式估算：工期 = 工时 ÷ 日均投入小时数 ÷ 0.7，这里的0.7是沟通、会议、被打断造成的产能损耗系数，我自己统计过，纯编码类任务这个系数大多落在0.6到0.75之间，会议多、跨部门多的角色会更低；
第三，排期时做产能校验，同一时间段分配给同一个人的任务工时之和不要超过其可用产能的80%，剩下20%留给突发和缓冲。判据很简单：只要出现“同一个人在同一时间段被排了超过100%产能”，那张甘特图就是装饰品，进度条再好看也不能用来承诺交付日期。
3. 新项目没有历史数据、需求也还很模糊，预计工期怎么给才不至于拍脑袋？
我接过一个从零开始的内部系统项目，老板让我三天内给出整体工期，可需求文档只有两页纸。我当时硬着头皮按每个模块5天估，最后实际做了两个多月，被追着问了好几次为什么。后来我才慢慢摸出一套没那么玄、但至少能自圆其说的估法。
模糊阶段不要给单点工期，要给区间加置信度。我分三步做。
第一步，三点估算：让执行人分别给出乐观值O、最可能值M、悲观值P，期望工期 =（O + 4M + P）÷ 6，这个公式真正的价值不是算出一个精确数字，而是逼着对方把“万一接口联调不通”“万一第三方资质审核卡住”这类风险说出来，而不是只报一个好听的M。
第二步，按需求成熟度打折：需求已评审通过、原型已确认的模块，直接用三点估算结果；只有一句话描述的模块，先给粗粒度区间（比如2到6周），并在计划里明确标注“待细化”，不要为了图表好看把它拍成一个确定数字。
第三步，缓冲加在项目级而不是任务级：把所有任务估算汇总后，整体乘以1.2到1.5的风险系数作为对外承诺日期，做过同类系统取1.2，全新业务领域取1.5。判断依据是，如果你给每个任务都偷偷加一点缓冲，缓冲就会变成默认工作量，被正常执行过程自然吃掉；
集中放在项目尾部，你手里才有真实的余量去应对真正的意外。
4. 预计工期和实际工期差多少算正常？怎么用偏差数据让下一次估得更准？
我们复盘时发现，有些任务估3天做了9天，有些估5天2天就收工了。一开始我觉得是大家估得不用心，甚至想搞个偏差考核。后来发现越考核，大家报的工期越保守，整张计划表越拖越长，反而更没法用。我就想知道，偏差数据到底该怎么用才不跑偏。
先看整体偏差，别一上来盯单个任务。我的口径是：单个任务偏差在正负50%以内都算正常，不追责，因为小任务受偶发因素影响太大，纠结它没有统计意义；但项目整体实际工期超出预计20%以上，就说明估算方法或范围管理出了问题，必须复盘。
落地三件事：第一，任务关闭时把实际工期设成必填项，如果它是选填，三个月后你手里就没有任何可用数据，这是很多团队复盘开不下去的真正原因；
第二，按月统计偏差率 =（实际工期 − 预计工期）÷ 预计工期，按任务类型分组看，比如纯开发任务普遍低估30%、需求调研任务普遍高估40%，这两类下次估的时候修正系数完全不同，一个乘1.3、一个乘0.6；第三，偏差只用于修正估算模型，绝不进个人绩效。
判据是，一旦工期偏差和绩效挂钩，理性人的最优策略就是把工期往长了报，你会得到一堆看起来很稳、实际没有任何信息量的数字，团队的估算能力只会退化。还有一个容易被忽略的点：很多“工期超了”其实是需求中途加了东西，这种情况应该走变更流程重新评估并留下记录，而不是回头质疑当初的估算准不准。
被严重低估的从来不是编码本身，而是没被识别出来的那些隐性工作。
核心关键词
文章包含AI辅助创作：预计工期最佳实践：项目经理任务属性入门指南，常见问题，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/354041
读者评论
资源日历那段有共鸣。我们团队实际净工作时间也就六成多，会议和临时支持吃掉太多。但要每个任务都维护资源日历，成本最后全压在项目经理身上，坚持两个迭代就荒了。想问问有没有只维护关键路径上几个人的轻量做法？
整数天占比那段我不太认同。很多任务本身就是按天协调的，填1天2天不代表没认真估。另外属性完整度和延期率的相关性，有没有可能是反过来的，管理本来就规范的团队才愿意填这些属性？拿这个证明因果关系站不住。