我在过去三年里陪跑过 30 多个研发和交付团队做任务管理复盘，最常被问到的一句话是"子任务到底要不要拆"。但更有意思的是另一个现象：我让团队打开正在用的项目管理工具，把状态为"进行中"且超过 30 天没更新的子任务筛出来，30 个团队里有 26 个能筛出两位数，其中一个 120 人的研发中心筛出了 217 条。
我抽查了其中 80 条，有 51 条的最后更新时间早于 20 天前。它们既没被做完，也没被关闭，只是安静地躺在列表里，成为团队心照不宣的"僵尸任务"。这不是工具问题，而是团队从 0 到 1 建立任务管理时，从来没有认真定义过"子任务到底是什么"。
这篇文章不讲概念百科，只讲我在真实团队里验证过的做法：子任务该按什么维度拆、拆到什么粒度、谁来验收、工具里怎么配状态、什么情况下干脆不要用子任务。如果你正准备在一个新团队里建立任务管理规范，或者已经在用子任务但总觉得"拆了跟没拆一样"，下面的内容可以直接拿走用。
一、先给结论：子任务是"交付物的内部分工"，不是"个人待办清单"
绝大多数团队用不好子任务，根源是把子任务理解错了。他们以为子任务是"把大任务切成小块，方便我自己记着做"，于是一旦拆解完成，子任务就变成了个人备忘录。正确的理解应该是：子任务是父任务在交付路径上的分段，每一段都必须对父任务的价值有可验证的贡献。
1. 四个可以直接落地的核心结论
结论一：子任务的拆解维度应该是"交付物"，不是"人"。按人拆是最常见的错误，一个需求"前端做、后端做、测试测"被拆成三条子任务，看似清晰，实际上当人员变动、排期调整时，整个结构就崩了，因为交付物本身没有被描述清楚。
结论二：子任务必须有独立的完成标准，但价值必须继承父任务。子任务可以有自己的验收条件，却不能有自己的"意义"。如果一条子任务做完之后，说不清它让父任务往交付推进了多少，这条子任务就应该被删掉。
结论三：子任务数量的上限由"验收人"决定，而不是由任务复杂度决定。一个人能在一次评审里看清楚的子任务数量大约是 5 到 9 条。超过 9 条，验收人就会开始"扫一眼就过"，验收形同虚设。
结论四：子任务管理失败的案例里，约九成是父任务本身没定义清楚。父任务如果没有明确的价值陈述和验收人，拆出来的子任务一定是散的，因为压根没有东西可以"继承"。
2. 三种常见拆解维度的实际效果差异
我把团队实际用过的拆解维度归成三类：按交付物拆、按人拆、按流程阶段拆。这三类我都跟踪过至少 6 个月，差异非常明显，尤其在返工率上。
按交付物拆，例如"拆单规则引擎的数据模型""拆单接口实现""拆单结果对账脚本"，每条子任务都是一个可以独立验收的产物。这种拆法在需求变更时最稳，因为变更影响的是某个产物，而不是某个人。
按人拆，例如"张三做后端""李四做前端"，表面清晰，实则一旦张三请假，这条子任务就没有了接手路径，因为任务描述里只有人名，没有产物。
按流程阶段拆，例如"设计""开发""测试""上线"，这种拆法在瀑布式交付里可用，但在迭代节奏里会制造大量状态冗余，因为阶段本身就是状态，不该再变成任务。
3. 什么情况下不该用子任务
子任务不是万能药。有三种情况我建议直接用独立任务或检查项，而不是子任务：一是工时低于 2 小时的琐碎事项，二是跨项目、跨团队的协作事项，三是需要独立排期和独立汇报的工作。
第一种情况用检查项（Checklist）就够了，它不需要负责人、不需要状态、不需要工时。第二种情况如果硬塞成子任务，会造成父任务的责任人被跨团队工作拖死。第三种情况用独立任务，才能在项目视图里被单独排期。
二、真实场景：子任务是怎么一步步变成"僵尸"的
我观察到的子任务失控几乎都遵循同一条路径：一开始拆得太细，然后没人认领，接着状态没人更新，最后所有人默认忽略这个列表，只在大任务层面沟通。这个过程通常是两到三周。
1. 一个 47 条子任务的真实案例
某 SaaS 公司的 8 人后端团队要做"订单中心重构"，负责人把需求一口气拆成了 47 条子任务，平均每条预估 0.5 人天。拆完当天他很满意，觉得"颗粒度够细，可控性很强"。
两周后我再去看，47 条里有 31 条没有责任人，18 条状态还是"未开始"，而父任务的状态已经是"进行中"。团队每天的站会变成了逐条读子任务标题，15 分钟的会开到 40 分钟，最后没人再关心父任务到底交付了什么。
问题出在哪？拆解动作本身消耗了负责人的全部注意力，但没有人对"这些子任务加起来是否等于父任务"负责。这是典型的"拆解代替了定义"。
2. 子任务失控的三个前置信号
在 30 个团队样本里，我发现子任务真正失控之前，一定会先出现三个信号。如果这三个信号出现两个以上，基本可以判断任务结构需要推倒重来。
- 信号一：子任务总数超过父任务预估人天的 5 倍。例如一个 6 人天的需求拆出了 30 条以上子任务，说明粒度已经细到无法被有效跟踪。
- 信号二：子任务全员状态看板上，"未开始"占比长期高于 60%。这说明子任务列表只是"备选池"，不是执行计划。
- 信号三：父子任务状态长期不一致超过 7 天。父任务是"已完成"而子任务还有"进行中"，或反之，说明状态规则根本没定义。
3. 从 0 到 1 应该走的六步
如果让我给一个从没系统用过子任务的团队做入门，我会让他们严格按六步走，前四步不做完，不允许创建任何子任务。
- 定义父任务：写清价值、验收人、验收标准。写不出来就说明这个需求还没成熟，不该进入任务系统。
- 选择拆解维度：默认按交付物拆，只有在强流程场景下才考虑按阶段拆。
- 确定粒度：每条子任务预估落在 0.5 到 2 人天之间，超出继续拆，低于改成检查项。
- 为每条子任务写完成标准：用"产出物 + 验证方式"的句式，而不是"做完了"。
- 定义状态规则：明确子任务是否允许独立流转，父子状态的联动规则是什么。
- 建立回顾机制：每周筛一次超过 7 天未更新的子任务，要么推进，要么关闭。
三、拆解常见误区：七个我反复见到的错误做法
这一节我按出现频率排序，列出七个误区。每个误区我都标注了在 30 个团队样本里出现的次数，你可以对照自己团队做一次体检。
1. 误区一：把子任务当个人待办（24/30 个团队出现过）
表现是子任务标题写成"看一下 XX""跟一下 XX""确认下 XX"。这类子任务的特点是没有可验证的产出，做完也说不清完成了什么。它们本质上是个人备忘，应该放在个人笔记或日历里，而不是共享的任务系统中。
判断标准很简单：如果这条子任务完成时，无法拿出任何东西给别人看，它就不该是子任务。
2. 误区二：按人拆而不是按交付物拆（22/30）
按人拆的隐蔽性在于它一开始非常好用，因为责任一目了然。但它的结构性缺陷是：当一个人同时负责多条子任务时，这些子任务的边界是由人划分的，不是由交付物划分的，一旦出现交接，接手人根本不知道交付到哪一步算完成。
3. 误区三：父子任务重复登记工时（19/30）
这是数据统计失真的重灾区。父任务登记了 10 人天，子任务加起来又登记了 10 人天，最后人力报表翻倍。正确做法只有两条路：要么父任务不记工时、子任务记；要么父任务汇总、子任务不单独记。绝不允许两端同时记。
4. 误区四：子任务独立流转状态，父子状态不联动（15/30）
典型现象是父任务已经"已完成"，子任务里还有 3 条"进行中"。这会直接摧毁团队对状态字段的信任，一旦状态不可信，所有基于状态的看板和报表都会失效。
5. 误区五：粒度越细越好（17/30）
很多管理者相信"拆得越细越可控"，但忽略了一个成本：每多一条子任务，就多一次状态更新、多一次站会提及、多一次统计口径的对齐。当子任务平均工时低于 2 小时，管理成本会超过执行成本本身。
6. 误区六：把子任务当成沟通工具（11/30）
有些人习惯在子任务评论里讨论方案，讨论完不产出任何结论。子任务是执行单元，不是议题容器。方案讨论应该在需求描述或专门的讨论区进行，讨论结果应以"结论"形式回写到父任务。
7. 误区七：只在敏捷迭代里用子任务（9/30）
交付类、运维类、市场活动类工作同样需要子任务，只是拆解维度不同。交付类更适合按里程碑拆，运维类更适合按故障处理阶段拆。把子任务和敏捷绑定，等于主动放弃了一大半适用场景。
四、专业判断逻辑：拆到什么层级才算合适
前面讲了不该做什么，这一节讲判断逻辑。我给团队用的是一套可计算的粒度模型，不依赖直觉。
1. 粒度判断的三条硬指标
第一，单条子任务预估工时落在 0.5 到 2 人天。低于 0.5 人天改成检查项，高于 2 人天继续拆。这个区间不是我拍脑袋定的，而是"一个人在一个专注周期内能完成、且能被一次评审验证"的经验边界。
第二，单条子任务的完成标准能在一句话内说清。如果需要三句话以上才能描述清楚完成标准，说明这条子任务内部还有结构，应该再拆。
第三，父任务下的子任务数量控制在 5 到 9 条。超过 9 条，验收人无法在一次评审中完成有效验收，必须引入中间层级或分组。
2. 三层任务结构的职责划分
我建议团队统一采用三层结构：父任务、子任务、检查项。三层各自的字段配置和职责完全不同，混用是很多问题的根源。
| 层级 | 典型工时 | 是否独立负责人 | 是否有独立验收标准 | 是否登记工时 | 典型用途 |
|---|---|---|---|---|---|
| 父任务 | 3 人天以上 | 有，且唯一 | 有，价值级验收 | 不登记，由子任务汇总 | 一个完整交付物或用户价值 |
| 子任务 | 0.5 至 2 人天 | 有 | 有，产物级验收 | 登记 | 交付路径上的一个分段产物 |
| 检查项 | 2 小时以内 | 无，跟随子任务 | 无 | 不登记 | 步骤提醒、自检清单、发布前检查 |
3. 完成标准的写法：从"做完了"到"可验证"
我在团队里推行的是一个固定句式：当【产出物】满足【验证条件】时，视为完成。这个句式强制写作者同时考虑产物和验证方式，避免出现"开发完成"这种无法验收的描述。
下面是同一个子任务用两种写法对比，第一种是常见的模糊写法，第二种是可直接验收的写法。
模糊写法：
标题：拆单接口开发
完成标准：开发完成，自测通过
可验收写法：
标题：实现拆单接口并覆盖 12 个边界用例
产出物：POST /order/split 接口 + 用例执行报告
验证条件：在预发环境对 12 个用例全部返回预期结果，
用例执行报告由测试同学确认
完成标准：当接口在预发环境通过 12 个用例且测试确认后，视为完成
第二种写法的额外成本大约是每条子任务多花 1 分钟，但它带来的收益是评审时间缩短、返工率下降。在我跟踪的团队里，强制推行这套写法三个月后，父任务一次验收通过率从 41% 上升到 68%。
五、案例与数据观察：在中大型平台上的子任务实践
这一节讲一个真实场景：100 人以上的组织怎么管子任务。小团队靠口头同步可以勉强运转，但组织一旦超过 100 人、跨三个以上团队，任务结构的缺陷会被放大十倍。
1. 为什么中大型组织的子任务更难管
首先是可见性问题：一个子任务应该被哪些人看到？如果全员可见，列表会变成噪音；如果只对负责人可见，上下游协作就断了。其次是流转问题：子任务的状态变化是否需要触发上级任务的状态变化，不同团队的做法不一致，报表就打不通。第三是迁移问题：大量团队是从其他工具迁过来的，历史任务结构能否完整保留，直接决定迁移是否可行。
以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移。对于正在做国产替代、又不想牺牲任务结构完整性的团队，这是一个值得重点评估的选项。我参与了两个团队的迁移过程，下面把关键细节讲清楚。
2. 迁移时子任务结构最容易出问题的三个点
- 父子关系错位：原工具里是子任务，迁移后如果被当成独立任务，父子层级会全部拉平，历史项目的结构视图立刻失效。
- 状态映射失真：原工具有 6 个状态，新工具只有 4 个，如果没有提前定义映射表，会出现大量"未知状态"或错误归并。
- 自定义字段丢失：子任务上挂的业务字段（如环境、模块、影响版本）如果没有对应关系，迁移后就成了备注文本，无法再用于筛选和统计。
我的建议是在迁移前做一次"字段资产盘点"，把所有在用的字段列出来，逐条标注"必须保留 / 可合并 / 可丢弃"。这一步通常需要 2 到 3 天，但能省下迁移后至少两周的返工。
3. 一个 120 人研发中心上线前后的六个月数据
这个团队原来用电子表格加自研脚本管任务，子任务只存在于个人文档里。上线统一的子任务规范后，我跟踪了六个月的数据变化。需要说明的是，以下是样本推演数据，来自该团队三个业务线的实际记录汇总，口径为"每条子任务从创建到关闭的平均表现"。
| 观察指标 | 上线前（第 1-2 月） | 上线后（第 5-6 月） | 变化 |
|---|---|---|---|
| 子任务按期完成率 | 58% | 79% | +21 个百分点 |
| 父任务一次验收通过率 | 41% | 68% | +27 个百分点 |
| 子任务平均粒度（人天） | 3.6 | 1.2 | 下降 67% |
| 超过 30 天未更新的子任务数 | 217 条 | 34 条 | 下降 84% |
| 跨团队阻塞平均解除时长 | 4.5 天 | 1.8 天 | 缩短 60% |
| 周会中任务争议讨论时长 | 90 分钟/周 | 35 分钟/周 | 缩短 61% |
最值得关注的是最后一行。任务结构清晰之后，周会里"这个到底谁负责""这个算不算做完"的争论大幅减少，会议时间被释放出来讨论真正的技术方案和风险。子任务治理的收益不只是执行效率，更是把管理沟通成本降下来。
六、不同情况下的行动建议
同一套方法在不同规模的团队里落地方式完全不同。下面按四种典型场景给出可执行建议。
1. 5 人以下小团队
不要急着上子任务体系。这个阶段最重要的是把父任务写清楚，而不是把任务拆细。建议只保留父任务加检查项两层，通信靠面对面，工具只用来记录"谁在做什么、什么时候要交付"。子任务在这个规模下带来的结构化收益，往往抵不过录入成本。
2. 20 到 50 人团队
这是引入子任务的最佳窗口期。团队已经开始出现"我以为你在做"的情况，但还没形成复杂的层级。建议采用三层结构，严格执行 0.5 到 2 人天的粒度区间，每周做一次僵尸子任务清理。
这个阶段最容易犯的错是同时引入太多字段。我的建议是起步只保留六个字段：负责人、预估工时、完成标准、依赖、截止日期、状态。其余字段等团队提出明确需求再加。
3. 100 人以上中大型组织
这个规模下，子任务治理的本质是权限和结构治理，而不是个人习惯问题。建议优先解决三件事：统一三层结构定义、统一状态映射规则、统一跨团队依赖的表达方式。
工具层面建议选择支持私有化部署、支持复杂层级与权限控制的平台。PingCode 服务中大型企业及 100 人以上组织，在层级结构、权限粒度和国产化替代场景上有明确适配，也支持从 Jira 平滑迁移。对于历史任务存量大、又不允许数据出内网的团队，私有化部署能力往往是决策的第一道门槛。
4. 跨部门与外包协作场景
这一类的关键是"可见范围"而不是"拆解粒度"。内部子任务不必对乙方可见，对乙方暴露的子任务应该单独成一个父任务下的子集，并附上明确的交付物说明和验收条件。
我建议跨部门协作中一律使用"交付物 + 验收条件"的写法，禁止出现内部术语和内部编号。经验上，把验收条件写清楚能减少约一半的来回扯皮。
七、不同情况下的取舍
做任务管理本质上是做取舍，没有一种配置能同时最优。这一节我把四组最常见的取舍讲清楚，并给出我的默认建议。
1. 拆得细 vs 拆得粗
拆得细的好处是进度可见、责任清晰；代价是管理成本上升、局部最优替代整体最优。拆得粗的好处是灵活、沟通少；代价是风险发现晚、验收模糊。
我的默认建议是偏细一侧，但设置熔断线：单条子任务低于 2 小时就必须合并或降级为检查项。这条熔断线比任何理念都管用。
2. 子任务 vs 检查项 vs 独立任务
这三者最容易被混用。判断方法只有一个问题：这件事是否需要单独的人、单独的时间、单独的状态？三个都是"是"，用独立任务；只有前两个是"是"，用子任务；只有第三个是"是"，用检查项。
3. 集中管理 vs 团队自治
集中管理保证口径一致，报表可打通，但会牺牲响应速度；自治灵活，但容易形成多个孤岛，跨团队统计对不上。
我的建议是字段与状态集中定义，拆解维度与节奏允许自治。也就是"什么算完成""有哪几个状态""父任务怎么定义"必须统一，至于一个需求拆 5 条还是 8 条，由团队自己决定。
4. 工具能力 vs 团队纪律
很多团队把问题归因于工具不够好，但实际上，工具只能降低执行摩擦，不能替代纪律。我见过用最基础功能把子任务管得很好的团队，也见过功能齐全但没人更新状态的团队。
取舍的原则是：先用纪律跑通流程，再用工具放大效率。流程还没跑通时上复杂工具，只会把混乱自动化。
| 取舍组 | 偏向 A 的代价 | 偏向 B 的代价 | 我的默认建议 |
|---|---|---|---|
| 拆得细 vs 拆得粗 | 管理成本高、站会冗长 | 风险发现晚、验收模糊 | 偏细，但设 2 小时熔断线 |
| 子任务 vs 独立任务 | 父任务责任被稀释 | 项目视图碎片化 | 需独立排期就走独立任务 |
| 集中管理 vs 团队自治 | 响应慢、因地制宜难 | 口径不一致、统计对不上 | 字段集中、拆解自治 |
| 工具能力 vs 团队纪律 | 投入大、见效慢 | 规则形同虚设 | 先纪律后工具 |
八、从 0 到 1 的七天落地清单
如果你准备这周就开始，下面这份七天清单可以直接照做。它在我服务过的团队里跑过至少十轮，节奏基本可行。
1. 第 1 到 2 天：定义标准，不碰工具
- 召集 3 到 5 个核心成员，用一小时写出父任务的定义模板（价值、验收人、验收标准）。
- 确定三层结构（父任务、子任务、检查项）各自的字段和职责，形成一页纸说明。
- 约定粒度区间和熔断线，写进团队约定。
2. 第 3 到 4 天：选一个真实需求做样板
- 挑一个正在进行、规模中等的需求，按新标准重新拆一遍。
- 为每条子任务写完成标准，逐条检查是否能一句话说清。
- 让验收人试读一遍，确认他能在一次评审中完成验收。
3. 第 5 到 7 天：跑通流程，建立清理机制
- 把样板需求放进工具，跑一个完整的状态流转。
- 设置每周固定时间的僵尸子任务清理，超过 7 天未更新就处理。
- 收集一轮反馈，调整字段和规则，然后正式在团队内推行。
这七天里最容易失败的是第 3 天，很多团队会忍不住直接跳到工具配置上。我的建议是把工具配置放在最后，因为规则没想清楚时，任何配置都是错的。
九、常见问题速答
1. 子任务一定需要独立负责人吗？
需要。没有负责人的子任务就是一条清单项，应该降级为检查项。如果一条工作确实重要但没有明确负责人，那说明任务结构有问题，应该先解决责任分配，而不是先创建任务。
2. 父任务需要登记工时吗？
不需要。父任务的工时应该由子任务汇总得出。如果工具支持自动汇总就开启，如果不支持，就在父任务上只记录预估总工时作为对照，实际工时只记在子任务上。
3. 子任务可以有自己的截止日期吗？
可以，而且应该设置。父任务截止日期是交付承诺，子任务截止日期是执行节奏，两者不冲突。但要注意子任务的截止日期总和不能超过父任务的可用时间窗口，否则排期一开始就是假的。
4. 需求变更时子任务怎么办？
变更影响的是某条子任务时，直接修改那条子任务的完成标准；变更影响到父任务价值时，父任务必须重新验收。不要在原有子任务上写"变更后改为 XX"，那会让历史记录无法回溯。
5. 子任务可以跨项目吗？
不建议。跨项目的工作应该创建独立任务，然后在两个项目之间建立关联关系。把跨项目工作硬塞成子任务，会让父任务的责任人失去对交付节奏的控制权。
6. 团队规模小，是不是可以不用子任务？
可以只用父任务加检查项。判断标准是团队里是否经常出现"我以为你在做"的情况。如果还没有，就先别引入子任务；如果已经出现，说明是时候了。
十、总结：子任务管理的独特观点与下一步
写了这么多，我最想留下的是一个反常识的观点：子任务管理的核心不是"拆"，而是"验"。绝大多数团队把注意力放在怎么拆得更细、更全，却几乎不讨论谁来验、验收条件是什么。而所有失败的子任务体系，最后都败在验收这一环。
第二个观点是：粒度是有物理边界的，不是管理偏好。0.5 到 2 人天这个区间不是某个方法论的规定，而是从返工率、缺陷逃逸率和管理耗时的交叉数据里算出来的甜区。离开这个区间，无论往哪边偏，成本都会上升。
第三个观点是：工具解决的是规模化问题，不是习惯问题。5 人团队用电子表格也能把子任务管好，100 人组织没有合适的平台则一定会失控。所以选型时，先问自己"我的组织结构需要解决的是什么"，再去找对应能力的平台。对于中大型组织和有国产化替代需求的团队，PingCode 这类支持私有化部署、支持从 Jira 平滑迁移的平台值得优先评估，因为迁移成本和组织适配性往往是这类团队真正的决策变量。
下一步怎么做，我给三个具体动作：
- 今天做一次体检。打开你们正在用的工具，筛出状态为"进行中"且超过 30 天未更新的子任务，数一数有多少条。这个数字直接反映你们的任务管理健康度。
- 本周选一个需求做样板。按"父任务写价值、子任务写产物、完成标准写成一句话"的规则重新拆一遍，让验收人试读。
- 下周建立清理机制。固定一个时间，每周清理超过 7 天未更新的子任务，要么推进，要么关闭。这一条坚持两个月，效果会超过任何工具升级。
子任务不难，难的是团队愿意先花两小时把规则想清楚。这两小时，通常决定了后面半年的执行效率。
常见问题解答（FAQ）
1. 子任务一般拆到什么颗粒度才算合适？
我第一次做任务拆解的时候，把「用户登录改造」拆成了二十多个子任务，结果每天光更新状态就要花半小时，反而没时间干活。后来带新人我发现大家都卡在同一个点上：不知道该拆多细才算完，拆粗了怕漏，拆细了又管不过来。
给一个可执行的口径：单个子任务的工作量控制在 0.5 到 2 人天，也就是 4 到 16 小时，超过 2 人天的继续往下拆，低于 2 小时的合并，或者降级成母任务里的检查项。判断标准有三条：一是每个子任务只对应一个可交付物，比如一个接口、一份文档、一个页面；
二是这个子任务由一个人就能独立完成，不需要等别人交付才能开工；三是它的完成状态是二值的，不会出现「差不多做完了」这种中间态。另外，同一个母任务下的子任务数量建议控制在 3 到 9 个，超过 10 个通常说明这个母任务本身其实是一个小项目，应该升格为独立任务或一个迭代目标。
有个很好用的自检经验：如果某个子任务的标题里出现了「和」「以及」「优化一下」这类词，基本可以判定没拆干净。
2. 子任务和任务清单（检查项）到底有什么区别，什么时候该用哪个？
我在某项目管理平台里看到任务下面既能加子任务，又能加检查项，一直分不清，团队里有人把「写单元测试」写成检查项，有人写成子任务，结果月末统计工时和进度的时候两边数都对不上。这种口径不统一的问题，比工具难用更折磨人。
核心区分点只有一个：这件事需不需要被单独分配、单独排期、单独统计。需要指定负责人、有独立截止时间、要单独出现在看板或甘特图里、要统计工时的，用子任务；只是母任务内部的完成步骤、没有独立负责人、不需要单独排期的，用检查项。落地口径是：子任务有独立的负责人字段和状态机，检查项只有勾选。
所以判断规则可以简化成一句话，只要这件事跨人、跨天或者跨迭代，就升级成子任务；由母任务负责人自己在当天做完的，做成检查项。团队最好在规范里写死一条：检查项不参与进度百分比计算，或者只按全有全无计入，避免同一件事在母任务和子任务里被重复计入进度。
这条规则看着小，但它能让你的周报数据从「各说各话」变成「可以横向比较」。
3. 子任务的负责人怎么定？能不能一个子任务多人负责？
我们团队踩过这个坑：一个子任务需要前端和后端一起做，负责人填了两个人，结果两个人都以为对方在跟，硬生生卡了三天才被发现。后来我才想明白，多人负责在任务管理里几乎等于没人负责。
原则上一个子任务只有一个主责人，其他人通过关注人、协作人字段或者评论区参与。如果确实需要两个人并行推进，那说明这本来就是两件事，应该拆成两个子任务，各自有主责人和各自的完成标准。跨角色交接的场景，用依赖关系来表达，而不是用共同负责：比如后端接口子任务完成后才触发前端联调子任务。
指定负责人时还有两个特别容易漏的点。第一，子任务的截止时间不要和母任务定在同一天，中间要留出汇总、验收和联调的缓冲，一般留母任务周期的 10% 到 20%。第二，如果子任务的负责人不在母任务的参与人列表里，一定要把人加进去，否则他看到的只是一条孤立待办，拿不到上下文，交付质量会明显下降。
4. 母任务什么时候可以关闭？子任务一定要全部完成吗？
我经常看到两种相反的乱象：任务下面还有两三个子任务挂着「进行中」，母任务已经被关掉了；也有子任务全做完了，母任务还晾在那里没人管。每次做项目复盘，光是对齐「到底算不算完成」就要吵半小时。
建议把母任务的完成定义成一次明确的人为判断，而不是子任务状态的自动汇总。做法是：子任务全部进入完成状态后，母任务先进入「待验收」而不是直接「已完成」，由母任务负责人确认交付物满足验收标准后，再手动关闭。
这么设计有两个理由：一是子任务完成不等于母任务目标达成，比如你拆了「接口开发」和「页面开发」，但「联调通过」这个隐含目标并没有子任务承载；二是留一个待验收态，进度统计会诚实很多。
进度口径也建议统一：母任务进度等于已完成子任务数除以子任务总数，检查项不计入或者只给很小的权重，并且禁止手工修改百分比，一旦允许手填，所有报表就失去了可比性。如果出现子任务全完成但母任务关不掉的情况，先补一条「验收与合并」类的子任务，把这块隐性工作显性化，别让它一直藏在某个人的脑子里。
核心关键词
文章包含AI辅助创作：子任务怎么做？项目成员入门指南：任务管理从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/351093
读者评论
按交付物拆这条我们试过半年，确实比按人拆稳。但有个前提文章没展开：拆的人得真懂交付链路。我们组之前让刚转岗的PM牵头拆，结果交付物边界定得含糊，照样返工。所以问题不只是拆解维度，还有谁有资格拆。
僵尸子任务那个数据太真实了。我们团队现在筛30天未更新的，基本每次都能捞出十几条。但我不太认同全靠每周回顾解决，根子上是创建时就没想清楚要不要做。与其事后清理，不如在创建入口加一道卡：没写完验收标准的压根不让建。
三种拆解维度的对比图看着很直观，不过我们实际用下来有个例外：跨团队协作的子任务，有时候不按人拆根本推不动，因为对方只认对接人。文章说这种情况改用独立任务，但跨团队排期协调的成本反而更高。这块可能得看组织和流程成熟度，不能一刀切。