去年下半年，我参与了一家做智能硬件的公司（约 600 人，研发 320 人）的交付流程复盘。他们的项目管理平台上线 8 个月，理论上“任务属性”字段已经配得很全：优先级、负责人、开始时间、预计工时、依赖关系一应俱全。但复盘拉出来的数据很难看：跨部门任务的预计工期平均偏差率 47%，硬件结构、嵌入式软件、云端三方的联调任务，有 31% 实际耗时超过预估的两倍以上。更反常识的是，他们的项目经理并没有偷懒，每周都在更新工期，会议记录厚厚一叠。
问题不在于“有没有更新”，而在于任务属性从一开始就落错了地方：把“预计工期”当成一个日期字段填，而不是一组驱动协作的约束条件来建模。这篇文章我想把这类问题讲透：预计工期的最佳实践到底是什么，跨部门团队该怎么设计任务属性，以及在真实落地中会反复遇到哪些坑。
一、核心结论：预计工期是算出来的，不是“拍”出来的
先说我最核心的判断，后面所有内容都是围绕它展开的。预计工期（Estimated Duration）和截止日期（Due Date）是两回事，跨部门团队失控的根源，就是把两者混为一谈。
截止日期是承诺，是对外的一个点；预计工期是能力，是任务本身需要消耗的时间量。当你只有截止日期而没有可信的预计工期时，排期就退化成一场讨价还价，谁嗓门大谁拿到的缓冲多，谁脾气好谁被压缩。这在单一部门内还能靠熟人默契糊过去，一旦跨部门，默契就失效了。
我的第二个结论：预计工期的可信度，取决于任务属性是否“可执行到验证”这一层，而不是字段有多少个。我见过不少团队在平台上配了十几个自定义字段，看起来极其规范，但字段之间没有逻辑关系，改了预计工时不会触发依赖链重算，改了负责人不会通知下游，那这些字段就是装饰品。
第三个结论更具体：跨部门场景下，预计工期必须拆成“净工作时间 + 协调等待时间 + 缓冲”三段来建模，并且这三段要允许不同角色分别维护。技术负责人管净工作时间，项目协调人管协调等待，管理层管缓冲。混在一个字段里，就一定会被某一方按自己的立场扭曲。
二、背景与真实场景：跨部门工期为什么总在“联调”环节爆炸
我先把一个典型场景讲清楚，因为它几乎在每一家中大型企业里重复上演。
1. 场景还原：一次硬件联调的 23 天
某智能硬件公司的“整机联调”任务，初版预计工期填的是 5 个工作日。这个数字是硬件负责人凭经验拍的，因为过去类似任务“大概一周”。
实际结果：从任务创建到关闭，用了 23 个工作日。我拉着他们复盘时把时间摊开看了，结论非常清晰，真正用于技术调试的时间只有 6.5 天，剩下 16.5 天全都消耗在“非技术”环节上：等嵌入式同事从另一个高优项目抽身、等测试环境的板子到位、等供应商寄错的一颗器件、等三方确认接口协议的一个字段定义。
换句话说，5 天的估算本身没错，错的是它只描述了任务的一部分。当这个“5 天”进入跨部门排期视图后，下游的云端联调、结构验证、认证送测全部按这个假数据往后推，整条链路集体失真。
2. 为什么单一部门不会炸，跨部门就炸
在同一个部门内，等待成本是“隐性”的。同事就在旁边工位，喊一声就能协调，资源冲突由同一个主管当场裁决，等待周期往往以小时计，可以忽略。
跨部门时，这些成本全部显性化了。部门之间的目标函数不一致：硬件部门 KPI 是良率，软件部门 KPI 是迭代速度，测试部门 KPI 是缺陷拦截率。三方对同一个“整机联调”任务的优先级判断天然不同，等待就产生了。
更关键的是信息不对称：你看不到对方部门正在排队的任务队列，你只知道“他还没回我”。这种不可见性会让工期估算彻底失去依据。
3. 我观察到的三个典型信号
当一个团队的预计工期开始系统性失真时，往往先出现这几个信号，我列出来供你对照自查：
- 工期字段被当作打卡工具：执行人月底统一把日期往后拖，形成"滚动式更新"，但没人看历史版本。
- 缓冲集中在项目经理手里：所有任务的缓冲都被收走，项目经理成了唯一的缓冲分配者，一旦他休假，排期立刻瘫痪。
- 跨部门任务的属性由单方填写：只有发起方在填属性，承接方从未确认过工期，等于一份没有人签字的合同。
三、拆解常见误区：五个把预计工期带偏的想法
下面这五个误区，我在不同公司反复见到，且往往同时存在。每一条我都会给出为什么错，以及正确的做法应该是什么。
1. 误区一：字段越多越规范
很多团队把任务属性理解成“配置清单”，一口气加了十几个字段：客户名称、项目编号、成本中心、风险等级、技术栈、代码分支……看起来很专业。结果是执行人嫌麻烦，只填必填项，其余全部留空或填默认值。
我的判断是：预计工期相关的属性，宁少而联动，不要多而孤立。一个字段如果它的变化不会触发任何其他动作，不重算依赖、不通知干系人、不进入预警，那它对工期管理就没有价值。
2. 误区二：用“人天”替代“工作日”
这是极其常见的混淆。一个人天指的是一个标准人一天的有效产出，工作日指的是一段日历时间。一个任务写了 8 人天，可能是 1 个人干 8 天，也可能是 4 个人干 2 天，还可能是 2 个人边互相等边干 8 天。
在跨部门场景里这个歧义是致命的。正确的做法是让属性同时承载“工作量”和“工期”两个概念，并明确它们之间的换算关系（即投入人数）。只写一个数字，下游只能靠猜。
3. 误区三：假设干扰为零
几乎所有的工期估算都是基于“这个人这段时间只做这一件事”的假设。现实是这个假设基本不成立。我做过一个粗糙的统计：在 300 人以上的研发组织里，一个工程师同时处于“进行中”状态的任务平均是 3.4 个。
并行数是工期估算里最重要的隐性参数，却最少被写成属性。如果你不告诉排期系统这个人还有别的任务，系统只能假设他是全力投入的。
4. 误区四：把缓冲藏进每个任务里
每个人在自己的任务里偷偷加 20% 保险，这在个体层面是理性的，在系统层面是灾难。因为缓冲被分散隐藏后，管理者看不见总量，也无法重新分配。真出现风险时，缓冲已经被各任务吃掉了，只能集体延期。
5. 误区五：只在排期时用属性，执行中不再更新
这是最隐蔽的误区。任务启动时属性填得很仔细，一旦开工就再也不动，直到关闭。这样系统里存的永远是“过去的计划”，而不是“当前的事实”。预计工期的价值恰恰在于越早偏离、越早暴露，你不更新，预警就是假的。
四、专业判断逻辑：任务属性的四层模型
讲完误区，我给出我自己在实践中沉淀下来的一套结构。我把它叫“四层任务属性模型”，从下到上分别是：基础层、工作量层、约束层、协调层。越往上越容易被忽略，但对跨部门工期的预测力越强。
1. 基础层：定义任务是什么
这一层包含任务类型、负责人、所属项目、所属部门、交付物定义。大部分团队都配得不错，无需多讲。唯一要强调的是交付物定义必须是可验证的：不是“完成接口开发”，而是“接口文档评审通过且联调环境可调用”。这一条直接决定了任务的关闭标准。
2. 工作量层：定义需要多少投入
关键属性有三个：预计净工作量（人天）、预计投入比例（0-100%）、并行任务数参考。我强烈建议把投入比例做成显式字段，因为它能把“人天”和“工作日”的换算关系固化下来。
举个例子：一个任务净工作量 5 人天，投入比例 50%，那它占用的日历工期就是 10 个工作日。这个换算必须在系统里自动完成，而不是靠人脑算。
3. 约束层：定义不能违反的条件
这一层包含前置依赖、后置影响、可用的时间窗口、环境/物料前置条件。跨部门场景下我会额外加一个“外部依赖方”字段，明确标出这个任务需要哪些其他部门配合，配合的具体内容是什么。
这不是装饰。当外部依赖方被登记后，系统可以自动向对方推送确认请求，形成一个双向确认，而不是单方面的期待。
4. 协调层：定义等待和沟通成本
这是最被忽视、但对跨部门工期影响最大的一层。我认为至少要包含四个属性：
- 协调等待时间估算：需要等对方响应的平均时长，可以按历史数据按部门维护。
- 审批或评审环节数：每一次评审都可能带来 1-3 天的排队。
- 缓冲量及其归属：缓冲必须显式登记，并注明由谁持有、何时可动用。
- 同步节奏：这个任务通过什么机制同步（每日站会、周同步、里程碑会议）。
5. 一个判断口诀：三问法快速验证属性是否够用
每次设计或审视任务属性时，我会问三个问题，答不上来就说明属性不够：
- 问执行人：只看这些字段，你有没有把握在不问任何人的情况下开始干活？
- 问下游：只看这些字段，你能不能判断自己什么时候可以开始？
- 问协调人：只看这些字段，任务延期 3 天时你能不能定位到卡在哪一层？
三问法看着简单，但在我参与过的评审里，能全部通过的任务类型不到三成。这恰恰说明任务属性设计不是配置工作，而是协作契约的建模工作。
五、落地案例与数据观察：任务属性重做后的 6 个月
下面这个案例来自前面提到的那家智能硬件公司。他们在复盘后决定重构任务属性模型，并选择了 PingCode 作为落地平台，原因是他们需要私有化部署（涉密硬件图纸不能出内网），同时之前用 Jira 积累了大量历史 issue 数据，必须能平滑迁移。PingCode 在这两个硬性条件上都满足，且支持 Jira 数据字段级映射迁移，这是他们选型时最关键的加分项。
1. 他们的落地路径
整个改造分四步走，我用列表还原一下，因为顺序本身很重要：
- 先固化关闭标准：把每类任务的“可验证交付物”定义清楚，这一步花了 2 周，但后面所有属性都挂在它上面。
- 再拆分工作量字段：从原来的单一“预计工时”，拆成净工作量、投入比例、并行度三个字段，并让系统自动算日历工期。
- 然后补协调层：新增外部依赖方和缓冲归属两个字段，并强制要求跨部门任务必须由双方确认工期。
- 最后接监控：设置工期偏差预警，偏差超过 20% 自动通知协调人和负责人。
2. 6 个月后的数据
我不想只给结论，把具体数字摊开更有说服力。他们在改造前后各取 3 个月的同类跨部门任务（样本约 1,800 个）做了对比：
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 跨部门任务工期偏差率 | 47% | 19% | 下降 28 个百分点 |
| 工期偏差 20% 以上的任务占比 | 61% | 23% | 下降 38 个百分点 |
| 跨部门任务平均返工次数 | 1.9 次 | 0.8 次 | 减少 58% |
| 协调等待时间占总工期比例 | 约 42%（隐性） | 约 24%（显性） | 降低且可见 |
| 排期会议平均时长（周） | 5.5 小时 | 2.8 小时 | 减少 49% |
3. 一个我必须诚实说明的观察
改造并不是全程顺利。前两个月，工期偏差率一度从 47% 上升到 53%。原因很有意思：属性细化后，原本被隐藏的等待时间第一次被诚实记录，账面数字变差了。团队一度想放弃，认为“以前那样挺好”。
我当时的建议是：这不是变差，是显影。你以前看到的是美颜后的照片，现在看到的是真实的脸。坚持到第三个月，随着协调等待被识别并被主动优化（比如固定每周的跨部门接口确认会），数字才真正开始改善。
如果你也遇到“上系统后指标先变差”的情况，先别急着推翻，很可能是测量方式变诚实了。
4. 他们在 PingCode 上的具体配置
为了让你有可参照的操作样本，我把他们的核心配置还原成一段说明。他们在 PingCode 里没有使用单一工时字段，而是把任务属性做成了一套互相联动的结构，并且在跨部门任务上引入了“双方确认工期”的动作。这个动作的实现方式是利用 PingCode 的自定义字段加自动化规则，把“外部依赖方确认”做成任务推进到开发阶段的准入门槛。
任务属性配置（节选，示意）
──────────────────────────────
【工作量层】
净工作量(人天) 自定义数值字段
投入比例(%) 单选：25 / 50 / 75 / 100
并行任务数 自定义数值字段，默认继承负责人当前进行中任务数
日历工期 = 净工作量 / 投入比例 × 并行修正系数（自动计算）
【约束层】
外部依赖方 多选字段（部门/人员），必填于跨部门任务
前置依赖 任务关联字段
环境/物料就绪 布尔字段，未就绪时不进入"进行中"
【协调层】
协调等待估算(天) 自定义数值字段，按依赖方历史均值预填
缓冲量(天) 自定义数值字段
缓冲归属 单选：执行人 / 协调人 / 管理层
同步节奏 单选：每日 / 每周 / 里程碑
【自动化规则】
规则1：任务进入"进行中"前，外部依赖方需完成工期确认，否则阻断流转
规则2：实际耗时至预计日历工期 80% 时，自动提醒负责人复核
规则3：工期偏差超过 20% 时，通知协调人并记录原因码
这套配置的核心不是字段本身，而是那三条自动化规则。属性如果只是被填写而不驱动行为，它很快就会被敷衍掉；只有当属性直接决定任务能不能流转时，填写的严肃性才会稳定下来。
六、不同情况下的行动建议
上面是一家中大型企业的完整路径，但你的组织不一定具备同样的条件。我按团队规模和协作复杂度分几种情况给出建议，请对号入座。
1. 情况一：100 人以下、单一产品线
这个阶段不要上复杂模型。我建议只做三件事：明确关闭标准、拆分净工作量和投入比例、把缓冲集中到一个地方管理。协调层可以先不用字段承载，靠每周固定同步会解决即可。
我的判断依据是：团队规模小的时候，信息不对称的成本低于维护复杂属性的成本。过早引入四层模型，会让执行人觉得“填字段比干活还累”。
2. 情况二：100-500 人、多产品线、跨部门频繁
这是四层模型收益最大的区间，也是我认为最应该优先投入的阶段。这个规模下，部门墙开始形成，隐性等待快速增加，靠会议已经堵不住。
建议动作：
- 先把协调层的两个字段（协调等待估算、缓冲归属）补上，其他层保持现状。
- 把跨部门任务的工期确认做成流转规则，强制双向签字。
- 建立工期偏差的原因码体系，让每次偏差都能归类到具体层面。
- 选型时优先考虑支持私有化部署和字段级迁移的平台，避免数据孤岛。
3. 情况三：500 人以上、多事业部、有强合规要求
这个规模下，我建议把任务属性模型当成基础设施来做，而不是某个项目的配置。需要统一字段语义、统一换算口径、统一原因码，否则不同事业部之间的工期数据无法比较，也就无法做组织级优化。
同时这一层级的选型必须考虑数据主权问题，很多涉及硬件图纸、客户数据的组织无法使用公有云 SaaS，私有化部署是硬门槛。历史数据迁移能力同样关键，切换平台的成本往往被严重低估。这也是为什么在中大型组织的国产化替代场景里，能够支持 Jira 平滑迁移、支持私有化部署的方案会更有优势，PingCode 就属于这一类。真正要评估的不是功能清单有多长，而是迁移过程会不会丢字段、丢历史、丢关联关系。
七、不同情况下的取舍
任何方法都有代价。这一节我讲清楚三组关键取舍，帮你在真实约束下做决定。
1. 取舍一：估算精度 vs 填写成本
属性越细，估算越准，但填写成本越高。我的经验曲线是这样的：当属性字段从 3 个增加到 8 个时，工期预测准确率提升最明显；从 8 个增加到 15 个时，提升开始变缓；超过 15 个之后，因为执行人开始敷衍，准确率反而下降。
我的建议是控制在 8-12 个核心字段，其余通过自动化推导而不是手工填写。比如日历工期应该由净工作量和投入比例自动算出来，而不是让人再填一遍。
2. 取舍二：缓冲集中管理 vs 分散持有
缓冲分散持有（每个任务各留 20%）的好处是执行人有心理安全感，不容易因风险暴露而被追责；坏处是总量不可见、无法重分配。
缓冲集中管理（统一放在项目级）的好处是总量可控、可以按风险动态调配；坏处是被收走缓冲的执行人会有抵触，且在遇到问题时不主动上报。
我的判断是：跨部门任务必须走集中管理，单一部门内的任务可以允许分散持有。理由是跨部门任务的缓冲被某一个人挪用时，损害的是多个部门的利益，必须有统一的裁决者。
3. 取舍三：准确性 vs 时效性
在快速变化的业务里，追求高精度估算往往不划算。一个需求本身可能下周就变了，你花两天把它估得很准，是一种浪费。
我的处理方式是分级估算：
| 任务类型 | 估算精度要求 | 允许偏差 | 适用场景 |
|---|---|---|---|
| 探索型任务 | 粗估，量级即可 | ±100% | 新技术验证、方案调研 |
| 标准迭代任务 | 中等精度 | ±30% | 常规功能开发 |
| 跨部门联调任务 | 高精度，需双方确认 | ±15% | 涉及多部门接口与依赖 |
| 对外承诺型任务 | 高精度 + 显式缓冲 | ±10% | 有客户或合规截止日期 |
分级的意义在于：不是所有任务都值得精细估算，但所有任务都必须知道自己属于哪一级。你按 ±100% 估的探索任务，不该被下游当成 ±15% 的承诺来排期。
八、下一步：从今天开始能做的三件事
讲到这里，我把可执行的起点收拢一下。如果你只能做三件事，我建议按这个顺序：
1. 第一步：给你的任务类型做一次偏差体检
导出过去 3 个月已关闭的跨部门任务，计算每个任务的（实际耗时 – 预计工期）/ 预计工期。不用追求分析得多深，你只需要知道哪一类任务的偏差率最高。通常你会发现问题高度集中在少数几类任务上，先把它们拎出来。
2. 第二步：给偏差最高的那类任务补协调层属性
不要全面铺开改造。选偏差最高的那一类任务，补上外部依赖方、协调等待估算、缓冲归属三个字段，并加上“双方确认工期”的流转规则。运行一个月看数据。小范围验证比全面推行更容易拿到共识。
3. 第三步：把关闭标准写成一句可验证的话
挑出你最常出问题的那几个任务模板，把它们的交付物从“完成 XX”改写成“XX 通过、且 XX 可调用”。这一个动作的成本极低，但它能同时减少返工和工期偏差。
最后我想回到最开始那个判断。预计工期管理的本质，不是让估算变得多准，而是让不确定性变得可见、可分配、可协商。跨部门团队真正缺的从来不是更准的估算能力，而是一套让不同部门能就“这段时间怎么用”达成共识的机制。任务属性只是这套机制的载体，字段是形式，确认才是内容。当你把每一段等待、每一份缓冲、每一次依赖都摆到台面上时，工期自然就不再是一个需要靠拍脑袋决定的东西了。
常见问题解答（FAQ）
1. 跨部门团队里，任务属性字段到底该怎么设计，才能让不同部门的「预计工期」可比？
我们公司研发、设计、市场三拨人用同一个项目管理平台，结果发现每个人填的「预计工期」根本不是一回事：有人填自然日，有人填工作日，有人把等对方回复的时间也算进去。我作为项目协调人，每次汇总排期都要手工换算一遍，特别崩溃。到底字段该怎么设计才不乱？
先统一口径，再统一字段，顺序反了就会白做。我的做法分三层。第一层是基础口径，必须做成受控枚举，不允许自由填写：工期单位统一为「人日」，并明确一天按几个有效工时算（我们按6小时，因为会议和协作天然吃掉2小时），周几算工作日、节假日怎么扣，全部写进字段说明。
第二层是资源属性，包括执行角色（前端/后端/设计/文案）和投入比例（全职100%、半投入50%），同时规定工期一律存「投入人日」，日历天数由系统按投入比例换算，这样跨部门才可比。
第三层是依赖与交接，跨部门任务最容易被漏掉的是等待对方响应的时间，所以单列一个「外部等待时间」字段，不计入执行人工期但要计入整体排期。落地时把这三层做成任务模板加必填校验，缺一个字段不让创建任务。
上线前先拿两个已结束的跨部门项目做回溯试填，如果同一任务两个部门填出的工期差异超过30%，说明口径还没对齐，继续改字段说明，而不是急着全量推广。
2. 预计工期应该由谁估？让执行人自己估，还是项目经理拍？
我以前一直让项目经理拍工期，结果执行人接手后说根本做不完，最后背锅的是我。后来我改成让执行人自己估，又出现有人说3天有人说10天，差异大到没法排期。我到底该让谁来估才靠谱？
我的判断是「谁执行谁估，但估完必须过一遍校准」。项目经理拍工期的问题是信息不对称，真正动手的人才知道接口联调要多久、历史代码有多烂、跨部门等审批要几天；但纯靠执行人自估，又会有乐观偏差和留缓冲的心态。我实际操作是三步。
第一步，执行人给三点估算（乐观、最可能、悲观），最终工期取「乐观＋4×最可能＋悲观」除以6，这个加权值比单点估算稳定得多，我们团队用了半年，整体偏差从±60%收窄到±25%左右。
第二步，跨部门任务的估算必须由需求方和执行方各出一个数，差1倍以内取中位数，差1倍以上强制开15分钟对齐会，把差异原因写进任务备注，最常见的原因是需求描述里没写要兼容老数据。第三步，第一次合作的外部或兄弟部门任务，在加权值上乘1.3的经验系数，第二次合作再回到1.0。
这套规则的真正价值不是把工期估准，而是把分歧显性化，让扯皮发生在开工前而不是交付前。
3. 预计工期和截止日期要不要分开？能不能只用一个日期字段？
我们平台上任务就一个日期字段，大家默认把它当截止日期填，结果一眼看不出这个活到底要干几天。排期的时候我只能挨个去问，问完再手工画表格，特别低效。是不是必须拆成多个字段？拆了大家会不会嫌麻烦不肯填？
必须分开，而且至少要三个字段：预计工期（纯投入量）、计划开始与结束（排期）、截止日期（对外承诺的时间点）。混在一起最直接的后果是没法做关键路径分析，你只看日期，看不出一个任务是3天的活还是20天的活，也就判断不出延迟一天会不会拖垮整条链路。我的落地方式是：预计工期只让人填数字和单位，不让人填日期；
计划开始日期由依赖关系自动推导，等于前置任务结束加等待时间；计划结束等于开始加工期换算出的日历时间；截止日期单独一个字段，并且规定只有对外承诺的任务才允许填，避免所有任务都变成紧急。
跨部门场景还有一个必踩的坑：对方部门给你的截止日期，往往是他自己内部的最后期限，而不是他需要你交付的时间，你的实际交付时间要往前倒推至少2个工作日留出交接和验收。
我们踩过一次，按对方截止日当天交付，结果对方走内部流程走了3天，整条链路延迟，后来统一改成「最晚交付时间」字段，由接收方填写，写清楚我需要在几号几点前拿到。
4. 跨部门任务的工期老是估不准，有没有可量化的校准方法？
每次复盘大家都在说下次估准点，但下次还是不准，跨部门任务尤其离谱。我也试过让所有人写复盘文档，写完没人看，感觉根本没有改进的抓手。到底有没有能落地的校准机制？
别指望「下次估准点」这种口号，要建一个能量化的偏差台账。具体做法是：任务关闭时必填两个数，预计工期和实际工期，实际工期按同样口径统计（同样的人日、同样的有效工时定义），这样偏差率等于实际减预计再除以预计，才有可比性。然后按维度看偏差，而不是只看整体平均值。
我的经验是整体平均偏差往往在±15%以内，看上去很好，但拆开看会发现首次合作的跨部门任务平均超期50%以上，单人独立任务反而普遍提前，整体均值把问题掩盖了。校准手段有三个：一是给高偏差类型设缓冲系数，比如首次跨部门协作1.3、涉及外部供应商1.5，系数每季度用新数据回算一次；
二是每月做一次偏差TOP10任务复盘，只讨论漏了什么、下次加什么检查项、要不要改模板字段，控制在40分钟内；三是把偏差率作为团队指标而不是个人指标，否则大家会故意把工期估长来保护自己，台账数据立刻失真。
最后提醒一句，估算精度的合理目标不是100%，需求明确、流程稳定的重复型任务做到±20%就很好了，探索型任务偏差大是正常的，别用同一个标准去考核。
核心关键词
文章包含AI辅助创作：预计工期最佳实践：跨部门团队任务属性落地方案，常见问题，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/362027
读者评论
协调等待按历史数据维护这条我认同，但有个前提：对方部门的排队情况得能被看见。我们试过在平台里填历史均值，稳定的团队有效，一到季度末冲刺就全失效。现在只对两三个高频协作的部门建响应基线，其余靠人填，反而更能坚持下来。
并行任务数做成字段我持保留意见。这个数一天变三次，让执行人自填基本等于填个大概，之后也没人维护。我更倾向把它放进资源日历由排期侧反推，任务属性只保留投入比例。不过投入比例现场也很难如实填，人被借调走了字段还挂着百分之八十，比不填更容易误导下游。
缓冲显式登记这条，难点不在设计字段，而在管理层看到明面上的缓冲会直接砍掉。我们后来把缓冲挂在里程碑而不是单个任务上，只有协调人能动用，砍的时候有据可依。三问法确实好用，我们多加了一问：新人接手时只看字段，能不能判断该先找谁。