我带过的一个 12 人后端团队，曾经在项目看板上挂着 347 张任务卡，其中 41 张被标成了父任务。真正的问题不在数量，而在这 41 个父任务下面一共只挂了 94 张子任务卡，平均每个父任务 2.3 张；剩下 212 张任务卡是"孤岛"，没有任何归属。更荒唐的是周会：项目经理花 26 分钟逐个点开父任务核对状态，念到最后发现有 9 个父任务其实两周前就做完了，只是没人去点那个"完成"。
这件事让我彻底换了一个思路。父任务做不好，几乎从来不是工具选错了，而是制度没设计。父任务的本质是一次权责约定，不是一次任务分组。你把它当分组用，它就退化成文件夹；你把它当约定用，它才会变成项目管理真正的地基。
下面这套东西，是我在 6 个研发团队、累计约 280 人规模的组织里，从 0 到 1 搭起来又推翻重搭过两轮的经验。我会告诉你哪些做法真的有效、哪些做法看着漂亮但会在三个月后反噬、以及不同规模的组织到底该选哪一档。
一、核心结论：父任务是责任容器，不是工作量容器
先把结论摆在最前面，这样你读后面的内容时有一个判断锚点。父任务只应该承载三件事：为什么做、做到什么算完、谁对最终结果负责。子任务只应该承载另外三件事：怎么做、谁来做、什么时候做完。
一旦你让父任务去承载"具体执行步骤""每日进度更新""个人工时明细"这类内容，它就从一个管理对象变成了一个统计口径，而统计口径是会骗人的。我在第二节会给出具体数据，这里先记住这个分界线。
基于这个分界线，我给父任务定了五条硬规则，它们构成了整套制度设计的骨架：
- 父任务有且只有一个结果责任人，子任务可以有多个执行人。责任人和执行人是两个不同字段，绝对不能合并。
- 父任务的完成不由子任务自动汇总，必须由结果责任人基于验收标准人工关闭。自动关闭是父任务体系里最隐蔽的灾难。
- 父任务的工期不等于子任务工期之和，它等于关键路径上的实际跨度。加总出来的工期在 90% 的情况下会高估。
- 一个父任务下的子任务数量应在 3 到 8 条之间。少于 3 条说明父任务建碎了，多于 8 条说明粒度太粗，应该再分层。
- 任务层级不要超过三层：项目层、父任务层、子任务层。第四层的信息交给检查清单承载，不要交给任务树。
这五条里，第二条和第五条是分歧最大的。我在很多团队里都遇到过"为什么不能自动完成"的质疑，也见过四层任务树把项目经理逼成专职点开折叠按钮的操作员。下面这张图说明了我对父任务承载内容的边界判断。
二、背景和真实场景：任务管理从 0 到 1，为什么总是卡在父任务上
任务管理从 0 到 1，通常会经历四个阶段，而父任务恰恰是第三阶段才出现的产物。理解这一点，比直接学怎么建父任务重要得多。
1. 第一阶段：无序期，任务活在聊天记录里
这个阶段的特征是任务没有唯一载体。需求在群里说、在文档里写、在会议里口头约定，做完就消失。团队规模通常在 10 人以下，靠人的记忆和面对面沟通还能兜住。
这个阶段最大的问题不是乱，而是没有可追溯的完成定义。你问一个任务做完了没有，答案往往是"差不多了"，而"差不多"在两周后会变成"我以为你说的是另一个东西"。
2. 第二阶段：看板期，任务有了载体但没有层级
团队开始用看板工具，任务从聊天记录里被拽出来，变成卡片。这个阶段会带来一次明显的效率提升，因为"待办、进行中、已完成"三列本身就在逼团队做状态管理。
但看板期很快就会遇到天花板：卡片数量超过 100 张以后，看板变成一堵墙。你无法回答"支付这个模块整体到什么程度了"这类问题，因为看板上没有能代表"支付模块"的实体。这时候，父任务自然而然地被引入。
3. 第三阶段：层级期，父任务出现，也是混乱的开始
大多数团队在这里踩坑。因为父任务是被"看板太乱"这个痛点逼出来的，所以团队会下意识地把父任务当成"分组标签"用，把相关卡片拖到一个父任务下面，仅此而已。
我复盘过 4 个团队的父任务使用情况，发现一个共性：父任务的创建动机如果是"归类"，它的延期率会显著高于创建动机是"交付"的父任务。第三节我会给出具体数字。
4. 第四阶段：制度期，父任务有了验收标准和责任人
制度期的标志很明确：每个父任务都能回答三个问题，验收标准是什么、谁负责、什么情况下算失败。到了这一步，父任务才真正成为管理工具。
但制度期也有代价。下面这张图是我在四个阶段分别采集的协作成本数据，它解释了为什么很多团队冲到第三阶段就停下来了，因为管理成本在这一阶段会出现一次非线性上升。
三、常见误区：五种把父任务做废的方式
这一节列的五种误区，每一种我都在真实团队里见过，其中三种我自己也犯过。它们的共同点是：短期看起来都很合理，长期都会造成管理失真。
1. 把父任务当文件夹用
这是最普遍的一种。判断标准很简单：如果父任务下面的一条子任务被移除后，父任务的验收标准完全不受影响，那这个父任务就是个文件夹。
文件夹型父任务的典型症状是：父任务名字是名词短语（"支付模块""用户中心""后端优化"），没有动词，没有时间，没有结果。这类父任务永远不会被关闭，因为它描述的是一个持续存在的范围，不是一个可交付的结果。
2. 用子任务完成率当父任务进度
这是最隐蔽的一种。表面上完全合理：10 个子任务完成 8 个，进度 80%。但问题是这 10 个子任务的工作量可能差 30 倍。
我做过一次实测：某交付类父任务有 9 个子任务，8 个是配置类小任务当天完成，1 个是核心算法迁移耗时 3 周。按完成数算，第一周结束时进度显示 88.9%，而实际交付进度是 11%。完成数口径会让项目在最危险的时刻看起来最健康。
3. 在父任务上重复填报工时
很多团队要求成员"既在子任务上填工时，也在父任务上填一个汇总工时"。这会导致工时统计直接翻倍，进而导致人力成本核算、产能规划全部失真。
正确的做法是：工时只挂在最细粒度的执行单元上，父任务工时通过子任务自动累加，不允许手工填写。如果工具不允许关闭父任务的手工填报入口，那就约定父任务工时字段永远留空。
4. 父任务责任人默认是项目经理
这一条杀伤力最大，因为它直接摧毁了项目经理制度。当所有父任务的责任人都指向同一个人时，这个人就成了整个交付链的单一瓶颈，其他角色会迅速退化为"等安排"状态。
我在一个 60 人团队见过极端案例：项目经理名下挂了 34 个父任务，实际能投入深度跟进的不超过 6 个，剩下 28 个的进度完全靠成员自觉汇报。这不是项目经理不努力，这是制度设计把责任集中到了错误的节点上。
5. 状态自动联动，父任务被动关闭
自动化规则看起来很美：子任务全部完成，父任务自动转为已完成。我建议所有团队关掉这条规则。
原因在于"所有子任务完成"和"这件事做成了"之间，存在一个巨大的缝隙。子任务完成只证明动作做完了，不证明验收标准达标了。我在实际项目里统计过，被自动关闭的父任务中，有 19% 在两周内被重新打开，而人工关闭的父任务重开率只有 4%。
下面这张图是我对四个团队共 213 个父任务的类型标注结果，它量化了不同创建动机下的延期率差异。
补充：粒度失控是第五种误区的连带后果
父任务做废之后，团队的本能反应是"再分细一点"，结果父任务下的子任务数量失控。我统计了不同子任务数量区间的父任务表现，发现一个明确的拐点。
子任务数在 3 到 8 条之间时，父任务的延期率和周会停留时间都处于可控区间；一旦超过 15 条，延期率接近一半，周会讨论时间也接近 10 分钟每条。这说明父任务的健康区间是有物理边界的，不是"越细越好"。
四、专业判断逻辑：父任务的四要素与三问法
前面讲的是不该做什么，这一节讲该怎么判断。我把父任务的设计拆成四个必须固化的要素，再加一个决定"要不要建"的三问法。
1. 要素一：命名规范，用动词和结果，不用名词和范围
父任务名称必须包含三个信息：交付物、可验证的结果状态、时间边界。我推荐的格式是"【域】+ 交付物 + 结果状态 + 时间"。
对比一下："支付模块优化"是典型的反面样本，它无法判断什么时候算完；"【支付域】分账结算能力上线并完成生产验证 – 2025Q3"就明确得多，任何人读完都知道终点在哪里。
2. 要素二：验收标准，用可验证的事实，不用主观描述
验收标准要写成"可以被第三方验证"的句式。我见过太多"性能良好""体验流畅""稳定性提升"这类描述，它们的问题是：没有一个人能在周会上说"这不符合标准"。
一条合格的验收标准应该包含指标、阈值和验证方式。下面是我实际使用的一份父任务模板，你可以直接拿去改。
父任务标题：【支付域】分账结算能力上线并完成生产验证 – 2025Q3
验收标准（Definition of Done）：
分账规则配置接口在生产环境通过压测，P99 响应 < 200ms
连续 7 天对账误差率 < 0.01%，期间无人干预
财务侧完成 3 笔真实分账并书面确认结果一致
结果责任人：张 XX（唯一 Result Owner，不可转让给项目经理）
执行协作人：李 XX（后端）、王 XX（测试）、赵 XX（财务对接）
前置依赖：清结算中台 v2.3 上线（外部团队，需在父任务依赖字段挂接）
子任务上限：8 条，超过则拆分为同级父任务
进度口径：关键路径口径（以第 1、2、3 条验收标准的达标情况计算）
3. 要素三：单一结果责任人，这里是项目经理制度的关键
这一条是我认为整套设计里最重要的。父任务的结果责任人必须是能对交付结果负责的业务角色，而不是项目经理。项目经理的角色是维护制度运行，不是替所有人背交付责任。
在实操中我会明确区分三个角色：结果责任人（Result Owner）对验收标准负责，执行人（Assignee）对子任务完成负责，项目经理（PM）对父任务的完整性和节奏负责。项目经理有权要求补充验收标准、有权升级风险，但无权替结果责任人关闭父任务。
这个区分一旦建立起来，项目经理的工作量会立刻从"逐个盯任务"变成"盯异常"，这是我观察到的最大杠杆点。
4. 要素四：进度口径，放弃完成数，改用关键路径
我把三种常见进度口径做了对照测试，结论很明确：完成数口径在项目早期会严重高估，工时加权口径相对准确但依赖工时填报质量，关键路径口径最准确但需要父任务上明确挂依赖。
我的建议是分层使用：交付周期短于两周的父任务用关键路径口径（其实就是看验收标准达标了几条），长于两周的父任务用关键的 2 到 4 个里程碑节点来计算，永远不要用完成数占比。
5. 三问法：决定这个父任务到底要不要建
上面四个要素解决的是"怎么建"，三问法解决的是"要不要建"。我在每次需求评审会上都用这三个问题过滤父任务，效果比任何规范文档都好。
第一问：它有没有独立的验收标准？如果它的完成完全由另一个父任务的完成决定，那它就不该是父任务，应该是一条子任务或者一个检查项。
第二问：它有没有独立的结果责任人？如果责任人和上级父任务完全相同，把它降级为子任务，除非它涉及跨团队协作需要单独升级。
第三问：它会不会在周会上被单独拿出来讨论？如果它永远不会被单独提起，说明它的风险等级不支撑单独的管理开销，降级处理。
这三个问题必须全部答"是"，才允许创建父任务。我用这套方法在一个 90 人团队做过验证，候选父任务从 100 个压缩到 27 个，而团队反馈"信息缺失"的比例不到 5%。
五、真实案例与数据：一次 280 人规模的父任务治理
下面这组数据来自我参与的一次真实治理，覆盖 6 个研发团队、约 280 人、历时 3 个月。我先说明数据口径，方便你判断可迁移性。
1. 治理前的基线情况
治理前，这 6 个团队共用一套任务管理平台，全量父任务 412 个，其中 87 个在 60 天内没有任何状态变化，属于典型僵尸父任务。父任务平均子任务数 14.7 条，平均存活天数 63 天，周会用于父任务状态同步的时间是 26 分钟每场。
更关键的是归属问题：把所有任务卡拿出来统计，有 61% 的任务卡不属于任何父任务，也就是孤岛任务。这意味着超过一半的工作内容在管理视图上是不可见的。
2. 我们做了哪四件事
治理动作一共四步，没有任何一步依赖工具的高级功能，全部是制度层面的改动。
- 清理僵尸父任务：把 60 天内无状态变化的 87 个父任务全部归档，涉及仍在进行的子任务重新挂接到新建的交付物型父任务上。
- 统一父任务模板：强制填写四项内容，交付物、验收标准、结果责任人、进度口径。模板里不提供"模块名"这类字段，从物理上阻断目录型父任务。
- 关闭自动完成规则：父任务必须由结果责任人基于验收标准人工关闭，并要求在关闭时填写一行验证说明。
- 设置粒度阈值告警：子任务数超过 8 条的父任务，每周自动出现在项目经理的治理清单里，逐个判断是拆分还是升级为项目层。
3. 治理后的结果数据
三个月后复查，六项核心指标全部改善。其中我最看重的是父任务关闭后重开率，从 19% 降到 4%，这说明"人工验收"这一步真的拦住了假交付。
另一个意外收获是周会时长。我原本预期能压缩到 15 分钟就不错了，实际降到了 9 分钟，因为讨论从"念状态"变成了"过异常"。
4. 父任务生命周期分布的变化
把父任务存活天数做成分布看，变化更明显。治理前有 56% 的父任务存活超过 30 天，这是一个危险信号，因为长周期父任务意味着验收标准在很长时间内无法被验证，风险只能靠人的主观判断兜底。
治理后，65% 的父任务集中在 8 到 30 天这个区间，超过 60 天的只剩 3%。这个分布才是一个健康交付体系应有的形状。
5. 为什么把承载平台换成了 PingCode
这次治理进行到第二个月时，我们做了一次平台迁移决策。原因是原平台在三个点上成了制度落地的阻碍：父任务的验收标准字段无法强制必填、子任务数阈值告警需要额外开发、以及任务层级的显示深度不可配置，四层以上的树形结构在页面上几乎不可读。
最终选择 PingCode，主要基于三个实际考量。第一是它面向中大型企业和 100 人以上组织的场景设计更完整，我们这个 280 人的规模正好落在它的核心适用区间，权限模型、跨团队协作、多项目视图这些能力不需要二次开发。
第二是支持私有化部署。我们的财务和结算相关任务涉及敏感数据，必须走内网，这一点在选型时是硬性门槛。
第三是支持从 Jira 平滑迁移。我们此前积累了大量历史任务数据，迁移过程中字段映射和父子关系保留是关键，实际迁移时我们用了一周完成数据搬迁和字段对齐，没有出现父子关系断裂。对我们这类需要做国产替代的团队来说，这是一个阻力比较小的路径。
不过我还是要说清楚一点：工具能解决的是"制度能不能被强制"，不能解决"制度对不对"。如果三问法和四要素没有先想清楚，换任何平台都只是把混乱换个地方摆放。
六、不同情况下的行动建议
父任务的做法必须和组织规模匹配。我见过 8 个人的团队抄了 200 人团队的层级结构，结果每周花三小时维护任务树；也见过 300 人的组织坚持用平铺看板，导致跨团队依赖完全靠口头同步。
1. 10 人以下团队：不要父任务
这个规模下，沟通成本远低于管理成本。你需要的是一条清晰的待办列表加上责任人字段，最多再加一列"本周重点"。
如果你觉得看板乱了，先问自己是不是任务卡本身写得不够清楚，而不是急着建父任务。这个阶段建父任务，99% 会退化成文件夹。
2. 10 到 50 人团队：一层父任务，只服务交付物
这个规模可以引入父任务，但只用于承载跨迭代的交付物，比如"XX 能力上线"。同一时间活跃的父任务控制在 6 到 10 个，超过这个数量说明父任务建得太碎。
项目经理在这个阶段的角色是维护父任务模板和做粒度巡检，每周花 30 分钟检查是否有子任务数超过 8 条的父任务就够了。
3. 50 到 200 人团队：三层结构，父任务必须有唯一责任人
这是父任务制度收益最明显的区间。项目层、父任务层、子任务层三层结构稳定运行，父任务数量在同时间保持在 15 到 25 个之间。
这个阶段必须建立两件事：一是父任务的结果责任人不能默认是项目经理，二是每周一次的父任务健康度检查，重点看子任务数和存活天数两个阈值。
4. 200 人以上团队：加视图，不要加层级
组织变复杂后，很多团队的第一反应是加一层"项目群"或者"版本"。我的建议是用视图和标签解决聚合问题，不要用层级。
四层结构的可读性会急剧下降，项目经理会变成专职展开折叠的操作员。正确做法是保持三层，通过"版本""业务域""季度"这类字段做筛选视图，需要看全局时切换视图即可。
这个阶段通常需要平台级支持，比如跨项目的父任务汇总视图、依赖关系可视化、以及字段级权限控制。这也是为什么 100 人以上的组织在选型时会更看重平台完整性，而不是单点功能好不好用。
5. 跨部门与外包混合团队：父任务升级为合同边界
当父任务涉及外部供应商时，它的性质会发生变化，从管理单元变成验收单元。这时候验收标准必须写得比内部任务更死，最好做到可以逐条打勾，并且明确"未达标时的处理方式"。
我建议这类父任务单独设一个字段标记为"外部交付"，并在关闭流程里增加一道外部确认动作，由对接人上传确认记录后才能关闭。这一步多花两分钟，能省掉后续大量的扯皮成本。
七、不同情况下的取舍
制度设计本质上是一连串取舍，没有全赢的选项。这一节我把四个最常见的取舍摊开讲，每个都给出我的选择和理由。
1. 层级深度与管理成本的取舍
层级越深，信息完整度越高，但每日维护成本也越高。我实测过不同层级数下的维护成本：两层结构下每人每天约 3 分钟，三层约 5 分钟，四层约 11 分钟，五层会超过 18 分钟并且开始出现明显的字段空置。
我的选择是三层封顶。第四层的信息用检查清单承载，检查清单的维护成本远低于任务层，而且不需要状态管理。
2. 自动汇总与人工验收的取舍
自动汇总省人力，但会放行假交付；人工验收增加一次确认动作，但能拦住问题。我的选择是父任务一律人工关闭，子任务允许自动流转。
为了降低人工关闭的摩擦，我会在流程上做减法：关闭时只要求填写一行验证说明，不要求上传附件、不要求走审批流。这一行说明是整个流程里性价比最高的投入。
3. 工时填报与无工时管理的取舍
工时数据对产能规划和成本核算很有价值，但填报本身是纯开销。我的判断标准是：如果组织需要对外结算或者需要做人力成本分摊，就必须填；如果只是内部研发团队，可以不填。
如果决定填，只有一条铁律：工时只挂最细粒度的执行单元，父任务工时自动累加，禁止手工填写。这条规则不遵守，工时数据还不如不填。
4. 强制度与弱制度的取舍
强制度指必填字段多、流程环节多、违规有明确后果；弱制度指字段精简、流程短、靠自觉。这里面有一个反直觉的结论：强制度在初期落地速度快，但在第 3 到 6 个月会遭遇大规模形式化填报；弱制度见效慢，但可持续性明显更好。
我的选择是折中：父任务模板只强制四个字段（交付物、验收标准、结果责任人、进度口径），其余全部选填；但粒度阈值和人工关闭这两条做成硬约束，没有例外。这样既保住了核心质量，又不至于让团队觉得在被填表。
5. 平台层级能力与自建标签体系的取舍
有些团队选择用标签模拟层级，好处是灵活，坏处是无法做父子进度汇总和依赖管理。我的判断是：如果你的组织超过 50 人，且存在跨团队依赖，就不要用标签模拟层级。
标签适合做横向切分（业务域、版本、优先级），不适合做纵向切分（父子关系）。两者的本质区别在于：纵向关系有状态传递和进度汇总的需求，标签没有。
八、总结：父任务的本质是一次权责约定
回头看那 412 个父任务和 61% 的孤岛任务，我最大的体会是：父任务问题从来不是"管得太少"，而是"在错误的地方管得太多"。团队花了大量时间维护任务树的外观，却没有花时间定义什么叫做完。
父任务真正解决的问题只有一个：让一件需要多人协作、跨越较长时间的事，有一个可以被验证的终点和一个明确的负责人。所有其他功能，都是这个核心的副产品。
如果你想立刻动手，我建议按下面这个七天节奏推进，不要一次性全铺开：
- 第 1 天：导出当前所有父任务，统计子任务数、存活天数、责任人字段填写率三项数据，先看到真实基线。
- 第 2 天：把存活超过 60 天且无状态变化的父任务全部归档，这一步通常能清理掉 20% 左右的僵尸数据。
- 第 3 天：上线父任务模板，只强制四个字段，其余保持选填，减少落地阻力。
- 第 4 天：关闭父任务自动完成规则，改为结果责任人人工关闭并填写一行验证说明。
- 第 5 天：对全部父任务跑一遍三问法，不通过的降级为子任务或检查项。
- 第 6 天：设置子任务数超过 8 条的治理清单，指定每周固定时间巡检。
- 第 7 天：把结果责任人和项目经理的角色边界写成一页纸，在团队内公开确认，这是整套制度能不能活过三个月的前提。
最后一句提醒：父任务的数量应该随团队成熟度先升后降。刚引入时会增加，规范之后会减少，最终稳定在一个和你组织交付节奏匹配的水平。如果你发现父任务数量只增不减，那不是团队用得不好，而是制度里缺少一个收口的动作。
常见问题解答（FAQ）
1. 父任务到底该怎么拆？是不是把所有子任务都挂在父任务下面就完事了？
我第一次做项目经理时，把需求评审、开发、测试全塞进一个父任务，结果进度永远卡在30%，直到延期才发现风险。后来我疑惑，父任务应该按阶段拆还是按交付物拆，子任务又该拆到多细？
父任务不是容器，而是可独立验收的交付物或里程碑。拆分时先问一句话：这个父任务完成后，交付给谁、对方拿什么标准验收。按交付物拆，一个父任务下挂3到7个子任务，超过10个通常说明父任务太大了。每个子任务必须有唯一负责人、开始日、截止日、预估工时和验收标准。
父任务进度用子任务加权，权重优先用预估工时，其次用故事点，最后才用数量。父任务完成标准是全部子任务通过验收且父任务验收人确认，不是子任务一关闭就自动完成。经验判断：父任务连续两周没有子任务更新，或者逾期子任务比例超过20%，基本就是僵尸父任务，要马上拆开或重新定负责人。
2. 项目经理制度从0到1，最小可行制度到底该包含什么？要不要一上来就写几十页流程？
我们团队原来没有项目经理，老板让我三个月搭起来，我一开始写了很多流程，结果没人看也没人执行。我想知道先定什么、后定什么，怎么让制度真的跑起来而不是挂在墙上。
最小可行制度先定四件事：角色与授权、任务分层、例会和升级机制、度量口径。角色上写清楚项目经理对交付结果负责，职能经理对人天和资源负责；授权上写清楚项目经理能排优先级、能拉会、能升级。任务分层只做三层：父任务对应交付物或里程碑，子任务对应可执行动作，最多再拆到检查项。
例会每周一次30分钟风险会，只盯阻塞、变更和逾期，不逐条汇报。升级机制写死：阻塞超过24小时，或影响关键路径超过1天，必须升级。度量口径先看按期交付率、逾期任务数、需求变更次数、阻塞时长。落地顺序是在一个6到10人项目试点2个迭代，再推广。制度文档不超过2页，附任务模板和填写例子。
判断依据：如果项目经理每天超过30%时间在催进度，说明角色、任务分层或负责人没定清。
3. 没有专门的项目管理工具，只用表格和聊天工具，父任务和项目经理制度还能落地吗？
我们团队预算有限，平时只用聊天工具和在线表格，我担心父任务一多就乱成一锅粥。我想知道不用某项目管理平台，能不能先把制度跑起来，以及什么信号出现时必须换工具。
能落地，但要接受三个限制：状态更新靠人、依赖关系容易丢、历史数据难沉淀。表格最小字段包括任务ID、父任务ID、任务名称、负责人、状态、优先级、开始日、截止日、预估工时、实际工时、阻塞原因、验收人。父任务可以单独一张表，或者用筛选视图看。
制度上固定两个动作：每天下班前更新一次状态，每周五校准一次父任务完成度。用条件格式把逾期和阻塞标红。数据口径：父任务完成率等于已验收子任务工时除以父任务总工时，不要用子任务个数简单平均。
什么时候换工具：同时进行的父任务超过20个、跨3个以上部门、或者每周因为状态不同步开超过2次对账会，就建议引入某项目管理平台。判断依据不是团队人数，而是协调成本。
4. 父任务进度怎么算才不骗人？为什么很多父任务显示90%却还能拖一个月？
我最怕看到父任务进度90%，问负责人就说快好了，结果又拖两周。我想知道百分比到底该由谁定、按什么口径定，才能让老板和团队都认。
父任务进度不要靠负责人拍脑袋，要用子任务加权自动汇总。权重优先用预估工时，其次用故事点，最后才用子任务数量。口径是：父任务进度等于已完成且通过验收的子任务权重之和除以父任务总权重。子任务只设两种终态：未完成和已验收，开发完但没验收不能算完成。
如果父任务是里程碑，可以按检查项算，例如需求冻结、开发完成、测试通过、上线各占25%。防骗机制是每周更新一次，进度只能通过子任务状态自动汇总；如果负责人要手动改父任务百分比，必须写变更原因。异常判断：父任务连续两周进度不变，或者已验收权重低于60%但截止日只剩3天，就要升级。
经验上，90%拖延通常不是执行慢，而是验收标准不清或隐藏依赖没暴露。
核心关键词
文章包含AI辅助创作：父任务怎么做？项目经理制度设计：任务管理从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/344750
读者评论
自动关闭父任务这条我踩过坑。之前设定子任务全完成就关闭，结果测试子任务还没验收就关掉了，两周后重新打开。后来改成父任务必须责任人手动填验收结论，且验收人不能是执行人，重开率明显下降。不过小团队人少时，硬拆验收人反而增加形式感，这里可能得看团队规模。
到8条子任务的建议我部分保留。我们做硬件和固件联调，一个父任务下经常十几条，因为按测试项拆的，砍到8条会丢掉追溯性。我的做法是父任务下再按阶段分，但限制父任务本身只看关键路径。文章说第四层交给检查清单，问题是检查清单无法挂责任人和截止时间，这点想听听实际怎么补。
父任务责任人不能默认项目经理，这点很认同，但落地时有个现实问题：很多研发组长只愿对技术结果负责，不愿对交付时间和跨团队依赖负责。我们试过让技术负责人做父任务责任人，结果依赖谈判还是推回PM。后来把跨团队依赖单独拆成项目级任务，父任务只留交付物，才稍微顺一点。制度设计可能还得配考核。