任务属性如何做好实际工期？跨部门团队落地方案与操作步骤

去年第三季度，我帮一家做智能硬件的公司做研发流程诊断。项目经理给我看了一张表：同一个跨部门的固件联调任务，硬件团队填的工期是 11 天，嵌入式团队填的是 6 天，测试团队填的是 3 天，而项目复盘时从系统状态日志里拉出来的真实跨度是 26 天。三个部门都没有说谎，他们只是各自在用不同的口径记录“工期”。硬件算的是从出图到打样回来，嵌入式算的是从写完代码到自测通过，测试算的是从拿到样机到出报告；

中间那些等物料、等确认、等环境、返工重测的时间，谁的账本里都没有。

我把这类问题叫做“工期口径黑洞”。过去三年我在 8 个跨部门团队（规模从 30 人到 400 人）做过类似的流程改造，结论高度一致：跨部门团队做不好实际工期，绝大多数不是执行力问题，而是任务属性没有定义清楚。工期不是一个需要人去“填准”的数字，而是一个应该由任务属性、状态迁移和依赖关系自动推导出来的结果。这篇文章会把我的判断逻辑、落地步骤和真实数据完整拆开讲，包括我在几个团队里踩过的坑。

一、核心结论：先分清口径，再谈准确

先把最关键的判断放在前面。如果你只想从这篇文章里拿走一句话，那就是：在跨部门团队里，实际工期的准确性不是靠人填出来的，而是靠任务属性算出来的；凡是依赖人工回填的工期数据，半年内一定会重新失真。

1. 三个必须先分开的工期口径

大部分团队的混乱，从“工期”这个词本身就没定义清楚开始。我在做流程诊断时，会强制要求团队先把三个概念分开，并且要求所有系统字段、报表、周会口径都严格对应其中之一。

• 承诺工期：任务责任人在接到任务时，向上下游承诺的完成天数。它本质上是一个契约，用于对齐期望。
• 计划工期：排期后系统计算出的工期，包含前后置依赖、资源可用性、节假日日历。它反映的是“理论上什么时候能做”。
• 实际工期：从任务首次进入“进行中”状态，到最终进入“已完成”状态之间的真实日历跨度，包含等待、阻塞、返工、审批排队等全部时间。

这三个数字正常情况下应该各不相同。承诺工期短于计划工期，说明承诺过于乐观；实际工期远长于计划工期，说明排期没有把等待和阻塞算进去。当一个团队只维护一个“工期”字段时，这三个概念会被压缩成一个数字，任何复盘都会变成互相甩锅。

2. 实际工期是“算”出来的，不是“填”出来的

手工填写的工期数据有两个致命缺陷：一是它记录的是“我感觉花了多久”，而不是系统记录的客观跨度；二是它无法拆分构成，你不知道多出来的 10 天里，有多少是等上游、有多少是返工、有多少是纯粹排队。

正确的做法是把工期变成派生字段。系统只要记录了状态迁移时间戳、阻塞标记和依赖关系，就能自动算出实际工期、有效工期和阻塞时长。人只需要对“阻塞原因”做一次分类选择，其余全部自动生成。这样做的好处是，工期数据的可信度不再依赖填写者的自觉性。

3. 跨部门场景的三个硬约束

跨部门团队比单部门团队多了三个约束，这也是通用模板往往失效的原因：第一，口径不同源，硬件按周报进度、软件按迭代、测试按批次；第二，依赖跨系统，上游任务可能在另一个团队甚至另一个平台里；第三，责任边界模糊，一个任务卡住时，界定“谁的锅”比修复它更费时间。

因此跨部门团队的属性设计，目标不是“记录得更细”，而是让偏差可归因。我不追求工期预测 100% 准确，我追求的是：当偏差发生时，团队能在 30 分钟内说清楚偏差由哪几段构成、责任在哪个环节。

二、背景与真实场景：工期是在哪里丢掉的

要设计属性，先要知道偏差从哪来。我在 2023 年统计过三个跨部门团队共 1,142 个跨部门任务的工期构成，结论和我原本的猜测并不完全一致。

1. 三类跨部门协作形态，工期失真方式完全不同

第一类是阶段型协作，比如硬件出图到打样、软件提测到上线，特点是严格串行，工期失真的主因是等待和交接。这类团队的问题是“交接无记录”，上一环节说“已交付”，下一环节说“没收到”，中间能空转好几天。

第二类是交付型协作，比如产品、设计、研发、测试围绕一个功能版本推进，特点是部分并行、频繁返工。这类团队的工期失真主因是需求中途变更，一个字段没锁住，整个链路重来一遍。

第三类是支撑型协作，比如安全评审、合规审批、运维发布，特点是流程节点多、审批链长。这类团队的问题不是执行慢，而是排队久，一个任务实际动手可能只有 2 小时，但排队排了 5 天。

三类形态对应三套完全不同的属性重点。用一套模板套所有团队，是我见过最常见的失败原因。

2. 口径不一致在系统里的五种表现

这五种表现里，杀伤力最大的是第五种。我见过一个团队，季度复盘中显示某类任务平均工期 14 天，看起来效率极低。加上阻塞标记重新统计后，有效工期只有 5.5 天，剩下 8.5 天全在等一个外部供应商的固件授权。没有阻塞标记，团队会长期为一个不属于自己的问题背锅，然后逐渐不信任工期数据。

3. 我的数据观察：偏差主要发生在哪里

在那 1,142 个任务的样本里，我把每个任务的工期构成拆成有效工作时间、等待上游时间、返工重做时间、审批排队时间和资源被抢占时间。结果如下：等待上游交付占 34%，需求中途变更导致的返工占 24%，返工重做（非变更原因）占 18%，审批排队占 12%，资源抢占占 8%，其他占 4%。

这份数据最重要的启示是：排名前三的偏差来源全部是“跨部门链接问题”，而不是个人效率问题。这也解释了为什么单纯做个人工时统计、做加班分析，对跨部门工期几乎无效，偏差压根不在那里。

三、拆解五个常见误区

下面五个误区，我在几乎所有跨部门团队里都见过至少三个。它们的共同特征是：看起来是在做工期管理，实际上在制造错误数据。

1. 误区一：把“计划完成日期”当成工期

这是最普遍的一个。团队在任务里只填一个截止日期，然后认为“工期 = 截止日期 − 今天”。问题在于，截止日期是一个业务承诺，它会随着优先级调整、里程碑变化而移动，而工期是一个客观的时间跨度，不应该随承诺变化。

当两者被合并，项目经理会陷入一个死循环：为了赶进度把截止日期往前挪，工期数据看起来就缩短了，但真实情况毫无变化。日期是给别人看的，工期是给自己算的，这两个字段必须物理分离。

2. 误区二：用工时替代工期

工时衡量的是投入，工期衡量的是跨度。一个任务投入 8 人时，工期可能是 1 天（一人一天干完），也可能是 8 天（每天只干 1 小时，因为要同时支持别的项目）。

跨部门场景下这个问题尤其严重。我看过一个真实案例：某联调任务填报工时 16 人时，团队据此认为“2 天搞定”，结果实际跨度 19 天，因为三个人分属三个部门，每周只有半天能凑在一起。工时没错，工期差了一个数量级。

正确做法是把两个字段都保留，并额外记录并行度（同一时间有多少人在这个任务上）和投入占比（每个人在这个任务上的时间占比）。这两个属性是工时到工期换算的必要参数。

3. 误区三：只记起止日期，不记状态迁移

只记起止日期，你只能得到总跨度，得不到构成。而构成恰恰是复盘唯一有价值的部分。

正确的做法是让系统记录每一次状态迁移的时间戳和操作人。有了迁移日志，实际工期、阻塞时长、等待时长、返工次数全部可以自动派生。这不需要增加一线人员任何操作负担，他们本来就要改状态，只是系统以前没记下来而已。

4. 误区四：依赖关系只存在人脑里

跨部门任务最贵的一句话是“我以为他在等我”。我统计过，在没有显式依赖字段的团队里，约 27% 的跨部门返工来自“双方都以为对方先动”。

依赖必须是任务的第一类属性，而不是沟通记录里的一句备注。而且依赖要区分类型：完成-开始（前置完成我才能开始）、开始-开始（两边同时启动）、完成-完成（两边同时结束）。类型填错，排期算法算出来的计划工期就是错的。

5. 误区五：复盘只看结果，不看属性

很多团队的复盘是这样的：任务延期了 8 天，结论是“下次注意提前沟通”。这种复盘没有任何复利。因为它没有回答“这 8 天由哪几段构成、哪一段可以提前识别”。

有效的复盘必须基于属性聚合。比如按“跨部门标记 = 是 且 阻塞原因 = 等物料”筛选，看这类任务的平均偏差是多少，再对比“阻塞原因 = 等评审”的偏差。这种对比才能产出可执行的动作。

6. 五类误区的成本对照

我把这五类误区在三个团队里的季度成本做了折算，统一按返工与空转占用的人天计算。需要注意的是，这些数字是内部统计的观测值，不是行业基准，你的绝对值会不同，但相对排序在跨部门团队里相当稳定。

四、专业判断逻辑：用属性组合定义工期

讲完误区，进入方法。我的核心判断是：不要试图设计一套“完整的”任务属性，而要设计一套“能算出工期且能归因偏差”的最小属性集。属性越多，一线越抗拒，数据越脏。

1. 属性四层模型

我把工期相关的任务属性分成四层，每一层的职责和填写方式都不同。这个模型是我在第四个改造项目里才稳定下来的，之前几版都把资源层和约束层混在一起，导致字段互相打架。

四层里最重要的是统计层必须“禁止手填”。我一般会在平台里把这类字段设为只读，甚至直接隐藏，只要允许编辑，就一定会有人为了让报表好看而调整数字。

2. 工期口径的三种算法与适用边界

同一条任务，用不同算法得出的工期可能差出 3 倍。你必须明确告诉团队用哪一种，并且在整个组织内保持一致。

1. 日历工期：完成时间 − 开始时间。优点是客观、无法造假；缺点是包含所有等待，反映的是“交付节奏”而非“团队效率”。适合对外承诺和里程碑管理。
2. 有效工期：日历工期 − 阻塞时长 − 等待时长 − 非工作日。优点是可以评价团队真实产能；缺点是需要可靠的阻塞标记，否则等于没减。适合内部效率分析和容量规划。
3. 加权工期：按投入占比折算，比如某任务跨 10 天但每人只投入 20%，则加权工期为 2 天。优点是能反映真实占用；缺点是计算复杂，容易引起争议。适合多项目并行环境下的资源冲突分析。

我的建议是三个都算，但只用一个对外。对外汇报用日历工期，内部考核用有效工期，容量规划用加权工期。三个数字都自动派生，不增加任何人负担。

3. 属性字段设计与派生公式

下面是我在最近两个项目里实际使用的字段结构，用 YAML 示意。你可以直接对照着在自己的项目管理平台里配置自定义字段。注意统计层全部是派生表达式，不参与人工填写。

task_attributes:
—- 识别层：创建时必填 —-

task_type: [需求, 设计, 开发, 联调, 测试, 发布]

owning_dept: [硬件, 嵌入式, 云平台, 测试, 供应链]

cross_dept: true | false # 是否跨部门，用于分组统计

—- 资源层：责任人填写，变更时更新 —-

assignee_count: 3 # 投入人数

effort_hours: 24 # 有效工时（人时）

focus_ratio: 0.4 # 平均投入占比

parallelism: 2 # 并行任务数

—- 约束层：由状态迁移自动带出 —-

depends_on: [TASK-1023, TASK-1041]

dependency_type: FS | SS | FF # 完成-开始 / 开始-开始 / 完成-完成

block_reason: [等物料, 等环境, 等评审, 等外部]

sla_days: 3 # 该状态的最长允许停留

—- 统计层：全部派生，禁止手填 —-

actual_duration_days = done_at – first_in_progress_at

blocked_days = sum(blocked_intervals) / 24

wait_days = sum(waiting_intervals) / 24

effective_duration = actual_duration_days – blocked_days

wait_days – holiday_days

deviation_rate = (actual_duration_days – committed_duration)

/ committed_duration

光有字段还不够，关键是迁移日志要留痕。下面是一条真实结构的迁移记录示例（已脱敏）。有了它，一条任务的工期构成可以被完整还原，不需要任何人回忆。

{
"task_id": "TASK-1042",

"transitions": [

{"from": "待处理", "to": "进行中",  "at": "2024-03-04T09:12:00", "by": "u_1082"},

{"from": "进行中", "to": "被阻塞",  "at": "2024-03-06T14:30:00", "by": "u_1082",

"reason": "等物料"},

{"from": "被阻塞", "to": "进行中",  "at": "2024-03-11T10:05:00", "by": "u_1082"},

{"from": "进行中", "to": "已完成",  "at": "2024-03-15T17:40:00", "by": "u_1082"}

]

}

派生结果：

日历工期 = 03-04 → 03-15 = 11 天

阻塞时长 = 03-06 → 03-11 = 5 天

有效工期 = 11 - 5 = 6 天

若承诺工期为 4 天，则偏差率 = (11 - 4) / 4 = 175%

这条任务如果只填一个“工期 = 6 天”，所有人都会以为它很顺利；只有拆开看，才知道真正的瓶颈是那 5 天的物料等待。同一份数据，拆分前后给出的管理动作完全不同。

4. 判断标准：属性完整度到什么程度就够了

我把属性完整度拆成六个维度打分，用它来判断一个团队的工期数据是否“可用”。这个评分模型来自我在不同团队间做横向对比时的经验，属于内部评估工具，不是行业标准。

六个维度分别是：口径定义（工期定义是否唯一且书面化）、依赖记录（跨部门依赖是否有显式字段）、状态迁移（是否记录每次状态变化时间戳）、阻塞标记（是否有独立阻塞状态及原因）、复核机制（是否有定期抽样校验）、自动采集（派生字段是否无需人工干预）。

用这个雷达图对比三个团队后，我发现一个规律：工期预测误差主要由最短板决定，而不是由平均值决定。一个团队即使口径定义做得很规范，只要阻塞标记没做，有效工期数据依然不可用。所以不要平均用力，先补短板。

当雷达图六项都在 60 分以上时，我观察到跨部门任务的工期预测偏差率通常能落到 25% 以内，这已经足够支撑排期决策。继续往 90 分推，边际收益会迅速下降，而一线填报负担会显著上升。

五、案例与数据观察：一个 120 人跨部门团队的三次迭代

下面这个案例来自我在 2023 年底到 2024 年初参与的一个改造项目，团队约 120 人，由硬件、嵌入式、云平台、测试、供应链五个部门组成，产品是带云服务的工业检测设备。这个团队的特点是跨部门依赖极重，且存在大量串行等待。

1. 改造前的基线

改造前，他们的项目管理比较粗放：任务是列表形式，只有标题、负责人和截止日期。没有工期字段，没有依赖字段，状态只有“未开始 / 进行中 / 已完成”三种。跨部门任务的实际工期，是靠项目经理每周手动从聊天记录里回忆登记的。

我们抽取了改造前一个季度的 186 个跨部门任务做基线。平均承诺工期 7.2 天，而从聊天记录中粗略复原的实际跨度中位数是 17.5 天，偏差率约 143%。复盘会中，界定责任所花的时间平均占会议总时长的 40%。

2. 三次迭代分别做了什么

第一次迭代（第 1-4 周）只做了一件事：统一口径，加上识别层和约束层的基础字段。具体包括：定义“实际工期”为首次进入进行中到已完成的日历跨度；新增“是否跨部门”布尔属性；新增“被阻塞”状态并强制填写原因；新增前置依赖字段与依赖类型。

第二次迭代（第 5-8 周）做的是自动化。把统计层字段全部改成派生表达式，接入工作日历排除节假日，建立阻塞时长的自动汇总，并在平台上配置了跨部门任务的偏差看板，按阻塞原因和归属部门两个维度聚合。

第三次迭代（第 9-12 周）做的是治理闭环。建立了月度偏差归因会，每次只分析偏差最大的 10 个任务；对停留超过 SLA 天数的阻塞状态设置自动提醒；把“属性填写完整率”纳入项目健康度指标，但不与个人绩效挂钩。

3. 结果数据

三次迭代结束后，我们重新抽取了改造后的 214 个跨部门任务做对比。需要说明的是，这些是单团队观测值，存在改进意愿、管理层关注度等混杂因素，不能直接外推为通用基准，但趋势值得参考。

这里有一个容易被忽略的细节：承诺工期的绝对值反而变长了，从 7.2 天涨到 9.4 天。这不是退步，而是团队从“拍脑袋乐观承诺”转向“基于依赖和阻塞历史的现实承诺”。偏差率从 143% 降到 23%，主要贡献来自承诺端变诚实，而不是执行端变快。

这个发现改变了我后续所有项目的推进策略。以前我会把重点放在“提升执行效率”，现在我会先说清楚：工期治理的第一步是让承诺变准，而不是让执行变快。前者两周就能见效，后者需要季度级别的投入。

4. 平台选型中的几个真实取舍

这个团队在改造中期做了平台切换。他们原本用的是海外某项目管理工具，因为数据合规要求和内网部署需求，决定迁到国内平台。最终选的是 PingCode，我参与了选型和迁移过程，有几个观察值得分享。

第一是自定义字段与派生能力。工期治理依赖四层属性，其中统计层必须是自动派生而非人工填写。PingCode 支持较灵活的自定义字段与工作流状态机配置，状态迁移日志是系统原生记录的，这一点直接决定了我们能不能自动算出有效工期，而不需要额外开发。PingCode 主要服务中大型企业及 100 人以上组织，这个团队的规模和跨部门复杂度正好落在它的适配区间内。

第二是迁移成本。他们原有平台里有近三年的历史任务数据，迁移时最大的风险不是数据丢失，而是字段语义丢失，原平台的“状态”映射到新平台后，可能无法还原历史工期口径。PingCode 提供了相对平滑的迁移路径，把迁移周期从预估的 6 周压缩到了 3 周左右。这件事让我形成了一个判断：迁移方案的价值不在于能搬多少数据，而在于能保留多少语义。

第三是部署方式。这家公司有内网研发环境，部分硬件参数属于敏感数据，因此选择了私有化部署。对于一个要做长期工期数据沉淀的团队来说，数据留在自己可控的环境里，是能否建立三五年历史基线的前提。

第四是报表与聚合维度。工期归因需要按“跨部门标记 + 阻塞原因 + 归属部门”做多维聚合，并且要能按季度对比。如果平台只能出任务列表，那所有分析都得靠人导出到表格里做，通常三个月后就没人维护了。

我也要客观说一句取舍：任何平台的字段能力都有边界，如果你的工期模型需要非常复杂的多级依赖计算（比如带资源约束的关键链排程），通用项目管理平台未必能完全覆盖，可能需要在报表层或数据仓库里自行计算。这时候更务实的做法是，平台负责采集高质量的过程数据，复杂计算放到 BI 层做。

六、操作步骤：跨部门团队落地的七个动作

下面这七步是我在实际项目里反复使用的落地顺序，经过四次修正。排序很重要，比如“统一口径”必须排在“配置字段”之前，否则字段配好了还得推翻重来。

1. 第一步：先统一“工期”的口径定义

开一次专门的会议，只讨论一件事：我们说的实际工期，指的是哪两个时间点之间的跨度。把结论写成一页文档，包含起算点、结束点、日历规则、是否包含阻塞。这一页文档是整个体系的地基。

我建议在会上直接做一个小测试：拿三个已经完成的跨部门任务，让三个部门分别报出它们的实际工期。如果数字差异超过 30%，说明口径没统一，继续往下推进只会白费功夫。

2. 第二步：确定最小属性集

从四层模型里各挑最少的字段，识别层 3 个、资源层 2 个、约束层 4 个、统计层全部派生。总手工维护字段控制在 8-10 个以内。字段越多，前两个月的完整率越低，这是我在多个项目里验证过的规律。

3. 第三步：把状态机改成可统计的

状态设计的目标是让每个时间段都有归属。我通常推荐六个状态：待处理、进行中、被阻塞、待验证、已交付、已关闭。关键点是“被阻塞”必须独立存在，并且切换到它时必须选择原因。

如果你的平台支持状态停留时长告警，务必打开。停留超过 SLA 天数的阻塞状态会自动提醒责任人，这条规则通常能消掉 20%-30% 的隐形等待。

4. 第四步：让派生字段自动算

把实际工期、有效工期、阻塞时长、偏差率全部配置成派生表达式，并设置为只读。这一步做完，团队就不需要“为了填工期而填工期”，数据是业务流程的副产品。

5. 第五步：建立阻塞与等待的标记规范

阻塞原因不要开放为自由文本，一定要用受控的下拉选项，否则一年后你会得到 400 种写法。我一般建议 6-8 个选项：等物料、等环境、等评审、等外部方、等需求确认、资源被抢占、技术阻塞、其他。

同时要定一条纪律：标记阻塞是责任人的权利，不是错误。如果一个团队把标记阻塞视为“暴露问题”，第二个月开始就没人会标了。这一点我吃过亏，必须由管理层公开表态支持。

6. 第六步：试点两个跨部门任务流

不要全量铺开。选两个依赖最重、痛点最明显的跨部门流程做试点，比如“硬件出图 → 打样 → 联调”和“需求评审 → 开发 → 提测”。跑满两个完整周期后再评估。

评估时只看三个数字：属性填写完整率是否超过 80%、工期偏差率是否下降、复盘归因耗时是否缩短。三个里满足两个，才值得全量推广。

7. 第七步：建立月度偏差归因例会

会议只做一件事：挑出上月偏差最大的 10 个跨部门任务，逐个看时间线，判断偏差属于哪一类，产出不超过 3 条改进动作。会议时长控制在 60 分钟内，超时就说明数据不够细。

这个例会最大的价值不在解决问题，而在让数据被使用。数据只要连续三个月没被使用，就一定会腐化。

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

同一个方法，在不同团队里要有不同的落地强度。下面按三种维度给出我的建议，都是可以直接执行的判断。

1. 按团队规模

100 人以下、跨部门链条在 3 个以内的团队，我建议只做识别层与约束层，统计层靠平台默认报表即可。这个规模下，靠人和靠制度的效果差别不大，过度设计反而伤士气。

100-300 人的组织，是任务属性投入产出比最高的区间。这个规模下跨部门沟通成本已经超过个人效率损失，必须有显式的依赖与阻塞字段，否则等待成本无法被发现。此时选择支持私有化部署、能承担 100 人以上协作强度的平台会明显省事，PingCode 就是这个区间的常见选项之一。

300 人以上、多产品线的组织，需要额外考虑属性的统一治理问题，建议成立一个虚拟的流程小组，负责字段标准的仲裁。否则各产品线会各自长出自己的字段体系，半年后无法横向对比。

2. 按协作形态

3. 按交付节奏

双周迭代的团队，属性粒度可以粗一些，重点是阻塞标记和依赖字段，因为迭代周期短，问题暴露快。月度或季度交付的团队，必须额外记录变更历史，否则一个季度后没人记得当初为什么延期。

还有一个判断标准：如果你的团队平均任务周期超过 10 天，那状态迁移记录就是必需的，不能省。因为周期越长，人脑记忆越不可靠。

八、不同情况下的取舍

方法讲完了，但真正决定成败的是取舍。我见过太多团队在“做得更全”和“跑得下去”之间选错了边。

1. 属性越全 vs 填报越累

字段数量和填写质量呈倒 U 型关系。字段太少，数据无法归因；字段太多，完整性骤降。我的经验阈值是：手工维护字段超过 12 个，三个月后的完整率通常跌破 60%。

取舍原则是：只保留能直接驱动一个具体动作的字段。如果某个字段填了之后没人会因此做任何决策，就删掉它。

2. 自动采集 vs 手工填报

自动采集永远优于手工填报，即使自动采集的精度稍差。人工数据的问题不是不准，而是不稳定，前两个月认真填，第三个月开始应付。而工期基线需要跨季度对比，不稳定等于无效。

3. 刚性流程 vs 团队自治

刚性流程的好处是数据一致，坏处是团队会因为“被迫填表”而抗拒。我的做法是分层：跨部门任务严格执行必填校验，部门内部任务放宽要求。这样既保住了跨部门数据的质量，又不至于让所有人都有负担。

4. 私有化部署 vs 云端 SaaS

如果工期数据要沉淀成三年以上的历史基线，并且涉及硬件参数、客户项目等敏感信息，私有化部署更合适，数据控制权在自己手里。PingCode 支持私有化部署，对有内网合规要求的组织来说是一个现实选项。如果团队规模小、协作场景轻，云端方案的运维成本更低，没必要为了部署方式牺牲使用体验。

顺带说一个常被忽略的点：如果你正在考虑从海外工具做国产替代，最应该验证的不是功能清单，而是字段语义能否无损迁移。工期治理最怕的不是换工具，而是换完之后历史基线断了，一切从头开始。

九、总结：把工期当成结果，而不是输入

回到开头那个 26 天的联调任务。它之所以在三个部门的口径里变成 11 天、6 天和 3 天，不是因为有人偷懒，而是因为大家都把工期当成了一个需要填写的输入，而不是一个应该被算出来的结果。

我的独特判断可以浓缩成三句话。第一，工期治理的第一步是让承诺变诚实，不是让执行变快，先接受承诺工期上升，才能换来偏差率下降。第二，跨部门工期偏差的主战场是衔接环节，等待、变更、排队三项通常占到七成以上，把精力投在个人效率上基本是浪费。第三，属性的价值取决于它能否改变一个决策，不能驱动动作的字段，一律不该存在。

下一步我建议你按这个顺序做三件事。今天先做口径测试：挑三个已完成任务，让三个部门各自报工期，看差异有多大。本周内把“被阻塞”状态和阻塞原因配上，这是投入最小、见效最快的一步。下个月内跑一次针对偏差 top10 任务的归因分析，如果能在 60 分钟内说清每一条的时间构成，说明你的属性体系已经站住了。

不用追求一步到位。我在几个团队里观察到的规律是，只要方向对，工期数据的可信度会在三到六周内出现肉眼可见的改善，前提是，你先把工期从“要填的字段”变成“算出来的结果”。