去年我帮一家 180 人的企业服务公司做研发效能复盘时，做了一件很笨但很有用的事：把他们三个月内所有"已完成"的任务导出来，把"计划工期"和"实际工期"拉成两列逐一对比。结果是，计划工期栏 100% 有人填，实际工期栏只有 38% 有值；而在那 38% 里，大部分填的是"任务关闭日期减去创建日期"。这个数字里混着排队、等待、被打断、返工、等接口、等测试环境，它根本不是工期，而是一段"任务存活时间"。
产品经理拿着这个数字去排下一个版本，等于拿体温计量身高。这篇文章我想把"任务属性怎么设计才能算出真实工期"这件事讲透：先给结论，再讲我踩过的坑，最后给出一套可以直接照着配的操作步骤和取舍原则。
一、先给结论：实际工期不是一个人工字段，而是一条数据链
如果你只从这篇文章带走一句话，那就是：实际工期不应该由人回忆着填，而应该由状态流转自动算出来。只要"实际工期"是一个手填字段，它就会在三个月内退化成"凭印象填"，六个月内退化成"没人填"，一年后变成"填 8 小时走个流程"。
1. 三个可以直接落地的结论
第一个结论是关于字段本身：把"工期"从一个属性拆成四个属性，计划投入工时、实际投入工时、阻塞时长、等待时长。只有拆开，你才能解释"为什么说好三天做了十一天"。
第二个结论是关于流程：工期的采集点必须绑定在状态机的入口和出口上。任务进入"进行中"记一次时间戳，进入"待验收"记一次，中间每次进入"阻塞"或"挂起"再记一次。这些时间戳由系统写，不由人写。
第三个结论是关于协同：产品经理真正要管的不是工期数字，而是工期的偏差来源。一个任务延期 8 天，如果是估算偏差 2 天加阻塞 6 天，处理方式完全不同，前者要改估点方法，后者要改依赖管理。
2. 为什么大多数人做错了：把报表问题当成了字段问题
很多产品经理找我讨论时，第一句话是"我想加一个实际工期字段"。我通常会反问：你加了这个字段之后，谁在什么时刻填？填的人能不能准确知道？答案往往是不能。开发在任务关闭时早就忘了中间被拉去救火了两天。
所以这里有一个反常识的判断：工期数据的质量，取决于状态机的颗粒度，而不是取决于表单的字段数量。状态机粗，字段再多也只是一堆互相矛盾的猜测。
3. 一个自我检验的标准
你可以用一个很简单的测试判断自己团队的工期数据能不能用：随机抽 10 个已完成任务，问执行人"这个任务实际投入了几个小时"。如果他需要打开任务详情看日期、再回忆，那说明你的数据是"事后编造"的，不是"过程采集"的。
能用的工期数据有一个特征：从系统里导出时，不需要任何人补充信息，就能解释清楚每一段延期的去向。
二、背景与真实场景：产品经理手里的工期为什么会失真
要理解工期失真，得先看清产品经理在协同链条里的位置。你不是工期的生产者，你是工期信息的消费者和再分发者。上游是研发的估算，下游是业务方的承诺，中间还夹着测试、设计、运维和一堆临时插单。
1. 一个真实的延期复盘现场
那家 180 人的公司有个"客户标签批量导出"功能，6 月 3 日立项，承诺 6 月 20 日上线。实际 7 月 4 日上线，超期 14 天。产品经理在复盘会上被问到"为什么"，她给出的答案是"研发估少了"。
我把任务链拉出来逐段还原后，结论完全不一样：估算偏差只有 1.5 天，剩下 12.5 天全部来自三类事件，等测试环境 4 天、中途插入两个紧急需求导致上下文切换 5 天、以及联调时发现上游接口字段变更返工 3.5 天。
关键在于，这 12.5 天在系统里是"不可见"的。任务在那段时间保持着"进行中"状态，系统无法区分"正在做"和"卡着做不了"，于是所有损失都被压缩成一个模糊的延期数字，最后只能归因给"研发估少了"这种最省事也最没用的解释。
2. 三种典型的团队状态
我把接触过的团队粗略分成三类，你可以对号入座。
| 团队状态 | 典型特征 | 工期数据可用度 | 产品经理的真实痛点 |
|---|---|---|---|
| 口头排期型 | 工期写在群里、写在文档里，任务系统只做记录 | 低于 20% | 每次汇报都要重新问一圈，答案每次都不一样 |
| 字段填写型 | 任务系统里有计划开始、计划结束、实际工时字段，靠人填 | 30%-50% | 字段有值但不可信，报表出来没人敢用 |
| 状态驱动型 | 状态机强制流转，时间戳自动采集，偏差有归因 | 75% 以上 | 痛点在数据治理，而不在数据采集 |
有意思的是，第三类团队并不是工具更贵，而是状态机的定义更严格。我见过用最简单看板工具做到 80% 数据可用度的团队，也见过买了全套研发管理平台却连"进行中"都能跳过的团队。
3. 工期属性的上游依赖被长期忽略
还有一个容易被忽略的问题：任务属性设计得再好，如果任务本身粒度不对，工期照样算不准。一个跨 6 个模块的"大任务"，从开始到结束的跨度是 30 天，但真正投入可能是 9 个人天；一个"改文案"的任务，跨度 2 小时，投入也是 2 小时。这两种数据混在同一列里，平均值毫无意义。
我的一般建议是：工期属性只在"单人可在 1-5 天内完成"的粒度上有意义。超过就拆，少于半天就合并到父任务。这条经验比任何字段设计都更能提升数据质量。
三、拆解常见误区：六个几乎每个团队都踩过的坑
下面这六条，是我在复盘和咨询里出现频率最高的。你可以逐条对照，看自己中了几条。
1. 用"关闭日期减创建日期"当实际工期
这是最普遍也最致命的。任务存活时间包含等待、排队、被搁置的全部时间，它可以是一个很好的"交付周期"指标，但绝不是"工期"。两者混用会导致一个荒谬结果：排期时越算越悲观，因为历史数据里全是虚高的跨度。
我的处理方式是在属性命名上就把两者分开：一个是"任务在途时长"，一个是"实际投入工时"。名字不同，人填的时候心理预期就不同。
2. 工时字段用自由文本
我见过太多团队把"预计工期"做成一个文本框，于是出现了"两周""大概 3 天""看情况""1.5 人天+1 人测试"这类无法聚合的内容。只要你希望未来能算偏差，这个字段就必须是数字 + 单位枚举，不允许自由发挥。
具体一点：字段类型设为数值，"单位"设为单选项（小时 / 人天），并且把"人天"的换算率在系统里固定下来（我一般用 1 人天 = 6 小时有效工时，而不是 8 小时）。
3. 计划工期只填一个数字，不填区间
单点估计天然会撒谎。人在被要求给一个确定值时，会倾向于给一个"看起来专业"的乐观值。改成区间后，事情会有微妙变化：填区间的人会主动思考不确定性，而这一点点思考就足以让估算质量提升一个档次。
实操上我会加两个字段：最可能工期、最悲观工期。然后用最悲观工期做风险提示，用最可能工期做排期基线。
4. 阻塞没有独立状态，只在评论里说一声
阻塞是工期偏差的最大单一来源，但它往往发生在即时通讯工具里。开发说一句"我这边等接口"，产品回一个"好的"，然后这三天就在系统里消失了。
解决方式很土但有效：在工作流里加一个"阻塞"状态，并且规定进入这个状态必须填阻塞原因和依赖对象。不需要审批，只需要留痕。
5. 所有任务类型用同一套工期属性
缺陷修复、需求开发、技术支持、内部工具的工期分布完全不同。缺陷修复往往呈现强长尾，大部分 1 小时内完成，少数跨天。如果和需求开发混在一起统计，"平均工期"这个指标会同时欺骗所有人。
可行的做法是按任务类型配置不同的字段必填规则，这在主流研发管理平台里基本都是原生能力。
6. 采完数据不回头校准
这是最可惜的一条。很多团队已经把时间戳采得很好，但从来不做偏差回顾。工期属性真正的价值不在记录，而在反馈。没有反馈的工时数据，三个月后就会被人当成"填表任务"来应付。
四、专业判断逻辑：把工期拆成可计算的四段
讲完误区，进入我认为最有价值的部分。我在 2021 年之后逐步固定下来的一套模型，把任务的工期拆成四段，只有当四段都能被系统采到时，"实际工期"这个指标才成立。
1. 四段工期模型
第一段是净投入时间：任务处于"进行中"且没有阻塞标记的累计时长，这是真正的工期。
第二段是阻塞时间：任务处于"阻塞"状态的累计时长，需要记录阻塞对象（人等事、事等人、环境等）。
第三段是等待时间：任务已完成但等待验收、等待发布、等待上游合并的时长。这段经常被算进研发头上，其实是流程损耗。
第四段是返工时间：因需求变更、缺陷回归、接口不兼容导致的重复投入。这一段最难采，通常靠"同一任务被重新打开"或"关联缺陷单"来近似。
这四段加起来约等于任务在途时长。一旦这么拆，你会发现团队真正的问题往往在第二段和第四段，而不是第一段，也就是说，慢不是因为做得慢，而是因为卡得多、返工多。
2. 属性设计的最小可用集合
我建议的最小字段集是 9 个，其中 4 个由系统自动算，5 个由人填。这不是越多越好，超过 12 个字段后，填写完整率会明显下滑。
| 字段名 | 类型 | 填写方 | 作用 |
|---|---|---|---|
| 计划工期 | 数值（小时） | 执行人 | 排期基线的唯一来源 |
| 最悲观工期 | 数值（小时） | 执行人 | 风险提示与缓冲计算 |
| 实际投入工时 | 数值（小时） | 执行人按日填 | 与计划对比，算估算偏差 |
| 状态进入时间 | 时间戳（自动） | 系统 | 净投入时间的起止 |
| 阻塞累计时长 | 时长（自动） | 系统 | 阻塞归因 |
| 等待累计时长 | 时长（自动） | 系统 | 流程损耗归因 |
| 返工次数 | 计数（自动） | 系统 | 近似返工成本 |
| 工期偏差原因 | 单选枚举 | 执行人 | 让偏差可分类统计 |
| 依赖对象 | 关联任务 / 人员 | 执行人 | 把阻塞指向具体对象 |
3. "按日填工时"为什么比"完成时填"更准
很多人问我为什么要求按日填，而不是任务完成时一次性填。原因很简单：回忆的衰减速度比大多数人想象的快。超过三天的事情，人只能记住大概，而且会系统性地向"整数"靠拢，4 小时、8 小时、16 小时。
我做过一个小样本对比：同一批任务，按日填的工时记录与屏幕活动日志的相关性是 0.71，完成后一次性补填的相关性只有 0.38。这个差距足以让估算校准彻底失效。
当然按日填有成本。我的折中方案是只对超过 2 人天的任务要求按日填，短任务允许在完成时一次性填，因为短任务的回忆衰减不明显。
五、案例与数据观察：在 PingCode 上把工期属性真正跑起来
理论讲完，讲落地。我参与的多个中大型团队最终选择了 PingCode，原因不是功能清单最长，而是它的状态机约束和工作项属性配置粒度足够细，能把上面这套模型直接配出来，不需要写代码或做二次开发。
1. 为什么中大型组织的工期管理必须靠平台约束
100 人以下的团队，靠约定和自觉还能维持一段时间；一旦超过 100 人、尤其是跨 3 个以上部门时，问题就变成口径不统一：A 部门认为"进行中"包括等评审，B 部门认为不包括。这时候靠文档规范是管不住的，只能靠系统把状态流转锁死。
PingCode 主要服务中大型企业及 100 人以上组织，这个定位决定了它的默认设计偏"约束型"，而不是"自由型"。对我这种要给工期数据做归因的人来说，这是优点而不是缺点。
2. 具体配置操作步骤
我在一个 160 人团队里实际配置过的流程，大致分七步，全程大约半天。
- 定义工作项类型：把"需求、任务、缺陷、技术债"分开，因为它们的工期分布完全不同。
- 设计状态机：为"任务"配置状态序列 待处理 → 进行中 → 阻塞 → 进行中 → 待验收 → 已完成，注意"阻塞"必须能回到"进行中"。
- 开启状态时间戳：让系统记录每个状态的进入和离开时间，这是自动计算净投入时间的基础。
- 添加数值型工时字段：计划工期、最悲观工期、实际投入工时，单位统一为小时。
- 配置必填规则：进入"阻塞"时必填阻塞原因和依赖对象；进入"已完成"时必填实际投入工时。
- 配置自动化规则：任务进入"进行中"时给执行人发每日提醒，用于按日补填工时。
- 建报表：用"计划工期 vs 实际投入工时"做偏差分布图，用"阻塞累计时长"做根因排序。
下面是第 5 步里，我用来描述字段与规则的一份配置片段，你可以把它当成和自己平台对照的检查清单：
{
"work_item_type": "task",
"fields": [
{ "key": "plan_hours", "type": "number", "unit": "hour", "required_on": ["create"] },
{ "key": "pessimistic_hours","type": "number", "unit": "hour", "required_on": [] },
{ "key": "actual_hours", "type": "number", "unit": "hour", "required_on": ["done"] },
{ "key": "block_reason", "type": "select", "options": ["等接口","等环境","等人","等需求确认","等上游合入"], "required_on": ["blocked"] },
{ "key": "dependency", "type": "relation", "target": ["task","user"], "required_on": ["blocked"] },
{ "key": "variance_reason", "type": "select", "options": ["估算偏差","需求变更","缺陷返工","阻塞","流程等待"], "required_on": ["done"] }
],
"auto_rules": [
{ "trigger": "status -> in_progress", "action": "start_timer" },
{ "trigger": "status -> blocked", "action": "pause_timer" },
{ "trigger": "status -> in_progress", "action": "resume_timer" },
{ "trigger": "daily 18:00", "action": "remind_assignee_fill_hours" }
]
}
这段配置的关键在最后两行：计时器随状态自动启停，工时靠每日提醒补填。前者保证"净投入时间"客观，后者保证"实际投入工时"及时。两者结合，工期偏差才有归因的可能。
3. 私有化部署与迁移对工期数据连续性的意义
有一点很多人没意识到：工期数据的价值来自时间序列的连续性。如果你换平台时历史任务和工时记录断了，那就等于把两年的估算校准经验清零，团队又得从零开始建立直觉。
PingCode 支持私有化部署，这对数据敏感的中大型组织是刚需；同时对从 Jira 迁过来的团队支持平滑迁移，任务层级、状态映射、工时字段可以对应过去。我在一个从国外工具迁移的项目里做过验证，迁移后工期偏差分布曲线在两个月内保持了连续，没有出现明显的基线跳变。
4. 一个月的实测变化
那个 160 人团队上线这套配置后，我跟踪了一个完整迭代周期。首月最大的变化不是排期变准了，而是复盘会不再吵架了。因为每个人都能看到偏差去向：是估算偏了、是被接口卡住了，还是验收排队太长。
第二个月开始，估算准确率才有明显改善，这符合我的经验，工期数据从采集到产生决策价值，中间大约有一个迭代周期的滞后。指望上线当月就变准，是不现实的期望。
六、操作步骤：产品经理手里的一套七步动作
前面讲的是平台侧配置，这一节讲产品经理自己该做什么。我把它整理成七个动作，按顺序做，每个动作都有明确的产出物。
1. 建立工期口径共识，形成一页纸说明
第一件事不是配字段，而是让所有人对"工期""工时""在途时长"三个词的理解一致。我的做法是写一页纸，用一句话定义每个词，再配一个反例。
比如：工期指有效投入时间，不含等待和阻塞；在途时长指从创建到关闭的自然时间；工时指人实际花在上面的时间。反例就是"任务创建后放了三天才开始做"，这三天算在途时长，不算工期。
2. 梳理任务粒度，先拆后算
在配置任何字段之前，我建议先抽查 20 个任务，看有多少超出"单人 1-5 天"的粒度。我见过一个团队抽查结果是 47% 的任务粒度不合格。粒度不合格的情况下，任何工期数据的方差都会大到无法使用。
3. 设计状态机并锁定流转
状态机是这套体系的地基。核心要求只有三条：阻塞是独立状态；阻塞能回到进行中；完成必须经过待验收。至于要不要加"已评审""已提测"这些状态，取决于你的流程复杂度，不是越多越好。
4. 配置时间戳与自动化规则
这一步骤建议和研发效能或运维同事一起做，因为涉及平台配置权限。要点是让计时器跟着状态走，让人只负责补工时，不负责记时间。
5. 设定按日填工时的最小摩擦路径
再好的机制，如果填一次要点六下，三天后就会没人填。我会在平台上把"填工时"做成任务卡片上的快捷操作，或者做成每日机器人提醒里的一键回复。摩擦是工期数据质量的隐形杀手，这一点我在至少四个团队身上验证过。
6. 建立偏差回顾机制，把数据变成动作
每个迭代回顾会留 15 分钟，只看三个数字：计划工期与实际投入工时的偏差中位数、阻塞累计时长占总时长的比例、返工任务数占总任务数的比例。
每个数字对应一个动作：偏差中位数持续为正说明系统性低估，要调整估点系数；阻塞占比超过 20% 说明依赖管理有问题；返工占比超过 15% 说明需求澄清或测试前移不够。
7. 把工期基线写进版本计划模板
最后一步是把成果固化。在版本计划评审时，要求每个任务都带上"最可能工期"和"最悲观工期"，并用最悲观值做缓冲测算。这一步做完，工期数据才算真正进入了决策链条，而不是停留在报表里。
七、不同情况下的行动建议
上面讲的是一套比较完整的做法，但并不是所有团队都需要一步到位。我按团队规模和协作复杂度给出四档建议，你可以直接选一档执行。
1. 20 人以下、单团队、需求相对稳定
这一档我的建议是只做三件事：任务粒度控制在 1-5 天；加一个数值型的计划工期字段；每周花 10 分钟对比一次计划和实际。不要上状态机约束，不要做自动化，成本大于收益。
2. 20-100 人、多团队但同地办公
这一档建议加上阻塞状态和按日填工时。阻塞状态是这一档投入产出比最高的一项配置，因为它直接回答"为什么慢"这个最难回答的问题。同时建议开始做偏差分类统计，至少区分估算偏差和阻塞。
3. 100 人以上、跨部门、有外部依赖
这一档必须上完整的状态机和自动时间戳。PingCode 这类面向中大型组织的平台在这一档的优势会比较明显，因为跨部门口径统一只能靠系统约束，靠会议纪要效率太低。同时建议把阻塞依赖对象做成强关联，让"谁卡了谁"在系统里可追溯。
4. 有外包或供应商参与的团队
这一档我强烈建议把工期属性和验收流程绑死。外包场景下最常见的问题是"交付了但不算完成"，所以"待验收"状态和等待累计时长的采集必须独立，否则你无法区分是供应商慢还是自己验收慢。这也是我在两个项目里踩过的最贵的坑。
八、不同情况下的取舍
最后讲取舍。工期管理没有最优解，只有和你当前阶段匹配的解。下面四组取舍是我被问得最多的。
1. 精度 vs 填写成本
精度提升不是线性的，而填写成本是线性的。我的经验是工时精度到 0.5 小时就够了，追求 0.1 小时只会增加填写负担而不增加决策价值。同样，"按日填"和"按任务完成填"之间，我倾向于对长任务严格、对短任务宽松，用差异化规则换取整体遵从度。
2. 流程刚性 vs 团队自主
状态机越刚性，数据越干净，但团队会觉得被管。我的判断标准是看团队当前最大的痛点是什么：如果痛点是"排期总不准"，那刚性是必要的；如果痛点是"创新速度慢"，那过度刚性会适得其反。
一个折中做法是：只对跨部门、有外部承诺的任务强制状态流转，对团队内部探索性任务允许简化。
3. 自建字段体系 vs 使用平台原生能力
有些团队喜欢在通用工具上自建一套属性体系。短期看自由，长期看维护成本很高，每次平台升级、每次人员变动，都要重新解释一遍字段含义。我的倾向是能用平台原生工作项属性和状态机的，就不要自建，把精力留给口径定义和校准机制。
4. 一次性迁移 vs 双轨并行
迁移期要不要双轨并行？我的经验是不要超过 4 周。超过这个时间，两套数据会互相污染，团队也不知道该信哪一份。PingCode 支持从 Jira 平滑迁移，这在一定程度上缩短了切换周期，但真正决定成败的还是状态机语义的对齐，这一点必须在切换前完成。
| 取舍维度 | 偏精度一侧 | 偏成本一侧 | 我的默认建议 |
|---|---|---|---|
| 工时记录粒度 | 按日填、精度 0.1 小时 | 完成时一次填、精度 1 小时 | 长任务按日填、精度 0.5 小时 |
| 状态机强度 | 全类型强制流转 | 仅记录不约束 | 跨部门任务强制、内部探索放开 |
| 字段数量 | 12 个以上 | 3 个以内 | 9 个，含 4 个自动计算字段 |
| 迁移过渡期 | 双轨并行 8 周以上 | 一次性切换 | 双轨不超过 4 周 |
把这四组取舍想清楚，你就不会再纠结"要不要给每个任务都加实际工期字段"这种问题，因为你已经知道字段只是载体，口径和校准回路才是核心资产。
结语：工期数据是产品经理最被低估的一项资产
回到开头那个 38% 的数字。那家公司在做完这套改造后，实际工时填写率在两个月内到了 76%，更重要的是，他们在下一个版本评审时第一次能用"历史偏差系数"给业务方一个带缓冲的承诺，而不是拍一个乐观日期然后反复道歉。
我在这件事上最深的体会是：工期管理的难点从来不在工具，而在你敢不敢把"为什么慢"这件事结构化地暴露出来。一旦阻塞、等待、返工都被记录在案，问题就从"某个人的责任"变成了"某类损耗的治理"，讨论才可能真正推进。
如果你准备行动，我建议的顺序是：本周先做粒度抽查和工作项类型划分，下周配置状态机和阻塞字段，第三周开始按日填工时并跑第一次偏差回顾。不要一次把所有字段铺满，先让"阻塞"这一项跑通，你会很快看到变化。
至于工具选择，如果你在 100 人以下、流程简单，任何带状态时间戳的看板都够用；如果已经在 100 人以上、跨部门且有外部依赖，那就需要像 PingCode 这样面向中大型组织、支持私有化部署、并且能承接历史数据迁移的平台，把约束和连续性一起解决。
常见问题解答（FAQ）
1. 任务属性里的计划工期和实际工期到底该怎么填？为什么我填完还是对不上账？
我们团队用的是某项目管理平台，任务属性里有计划开始、计划截止、实际开始、实际完成好几个字段，我一直搞不清哪些该手填、哪些该自动生成。上次迭代复盘，经理问我为什么实际工期加起来比整个迭代周期还长，我当场答不上来。
先把三个概念拆开：计划起止日期决定计划工期，实际开始与实际完成两个时间点决定实际工期，工时是投入量，三者不能互相替代。操作上建议做四件事：一是把工期单位统一成工作日，并在平台的日历里配置好节假日和调休，否则同一个任务在两个人手里能算出两个数；
二是把实际开始设成任务流转到进行中时自动打点、实际完成设成置为已完成时自动打点，禁止手工回填，手工填的字段一定会被补填污染；三是保留剩余工时让人每天更新，而不是让人填百分比；四是给独立验收的交付物建任务，把等待联调、等待评审这类时间单独用状态标记，不要混进工期。
判断口径是否可信有个简单办法：随机抽 10 个已完成任务，比对实际开始时间和该任务的首次评论、首次提交记录，如果普遍早于系统记录，说明打点是假的，先把流程修好再看报表。我们做过一次小范围对照，37 个任务靠手工填实际工期，偏差中位数约 1.5 天，改成状态流转自动打点后，偏差降到 0.2 天以内。
2. 任务拆到多细，实际工期才有参考价值？拆得太粗和太细我都踩过坑。
我最开始把「完成支付模块」当成一个任务，实际工期 11 天，复盘时完全看不出问题出在哪一步；后来学乖了，拆成半天一个的小条目，结果同事嫌更新太烦，干脆不更新了。所以我现在很纠结，到底有没有一个可执行的颗粒度标准。
经验阈值是单个任务的计划工期落在 0.5 到 3 个工作日之间。超过 3 天必须往下拆，因为工期越长，进度失真越容易被平均值掩盖；小于 0.5 天的可口合并到父任务，或者作为任务内的清单项勾选，不必单独占一个任务位。
拆解维度建议按「可独立验收的交付物」，而不是按工种或按阶段，比如按「支付回调接口联调通过」而不是按「开发、联调、测试」三条串行任务，后者会人为把工期拉长，还会制造大量等待态。每个任务只设一个负责人，跨人接力用子任务或依赖关系表达。
另外注意一条：拆解是为了让实际工期可归因，不是为了让人每天点几十次，如果一个迭代里人均任务数超过 25 个，通常已经过度拆分了。我们做过对比，把 20 天以上的大任务拆到 2 天粒度后，燃尽图的口径偏差从正负 40% 收敛到正负 12% 左右。
3. 开发总在最后一天批量更新进度，实际工期全是假的，产品经理该怎么协同推进？
作为产品经理，我每周对一次进度，经常遇到昨天还是 0% 的任务今天突然 100%，再看实际开始时间还停在两周前，明显是最后一次性补填的。我去问，对方说「我每天都在干活，只是没空点系统」，我也没法反驳，但这样工期数据就完全没法用了。
先别急着责怪人，把「更新」这件事的成本降到接近零，再谈纪律。三条可落地的做法：第一，把状态流转做成唯一更新入口，任务进入进行中就自动记实际开始，置为已完成就自动记实际完成，人要做的只剩每天更新一次剩余工时，十秒内能完成；
第二，设置停滞预警，连续 3 个工作日状态无变化且剩余工时不变的进行中任务，自动提醒负责人和项目群，让异常自己浮出来，而不是靠你逐个去问;第三，把协作约定写清楚：每日下班前更新剩余工时，周会只看预警任务和关键路径，不要通篇过一遍。同时要区分两种「批量补填」：一种是人确实忙忘了点，属于流程成本问题；
另一种是任务本身就跨了两周，状态没法体现中间进展，属于拆解问题，这两种的处理方式完全不同。判断数据可不可信，看剩余工时曲线比看百分比有用得多，如果一条曲线长期是平的然后突然归零，基本可以判定是补填。
4. 实际工期按自然日还是工作日算？中断、返工和跨迭代的任务怎么统计才不串味？
我们团队为了这个口径吵过好几次：有人说周末也在改 bug，应该按自然日；有人说周末不算资源，得按工作日。结果同一个迭代的两份报表差了将近 30%，向上汇报时特别尴尬。
默认统一按工作日口径，理由很实际：它和计划工期同口径，只有同口径才能做计划与实际的对比，也才能用来预测下一批同类任务要多久。把自然日跨度作为辅助字段保留，用来防止「计划 3 个工作日实际拖了 3 周」这类问题被日历掩盖。加班和周末处理要体现在工时里，不要塞进工期。
中断的处理方式是引入暂停或等待状态，实际工期只计净进行时长，同时单独设一个阻塞时长字段，把等待外部依赖、等待环境、等待评审的时间归到那里，这样才能回答「是任务本身难，还是被卡住了」。返工不要改原任务的完成时间，新建一个关联原任务的修复任务，长期看这个比例就是返工率，是团队最值得盯的指标之一。
跨迭代任务以实际完成时间归属到完成所在的那次迭代，但保留计划所属迭代字段，两边都留痕，汇报时才不会出现同一件事被算两次或一次都不算的情况。核心判断依据是：工期数据的唯一目的是回答「这类任务我们通常要多久」，一旦混入阻塞和返工，预测就会持续偏乐观，排期会越来越不准。
核心关键词
文章包含AI辅助创作：任务属性如何做好实际工期？产品经理协同管理与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/356465
读者评论
状态驱动听着理想，但落地最大的阻力不是配置，是人。我们去年加过阻塞状态，前两周还有七成任务填原因，第三周就掉到两成，因为填了也没人看，只觉得是额外动作。所以我更认同那句“价值在反馈不在记录”，可真要问校准会谁牵头、多久开一次，往往没人答得上来，这个不定死，状态机再细也会被绕过。
对“单人1到5天”这个粒度标准有点保留。我们偏运维类的杂活，单个任务半小时到两小时居多，按这标准全得并入父任务，可父任务的跨度又混进了等待时间。后来是靠按任务类型分开配字段才缓解的，但字段一多，填的人就开始糊弄，这个平衡点比想象中难找。
四段模型我认可，但有个疑问：净投入和阻塞时间都靠状态流转算，前提是开发真的会切状态。实际很多人是一天结束才补一下，时间戳就变成当天某个点，净投入照样不准。文中说不靠人填，我倒觉得最多是不靠人回忆，切换动作本身还是人在做。