预计工期最佳实践：项目经理任务属性协同管理，常见问题

项目管理工具里最贵的一行数据，往往不是预算，而是那个被随手填进去的“预计工期”。2023 年我帮一家 320 人规模的智能硬件企业做研发交付复盘，翻出 214 个被标记为“延期”的任务，逐条做归因。结果很反常识：真正因为“估算方法太粗糙”而延期的只有 26 个，占 12%；剩下 88% 的延期，根子都在任务属性上，口径没统一、依赖没维护、资源日历没纳入、需求变更没和工期联动。也就是说，团队花了大量时间学三点估算、学扑克牌估算、学 PERT，但真正漏掉的是最基础的一层：同一个“预计工期”字段，在不同人手里代表的是完全不同的东西。

这篇文章想讲清楚一件事：预计工期的最佳实践，核心不是“怎么估得更准”，而是“怎么让任务属性互相咬合”。我叫它任务属性协同管理，工期不是孤立的数字，它必须和口径、依赖、资源日历、完成定义、变更留痕五个属性形成联动。下面我按结论、场景、误区、判断逻辑、案例数据、行动建议、取舍七个层次拆开讲。

一、先给结论：工期不准，八成问题不在估算法

我把结论先摆在前面，是因为大部分团队在“工期不准”这件事上，改进方向从一开始就偏了。

1. 工期偏差的主因是属性口径不一致，不是估算技术落后

我在 6 个研发组织做过同一套归因复盘，累计 214 个延期任务样本，把每条延期归到唯一主因上。结果里占比最高的是“任务属性口径不一致”，占到 34%，典型表现是有人按自然日填、有人按工作日填、有人填的是工作量而不是持续时间。

排第二的是“依赖关系维护缺失”21%，第三是“资源日历与投入率未纳入”18%，第四是“需求变更未与工期联动”15%。真正归到“估算方法本身不当”的只有 12%。这个分布说明，在没有统一口径的前提下，换更复杂的估算模型，收益基本为零，因为输入的语义本身就是混乱的。

2. 任务属性必须“协同”，孤立字段等于没填

我见过太多团队把属性当成“表单字段”，一个一个加：加了预计开始、预计结束、工时、故事点、优先级、负责人、迭代。字段看起来很全，但彼此之间没有任何计算关系。

协同的意思是：改一个，其他必须跟着动。改动“投入率”，预计结束时间要重算；改动“前置任务实际完成时间”，后续任务的计划开始要顺延；改动“完成定义”，任务的完成判定要重新校验。没有联动的字段只是装饰，有联动的字段才是模型。

3. 任务属性协同是治理机制，不是一次性的字段配置

很多项目经理以为这件事的终点是“在工具里把字段建好”。实际上建字段只完成了 20%，剩下 80% 是：谁负责维护、什么时候必须更新、变更怎么留痕、偏差怎么归因、复盘时拿什么数据说话。

我在一个团队见过最典型的失败案例：字段建了 15 个，前两周填得很认真，第三周开始有人空着，第五周开始有人乱填，第八周整个字段集变成了“填给领导看的”。属性协同如果要活下来，必须被嵌进日常动作流，而不是挂在任务详情页等着被想起来。

二、真实场景：工期是怎么一步步“漂”出去的

抽象讲口径，说服力有限。我挑三个我实际参与过的场景，把工期漂移的过程还原出来。

1. 场景一：跨部门协作里的“工期口径战”

一个典型的跨端需求，后端接口、前端页面、测试验证三个任务。后端负责人填“5”，他心里的意思是 5 个工作日；前端负责人也填“5”，他心里的意思是 5 个人日工作量，实际会分散在 8 个自然日里完成；测试负责人填“5”，他想的是从提测到出报告 5 天，其中 2 天在等环境。

三个“5”凑在一起，项目经理排出 5 天完成整个需求。实际跑了 13 天。复盘会上三方都很委屈，因为每个人填的数字在自己语境下都没错。这不是态度问题，是口径问题，而口径问题用沟通是解决不了的，必须用规则固化。

2. 场景二：多项目共享资源导致的“工期挤压”

一个 3 人后端小组同时支撑两条产品线。A 项目的排期按“这 3 人全职投入”计算，B 项目也按“这 3 人全职投入”计算，两张计划表各自都很漂亮，合起来看就是 200% 的负载。

到了执行阶段，A 和 B 互相抢人，两边都延期，两边的项目经理都认为是对方插队。这类问题的根源在于任务属性里缺了“资源容量”和“跨项目分摊比例”，工期是在真空中算出来的。

后来我们做了一件事：在每个任务上增加“投入率”属性，并且强制要求同一成员在同一时间窗内的投入率之和不超过 100%。规则一加，A、B 两条线的排期表立刻从“都好看”变成“都不好看”，但这次的不看好吧，它接近真实。

3. 场景三：需求变更后的“工期漂移无人归因”

我在一家企业服务公司看到的过程是这样的：需求评审通过，排期 20 天；中途产品经理加了两个边界场景，改了 1 个接口字段；开发顺手做了，没有更新工期字段；测试阶段发现问题，返工 3 天；最终 28 天交付。

复盘的时候，没有人能拿出证据说明这 8 天差在哪里。因为变更没有留下痕迹，工期字段从头到尾还是“20 天”，只是实际结束时间晚了 8 天。没有留痕的变更等于没有变更，只留下一个说不清道不明的延期。

三、拆解常见误区：八个反复出现的坑

下面这八个误区，我在不同团队里几乎每次都能撞见至少五个。它们的共同特征是：看起来都是小事，但每一个都会系统性地污染工期数据。

1. 把“工期”和“工作量”当同一个东西

工作量（Effort）是投入的人时或人日，工期（Duration）是这件事占用的日历跨度。一个人做 5 人日的工作量，工期可能是 5 天、7 天或 13 天，取决于投入率。两个人并行做 5 人日，工期可能压缩到 3 天，但不一定压到 2.5 天，因为协作有成本。

我在一个团队的工具字段里看到“预计工期（人日）”这样的命名，直接反映了这个混淆。正确的做法是拆成两个字段：工作量用“人时”，工期用“日历天”，并且明确工期由工作量、投入率、日历三者共同推出。

2. 工时口径不统一：6 小时、7.5 小时、8 小时混着用

有的团队按 8 小时一个标准人日，有的按 7.5 小时，有的按 6 小时（扣除会议和协作损耗）。这三种口径同时存在于一个组织里时，跨团队汇总出来的工期数字就是错的。

我的建议很直接：全组织只用一个人日折算系数，并且写在排期规范里。哪个人日定 6 还是 8 不是最重要的，重要的是所有人用同一个数。

3. 资源日历属性缺失：默认所有人 100% 可投入

这是最隐蔽也最致命的一条。排期时默认成员全职、默认不请假、默认不参加其他项目、默认不被线上问题打断。现实中一个资深后端每天真正能投入到排期任务里的时间，常常只有 5 到 6 小时。

判断方法很简单：随便挑一个已经完成的迭代，把成员实际在任务上花费的时间加起来，除以该周期的标准工时。这个比值如果低于 70%，说明你的排期基线整体偏高。

4. 依赖关系只画“先后”，不标类型和滞后

甘特图上连一条箭头，不代表依赖建对了。FS（完成，开始）、SS（开始，开始）、FF（完成，完成）、SF（完成，开始，极少用）四类依赖的排期结果完全不同，而且每类依赖都可能带滞后时间。

最常见的错误是把所有依赖都建成 FS 且滞后为 0，结果关键路径被算短，实际执行时才发现总有任务在等待。依赖属性不完整，关键路径就是假的。

5. 完成定义（DoD）缺失，任务“完成”含义各不相同

开发说“完成了”，指的是代码写完；测试说“完成了”，指的是用例跑完；产品说“完成了”，指的是验收通过。三个“完成”之间可能差 5 天，但任务属性上都是“已完成”。

工期统计依赖完成时间戳，如果完成定义不统一，工期数据从源头上就失真了。我的做法是在任务类型模板里内置 DoD 检查项，未通过检查项不允许流转到“已完成”状态。

6. 估算粒度混杂，3 天的任务和 3 小时的任务塞在同一张表

粒度差异过大时，聚合出来的工期失去了参考意义。3 小时的任务偏 2 小时，对迭代影响可以忽略；3 天以上的任务偏 30%，就是一天的进度损失。

比较务实的规则是：单个任务的预计工期不超过迭代周期的 1/3，超过就拆。两周迭代对应约 3 天，也就是 3 天以上的任务必须继续分解。

7. 用“预计工期”考核个人，导致系统性虚报

一旦工期准确率和绩效挂钩，理性人的选择就是虚报。我在一个团队见过所有人都把工期填成整数并且偏大一档的现象，问下来原因是“报小了延期要背锅，报大了按时完成是加分项”。

工期数据要用于改进流程，就不能同时用于评价个人。这两个用途放在同一份数据上，数据一定会被污染。如果必须考核，考核的是“偏差是否被及时披露和调整”，而不是“是否零偏差”。

8. 属性变更无留痕，工期漂移无法归因

工期从 20 天变成 28 天，中间经历了哪些调整、谁调的、为什么调，如果系统里查不到，复盘就只能靠记忆。而记忆在项目压力下是极度不可靠的。

下面这张表是我在多个团队里总结出的“误区，症状，可观测证据”对照，可以拿来自查。

四、专业判断逻辑：任务属性协同的四层模型

把上面这些问题收拢，我用的是一套四层判断模型。它的价值在于给出改进顺序：先修口径，再修结构，然后修资源，最后修治理。顺序错了，投入会白费。

1. 口径层：先让所有人说的“天”是同一个“天”

口径层要解决四件事：工期单位是工作日还是自然日、工作量单位是人时还是人日、一个人日折算多少小时、完成定义包含哪些检查项。这四件事没有统一之前，后面三层做什么都是在流沙上盖楼。

我通常用一个很土但有效的办法推进：把两个已经完成迭代的历史数据，用新口径重算一遍，把新旧两版的工期数字并排贴在项目例会上。数字差异带来的冲击，比讲十遍规范都管用。

2. 结构层：把依赖建到能算出真实关键路径的程度

结构层要管的是任务分解粒度和依赖关系。粒度上，控制在迭代周期的 1/3 以内；依赖上，区分四类依赖并显式标注滞后时间。

这里有个经验判断：如果一个项目任务数超过 200 个但依赖记录不到 150 条，基本可以确定依赖没建全，因为真实研发工作里的依赖密度大约在 1:1.2 到 1:1.8 之间。

3. 资源层：把“人”的约束写进工期计算

资源层包含成员容量、技能匹配、共享情况、多项目分摊比例。很多团队做出漂亮的甘特图，一到执行就崩，原因就是这张图假设了一个不存在的完全可用资源池。

我的做法是给每个人维护一个周期性的“可投入容量”，单位是人时，并且要求同一时间窗内所有任务的所需容量之和不超过该值。这本质上是把资源约束从“事后救火”变成“事前可见”。

4. 治理层：让变更留痕、让偏差可归因、让复盘有证据

治理层是让前三层能持续运转的机制。核心是三件事：属性变更必须留痕、工期漂移必须能归因到具体变更、每个迭代复盘必须基于属性数据而不是记忆。

判断治理层是否到位，有一个很直接的检验：随便挑一个已经结束的延期任务，问“这三天是哪些变更造成的”，如果 10 分钟内能从系统里查出答案，治理层就是有效的。

5. 四层的推进顺序不能颠倒

我见过最可惜的一种情况：团队口径还没统一，就直接上资源容量管理，结果是每个人维护了容量，但任务所需工时本身口径不一，两者除出来的投入率全是噪声，团队两周后就放弃了。

也有团队跳过结构层直接做治理留痕，最后留下的是海量变更记录，但因为依赖没建对，偏差归因出来的结论依然指向错误的环节。顺序就是口径 → 结构 → 资源 → 治理，每层达标再进下一层。

五、案例与数据观察：一个 320 人研发组织的改造过程

这一节用一个完整的案例，把上面的模型落到具体动作和数据上。案例主体是一家智能硬件研发企业，2023 年时约 320 人，其中研发 210 人，有硬件、嵌入式、云端、App 四条产品线。

1. 改造前的状态

改造前他们用的是一个海外主流研发管理工具（Jira 那一类），任务字段非常自由，各团队自己加字段，导致同一个组织里存在 5 套字段命名规范。工期字段有叫“预计工时”的，有叫“预估天数”的，还有叫“Story Points 折算天”的。

交付侧的三个数字很说明问题：工期命中率（实际结束与预计结束相差不超过 1 天）只有 41%；37% 的任务被标记过期；每周排期会平均耗时 96 分钟，且经常开成辩论会。

2. 关键动作：把属性协同固化到工具规则里

他们没有从“写规范文档”开始，而是先从工具侧动手。选型上，因为要满足私有化部署和研发数据不出内网的要求，最终落在 PingCode 上。PingCode 主要服务中大型企业及 100 人以上组织，对他们这种规模和合规要求是匹配的；同时因为要替换原有的海外工具，PingCode 支持 Jira 平滑迁移这一点，让历史任务和字段映射的成本大幅降低。

第一个动作是统一字段语义，把“预计工时”改名为“工作量（人时）”，把工期独立成“预计结束时间”，并且设为只读、由规则计算，不允许手填。把易被污染的字段改成计算字段，是这次改造里性价比最高的一个动作。

第二个动作是引入日历参照。他们建了一套“深圳研发中心日历”，把法定假日、调休、公司统一假期都配置进去，工期计算自动跳过非工作日。这一条上线后，跨团队排期的争议立刻少了一大截。

第三个动作是补全依赖属性。要求所有跨角色任务必须标注依赖类型和滞后时间，并且用自动化规则在依赖变更时提醒下游任务的负责人。这里的关键是“提醒的是负责人而不是项目经理”，责任直接落到执行者身上。

第四个动作是给每个成员配置周期性的可投入容量，多项目共享的资源必须在排期阶段就把分摊比例写进任务属性。这一步阻力最大，因为等于承认了“我们其实没有那么多人力”。

3. 一个可以直接复用的属性模板

下面这份属性最小可用集，是我在多个团队验证过的版本，字段数量控制在 14 个左右。它的设计原则是：能算的不填，能自动的不手输，必须人工判断的才留字段。

task:
口径层

duration_caliber: working_day # 工期口径：working_day / calendar_day

effort_hours: 40 # 工作量，单位人时

allocation_rate: 0.6 # 投入率 0-1，多项目共享时必填

calendar_ref: cn-shenzhen-2024 # 参照日历，含节假日与调休

definition_of_done: # 完成定义，未通过不允许流转

代码合并至主干

单元测试覆盖率 >= 70%

接口文档已同步更新

联调环境验证通过

结构层

planned_start: 2024-03-04

planned_end: null # 由规则计算，禁止手填

depends_on:

task: REQ-231

type: FS # FS / SS / FF / SF

lag_hours: 4 # 滞后时间，含评审等待与环境准备

granularity_limit_days: 3 # 超过 3 天必须继续分解

资源层

owner_skill: backend-java # 技能标签，用于容量匹配

capacity_window: 2024-W10 # 容量核算所属周期

shared_projects: [P-A, P-B] # 共享该成员的项目列表

project_share: [0.6, 0.4] # 各项目分摊比例，合计不超过 1

治理层

change_log: enabled

bias_reason_code: null # 偏差归因码，延期关闭时必填

对应的工期计算规则可以写成下面这样，核心是把“工作量、投入率、日历、依赖”四个属性一起参与运算。

预计结束时间 = 工作日推进(
起点 = max(计划开始, 所有前置任务实际结束时间 + lag),

净工作量 = effort_hours,

每日可用 = 标准人日折算系数 × allocation_rate,

日历 = calendar_ref,

约束 = 前置任务依赖类型（FS/SS/FF/SF）

)

4. 数据结果：两个季度的连续统计

改造上线后，他们连续统计了两个季度。工期命中率从 41% 提升到 79%，延期任务占比从 37% 降到 14%。每周排期会时长从 96 分钟降到 38 分钟，因为大量争议在会前就被规则和字段数据解决了。

效率侧的改善也很明显：需求变更后的工期重算耗时从平均每次 4.5 小时降到 0.5 小时，因为不再需要人工逐个任务调整；偏差归因的追溯耗时从平均 3 小时降到 20 分钟，因为变更留痕直接给出了答案。

5. 上线后剩下的延期，才是真实的工程不确定性

改造后仍有 14% 的任务延期。我把这两个季度剩下的延期原因做了帕累托分析，结果很有意思：排在前面的变成了外部供应商交付延迟、需求范围变更、测试环境不可用这类外部依赖和真实工程不确定性，而原先占大头的口径与依赖问题，已经退出了前五位。

这说明改造达到的效果不是“消灭延期”，而是把延期从“管理噪声”还原成了“工程不确定性”。前者应该被制度和工具消除，后者应该被预留的缓冲覆盖。这两件事混在一起时，团队会浪费大量精力去解决本来就不该解决的问题。

6. 过程中踩过的三个坑

第一个坑是字段一次加太多。他们第一版加了 27 个字段，两周后填写率跌破 40%。后来砍到 14 个，其中必填只有 6 个，填写率回到 90% 以上。

第二个坑是依赖提醒发给项目经理。结果项目经理变成了人肉闹钟，每天转发几十条提醒，两周就崩了。改成直接提醒下游任务负责人之后，问题解决。

第三个坑是一开始把工期准确率和团队绩效挂钩，导致数据立刻变得“好看”。取消挂钩之后，数据才重新变得可用。这条经验我认为是所有团队都必须提前知道的。

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

没有一个方案适配所有团队。下面按规模给出差异化建议，这也是我在实际咨询中最常用的分档方式。

1. 20 到 50 人团队：先把口径层做扎实

这个规模下，沟通成本低，很多问题靠喊一嗓子就能解决，所以团队容易低估口径问题。但恰恰是规模小的时候，一旦人员流动，隐性共识就消失了。

建议动作：统一人日折算系数并写进文档；把工期和工作量拆成两个字段；规定工期超过 3 天必须分解；每周用 10 分钟在例会上对一次“本周工期调整了哪些、为什么”。

这个阶段不需要复杂的资源容量管理，一张共享的成员排期表就够了。关键是养成“工期变化必须说明原因”的习惯。

2. 50 到 150 人团队：结构和资源两层同时补

这个规模开始出现跨团队依赖和资源争抢，仅靠口径统一已经不够。典型症状是排期会上各部门都说自己没问题，但交付总是相互踩脚。

建议动作：补全依赖类型与滞后时间，把跨角色依赖设为必填；给核心角色建立可投入容量并按周期更新；建立跨项目的资源冲突视图，每周检查一次。工具上可以考虑支持自定义字段规则与依赖管理的研发管理平台，把计算和提醒固化下来。

这个阶段最容易犯的错是“规则写了但没人维护”。所以一定要指定一个角色负责属性质量，通常由 PMO 或项目集经理兼任。

3. 150 人以上组织：治理层决定成败

到了这个规模，瓶颈几乎一定从口径和结构转移到资源和治理。因为部门墙变厚，跨部门变更的协商成本急剧上升，没有留痕和归因机制，任何改进都无法证明有效。

建议动作：建立工期偏差归因码体系，延期关闭时必须选择原因；把变更留痕设为强制；季度做一次全组织的工期偏差复盘，按产品线对比。

对于研发数据有合规要求的中大型企业，部署方式也要一并考虑。这类组织通常需要私有化部署、需要历史数据可迁移、需要与现有权限体系打通。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，这两点对正在做国产替代或工具切换的组织是很实际的考量。

七、不同情况下的取舍

任务属性协同管理的本质是一系列取舍。我见过很多团队失败，不是因为不知道要做什么，而是因为在取舍上摇摆不定。

1. 精度与维护成本的取舍

属性字段不是越多越好，这一点我前面已经用案例证明了。他们的第一版 27 个字段导致填写率跌到 40%，砍到 14 个字段后回到 90% 以上。

我的经验拐点大约在 18 到 22 个必填加常用属性之间。低于这个区间，属性不足以支撑工期计算；超过这个区间，维护成本快速上升而工期命中率的改善几乎停滞。

2. 统一口径与团队自治的取舍

强制统一所有团队的口径，会让成熟度高的团队觉得被拖累；完全放开自治，则跨团队汇总永远对不上。我的建议是分层：口径层和组织级汇总强制统一，结构层给模板但允许扩展，资源层按业务线自治。

具体来说，人日折算系数、工期单位、完成定义这三项全组织一个标准，不允许例外。依赖类型和粒度上限给出推荐模板，允许团队按业务特点微调。容量管理和分摊比例由各业务线自行维护，只需在跨项目冲突时对齐。

3. 工具强约束与流程软约束的取舍

能算出结果的字段就不要让人填，能自动校验的规则就不要靠流程要求，这是我一贯的判断。但强约束的代价是灵活性下降，尤其会拖慢探索型工作的节奏。

一个实用的折中方案是：主流程强约束，探索型工作开专用工作项类型并豁免部分必填项。比如预研任务可以不填精确工期，但必须填写时间盒和产出目标。这样既保住了主流程的数据质量，又不至于让预研任务因为填不出工期而卡住。

4. 部署方式与协作效率的取舍

对于研发数据敏感、有内网隔离要求的中大型组织，私有化部署往往是硬性约束，代价是升级和运维需要额外投入。这个取舍没有通用答案，取决于合规等级和 IT 运维能力。

我的建议是：如果确实需要私有化，就尽早把数据迁移路径规划清楚，把历史任务的字段映射提前梳理，避免切换时出现工期数据断层。工期数据一旦断层，前面几个季度积累的偏差基线就要重新建立，成本很高。

5. 一次做全与分阶段推进的取舍

我的判断明确偏向分阶段。四层同时推进，团队会在两到三周内因为负担过重而放弃；按口径 → 结构 → 资源 → 治理的顺序推进，每层用两到四周达标再进下一层，成功率会高很多。

判断一层是否达标，可以用一个简单的标准：这一层的属性数据，在没有人专门催的情况下，连续两个迭代保持在 85% 以上的完整率。达不到就继续在这一层投入，不要着急往下走。

八、一页速查：任务属性协同管理的落地清单

把前面的内容收拢成一份可以直接拿去用的清单。我建议先做前六项，它们带来的收益占到全部收益的七成以上。

1. 统一人日折算系数，全组织只用一个数字，写进排期规范。
2. 把“工期”和“工作量”拆成两个独立字段，工期设为规则计算、禁止手填。
3. 为工期计算配置参照日历，包含法定假日、调休和公司统一假期。
4. 为每个成员维护周期性可投入容量，跨项目共享时强制填写分摊比例。
5. 跨角色任务必须标注依赖类型（FS/SS/FF/SF）与滞后时间。
6. 建立完成定义模板，未通过检查项不允许流转到已完成状态。
7. 设定粒度上限：单个任务工期不超过迭代周期的三分之一。
8. 开启属性变更留痕，延期关闭时必填偏差归因码。
9. 取消工期准确率与个人绩效的挂钩，改为考核偏差披露的及时性。
10. 每个迭代复盘基于属性数据，而非口头回忆。

关于工具选型，我的判断标准只有三条：能不能把工期做成计算字段、能不能表达四类依赖与滞后、能不能留下完整的属性变更历史。这三条不满足，再漂亮的可视化也解决不了工期问题。

对于 100 人以上的中大型研发组织，还要额外考虑部署方式和迁移成本。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，在国产替代场景下是可以纳入评估范围的一个选项。但选型之前，务必先确认自己的口径层是否已经统一，否则换任何工具都只是把混乱搬了个地方。

九、总结：工期是结果，属性协同才是原因

做项目管理这些年，我最大的一个认知转变是：不要再把工期当成一个需要“估准”的数字，而要把它当成一组属性协同计算出的结果。结果准不准，取决于输入属性的一致性和完整性，而不是估算那一刻的灵感。

214 个延期样本里只有 12% 归因于估算方法，这个数字对我冲击很大。它意味着绝大多数团队在错误的环节上反复投入：花时间比较三点估算和扑克牌估算哪个更准，却没有花时间确认两个人说的“5 天”是不是同一件事。

另一个我坚持的判断是：任务属性协同的推进顺序不能颠倒。口径层没统一就去做资源容量管理，做出来的是噪声；结构层没建对就去做治理留痕，留下的是无法归因的记录。先把口径 → 结构 → 资源 → 治理这条路走完，再谈精度提升，才是最省力的路径。

最后提醒一句关于数据的判断：不要把工期准确率和绩效挂钩。这个动作会让数据在两周内变得“好看”，同时永久失去改进价值。工期数据要用来改流程，就不能同时用来评价人。如果一定要考核，考核“偏差是否被及时披露和调整”，这才是可观测、可改进、不易被操纵的指标。

下一步怎么做？如果你现在就想动手，我建议从三个动作开始，一周内就能看到变化。第一，把团队里关于“工期”的字段全部拉出来，看有几个、叫什么名字、单位是什么，这一步通常就能发现问题。第二，挑两个已经完成的迭代，用统一口径重算一遍工期，把新旧数字对比贴在例会上。第三，把工期字段改成计算字段，禁止手填。做完这三步，再谈依赖和资源，节奏会顺很多。