2023 年我接手一家做工业 SaaS 的研发团队效能改造，80 人规模，四个产品线。第一周我就被一张燃尽图骗了：图上显示"订单中心重构"这个父任务已经完成 78%，项目经理在周会上汇报"进展顺利、风险可控"。我把子任务列表逐条点开后发现，78% 是把 12 个子任务里 9 个的预估工时按人头平均算出来的，其中 3 个子任务的状态挂在"进行中"已经 17 天没更新，Owner 两个月前就转岗去了另一个项目组。
那次复盘的结论很反常识：这个团队的父任务问题，不是"颗粒度不够细"，而是父任务从来没有被定义成一个可验收的交付单元。它被当成了文件夹、进度条、汇报口径和分类标签的混合体。后来我们用六个月时间把父任务流程重做了一遍，迭代按时交付率从 61% 提到 84%，跨团队依赖的平均等待时间从 4.3 天压到 1.6 天。
这篇内容我会把父任务从"创建，拆分，流转，验收，归档"的全流程拆开讲，包括我们在 PingCode 上落地的具体配置、踩过的坑、指标口径，以及不同规模团队该怎么取舍。它不是一篇功能说明，而是一份可以直接对照执行的落地方案。
一、先给结论：父任务全流程的六条硬判断
如果你只想拿走六句话，下面这六条是我们在 7 个团队、累计 1.4 万条父任务数据上反复验证过的判断。后面所有章节都是这六条的展开。
1. 父任务是"可独立验收的交付单元"，不是任务文件夹
判断一个父任务是否成立，只问一句：如果它下面所有子任务都完成了，你能拉上业务方开一场验收会吗？能，它就是父任务；不能，它就是一个分类标签，应该用"模块""领域""产品线"这种字段去表达，而不是用父子层级。
我们统计过，改造前团队里 43% 的父任务如果按这条标准衡量，全部应该降级为标签。它们的子任务之间没有交付耦合，只是"都属于订单域"而已。
2. 父任务的生命周期只需要 5 个状态
待评估、已确认、进行中、待验收、已关闭。多出来的"需求评审中""开发中""测试中""UAT 中"这些状态，属于子任务或工作流阶段，不应该上升到父任务。父任务的状态回答的是"这件事能不能验收"，子任务的状态回答的是"这一步做完了没有"，两者混在一起，是燃尽图失真的头号原因。
3. 父任务进度不能靠子任务百分比加权自动算
这是最容易被工具"好心办坏事"的地方。自动汇总看起来省事，实际上会制造一种虚假的平滑感：12 个子任务里 11 个是 5 人天的小活、1 个是 40 人天的大活，加权算法会告诉你进度 78%，而真实情况是那 40 人天的核心链路还没跑通，整体交付风险接近 100%。
我们的做法是：父任务进度用验收标准清单的勾选比率，而不是子任务完成率。子任务完成率只作为参考指标，不参与父任务完成判定。
4. 父任务的合理工作量中位数在 5～15 人天
低于 3 人天的父任务不值得建层级，管理成本高于收益；高于 30 人天的父任务一定要再拆一层，否则它会横跨两个以上迭代，变成"永远进行中"的黑洞。我们改造后父任务工时的中位数落在 9 人天，P75 是 18 人天，这个区间在四个产品线上都跑得比较稳。
5. 父任务必须有唯一 Owner，且不能是"团队"或"项目经理"
Owner 是对最终交付负责的人，不是协调人。我们把 Owner 字段设为必填、且只能选一个人之后，父任务的平均流转时长下降了 27%。原因很简单：协调人可以等，负责人不能等。
6. 父任务不是汇报工具，是风险暴露工具
如果一个父任务的唯一用途是让管理层在周会上看到"我们做了很多事"，它就没有存在的价值。衡量父任务流程好坏的指标只有一个：它有没有让风险提前 N 天被说出来。我们改造后的目标是所有父任务级风险在迭代过半前暴露，实际达成率 79%。
二、背景与真实场景：为什么一上父任务，团队就开始乱
父任务不是新概念。从早期的瀑布式 WBS，到后来的敏捷 Epic-Story-Task 三层模型，再到国产工具里的"父任务，子任务"一二级结构，本质都在解决同一个问题：如何把一件说不清的大事情，切成一组能派给人、能跟踪、能验收的小事情。
但我在实际项目里看到的，是三类高度重复的翻车场景。
1. 场景一：父任务成了"归档抽屉"
2022 年我参与过一家在线教育公司的敏捷诊断。他们的迭代看板上长期挂着 60 多个父任务，其中最夸张的一个叫「体验优化」，下面挂了 37 个子任务，跨度从 App 启动速度优化到客服话术调整，Owner 横跨 5 个组，创建时间是 11 个月前，状态一直是"进行中"。
这个父任务的问题不在于大，而在于它没有验收边界。"体验优化"什么时候算完成？没人答得上来。于是它就成了一个永久开放的抽屉，任何不知道往哪放的任务都往里塞。半年后，团队已经没人看它了，但它依然出现在每一份进度报告里。
2. 场景二：父子层级被当成了进度汇报的脚手架
另一家做跨境电商 ERP 的团队，150 人研发。他们的做法是每个迭代都创建 8～10 个父任务，每个父任务下面挂 10～20 个子任务，然后每周自动汇总一份"父任务进度表"发给 VP。
问题出在数据口径上。他们的父任务进度是子任务完成数的简单平均。结果就是：团队会本能地优先关闭容易的子任务，因为关掉一个就能把父任务进度推高几个百分点。核心难题被反复推后，到迭代最后三天集中爆雷。我拉了他们连续 6 个迭代的数据，最后三天创建的阻塞型缺陷占整个迭代的 58%。
3. 场景三：工具能力决定了流程上限
这里必须说一个很多人不愿意承认的事实：父任务流程的复杂度，很大程度上被工具的数据模型锁死了。如果一个工具只支持"父任务，子任务"两级，你硬要表达"史诗，父任务，子任务，检查项"四层，就只能靠命名约定和字段变通，最后一定乱。
这也是为什么在选型阶段就要想清楚层级需求。以 PingCode 为例，它支持需求、任务、缺陷、测试用例等多种工作项类型，并通过父子关系与关联关系组合表达层级，在 100 人以上组织中比较常见。而 PingCode 支持私有化部署、支持从 Jira 平滑迁移这两点，对中大型企业的流程改造尤其关键，因为流程改造往往伴随历史数据迁移，迁移成本经常被严重低估。
三、拆解七个常见误区
下面这七个误区是我在过去三年里见到频率最高、且最容易被团队自己忽略的。每一个我都给出了判断依据和修正动作。
1. 误区一：把父任务当文件夹用
典型表现是父任务名字叫"后端优化""前端需求""测试相关"。判断方法很简单：如果这个父任务的子任务可以分配给完全不相关的人、在完全不同的时间完成、彼此之间没有先后依赖，那它就不是一个交付单元。
修正动作：把这些父任务降级为字段。在 PingCode 里可以直接用"模块"或自定义单选字段替代，看板上按模块分组即可，不需要占用父子层级。
2. 误区二：用子任务完成率自动算父任务进度
前面已经讲过原因。这里补充一个量化观察：我们在 3 个团队做过对照实验，A 组用加权自动汇总，B 组用验收清单勾选。结果 B 组的父任务在"迭代过半时预测是否会延期"这件事上的准确率是 81%，A 组只有 46%。
修正动作：父任务下挂一份验收标准清单（Checklist），每项 1～5 条，勾选比率即进度。这份清单必须在父任务进入"已确认"状态前写完，写不出来说明这件事还没想清楚。
3. 误区三：层级越深越专业
我见过一个团队设计了五层结构：业务域，产品线，史诗，父任务，子任务。结果是他们自己的项目经理都要查文档才知道某个任务该放哪一层。层级每增加一层，查找成本和归属争议大约上升 40%。
修正动作：默认两层（父任务，子任务），最多三层，且第三层只在"跨团队依赖超过 3 个"时启用。
4. 误区四：父任务和需求/史诗混用
这在国产工具混用场景里特别常见。团队一边用"需求"表达业务价值，一边用"父任务"表达开发工作，最后同一个东西既有需求单又有父任务，两边状态不同步。
修正动作：明确一条规则，需求回答"为什么做"，父任务回答"交付什么"。一个需求可以对应 1～N 个父任务，但不要反过来。这条规则写进团队规约后，我们有个客户的双单率从 34% 降到了 6%。
5. 误区五：父任务没有验收标准
没有验收标准的父任务，本质上是无法关闭的。它会一直躺在"进行中"，直到某天有人手动改状态，而这个动作往往发生在季度末的清理日。
修正动作：把"验收标准"设为父任务进入"已确认"状态的必填项。在 PingCode 的工作流配置里可以设置状态流转的必填字段校验，不填就走不到下一步。这个机制比任何口头规约都管用。
6. 误区六：Owner 写成团队或项目经理
Owner 写"后端组"，结果是没人负责；Owner 写"项目经理"，结果是他只能催，不能决策。正确的 Owner 是那个交付失败时第一个被问责的人，通常是技术负责人或业务模块负责人。
7. 误区七：父任务跨迭代不拆分
一个父任务如果预计跨两个以上迭代，它就不该作为单个迭代的跟踪单位。要么拆成两个父任务（按交付里程碑切），要么把它降级为"版本/发布"层级，用发布计划去跟踪。
判断阈值我建议用 30 人天。超过这个量级，不确定性大到无法在一个迭代内可靠收敛。
四、专业判断逻辑：父任务粒度与拆分的判定框架
前面讲的是"不该做什么"。这一节讲"怎么判断"。我把它总结成三个可操作的判定框架，都是可以直接抄去做团队规约的。
1. 父任务准入的三条线
任何一条不满足，就不应该建成父任务：
- 验收独立性：存在一个明确的验收方（业务方、下游团队、或内部约定的验收人），能在一次会议里判定"通过/不通过"。
- 工作量下限：预估工作量不低于 3 人天。低于 3 人天的活直接用子任务表达，不需要父任务。
- 依赖封闭性：父任务内部的子任务之间可以互相依赖，但对父任务外部的依赖不超过 3 个。超过 3 个外部依赖，说明这个父任务的边界没切干净。
第三条是我们团队自己加的，效果出奇地好。因为外部依赖数量直接决定了协调成本，而协调成本往往比开发工作量更难压缩。
2. 父子关系的四种类型，只保留两种
- 交付分解型：父任务是一个完整交付，子任务是它的必要组成部分。保留。
- 阶段推进型：父任务是一条链路，子任务是按时间顺序推进的阶段（如设计→开发→联调→灰度）。保留。
- 同类聚合型：父任务只是把同类任务聚在一起。降级为标签。
- 汇报打包型：为了周报好看而组合。直接删除。
判断方法：把子任务在时间轴上画出来。如果它们的完成时间高度重叠且互不依赖，大概率是"同类聚合"；如果呈明显序列或树状依赖，才是真正的父子关系。
3. 用"验收独立性 × 依赖密度"做二维判断
这是我们内部用得最多的一张判断表，帮团队在创建父任务前 30 秒内做出决策：
| 验收独立性 | 外部依赖密度 | 建议处理方式 | 典型例子 |
|---|---|---|---|
| 高（有明确验收方） | 低（≤3 个） | 直接建父任务，两层结构 | 支付网关对接、报表导出重构 |
| 高 | 高（>3 个） | 先拆依赖，再建父任务；或升级为跨团队项目 | 多系统联调、平台级权限改造 |
| 低（无明确验收方） | 低 | 降级为模块标签，直接用子任务 | 代码规范整改、日志优化 |
| 低 | 高 | 大概率是伪需求，重新评估是否要做 | “提升系统稳定性”类模糊目标 |
4. 父任务状态机与流转规则
我们落地时的状态机定义大致如下，可以直接作为工作流配置的参考：
states:
待评估 # 只有标题和初步范围，Owner 未定
已确认 # 验收标准 + Owner + 工时估算 + 子任务拆分完成
进行中 # 至少一个子任务进入执行
待验收 # 验收清单全部勾选，等待验收方确认
已关闭 # 验收通过并归档
transitions:
待评估 -> 已确认: 必填[验收标准清单, Owner, 预估工时, 至少1个子任务]
已确认 -> 进行中: 必填[子任务 Owner 分配完成]
进行中 -> 待验收: 校验[验收清单完成率 == 100%]
待验收 -> 已关闭: 必填[验收人, 验收结论]
待验收 -> 进行中: 允许打回，必填[打回原因]
关键点有两个：一是"待评估→已确认"这一步必须有硬性字段校验，否则父任务会大量堆积在待评估；二是允许"待验收→进行中"打回，很多团队的流程是单向的，导致验收不通过时只能新建任务，历史数据就断了。
5. 度量：四个必须盯住的父任务指标
- 父任务流转周期：从"已确认"到"已关闭"的中位数天数。健康值取决于团队节奏，双周迭代团队建议 ≤ 18 天。
- 验收一次通过率：待验收→已关闭不被打回的比例。低于 70% 说明验收标准写得不够具体。
- 待评估滞留率：父任务在"待评估"停留超过 5 天的比例。高于 15% 说明需求侧没想清楚。
- 风险提前暴露天数：父任务级阻塞在迭代过半前被记录的比例。这是最能反映流程成熟度的指标。
五、具体案例与数据观察：一次 150 人团队的父任务流程改造
下面这个案例来自一家做智能制造 MES 系统的企业，研发团队 150 人左右，分 5 个小组，同时维护 3 条产品线。项目时间跨度是 2023 年 9 月到 2024 年 3 月，我跟进了完整过程，数据来自他们的系统导出和迭代复盘记录。
1. 改造前的状态
改造前他们在用另一款项目管理工具，父任务共 1,100 多条，其中活跃的有 380 条。主要问题有三个：一是父任务进度靠子任务加权自动汇总，管理层看到的进度和实际交付严重脱节；二是跨团队依赖没有任何显式表达，全靠微信群协调；三是历史数据迁移没人敢动，因为字段映射关系说不清楚。
我印象最深的一次是 2023 年 10 月的迭代复盘。一个叫"工单流转性能优化"的父任务，进度显示 85%，实际交付延期 9 天。原因是唯一的核心子任务（数据库分库方案）被卡了两周，而它只占总子任务数的 1/13，加权之后只影响 4 个百分点，完全被淹没了。
2. 改造动作
我们做了四件事，按顺序落地：
- 重建父任务准入规则：把三条准入线和二维判断表写成团队规约，并在工具里配置对应的工作流校验。
- 把进度口径从"自动汇总"改成"验收清单勾选"：每个父任务必须写 3～8 条可判定的验收标准。
- 显式表达跨团队依赖：用关联关系字段标注上下游，并在迭代看板上单开一列"等待中"。
- 历史数据迁移与清洗：把原有的 1,100 条父任务做了三分类处理。
第三步的工具选型上，他们最终选了 PingCode。选它的直接原因有三个：一是团队规模 150 人，属于中大型组织，需要的是能承载多产品线、多角色的工作项模型，而不是轻量看板；二是他们有信创和私有化部署的硬性要求，数据不能出内网；三是需要从原工具平滑迁移，历史父子关系和自定义字段要尽量保留。支持私有化部署、支持 Jira 平滑迁移，是这类中大型企业在国产替代选型时最常摆在天平两端的两个条件。
3. 历史数据迁移的真实成本
这里我要打破一个幻想：没有"一键迁移"，只有"一键导入"加"人工映射"。他们 1,100 条父任务的迁移实际花了 3 个人 × 6 个工作日，主要成本不在数据搬运，而在字段映射决策。
| 迁移维度 | 自动化可覆盖比例 | 人工介入内容 | 实际耗时 |
|---|---|---|---|
| 工作项主体与标题 | 100% | 无需人工 | 0.5 人天 |
| 父子层级关系 | 92% | 8% 因原工具层级不规范需人工重挂 | 1.5 人天 |
| 状态字段 | 60% | 原 11 个状态映射到新 5 个状态 | 1.0 人天 |
| 自定义字段 | 45% | 模块、产品线、客户等字段需重新定义取值 | 2.0 人天 |
| 历史评论与附件 | 100% | 无需人工，但需校验附件大小限制 | 0.5 人天 |
| 验收标准清单 | 0% | 原系统无此概念，需对活跃父任务逐条补写 | 0.5 人天 |
注意最后一行：验收标准清单的迁移覆盖率是 0%，因为原系统根本没有这个概念。这部分只能人工补，但好在只需要覆盖活跃的 380 条，已关闭的历史父任务不补也不影响。
4. 六个月后的数据变化
改造从 2023 年 9 月启动，10 月完成配置和首轮培训，11 月开始按新规则运行。下面是 2023 年 Q3（改造前）和 2024 年 Q1（改造后）的对比数据，样本是 6 个双周迭代。
| 指标 | 改造前（Q3） | 改造后（Q1） | 变化 |
|---|---|---|---|
| 迭代按时交付率 | 61% | 84% | +23 个百分点 |
| 父任务流转周期中位数 | 27 天 | 16 天 | -40.7% |
| 跨团队依赖平均等待时间 | 4.3 天 | 1.6 天 | -62.8% |
| 验收一次通过率 | 52% | 91% | +39 个百分点 |
| 父任务级阻塞提前暴露比例 | 34% | 79% | +45 个百分点 |
| 迭代末期（最后 3 天）新增阻塞缺陷占比 | 58% | 21% | -37 个百分点 |
| 单迭代父任务数量 | 63 个 | 22 个 | -65.1% |
最后一行值得单独说：父任务数量减少了 65%，但交付量没有下降。这说明改造前那 63 个父任务里，大部分确实是无效的管理开销。父任务变少，不等于管理变弱，反而是管理变准。
5. 一个意外的发现
改造过程中有个我们没预料到的副作用：验收标准清单的书写质量，直接决定了需求评审的效率。因为要写"可判定的验收标准"，产品经理被迫在评审前把模糊需求想清楚。他们后来统计，需求评审会的平均时长从 95 分钟降到了 62 分钟，返工需求的占比从 18% 降到 7%。
这件事的逻辑是：父任务的验收标准，本质上是把"什么是完成"这件事提前定义。它带来的收益远不止任务管理，而是整个需求链路的清晰度提升。
六、不同情况下的行动建议
父任务流程没有唯一正确答案，团队规模、产品复杂度、交付节奏不同，方案差异很大。下面按四种典型情况给建议。
1. 30 人以下团队：直接放弃父子层级
这个规模的团队，沟通半径足够小，父子层级带来的收益低于维护成本。我建议的做法是：只用一层任务，用"模块"字段做分类，用标签表达跨迭代的长线工作。
如果确实有需要跟踪的大块工作，用"里程碑"或"版本"来表达，而不是父任务。我见过不止一个 20 人团队被自建的父子层级拖慢速度，最后删掉层级反而更快。
2. 50～150 人团队：两层结构 + 强校验
这是父任务发挥作用的最佳区间。建议：
- 固定两层，禁止三层，除非外部依赖超过 3 个。
- 强制验收标准清单必填，通过工作流校验而非口头约定。
- 父任务 Owner 必须是单一个人，且必须是能对交付结果负责的角色。
- 每迭代父任务数量控制在 15～25 个，超过就要审视准入规则是否被绕过。
这个区间的团队通常也开始有私有化和数据合规诉求。如果有信创要求，选型时要优先确认私有化部署能力和迁移路径。像 PingCode 这类面向中大型组织的平台，在这个规模段是比较常见的选择之一，尤其是需要从既有工具做平滑迁移的场景。
3. 150 人以上或多产品线：两层 + 跨团队依赖显式化
规模上去之后，真正的难题不是父子层级，而是跨团队依赖。建议在两层结构之上增加一个"发布"或"版本"维度，用来聚合跨团队的交付节点。
同时必须把依赖关系显式化：谁在等谁、等什么、预计什么时候解除。我们实践中发现，把依赖可视化之后，跨团队等待时间平均下降 50% 以上，因为等待一旦可见，就会有人去推动。
4. 从其他工具迁移的团队：先清洗，再迁移
这条建议非常关键：不要把历史遗留的脏数据直接迁到新工具里。迁移前先做三分类：
- 活跃且合规的父任务：补写验收标准后迁移。
- 活跃但不合规的父任务：先降级或拆分，再迁移。
- 已关闭的历史父任务：只迁主体和结论，不迁层级细节。
第三类是最容易被过度投入的。很多团队花了大量时间把三年前已关闭的任务层级也完整迁移过来，结果从来没人查过。我的建议是：历史数据的价值在于可检索，不在于完整还原结构。
七、不同情况下的取舍
前面讲的是"怎么做"，这一节讲"必须放弃什么"。任何流程设计都是取舍，把取舍讲清楚，团队才不会在执行中反复摇摆。
1. 取舍一：流程严谨性 vs 创建速度
强校验会让创建父任务变慢。我们那个 150 人团队改造初期，产品经理抱怨"建个父任务要填 6 个字段太麻烦"，创建耗时从平均 2 分钟涨到 6 分钟。
但数据给出了答案：创建时多花的 4 分钟，换来的是评审返工率下降 11 个百分点、迭代末期阻塞缺陷下降 37 个百分点。这个交换是划算的。尺度在于：必填字段不要超过 6 个，超过就会诱发绕过行为。
2. 取舍二：自动化的便利 vs 数据口径的真实性
自动汇总进度很爽，但它会系统性地掩盖风险。如果你所在的团队管理层对进度数据的真实度要求高，就放弃自动汇总；如果只是内部参考，自动汇总可以保留，但要在看板上明确标注"仅供参考，不作为验收依据"。
3. 取舍三：颗粒度细 vs 管理成本
父任务越细，跟踪越准，但创建和维护成本越高。我们建议的分界线是 5 人天：低于 5 人天的交付，不值得单独建父任务。这条线可以根据团队规模调整，30 人团队可以抬到 8 人天，200 人团队可以降到 3 人天。
4. 取舍四：工具约束 vs 流程自由
工具给的约束越多，流程越稳定，但灵活性越低。反过来，流程自由度高，团队会各写各的，半年后数据就不可用了。
我的判断是：在父任务这个层面，宁可约束多一点。因为父任务是跨团队沟通的公共语言，语言不统一，沟通成本会指数级上升。可以把灵活性留给子任务和检查项这些执行层。
5. 取舍五：一次性重构 vs 渐进式演进
一次性重构的好处是快，坏处是团队抵触大、容易回退。我们那个案例选择了渐进式：第一个迭代只改验收标准，第二个迭代加依赖字段，第三个迭代再做历史数据清洗。
代价是见效慢，六个月才看到完整收益。但好处是过程中没有出现大规模回退，团队接受度一直维持在比较高的水平。流程改造最大的风险不是方案不够好，而是执行到一半没人跟了。
八、把父任务流程真正落地的最小行动清单
如果你打算在下个迭代就动手，我建议只做下面这五件事，不要贪多：
- 清理存量：把当前活跃的父任务全部过一遍，按"交付分解型/阶段推进型/同类聚合型/汇报打包型"四分类，后两类直接降级或关闭。
- 写验收标准：给保留的父任务补写 3～8 条可判定的验收标准，写不出来的说明这件事还没想清楚。
- 配工作流校验：把验收标准、Owner、预估工时设为进入"已确认"的必填项。这是最省力也最有效的机制。
- 改进度口径：停用子任务加权自动汇总，改为验收清单勾选比率。
- 定四个指标：父任务流转周期、验收一次通过率、待评估滞留率、风险提前暴露天数，每周看一次趋势，不看绝对值。
最后说一个我自己的判断。父任务流程的成熟度，不体现在层级有多规范，而体现在团队敢不敢把一个父任务标成"待验收"。因为标成待验收，意味着你要接受别人来检查、可能被打回、可能要重做。一个所有父任务都能顺畅走到待验收并一次通过的团队，流程一定不会差。
下一步，我建议你先从手头最活跃的那个父任务开始，试着给它写验收标准。如果写不出来，那它大概率就是那 43% 里的一员，应该被降级，而不是被优化。
常见问题解答（FAQ）
1. 父任务和子任务到底该怎么拆，拆几层、粒度多大才不失控？
我们团队一开始图省事，把每个需求都建成父任务，下面随手挂十几条子任务，结果看板上几十张卡片全是红黄灯，站会光过一遍就要二十分钟。我也试过另一个极端，只建一条任务不拆，结果一个人卡住了整条线，别人根本不知道卡在哪。到底哪些活该拆父任务、拆到几层、每层多大颗粒，我心里一直没底。
先定判断标准：父任务代表一个可以独立验收的交付结果，子任务代表单人一次能推进完的工作单元。触发拆父任务的条件有三个，满足任意一个就拆，需要两人以上协作、预计超过三天才能完成、需要跨迭代跟进。层数控制在三层以内，父-子结构覆盖九成场景，只有跨模块联动的大交付才用第三层，超过三层基本没人维护得动。
粒度上用两侧夹逼：子任务预估超过两天就继续拆，小于两小时的不值得建单，直接写在父任务描述的检查清单里。父任务本身不承担具体工时，工时全部记在子任务上，否则汇报时会重复计算。验收标准要写在父任务描述里，一句话说清什么状态算完成，比如接口联调通过且文档归档，不能写成推进一下、优化一下这种没法判定的描述。
落地上建议先拿一条真实业务线做试点，两周后再推全组，因为拆分标准是团队共识，硬推会变成形式主义。
2. 父任务的进度和工时怎么算才不被质疑？为什么三个人报出三个数？
上周站会问一个父任务到哪了，做的人说完成了八成，我按子任务数一数只到一半，项目经理按工时加权算出来是六成五，三个数字摆在投屏上，会就开不下去了。后来我发现不是大家不认真，是我们压根没约定用哪套口径。我现在特别想知道，行业里比较抗质疑的算法到底是哪一种。
选一套口径并且只认这一套，写进团队约定，其他算法只作参考不准上会。两种主流口径二选一：一是数量口径，父任务进度等于已完成子任务数除以全部子任务数，优点是直观好核对，缺点是忽略工作量差异；
二是工时加权口径，已完成子任务的预估工时之和除以全部子任务预估工时之和，更贴近真实投入，适合周期紧、需要预测交付时间的团队。别混着用，混用必然吵架。工时口径上坚持父任务不单独填报，工时只落在子任务，父任务展示的是汇总值和剩余值，这样剩余工时可以直接喂给燃尽图。
状态口径建议规则驱动而不是手工改：所有子任务完成才允许关闭父任务，任一子任务阻塞则父任务自动标记为阻塞，不允许出现子任务全阻塞而父任务还显示进行中。
使用加权口径要留意一个坑，如果最后一个子任务占了六成工时，进度会长期卡在四成不动，看起来像停滞，解决办法是把大颗粒子任务继续往下拆，或者对关键里程碑式子任务单独设置权重。口头百分比尽量不用，因为八成本身不可复现，换成还差哪几件事没做完，信息量大得多。
3. 父任务能不能指派给具体的人？能不能直接放进迭代看板？
我们组有个争论：一派说父任务只是容器，不该有人负责，派了就是甩锅；另一派说不指派就等于没人管，最后谁都在等。还有人习惯把父任务拖进当前迭代，结果迭代燃尽图被反复拉动，敏捷教练天天来找我。我确实拿不准容器类任务在这两件事上该怎么处理。
父任务建议指派一个责任人，而不是执行人。责任人的职责是拆解、协调、验收和在站会上代表这条线发言，具体干活的人挂在子任务上。没有责任人的父任务几乎必然烂尾，因为它不归任何人。看板要分两个视图而不是混在一起：管理者视图只显示父任务，一屏控制在十到十五张卡片，多了说明这条线的颗粒度已经失控；
执行者视图按人做泳道，只显示子任务。父任务进不进迭代，看子任务是否全在同一迭代内：全部在里面，父任务可以随迭代走；只要有子任务跨迭代，父任务就别放进迭代看板，让它留在版本或里程碑视图里当容器，否则每次有人改子任务日期，迭代燃尽图都要重画一遍，数据就废了。
更省事的做法是把父任务挂在版本或里程碑层级，迭代只装子任务，管理层看版本，执行层看迭代，两套数据各取所需。
4. 子任务跨迭代、父任务长期挂着不关闭，这种情况怎么治理？
我接手项目时翻了一遍任务列表，发现最长的一个父任务挂了四个多月，下面十几条子任务一半标着完成，一半连负责人都空着。每次问起来大家都说在推进，但没有任何证据。我不想搞运动式清理，因为清完两周又回去了，想找一套能长期跑下去的机制和判断指标。
先立一条硬规则并让它自动跑：父任务连续十四天没有任何更新，或者子任务完成率连续两个迭代没有变化，就自动进入僵尸清单，每周由技术负责人固定花半小时过一遍，每条只能三选一，关闭并写明不做的原因、降级并入其他父任务、或者拆出下一个可执行的小步骤并写清负责人和截止时间。
跨迭代的长周期交付，建议用里程碑承载时间维度，父任务只承载交付维度，两者分开以后就不会再出现一个任务挂四个月的情况。关闭动作必须带验收，验收人不能是执行人自己，验收标准在开单时就写在父任务描述里。指标上盯两个数：父任务平均存活天数和子任务完成率的周增速。
如果平均存活天数持续上升，说明拆分粒度变粗了或者需求在反复变更；如果完成率增速连续两周低于预期，先怀疑子任务估时失真而不是怀疑人不努力。另外把僵尸任务数量做成一张公开看板，不点名不考核，只统计数量趋势，三个月内这个数字一般能降一半以上，比开几次动员会管用。
治理机制要写进迭代回顾的固定议题，否则它一定会被新需求挤掉。
核心关键词
文章包含AI辅助创作：任务管理父任务全流程：研发团队落地方案与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/348058
读者评论
我们团队也踩过自动加权进度的坑，12个子任务里1个大活干到一半，父任务显示75%，周会上一片祥和，最后一周集中爆雷。改成验收清单勾选后，进度数字确实没那么好看了，但能提前两周看出来要延期，反而踏实。")
六条判断里最认同Owner必须是唯一自然人。我们之前写团队名，卡了半个月没人拍板，改成技术负责人后流转快了很多。但有个疑问：中小团队一个负责人同时挂五六个父任务时，Owner字段变成形式，这个怎么破？")
工时5到15人天这个区间对我们这种20人小团队偏重了，实际超过8人天的父任务就很难在一个迭代里收口。另外想知道那43%降级为标签的父任务，数据是怎么追溯的，历史关联关系迁移时会不会丢，这块成本文章里没展开。