去年我帮一家 780 人的装备制造企业做研发效能诊断，他们的研发副总给我看了一份数据：过去 12 个月立项的 43 个项目里，只有 9 个在原计划工期内交付，平均延期 27 天。他第一反应是"我们的工程师不会估算"，打算请外部讲师做一轮故事点估算培训。我把这 43 个项目的任务明细导出来看了一遍，发现问题根本不在估算方法：全公司 3200 多个任务里，有 61% 的"预计工期"字段填的其实是工作量（比如"改一个接口 8 小时"，但流程上要等测试环境、等评审、等联调），有 44% 的任务没有维护工作日历（默认 7×24 小时），还有 38% 的任务工期填的是"1 天"，因为发起人懒得算，先填 1 天，做完再改回来。
换句话说，这家企业的工期算不准，不是算得不好，而是任务属性没有定义清楚，导致工期字段本身在说谎。这也是我在过去五年服务 100 人以上组织的过程中反复见到的现象：大家愿意花几十万买工具、花几周做培训，却不愿意花两个小时把"任务属性"这件事定死。
这篇文章我会拆解预计工期为什么在三类企业里普遍失控，任务属性应该怎么定、哪些字段必须有、哪些字段是负担，并给出一个 800 人规模企业使用 PingCode 从工时混乱到工期可控的完整过程与数据。如果你正在被"计划三天、实际两周"折磨，这篇内容能帮你判断：该修的是估算能力，还是任务属性。
一、核心结论：工期算不准，先修属性再修方法
我把过去几个项目的诊断记录做过一次归因统计，结论和我们直觉不太一样。工期偏差的首要来源不是估算能力，而是任务属性的定义缺陷。在我的样本里，估算方法本身（点估算、类比估算、三点估算）带来的偏差，只占全部偏差的一小部分。
下面六条结论，是我在多个企业反复验证过的判断。它们不是教科书上的原则，而是踩过坑之后总结出来的操作底线。
- 结论一：工期（Duration）与工作量（Effort）必须拆成两个字段。这是所有工期问题的总开关。只要这两个概念混在一个字段里，后面所有的排程、关键路径、资源负荷计算全部失真。
- 结论二：一个项目里只能有一套估算单位。同一个任务列表里既有"小时"又有"人天"还有"故事点"，等于没有单位。
- 结论三：工作日历要先于估算存在。没有日历的工期是"自然日工期"，它和实际交付时间天然差 20%~30%。
- 结论四：缓冲放在项目层，不要藏在每个任务里。每个任务都加 20% 安全垫，累积起来会让整个项目周期虚胖，并掩盖真实的风险位置。
- 结论五：一个任务的预计工期超过 10 个工作日，就说明它该被拆了。不是估算问题，是任务颗粒度问题。
- 结论六：工期字段的填写成本必须低于 10 秒。任何需要打开三个页面才能填完的工期字段，最后都会变成"1 天"。
第六条尤其值得强调。我见过太多企业把任务属性设计得非常"完整"：工期、工作量、剩余工作量、预计开始、预计结束、实际开始、实际结束、完成百分比、资源投入比例……结果是一线员工直接放弃维护，数据质量反而更差。
那么偏差到底来自哪里？我用一个 3200 任务样本做的归因分布来说明。
二、背景和真实场景：三类企业的任务属性完全不一样
我服务过的 100 人以上组织里，工期问题呈现三种截然不同的形态。用同一套任务属性去套这三类场景，是很多企业推行失败的起点。
1. 研发型团队：工期的不确定性来自技术方案
这类团队通常是 200~2000 人的软件或硬件研发组织，任务的不确定性高，同一个需求，不同的技术方案工期可能差 5 倍。他们的核心诉求是"在不确定性中找到可控的节奏"。对这类团队，工期字段更适合按人天粒度填写，配合三点估算（乐观/最可能/悲观）来暴露不确定性，而不是强行精确到小时。
我在一家做工业软件的 600 人企业里做过对比：把研发任务从"小时估算"改成"人天估算 + 三点估算"之后，单个需求工期偏差从平均 +52% 收窄到 +19%，而估算所花的时间反而减少了三分之一。原因很简单，工程师在小时间粒度上根本没有可靠的判断依据。
2. 交付实施型团队：工期的不确定性来自客户现场
系统集成、设备交付、SaaS 实施这类项目，工期往往被客户环境、进场条件、验收标准牵着走。这类团队的任务属性重点是"里程碑 + 外部依赖 + 缓冲"，而不是精确的工作量拆分。
我观察到一个规律：这类项目里，凡是把"客户侧确认"单独建成任务并设置工期和责任人，交付准时率会比不建的高出 20 个百分点左右。因为把等待时间显性化之后，延期责任无法再被模糊掉。
3. 运营/市场型团队：工期的不确定性来自人力冲突
活动、内容、投放这类任务，单个任务工期不长（通常 1~5 天），但同一个人同时被三个项目占用。他们的问题不是估不准，而是资源日历和投入比例没定义，导致同一个人的工作量被重复计算。
这类团队的任务属性里，"投入比例"字段的重要性甚至高于"预计工期"本身。一个设计师被三个项目各占 50%，这种数据进到系统里，怎么排都是错的。
我把三类场景的必填属性差异整理成了一张对照表，这是我给企业做工作项类型设计时的标准起点。
| 属性字段 | 研发型团队 | 交付实施型团队 | 运营/市场型团队 |
|---|---|---|---|
| 预计工期（Duration） | 必填，人天 | 必填，人天 | 必填，小时或半天 |
| 工作量（Effort） | 必填，人天 | 选填 | 选填 |
| 工作日历 | 必填（团队日历） | 必填（含客户日历） | 必填（团队日历） |
| 前驱依赖 | 必填（有则填） | 必填 | 不强求 |
| 三点估算 | 建议（高风险任务） | 不建议 | 不建议 |
| 投入比例 | 建议 | 必填 | 必填 |
| 完成定义（DoD） | 必填 | 必填 | 建议 |
三、拆解常见误区：八个让工期失真的习惯
下面这八个误区，是我在调研中遇到频率最高的。它们往往不是"不懂"，而是"图省事"，但代价会在项目后期成倍返还。
1. 把工期当工作量填
这是最普遍、也最致命的一个。员工填"这个任务 8 小时"，他的意思是"我需要专注做 8 小时"，但系统理解为"这个任务占用 8 小时日历时间"。一旦有依赖关系和资源冲突，两者会差出十几倍。
判断方法很简单：如果一个任务的工期和它前面任务的工作量强相关，而不是和它自己的工作量强相关，说明这个团队在混填。
2. 用小时估算跨越三个月的任务
跨度越长的任务，估算精度越低。让人估算三个月后的任务，本质上和掷骰子区别不大。我的经验阈值是：超过 10 个工作日的任务，估算偏差会迅速放大；超过 20 个工作日，工期字段基本失去参考价值。
3. 任务颗粒度失控
颗粒度过大（一个任务 30 天）和过小（一个任务 1 小时）都会毁掉数据质量。过大导致偏差不可见，过小导致维护成本压垮团队。我在样本里统计过不同颗粒度下的偏差幅度，结论很直观。
4. 忽略工作日历与资源日历
没有工作日历，系统就会默认 7×24 小时。一个"5 天工期"的任务周五开始，系统算出来周三结束，但中间夹着周末。更麻烦的是资源日历：一个人同时被分配 200% 的工作量，系统仍然会按 100% 速率推进所有任务。
5. 依赖关系只填"显而易见的"
很多团队只填"开发 → 测试"这种明面依赖，忽略"等评审""等环境""等客户确认"这类软依赖。结果关键路径算出来短得离谱，项目看起来永远来得及，直到最后两周全面崩塌。
6. 把缓冲藏在每个任务里
每个任务加 20% 安全垫，是传统项目管理的经典反模式。它会造成三个后果：工期被系统性高估、帕金森定律生效（工作自动填满可用时间）、真实风险无法被识别，因为所有任务看起来都"有余量"。
7. 完成定义不一致
"开发完成"和"可交付"之间可能差三天：代码提交完成、自测通过、Code Review 通过、合并到主干、部署到测试环境。如果没有统一的完成定义，工期从第一天起就在两种口径之间漂移。
8. 跨项目复用同一套任务属性
研发项目需要三点估算，运营活动只需要一个截止日期。强行统一字段，会导致某些团队被迫填写毫无意义的字段，然后开始敷衍。
四、专业判断逻辑：任务属性是否合格的四层检验
我判断一套任务属性设计是否合格，不看字段有多少，只看它能不能通过四层检验。这四层从下到上，缺一层都会导致上层失效。
1. 第一层：可估算性
责任人能不能在 10 秒内给出一个合理的工期数字？如果不能，说明任务描述不够清晰，或者颗粒度不对。检验方式是抽样 20 个任务，让责任人当场估算，如果超过 5 个需要追问细节才能估，这层就没通过。
2. 第二层：可验证性
工期结束时，能不能用一个客观标准判断"完成"或"未完成"？如果只能靠感觉，那么实际工期的记录本身就是不准的，后续所有校准分析都建立在沙滩上。
3. 第三层：可追踪性
任务属性变化后，系统能否自动重算下游任务的开始时间、项目的关键路径、资源的负荷曲线？如果每次调整都需要人工同步，这套数据在两周后就会失去信任。
4. 第四层：可复算性
三个月后回头看，能不能算出"这类任务的估算偏差是多少"，并用它来校准下一次估算？这是从"能管项目"升级到"能持续改进"的分水岭。多数企业停在前三层。
在具体估算上，我一般推荐军团对高风险任务使用三点估算，公式如下：
期望工期 = (乐观工期 + 4 × 最可能工期 + 悲观工期) / 6
标准差 = (悲观工期 – 乐观工期) / 6
示例：
乐观 = 3 人天，最可能 = 5 人天，悲观 = 13 人天
期望工期 = (3 + 4×5 + 13) / 6 = 6 人天
标准差 = (13 – 3) / 6 ≈ 1.67 人天
解释：
期望工期 6 人天 > 最可能值 5 人天，说明悲观情景权重更高
标准差 1.67 说明该任务不确定性较大，建议加入观察清单
这里有一个容易被忽略的判断：三点估算的价值不在于算出那个"期望值"，而在于暴露乐观值和悲观值之间的差距。差距越大，说明这个任务需要的不是更精确的估算，而是先做技术验证或原型。
我还整理了一张任务属性自检表，是我给企业做工作项模板设计时的实际清单。凡是通不过的项，我会标记为"必须先解决再谈工期管理"。
| 检验层 | 关键问题 | 不通过时的典型症状 |
|---|---|---|
| 可估算性 | 责任人能否 10 秒内给出工期？ | 大量任务工期填 1 天，或工期字段长期为空 |
| 可验证性 | 完成标准是否客观？ | 任务反复"完成，打回"，实际工期无法记录 |
| 可追踪性 | 属性变化能否自动重算？ | 每次都靠 Excel 手工调整甘特图 |
| 可复算性 | 能否回溯计算历史偏差？ | 没有基线概念，每次估算从零开始 |
五、具体案例与数据观察：一家 800 人企业用 PingCode 的 12 个月
下面是我在 2023 年到 2024 年参与的一个完整案例。客户是一家 800 人规模的智能硬件企业，研发加交付共 640 人，原来使用某海外项目管理工具，全球账号费用和本地化适配都是痛点，同时需要满足数据不出内网的要求。
他们最终选择了 PingCode，主要基于三点：支持私有化部署，满足内网数据合规；支持从原先的工具平滑迁移历史工作项和字段映射；产品能力面向 100 人以上中大型组织的复杂研发流程。迁移过程本身不是这篇文章的重点，重点是迁移之后他们在任务属性上做的五件事，以及由此带来的数据变化。
1. 第一件事：把"工期"和"工作量"拆成两个独立字段
原来的工具里只有一个"预估"字段，团队混着填。迁移时他们做了一个关键动作：历史数据不做猜测性拆分，统一标记为"历史口径"，新数据从零开始按新规则采集。这个决定让前两个月的图表很难看，但避免了用脏数据污染新口径。
2. 第二件事：建立团队工作日历并强制关联
他们把研发、测试、交付三条线分别建立了工作日历，包含法定假期、公司调休日和各条线特有的非工作日。工作日历直接决定工期如何换算成日历日期，这是最容易做、收益最明显的一步。
3. 第三件事：设定任务拆分阈值
他们规定：单个任务预计工期超过 8 个工作日必须拆分，拆分后的子任务必须各自有明确的完成定义。三个月后，超过 8 个工作日的任务占比从 27% 降到 6%。
4. 第四件事：缓冲集中到里程碑层
他们取消了所有任务级的隐性缓冲，改为在里程碑上设置显性缓冲，并规定缓冲只能由项目经理申请动用。这一步的效果最出乎他们意料：项目总周期缩短了，但一线员工并没有觉得更紧张。因为他们原本藏在任务里的时间被释放出来，变成了可见的、可管理的余量。
5. 第五件事：建立估算校准机制
每两周，项目经理会抽取一批已完成任务，对比预计工期与实际工期，把偏差比例反馈到下一次估算中。这个动作每次只花 20 分钟，但它是"可复算性"落地的关键。
下面是他们上线前后四个季度的核心指标变化。数据来自该企业内部的项目管理度量看板，经过脱敏处理。
很多人关心投入产出。我按他们实际记录的数据做了一个收益拆解，其中人力口径按 800 人企业平均成本折算，属于情景模拟，供参考而不是精确财务结论。
6. 迁移与配置中的几个具体动作
他们在配置层面做了几件很实际的事，我认为比任何方法论都重要。第一，把工期字段设置成工作项类型的必填项，但允许"暂估"标记，暂估任务在度量时单独统计，不污染正常数据。
第二，把工作日历绑定到项目层级而不是全局，避免不同业务线的假期差异互相干扰。第三，在迁移阶段做了字段映射对照表，明确哪些历史字段保留、哪些废弃、哪些需要人工复核，避免了"迁过来一堆没人看得懂的字段"这种常见后遗症。
下面是一段任务属性配置的示意结构，用来说明字段之间的约束关系，实际配置会依据企业流程调整。
工作项类型：研发任务
必填字段：
预计工期（Duration） 单位=人天，正整数
工作量（Effort） 单位=人天，正整数，可等于工期
工作日历 关联=团队日历
完成定义 枚举=代码合并/自测通过/测试通过
校验规则：
IF 预计工期 > 8 人天 THEN 提示拆分，需项目经理确认
IF 工作量 > 预计工期 THEN 告警：工作量不应大于工期
IF 前驱任务未填 AND 存在外部等待 THEN 提示登记软依赖
度量口径：
工期偏差率 = (实际工期 – 预计工期) / 预计工期
统计范围 = 已完成任务，排除标记为"暂估"的记录
样本门槛 = 单项目完成不少于 30 个任务
六、不同情况下的行动建议
同样是做任务属性规范，100 人企业和 2000 人企业的做法完全不同。下面按规模、项目类型和成熟度三种维度给出建议。
1. 按组织规模分
100 人以下：不要设计复杂字段。只做两件事，拆分工期与工作量，统一一个估算单位。其他都先放一放，等团队习惯了再说。
100~500 人：增加工作日历和完成定义。这个规模开始出现跨团队依赖，软依赖不显性化会直接导致交付延期。同时开始建立最简单的偏差统计。
500~2000 人：必须做分线日历、任务颗粒度阈值和估算校准机制。这个规模的组织，靠人工协调已经不可行，只能靠数据驱动。私有化部署和字段级权限往往在这个阶段变成硬需求。
2000 人以上：重点转向度量口径统一和跨组织对标。此时最大的风险不是没有数据，而是同一个指标在不同部门有五种算法。
2. 按项目类型分
研发项目：优先建三点估算和颗粒度阈值，允许多一些字段，因为不确定性本身就是管理对象。
交付项目：优先建外部依赖登记和里程碑缓冲，工期字段可以粗一点，但依赖必须细。
运营类项目：优先建投入比例和资源日历，工期可以只精确到半天。
3. 按当前成熟度分
第一阶段（没有规范）：目标是让工期字段变得可读。做一次抽样诊断，找出混填比例，然后在工具里把字段拆开。
第二阶段（刚建立规范）：目标是让数据积累起来。此时不要急于看偏差指标，先看完整率。完整率不到 80%，一切分析都是噪音。
第三阶段（有历史数据）：目标是让数据反哺估算。建立校准机制和估算参考库，按任务类型给出历史偏差范围。
七、不同情况下的取舍
任务属性建设本质上是一组取舍，没有"全都要"的选项。下面五组取舍是我认为管理者必须明确表态的。
1. 精度 vs 填写速度
精确到小时，数据更细但填写成本高；精确到人天，成本低但难以支持小时级排程。我的判断是：除非是短周期、高并发的运营任务，否则一律用人天。研发和交付场景里，小时级精度带来的收益远小于它带来的填报负担。
2. 字段多 vs 字段少
字段多，理论上信息全，但实际填写率会下降。经验阈值是：一个工作项类型的必填字段不要超过 7 个。超过这个数，完整率通常会掉到 60% 以下，反而比字段少的时候更差。
3. 统一 vs 灵活
全公司统一一套任务属性，便于对标但容易僵化；每个团队自定义，贴合业务但无法横向比较。折中方案是"核心字段统一 + 扩展字段分线"，工期的单位、日历、偏差口径必须统一，其余字段允许分支差异。
4. 缓冲集中 vs 分散
缓冲集中在里程碑层，管理者看得见但一线容易感到压力；缓冲分散在任务层，一线舒服但项目整体容易失控。我倾向于集中，但配套一个规则：缓冲的动用必须记录原因。
5. 工具驱动 vs 流程驱动
很多企业指望买一套工具就解决工期问题。我的判断是：工具能解决的是"可追踪"，解决不了"可估算"和"可验证"。这两层必须靠流程和习惯。反过来，如果流程已经理顺而没有合适的工具支撑，数据同样会散落在 Excel 里。对 500 人以上、有内网合规要求、又要承接复杂研发流程的组织，像 PingCode 这类支持私有化部署、能平滑承接历史数据的中大型组织项目管理平台，往往是这个阶段的现实选择。
八、结语：先让工期字段说真话，再谈估算能力
回到开头那家企业。他们最后没有做估算培训，只做了三件事：拆开工期与工作量、建立团队工作日历、设定 8 个工作日的拆分阈值。六个月后，43 个在建项目的平均延期从 27 天降到 9 天。工程师的估算能力没有变化，变化的是他们填进去的数字终于开始说真话了。
我的核心观点是：预计工期的准确性，首先是一个数据定义问题，其次才是一个估算能力问题。多数企业把顺序搞反了，于是花了钱、做了培训、买了工具，工期还是不准。
如果你准备动手，我建议按下面的顺序推进，不要跳步。
- 导出最近 3 个月已完成任务，统计工期字段为"1 天"的比例、为空的比例、明显等于工作量的比例。这一步不花钱，半小时就能做完。
- 在工具里把工期和工作量拆成两个字段，只做这一件事，运行两周看完整率变化。
- 建立团队工作日历并绑定到项目，检查排程结果是否还包含周末和假期。
- 设定拆分阈值（建议 8~10 个工作日），对超阈值任务做一次集中拆分。
- 把缓冲从任务层上移到里程碑层，并规定动用规则。
- 两周一次的估算校准，坚持三个季度，形成自己团队的偏差基线和估算参考库。
最后提醒一句：这套动作见效有滞后性。数据质量的改善会先出现，工期偏差和按期达成率的改善通常要到第二、第三季度才明显。如果你的管理层期望一个月内看到交付准时率翻倍，先把这个预期说清楚，比急着改字段更重要。
常见问题解答（FAQ）
1. 预计工期到底该由管理者拍板，还是让执行任务的人来估？
我带团队时最纠结的就是这个：我自己拍的数字，团队嘴上认了但执行时各种理由延期；让团队自己报，我又觉得里面全是水分。后来发现这不是二选一的问题，而是谁估、谁校、怎么留痕的问题。
我的做法是执行人估算、管理者校准，两个动作都要在任务属性里留痕。具体是：需求澄清会后，由真正动手的人填两个字段，预计工时（人·小时）和计划起止日期。工时是给排负荷用的，日期是给排依赖用的，只填日期是最常见的坑，跨人协作时根本算不出谁在第几周会爆。
管理者不直接改数字，只做三道校验：一是看颗粒度，超过 3 天工时的任务一律要求拆；二是拿同类型任务的历史 P50 做锚点，报出来的值超过锚点 2 倍就要求给出拆分依据或风险点；三是看偏差趋势，同一个人连续两个迭代偏差都超过正负 30%，那说明估的不是任务而是心情。
判断依据是：管理者拍板容易拍出政治工期，团队会按这个数字倒推工作量；执行人自己估虽然第一轮偏差大，但三个迭代后精度会明显收敛。这套流程我在一个 30 人研发团队跑过两个季度，任务级偏差率从正负 60% 收敛到正负 25% 左右。
2. 任务要拆到什么颗粒度，预计工期才准、管理成本又不高？
我们团队以前两类任务都出现过：有的任务写着 10 天，结果第 8 天还不知道做没做完；有的拆成几十个半小时的小任务，光更新状态就占掉半天。颗粒度这事到底有没有可操作的标准？
我用的标准是 0.5 到 3 个人·天之间，超过 3 天的必须拆，小于半天的合并。理由很实际：小于半天的任务，创建、指派、更新状态、验收的管理成本已经超过任务本身的价值；超过 3 天的任务在做进度判断时是个黑盒，往往到第 5 天才能确认要延期，管理者拿不到任何可干预的窗口。
拆的时候我用两个约束：一是能不能在一个迭代内由一个人独立完成并可验证；二是命名必须是动词加可交付物，比如完成登录接口联调并通过测试用例，而不是登录模块。再落一层数据口径：统计团队任务时长的分布，中位数落在 1 到 2 天的团队，进度可视性最好，也是迭代燃尽图最有参考价值的状态。
如果中位数是 5 天以上，说明任务属性其实是项目名，不是任务。
3. 团队的预计工期总是不准，怎么判断是估算方法问题还是人的问题？
每次迭代回顾会都会吵这个，管理者觉得是执行人估得太随意，执行人觉得是需求天天变。我一开始也爱抓典型，后来发现绝大部分偏差是有规律的，抓人解决不了。
先别看人，看偏差的方向和分布。做法是把任务属性里的任务类型分开统计，比如需求、设计、开发、自测、联调、文档各一组，分别算偏差率，公式统一用（实际减预计）除以预计。如果所有类型一致偏乐观，比如普遍低估 30% 以上，那是流程问题，需求澄清不足、完成定义不清晰、没把返工和联调算进去；
如果只有开发类任务偏低 40% 而测试类正常，那是估算口径问题，开发漏算了自测和联调，不是谁不认真；如果只有个别人持续偏大，才轮到人的问题。
改善动作里性价比最高的一条是给完成下统一定义：测试通过、代码已合并、文档已更新之后才能把任务置为完成，这一条通常能消掉 20% 到 30% 的虚高偏差，因为它掐掉的是快做完了这种假完成。
4. 单个任务的预计工期都有了，怎么推出项目整体交付日期，缓冲要加多少？
我把每个任务的工期都填齐了，结果一加总发现跟实际交付差了将近一倍。团队说是因为每个人都留了安全时间，我不知道该不该让他们别留，又怕不留缓冲风险全砸在我头上。
做法是关键路径加聚合缓冲，不要在单个任务上各自加 20%。第一步排依赖，明确谁等谁，算出关键路径上用时的总和，这是理论最短工期；第二步把散落在每个人身上的安全时间收上来，集中成一个项目级缓冲，经验值是总量的 15% 到 25%，不确定性越高取上限。
判断依据来自关键链的思路：分散留安全时间会重复叠加，把项目周期吹到 1.5 倍以上，而且真正出问题时没人拿得出来；集中管理则能在关键节点上被看见、被消耗、被复盘。
数据口径举个例子：关键路径合计 40 人·天，团队 5 人，实际并行度按 60% 算（会议、支持、上下文切换是真实成本），理论日历工期约 40 除以 3 等于 13 天，加 20% 缓冲约 16 天，对外承诺说 3 周比较稳。
另外要区分预计完工日和承诺交付日两个字段，前者用于内部排产，后者留给你自己的缓冲，混成一个字段，缓冲就永远守不住。
核心关键词
文章包含AI辅助创作：预计工期最佳实践：企业管理者任务属性最佳实践，常见问题，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/360311
读者评论
我们前年也把工期和工作量拆成两个字段，半年后基本又回到只填一个。不是字段设计的问题，是工期一旦录进系统就变成对上级的承诺，没人愿意填真实数字。文章说的十秒填写门槛确实关键，但光简化字段解决不了填报动机这件事。
归因那张图我保留意见。混填占34%这类比例，靠的是字段抽查加访谈，本身就带判断成分，说成贡献三成偏差更像是相关而非因果。另外样本集中在制造业和工业软件，换到外包或互联网场景，人员变动那条恐怕不止5%。
到3天偏差最低这个结论我能理解，但研发里有些探索性任务天生拆不到3天，硬拆只会造出一堆没有独立产出的假子任务，维护成本反而更高。相比之下10个工作日就该拆这条更可操作，颗粒度标准最好按任务类型分开定。