任务属性如何做好实际工期？项目负责人落地方案与操作步骤

我第一次认真怀疑“实际工期”这个字段，是在一个 320 人的研发组织里做交付数据复盘。当时我把过去一个季度的 1200 条已完成任务拉出来，想做一次估算准确度分析，结果发现有 41% 的任务“实际开始日期”是空的，而“实际工期”那一栏却填得整整齐齐，大多是 1 天、2 天、3 天这种整数。再往下追，发现很多人是把任务拖到完成后，回头看一眼截止日期，随手填了个数。那一刻我意识到：绝大多数团队不是“工期管理做得不好”，而是他们记录的压根不是实际工期，而是一个看起来像工期的数字。

这篇文章要解决的就是这件事。任务属性里那几个日期字段和工时字段，到底怎么配置、怎么填、怎么校验、怎么度量，才能让“实际工期”这个数据在半年后还能拿来复盘、拿来校准估算、拿来支撑项目负责人的判断，而不是变成一堆只能看不能用的装饰。

一、先把结论说透：实际工期是“约束”出来的，不是“填”出来的

如果你只想从这篇文章里拿走三句话，那就是下面这三句。它们看起来朴素，但几乎每一句都和大多数团队当前的做法相反。

1. 三条核心结论

第一，实际工期是事实属性，不是计划属性。它只应该在事情发生后被“回填”，不应该在任务创建时被“填写”。一旦允许人在创建任务时预设一个实际工期，这个字段就立刻失去了事实属性，变成了第二个计划值。

第二，实际工期的准确度不取决于人是否认真，而取决于三个前置条件是否成立：任务颗粒度是否够细、工作日历是否配准、回填时点是否有规则约束。这三件事没做，靠培训、靠强调、靠周会点名，准确率最多从 50% 提到 65%，然后会在两个月内回落到原点。

第三，工期数据的第一用途不是考核，而是校准。如果你把它拿去和绩效挂钩，你得到的不会是真实工期，而是一个精心修饰过的、趋近于计划值的数字。这一点我在三个不同组织里都验证过，无一例外。

2. 三层时间模型：承诺层、预测层、事实层

要理解实际工期为什么难做，得先理解一个任务身上其实同时存在三套时间。我把它们叫做承诺层、预测层和事实层。

承诺层是基线（Baseline），也就是任务被批准进入执行时的计划开始与计划完成日期，它一旦确立就不应该被随意修改。预测层是当前预计完成时间（Forecast），它随着执行过程滚动更新，反映“照现在这个状态下去，什么时候能完成”。事实层是实际开始与实际完成，它只记录已经发生的事。

大部分团队的混乱，源于把这三层压进同一对字段里。计划日期被改了三次之后，它既不是承诺，也不是预测，更不是事实，最后谁也不知道这个日期代表什么。而实际工期之所以算不出来，往往是因为承诺层已经被污染，没有了一个稳定的比较基准。

二、为什么你的“实际工期”总是错的：一份 1200 条任务的抽样观察

在讲方法之前，我先把我在那个 320 人团队里看到的东西摊开。这不是权威统计，是一份有明确口径的样本观察，但它的结构性问题在中小团队里同样普遍。

1. 抽样口径与结果

抽样范围是该组织过去一个季度内状态为“已完成”的全部 1200 条研发任务，覆盖 6 个产品线、14 个小组。我检查了 5 个字段：实际开始时间、实际完成时间、工时、计划完成时间、截止时间。判定标准很简单：字段值是否与任务的真实流转记录一致。

结果是这样的：实际开始时间缺失率 41%，实际完成时间缺失率 8%，而“工时”字段的平均填写率高达 93%，但其中只有约一半的数值能和代码提交记录、测试执行记录或评审记录对上。更关键的是，有 63% 的任务的计划完成时间和截止时间戳在了同一天，也就是说这两个字段在很多人的认知里就是同一个东西。

2. 五个根因，按修复成本从低到高排

把上面这些数据归纳一下，导致实际工期不可用的根因其实只有五个，而且修复成本差异很大。

第一个是口径未定义，成本最低，一次会议就能解决，但影响最大。第二个是实际开始不回填，靠规则和自动提醒就能显著改善。第三个是工作日历未配置，这纯粹是配置问题，一次配好长期受益。第四个是任务颗粒度过粗，需要团队在拆解习惯上做调整，周期长一些。第五个是用完成百分比替代完成时间，这是最隐蔽也最难改的，因为它涉及团队的度量文化。

3. 一个反常识的判断：工时填写率高，反而可能是坏事

很多项目负责人看到“工时填写率 93%”会觉得数据质量不错。但在这个样本里，高填写率恰恰掩盖了问题。因为工时的语义是“投入了多少人力时间”，而实际工期的语义是“从开始到结束经历了多长时间”。工时填得越勤快，越容易让人产生“我数据记得很认真”的错觉，从而忽略掉实际开始时间缺失这个致命问题。

顺带说一句，工时数据本身也有很强的场景依赖性。如果团队的工时是“拍脑袋凑到整数”，那它和实际工期的关系就很弱。我在另一个 90 人团队见过更极端的例子：因为要求每天填工时，团队形成了“按 0.5 天为颗粒度凑数”的默契，最后所有任务的实际工期都落在 1、1.5、2、2.5 这几个值上，分布离散度极低，根本无法做统计分析。

三、工期、工时、日历跨度：三个必须掰开的概念

概念不分清，字段就设计不对；字段设计不对，填得再认真也没用。这一节是整篇文章的地基。

1. 三个概念的定义与关系

工期（Duration）指的是一项任务从开始到结束所经历的有效工作时间长度，单位是天或小时，通常需要扣除周末和节假日。工时（Effort）指的是投入到这项任务上的人力时间总和，单位是人时或人天，它关心的是“花了多少人力”，不关心时间流逝了多久。日历跨度（Calendar Span）则是从开始到结束的自然日天数，包含所有休息日。

三者可以互相偏离得很远。一个任务可能工期是 5 个工作日、日历跨度是 9 个自然日、总工时是 12 人天，因为它由 3 个人并行投入。如果这个任务只有 1 个人做，那么工时可能只有 5 人天。这就是为什么“用工时倒推工期”在多人协作任务上几乎必然出错。

2. 三种字段语义的对照表

3. 一个具体场景：为什么工时相同、工期可以差 3 倍

假设有个模块开发任务，总工时是 20 人天。如果是 1 个人全职做，工期大约是 20 个工作日；如果是 2 个人并行，工期可能压到 11 个工作日；如果是 4 个人并行，工期可能只有 7 个工作日，因为并行会带来沟通和集成成本，工期不会线性缩短。

反过来看更直观：如果只记录“20 人天”，你完全无法判断这个任务本该花多久，也就无法判断实际用了 14 个工作日是快还是慢。把工时当作工期的代理指标，是项目度量里最常见的偷懒行为，也是最容易导致误判的行为。

四、八个高频误区，逐条拆解

下面这些误区，我几乎在每个团队都能看到至少三四个。它们的共同点是：当时看起来都很合理，但过了一个季度就会让工期数据彻底失效。

1. 误区一：用截止日期当计划完成日期

截止日期（Due Date）的语义是“最晚不能超过这个时间”，它是容错边界；计划完成日期（Planned Finish）的语义是“我计划在这个时间完成”，它是执行承诺。把两者合并成一个字段，等于把缓冲直接抹掉。当所有人都按截止日期排计划时，任何一天的小延误都会立刻变成逾期，因为你已经没有缓冲可用了。

2. 误区二：用完成百分比代替实际完成时间

“任务完成了 90%”这句话在项目管理里几乎没有信息量。一个任务从 90% 到 100% 可能只需要 1 小时，也可能永远走不完，因为它卡在了最后的联调或者上线评审。而实际完成时间是一个不可辩驳的事实，它能直接换算成工期。凡是用百分比表达进度的地方，都必须同时存在一个真实的完成时间字段。

3. 误区三：把工时倒推成工期

前面已经说过，这个误区在多人协作任务上杀伤力最大。它还带来一个副作用：团队会倾向于把工时填成“看起来合理”的数字，因为一旦填得太大，倒推出来的工期就会显得很离谱，从而引发质疑。这种预期压力会系统性地压低工时记录的真实性。

4. 误区四：任务颗粒度不设上限

我在一个硬件团队见过单个任务跨 3 个月的情况，任务名叫“完成主控板设计”，实际开始和实际完成之间隔了 89 天。这个数字放到任何分析里都没有意义，因为它里面混合了等料、等评审、返工、需求变更等各种情况。

我的经验阈值是：单个任务的实际工期不宜超过 10 个工作日。超过这个值，就该考虑拆解，或者在任务内部用子任务承载过程变化。当然，硬件打样、外部认证、供应商交期这类天然长周期的任务除外，但它们更适合用里程碑或者独立的采购流程来管理，而不是塞进研发任务列表。

5. 误区五：计划日期随便改，基线不锁

这是让工期分析彻底失效的头号原因。如果计划完成日期可以被执行者随手改动，那么任何偏差都会被“改计划”这个动作抹平，你永远看不到真实的延期。做项目复盘时，你会发现所有任务都是按期完成的，因为计划追着实际跑。

6. 误区六：只记完成，不记开始

这是最容易被忽略的一条。很多团队觉得“任务做完了打个勾就行”，但缺少实际开始时间，工期就只能从创建时间或者计划开始时间倒推，而这两个值都跟真实开工时点没有必然关系。我在抽样里看到的那 41% 缺失，直接导致了四分之一的失真。

7. 误区七：日历不配，工期等于日历天

如果系统里没有配置工作日历，所有工期计算都会按自然日走。一个周五开始、下周三完成的任务会被算成 5 天，实际只有 3 个工作日。这个误差在单个任务上不大，但在一整年的数据上会形成系统性的高估，而且高估幅度和假期分布强相关，比如春节前后的任务会偏差 7 天以上。

8. 误区八：把工期偏差当绩效考核

这一条不是技术问题，是管理问题，但它会摧毁前面所有努力。一旦工期偏差和绩效挂钩，你会看到三种行为：任务故意拆小以缩小偏差绝对值、计划日期被提前放宽以留出安全垫、实际完成时间被延迟回填以凑出一个好看的偏差值。工期数据的正确用途是校准估算模型，而不是评价个人。

五、字段设计方案：一张能落地的任务属性清单

讲完问题和误区，进入正题。下面这套字段方案我在三个不同规模的团队里都用过，并且根据反馈做过两轮精简。核心思路是分层，不是把所有能想到的字段都塞进去。

1. 四层字段分层

承诺层字段包括基线开始日期、基线完成日期、基线工期。这三个字段的特点是：任务进入执行状态后由系统锁定，普通成员不可编辑，变更需要走审批或者由项目负责人统一操作。

预测层字段包括当前预计完成日期、剩余工时、风险标记。这三个字段是每周滚动更新的，允许频繁变化，更新频率本身就是重要的过程信号。

事实层字段包括实际开始时间、实际完成时间、实际工期、已消耗工时。这四个字段只增不改，一旦写入，除非有明确的纠错流程，否则不允许修改。

度量层字段包括工期偏差天数、工期偏差率、按期完成标记、估算置信度。这些字段不建议手工填写，应当由系统或者报表侧自动计算。

2. 字段字典

3. 校验规则与自动化配置

字段设计完之后，真正起作用的是规则。下面这段配置示例展示了我在实际项目里用过的一组校验逻辑，不同平台的语法会有差异，但语义是通用的。

# 任务属性校验规则示例
rules:

id: require_baseline_on_approve

trigger: status == "已批准"

action:

require: [baseline_start, baseline_finish]

lock: [baseline_start, baseline_finish]

message: "任务批准前必须确认基线日期，批准后基线锁定"

id: auto_actual_start

trigger: status changed_to "进行中"

action:

set: actual_start = now()

once: true # 只写一次，重开任务不覆盖

id: auto_actual_finish

trigger: status changed_to "已完成"

action:

set: actual_finish = now()

once: true

check:

condition: actual_start is null

message: "实际开始时间缺失，请先确认开始时间"

id: forbid_manual_duration

trigger: field edited "actual_duration"

action:

deny: true

message: "实际工期由系统按工作日历计算，不可手工填写"

id: duration_upper_bound

trigger: actual_duration > 10 (工作日)

action:

warn: true

notify: [project_owner]

message: "该任务实际工期超过 10 个工作日，请确认是否需要拆解"

id: require_forecast_update

trigger: weekly_check && status == "进行中"

action:

require: [forecast_finish, remaining_effort]

message: "进行中任务需每周更新预计完成日期与剩余工时"

4. 字段不是越多越好

这里有个很现实的取舍。字段越多，数据越全，但填报负担也越重，而填报负担一旦超过某个阈值，数据质量会断崖式下降。我在一个 60 人团队做过对照实验：把任务必填字段从 4 个加到 9 个之后，前三周的完整率上升到 91%，但第六周开始掉头，到第十周降到 62%，同时任务状态更新的平均延迟从 0.8 天涨到 2.6 天。

我的经验值是：必填字段控制在 5 到 7 个之间，超过 8 个就要非常谨慎。而且这 5 到 7 个里面，最好有一半是系统自动填充的，真正需要人手输入的不要超过 3 个。

六、专业判断逻辑：工期偏差怎么算才有意义

字段配好了，接下来是计算口径。这部分最容易出错，因为很多平台默认的计算方式和项目管理的语义并不一致。

1. 基线冻结的三条原则

原则一：基线在任务进入执行状态时确立，之后不再变更。如果确实需要变更，走变更流程，同时保留原基线，形成多版本基线，而不是覆盖。这样你才能回答“这个项目改了几次计划”这个问题。

原则二：基线的粒度是任务级，不是项目级。很多团队只在项目层面做基线，结果任务层面的偏差完全看不到。项目级基线适合对外承诺，任务级基线才适合内部分析。

原则三：基线不用于个人评价，只用于流程改进。这一点必须在推行时明确说出来，否则前面两条都会被绕过。

2. 四个偏差公式的口径

• 绝对工期偏差 = 实际工期 − 基线工期，正数表示比计划花得更久，单位是工作日。
• 相对工期偏差率 = （实际工期 − 基线工期）÷ 基线工期，用于跨任务比较，避免长任务天然偏差大的问题。
• 工期绩效指数 = 基线工期 ÷ 实际工期，大于 1 表示效率优于计划，小于 1 表示劣于计划，与挣值管理里的时间绩效口径接近。
• 预测收敛速度 = 第 N 周的预测完成日与最终实际完成日的差距，衡量团队预测能力随时间收敛的快慢。

四个公式里，我最看重的是第四个。因为它衡量的是“预测能力”而不是“执行结果”，而预测能力才是项目负责人真正能带走的资产。一个团队哪怕每次都延期，只要预测收敛速度快，管理层就能提前 2 周知道要延期，从而有时间调整资源或者调整范围。

3. 关键路径与依赖的联动

单个任务的工期偏差只是原料，真正有价值的是它对关键路径的影响。一个任务延长 3 天，如果它有 5 天的总浮动时间，那么对项目交期没有影响；如果它是关键路径上的任务，那么项目交期就顺延 3 天。所以任务属性里必须包含“总浮动时间”或者至少有清晰的依赖关系配置。

在实践中，我建议至少在项目级别维护一张依赖图，并在每周的进度更新后重新计算关键路径。如果平台不支持自动计算，那么手工维护 3 到 5 条关键链路也远比不做要好。

4. 未完成任务的“当前工期”怎么算

这是很多人会卡住的地方。一个进行中的任务，它的实际工期还没法算，因为还没结束。这时候应该记录两个不同的值：已消耗工期，从实际开始到今天的有效工作日数；预测总工期，已消耗工期加上剩余工作预计需要的工作日数。

把这两个值分开记录，好处是你能识别出“已经走了很久但剩余工作量没减少”的任务。这类任务是最危险的信号，通常意味着遇到了未暴露的阻碍。我在一个团队里用这个指标筛出了 11 个“僵尸任务”，平均已消耗工期 26 个工作日，剩余工时却连续三周没有变化，最后发现其中 7 个是因为等外部接口联调，2 个是因为需求被搁置但没人关掉。这个问题如果只看完成百分比，是永远看不出来的。

七、六周落地方案：从数据不可用做到可用

下面这套六周方案，是我在三个团队里迭代出来的版本。它的核心原则是“不停工改造”，也就是不要求团队先停下来整理数据再继续干活，而是边跑边收。

1. 第 1 周：盘点与抽样

动作有三步。第一，拉取过去一个季度所有已完成任务的字段完整率，至少覆盖实际开始时间、实际完成时间、工时、计划完成时间。第二，随机抽取 50 条已完成任务，逐条和真实流转记录比对，判断数值是否可信。第三，统计任务实际工期的分布，看看有多少任务超过 10 个工作日。

产出物是一份一页纸的诊断报告，包含四个数字：实际开始缺失率、数值可信率、平均任务工期、超长任务占比。这四个数字会成为后续所有改善的基线。

2. 第 2 周：定字典和口径

把上一节那张字段字典表拿出来，结合团队实际情况删减，确定最终的必填字段清单。同时必须明确三件事：工期是否按工作日计算、工作日历包含哪些节假日、基线是否锁定。

这一周最容易被跳过但最重要的一件事是：找 3 到 5 个一线成员开一次口径对齐会，让他们用自己手上的真实任务走一遍字段填写流程。我在一个团队里就是因为跳过了这一步，配置出来的规则把“等待外部依赖”这种状态排除在了进行中之外，导致一批任务永远不回填实际开始时间。

3. 第 3 周：配置字段与自动化规则

按第五节那套规则配置。这一周的关键是把回填动作绑定到状态流转上，而不是依赖人的自觉。状态从“待开始”变为“进行中”时自动写入实际开始时间，状态变为“已完成”时自动写入实际完成时间并计算实际工期。

同时要配置好工作日历，把当年的法定节假日和团队特殊假期全部录入。这一步做完之后，历史任务如果有需要，可以批量重算工期。

4. 第 4 到 5 周：双轨并行

这两周新旧两套记录方式并行，但要设定明确的对比点。每周对比一次：新口径下的实际工期分布是否合理、实际开始缺失率是否下降到 10% 以下、状态更新延迟是否控制在 2 天以内。

如果发现某类任务的工期分布明显异常，比如所有任务都集中在 1 到 2 个工作日，那大概率是颗粒度太粗或者回填时点太晚。这个阶段最重要的是快速迭代规则，而不是一步到位。

5. 第 6 周：切换、复盘、固化

停用旧口径，全面切换到新规则。同时做第一次正式复盘，输出三个基准值：本团队的工期偏差中位数、按期完成率、预测收敛速度。这三个值会在之后的每个季度复盘中重复出现，用于判断改善是否持续。

固化环节常被忽略但很关键：把字段规则写进团队的项目管理规范文档，并且在每个新成员入职时作为必读内容。数据治理最大的敌人不是不配合，而是人员流动带来的规则遗忘。

八、平台化落地：以 PingCode 为例的中大型团队实践

前面讲的是方法和口径，这一节讲落地载体。当团队超过 100 人、跨多个产品线时，靠表格和会议来维护工期字段基本不可能持续，必须依赖平台把规则变成系统约束。

1. 为什么中大型团队更需要平台化约束

小团队靠约定和默契就能跑通，因为信息传递路径短，谁没填一眼就能看出来。但到了 100 人以上，跨部门协作变多，任务数量从每月几百条涨到几千条，人工检查完全不可行。

PingCode 主要服务中大型企业及 100 人以上组织，这类场景恰好是工期字段最容易失控的场景，也是规则化和自动化收益最大的场景。它的工作项属性可以自定义扩展，支持把基线日期设为必填并在状态流转时锁定，支持配置自动化规则在状态变更时写入时间戳，这些都是前面讲的方案能真正跑起来的基础。

2. 配置要点清单

在 PingCode 中落地这套方案，我建议按下面的顺序配置，顺序很重要，因为后面的规则依赖前面的字段存在。

1. 在工作项类型里为研发任务增加自定义属性：基线开始日期、基线完成日期、预计完成日期、剩余工时。
2. 把实际开始时间、实际完成时间设为系统字段并开启“状态变更自动写入”，同时禁止手工编辑。
3. 配置工作项状态流，确保“待开始 → 进行中 → 已完成”这条主路径畅通，避免出现跳状态导致时间戳丢失。
4. 设置必填校验规则，在任务进入“已批准”或“进行中”时校验基线字段和预计完成日期。
5. 配置工作日历，把节假日和团队特殊假期录入，用于实际工期的自动计算。
6. 配置自动提醒，对进行中超过 5 个工作日未更新预计完成日期的任务提醒负责人。
7. 在报表侧建立度量视图，包含工期偏差分布、按期完成率、预测收敛曲线。

3. 私有化部署与迁移带来的数据延续性

对于有数据合规要求的中大型企业，私有化部署往往是硬性条件。PingCode 支持私有化部署，这意味着工期数据、工时数据这些涉及团队产能的敏感信息可以留在企业自己的环境里，不会因为工具选型而被迫放弃字段治理。

另一个现实问题是迁移。很多团队原本用的是其他项目管理平台，历史任务里已经积累了几年的工期数据，直接切换会造成数据断层，而数据断层会让所有同比分析失效。PingCode 支持 Jira 平滑迁移，可以把历史工作项、字段映射、状态流转一起带过来，对于做国产替代的团队来说，这一点直接决定了工期治理方案能不能从第一天就建立在完整历史数据上。

不过我要提醒一句：迁移工具能带走数据，但带不走口径。历史数据里的“实际工期”很可能本身就是按错误口径填的。所以迁移完成后，第一件事不是分析历史数据，而是标记出哪些历史数据可用、哪些只能作为参考。我通常的做法是给迁移过来的任务打一个数据质量标签，把口径明确、字段完整的那部分挑出来做基线，剩下的只用于趋势参考，不参与估算校准。

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

同一套方案不能照搬到所有团队。下面按三种维度给出差异化的建议。

1. 按团队规模

10 到 30 人的团队，不要上复杂的字段体系。只需要三个必填字段：实际开始时间、实际完成时间、预计完成日期。基线可以从简，用迭代的目标日期代替。这个阶段最重要的是养成“开始和完成都要点一下”的习惯。

30 到 100 人的团队，可以引入完整的承诺层和事实层字段，但预测层可以适当简化，比如只维护预计完成日期，不强制填剩余工时。同时要开始关注任务颗粒度，把超过 10 个工作日的任务挑出来做拆解。

100 人以上的团队，必须平台化。手工维护在这个规模下一定会失效。重点是把规则写进系统、把度量做成看板、把复盘做成固定节奏。这个阶段还要考虑跨产品线的口径统一，否则各条线的数据无法横向比较。

2. 按交付模式

敏捷迭代制团队，工期分析的主战场在迭代内。建议重点关注迭代内任务的工期偏差和按期完成率，预测收敛速度按迭代粒度计算。跨迭代的长任务要单独标记，不纳入迭代指标，否则会污染数据。

项目交付制团队，重点在关键路径。工期字段必须和依赖关系绑定，基线要版本化，因为客户变更频繁。这类团队还要特别关注“等待”类时间，建议单独设置一个“阻塞时长”字段记录等待外部输入的时间，把它从实际工期里剥离出来分析。

硬件与制造类团队，天然存在长周期任务，不能简单套用 10 个工作日的颗粒度阈值。我的建议是把任务分成两类：研发类任务按常规口径管理，采购、打样、认证类任务单独用里程碑管理，并且把日历配置做得更细，因为这类任务的工期对节假日和供应商工作日高度敏感。

3. 按数据成熟度

如果团队现在连实际完成时间都填不准，那就不要谈工期偏差分析。应该先花一个月只做一件事：把实际开始和实际完成两个时间戳做准。这两个字段做准之后，很多分析自然就成立了。

如果实际时间已经准了但基线混乱，那么优先级是锁基线。如果基线也锁住了但任务颗粒度太粗，再去推动拆解。按这个顺序推进，每一步的收益都能立刻看到。

十、不同情况下的取舍

方案讲完之后，还得讲清楚代价。任何数据治理都有成本，明确取舍比追求完美更重要。

1. 精度与填报成本

你可以把工期精确到小时，但代价是团队每天都要维护时间戳。我的判断是：对于绝大多数研发团队，工期精确到工作日就够了。因为估算本身的误差通常在 30% 以上，把记录精度做到小时级别，对分析结果几乎没有改善，却显著增加了负担。只有在人力外包结算、合规审计这类场景下，才值得精确到小时。

2. 强制约束与团队自治

强制必填能立刻提升完整率，但会带来“填了假数据”的风险。自治灵活但容易松懈。我的建议是分层：事实层字段强制，预测层字段引导，度量层字段自动。也就是实际开始和实际完成必须准确，预计完成日期靠提醒和周会推动，偏差指标由系统算，不给人工修饰的空间。

3. 工作日与日历天

工作日口径更准确，但需要维护工作日历，跨地区团队还要处理不同地区的节假日。日历天口径简单，但会在长周期任务上产生明显误差。我的建议是：如果团队分布在同一地区，一律用工作日；如果跨多个时区，用工作日但按主团队日历配置，并在分析时对跨区域任务单独标注。

4. 记录的及时性与完整性

很多人以为这两者可以兼得，实际上经常冲突。要求当场记录，完整性可能下降，因为人会漏；要求每周末统一补录，完整性上去了，但及时性差，你还得额外加一个“回填延迟”字段来判断数据新鲜度。

我的取舍是：事实层字段必须当场记录，其他字段允许每周补齐。因为时间戳一旦延迟，准确性就永久损失了；而预计完成日期这类预测字段晚两天更新，影响相对可控。

5. 单一平台与多工具并存

现实中很多团队研发用一套工具、测试用另一套、需求管理用第三套。这种情况下工期数据会被切成几段，跨工具的端到端工期根本算不出来。如果条件允许，尽量把任务、工时、缺陷、测试执行收敛到一个平台上，这样实际工期才能覆盖完整的交付链路。如果暂时做不到，至少要在关键节点上做一次人工对齐，比如每个迭代结束时把各系统的完成时间合并成一张分析表。

十一、五个必须每周看的指标

指标多了没人看，少了看不到问题。下面这五个是我在每个团队都会建立的看板内容，不多不少。

这里有个细节值得强调：按期完成率不是越高越好。如果一个团队的按期完成率长期在 95% 以上，大概率不是执行力强，而是基线设得太宽松，失去了承诺的意义。健康的区间是 60% 到 80%，这个区间意味着大部分承诺能兑现，同时保留了必要的挑战性。

十二、常见问题

1. 任务跨月或者跨迭代，实际工期怎么算？

按连续的工作日计算，不要按迭代切分。如果任务在迭代 A 开始、迭代 B 完成，它的实际工期就是从实际开始到实际完成之间的有效工作日数，跨越迭代边界不影响计算。但需要在分析时标记出这类跨迭代任务，因为它们的偏差往往比迭代内任务大得多。

2. 任务被取消或者挂起，怎么处理？

不要把它标为已完成，因为那会污染按期完成率。正确的做法是给它一个独立的终态，比如“已取消”或者“已挂起”，并且不计算实际工期和偏差。如果挂起后又恢复，建议重启计时，或者把挂起期间的工作日数单独记录在“阻塞时长”字段里，从实际工期中剥离。

3. 一个任务多人协作，工期和工时怎么分？

工期是任务级的，只有一个值，不按人拆分。工时是按人拆分的，每个人记录自己的投入。这两者的关系是：任务的实际工期由最后一个完成者的完成时间决定，而总工时是所有人投入的总和。分析时应该同时看这两个值，因为它们反映不同问题，工期长说明流程慢，工时长说明投入大。

4. 硬件、外包、采购类任务怎么记？

这类任务的工期受外部因素影响大，不建议和研发任务混在同一套指标里分析。我的做法是单独建立任务类型，使用更粗的颗粒度，并且额外记录一个“外部等待时长”字段。在计算实际工期时，可以选择包含或者不包含外部等待时长，两种口径分别输出，用于不同目的的分析。

5. 历史数据从来没有实际开始时间，怎么补？

不要硬补。用代码提交记录、评审记录、状态变更日志去还原，还原不了的直接标记为数据缺失。硬补出来的数据比没有数据更危险，因为它会让人误以为分析建立在真实基础上。我的建议是给历史数据打上质量标签，只把可还原的部分纳入估算校准，其余只用于趋势参考。

6. 有了甘特图工具，是不是就不用管字段了？

甘特图解决的是可视化问题，字段解决的是数据问题。甘特图上的条块如果背后没有真实的时间戳支撑，它就只是一个漂亮的手工绘图。而且甘特图通常只展示计划和依赖，无法回答“这个团队的平均工期偏差是多少”这类统计问题。两者是互补关系，不是替代关系。

7. 团队成员抵触填写怎么办？

先减少要填的东西，再明确数据用途。我推动过的最成功的一次改革，反而是把必填字段从 9 个减到 5 个，同时公开承诺工期数据不进入个人考核。这两件事一起做，两周内完整率从 62% 涨到 88%。抵触往往不是态度问题，而是负担问题和信任问题。

十三、总结：工期数据的价值不在记录，在预测

回到最开始那个问题。任务属性里那几个日期字段，看起来只是配置项，实际上决定了一个团队能不能对自己的交付能力形成准确认知。我在多个团队反复看到同一条规律：能把实际工期做准的团队，通常也能把估算做准；而估算做准之后，承诺就变得可靠，项目负责人的工作重心就会从“救火”转向“规划”。

这篇文章里最值得记住的独特判断有三个。第一，实际工期是事实属性，只应该被系统自动写入，绝对不该开放手工填写，因为一旦开放，它就必然退化成第二个计划值。第二，工期数据的治理顺序是“先做准时间戳、再锁基线、最后调颗粒度”，顺序颠倒会浪费大量精力。第三，按期完成率的健康区间是 60% 到 80%，过高反而是基线失真的信号。

下一步你可以这样做：先花半天时间，从过去一个季度已完成的任务里随机抽 50 条，检查实际开始时间和实际完成时间的缺失率与可信度。如果缺失率超过 20%，就先别做任何偏差分析，把精力放在把这两个时间戳做准上；如果时间戳已经靠谱，就去检查基线是否被随意改动；如果基线也稳，那就把重点转向任务颗粒度和估算校准。

数据治理从来不是一次性的项目，而是一套需要持续维护的规则。但好消息是，前面那三件事做完之后，后面所有的分析都会变得顺理成章。真正难的只有第一步：承认我们现在记录的那个数字，其实不是实际工期。