父任务管理指南：PMO如何做好任务管理，风险控制全流程

2022年我接手过一个制造业集团的PMO诊断项目。客户当时在用的某项目管理平台里躺着876个父任务，季度经营分析会前一天，项目经理们还在手工拼进度。我让团队抽样核了214个父任务，其中133个（62.1%）在过去30天里没有任何子任务状态变更，却依然挂着"进行中"的标签。真正让我警觉的不是这个比例，而是其中41个父任务的负责人，直到我在会上被点名，才知道自己"负责"这件事。

这件事之后我把父任务管理单独拆成了一个课题。父任务不是任务列表里的一层缩进，它是PMO把分散的执行动作聚合成可管理风险单元的唯一抓手。如果父任务这一层失效，PMO拿到的所有汇总数据都是噪音，风险管理也就无从谈起。

这篇指南会把我这几年的判断标准、误区清单、阈值设定和取舍逻辑一次性讲清楚，包括我在一个中大型企业客户那里用PingCode做的完整治理复盘。

一、核心结论：父任务管理的本质是设计一条风险传导链

先说结论，省得你看到第三部分才发现方向不对。父任务管理的核心目标不是"让进度看起来整齐"，而是建立一条从执行动作到管理层决策的风险传导链。链路上任何一环断了，PMO就只能在出事后做解释，而不能在出事前做干预。

1. 父任务承担的是聚合职责，不是收纳职责

很多人把父任务理解成"文件夹"，把相关的子任务往里一塞就算完事。这种用法在个人待办清单里没问题，在企业级项目管理里就是灾难。文件夹只需要收纳，父任务要承担三件事：聚合进度、聚合风险、聚合责任。

聚合进度解决的是"这件事整体到哪了"；聚合风险解决的是"这件事会不会拖垮里程碑"；聚合责任解决的是"出了事我找谁"。三者缺一不可，只有进度没有风险的父任务，本质是一个美化过的进度条。

我的判断标准很直接：如果一个父任务无法回答"当前最大风险是什么、由谁在什么时候解决"，它就不配作为父任务存在于PMO的视图里。

2. 父任务必须绑定四个不可省略的属性

在给客户做流程设计时，我会强制要求每个父任务至少绑定四个属性，缺一个就不允许创建。这四个属性构成了风险传导链的最小闭环。

• 唯一可交付物：用一句不含动词模糊词的话描述交付结果，例如"完成MES与ERP的物料主数据双向同步上线"，而不是"推进系统集成"。
• 单一责任人（Owner）：只能是一个人，不能是部门、不能是两人共担。共担责任在父任务层级等于无人负责。
• 承诺完成日期：必须有明确日期，且该日期要与里程碑或合同节点挂钩，不能是"预计下季度"。
• 风险开关：一个布尔字段加一段文本，标识"当前是否存在需要PMO介入的风险"。这是父任务区别于普通任务的唯一标志。

3. 风险控制的关键是父任务级别的可观测性

我常说一句话：PMO不是管任务的，是管偏差的。偏差要能被看见，前提是父任务这一层有足够的可观测信号。

可观测信号不需要多，但不能假。我通常只保留四个信号源：子任务逾期数量、关键路径上的子任务状态、父任务剩余工期与预估工期的差值、以及子任务的阻塞标记。这四个信号足以支撑红黄绿三色健康度，也足以让PMO在周会上只讨论红灯项。

二、真实场景：父任务是怎么一步步失控的

抽象结论讲完，我需要把场景铺开。因为父任务失控从来不是某一次失误造成的，而是几个看起来都很合理的小决策叠加出来的。

1. 一个典型的失控现场

回到那个制造业客户。项目启动时，PMO设计了三层结构：项目群 → 父任务 → 子任务。设计本身没问题，问题出在执行。

第一阶段，业务部门嫌拆得细，把原本应该拆成8个父任务的工作包合并成2个，理由是"这些本来就是一回事"。第二阶段，IT部门为了保证可追溯，把每个父任务下面的子任务拆到30个以上，最夸张的一个父任务挂了61个子任务。第三阶段，为了赶季度汇报，项目经理被要求"先把状态填了"，于是大量父任务被批量置为"进行中"，再没人回头改。

三个动作单独看都合理，叠加起来的结果就是：父任务粒度极不均匀，完成度计算失去意义，状态字段彻底失真。PMO在季度末拿到的进度数据，和实际交付进度偏差超过三周。

2. 失控的组织原因大于工具原因

每次做诊断，客户第一反应都是"是不是工具不行"。我通常会把这个假设先按住，因为在我复盘过的案例里，父任务失真的第一因几乎都是组织责任没有被压到父任务这一层。

具体表现是：父任务的责任人往往是部门负责人而不是实际交付人；父任务的完成日期由PMO填而不是由承诺方填；父任务的风险状态由PMO在周会上追问后补录。这三条决定了父任务从诞生起就是"PMO的父任务"，而不是"交付团队的父任务"。

工具在这里的作用是放大或抑制这种失真。一个有强制字段、有变更留痕、有健康度自动计算能力的平台，会让失真变得困难；一个只提供层级展示的平台，会让失真变得毫无成本。

3. 中大型企业的复杂度是数量级的差异

100人以下团队，父任务管理靠一个靠谱的项目经理加一张表就能撑住。一旦超过100人、跨三个以上部门、同时跑五个以上项目，复杂度不是线性增长。

我统计过自己接触过的项目：50人规模的单项目，父任务数量通常在20-40个；300人规模的项目群，父任务数量会到400-900个；如果是集团级多项目并行，父任务数量会突破2000个。这个量级下，没有自动化的健康度计算和风险聚合，PMO的人力根本覆盖不过来，必然退化成抽样检查和事后救火。

三、父任务管理的七个常见误区

下面这七条是我在过去几年里反复见到的，按出现频率排序。每一条我都会说清楚"为什么错"以及"错在哪一步"，因为只知道结论不改行为没有意义。

1. 误区一：把父任务当文件夹用

表现是把一堆不相干的子任务塞进同一个父任务，只因为它们"属于同一个系统"或"同一个部门负责"。这种父任务没有唯一可交付物，也没有明确的完成定义。

为什么错：没有唯一可交付物的父任务，无法判断完成，也无法判断延期。你只能得到一个百分比，而这个百分比在任何决策场景下都不可用。判断方法很简单，如果你不能用一句话说出"这个父任务交付了什么"，它就该被拆掉。

2. 误区二：完成度按子任务数量平均

这是最隐蔽也最普遍的误区。10个子任务完成9个，父任务进度就是90%。听起来合理，实际上完全错误。

因为子任务的工作量差异可能是20倍。一个"完成数据迁移方案评审"和一个"完成全量数据迁移"在数量上等价，在工期上差三周。这种算法会让父任务进度在高位虚挂很久，然后在最后阶段断崖式下跌。

正确的做法是加权完成度：父任务进度 = Σ（子任务权重 × 子任务完成度）。权重可以用预估工时、也可以用Story Point，关键是必须有一个非数量的锚。如果团队连估算都没有，那么退一步用关键路径法：父任务进度只看关键路径上最后一个未完成子任务。

3. 误区三：父任务负责人挂名

很多组织的父任务负责人填的是部门经理或项目总监。他们的名字出现在系统里，但实际不做任何推进动作。真正干活的人以子任务执行者身份存在，却没有权限更新父任务的风险字段。

结果是父任务的状态永远滞后于现实，因为信息要经过一层甚至两层传递才能上报。我的规则是：父任务负责人必须是能够对交付结果负责、并且有权限调动资源的人，通常是子任务的直接协调者，而不是汇报链上级。

4. 误区四：分解层级越深越可控

我见过拆到五层的项目结构：项目 → 子项目 → 父任务 → 子任务 → 子子任务。设计者以为这样更精细，实际上带来三个问题：层级维护成本指数上升、汇总口径难以统一、执行者抵触填写。

经验值是三层为上限：项目/项目群 → 父任务 → 子任务。如果确实需要更细，那说明父任务粒度太大，应该拆分父任务而不是增加层级。层级是管理成本的放大器，不是精度的保证。

5. 误区五：风险写在周报里，不写在父任务上

这是最致命的误区。风险被写进Word周报和PPT，然后讨论、然后遗忘。到下一次周会时，同一个风险以更严重的形态重新出现。

根本原因是风险没有和任务对象绑定，就无法进入追踪闭环。写在文档里的风险，责任人和截止日期是自由的；写在父任务字段里的风险，会随着父任务一起进入看板、进入过滤器、进入升级提醒。这两者的追踪强度差一个量级。

6. 误区六：只看逾期，不看阻塞

逾期是结果，阻塞是原因。只统计逾期数量的PMO，永远在事后工作。我要求客户的父任务视图里必须有一个"阻塞子任务数"字段，并且这个字段的告警优先级高于逾期。

因为一个子任务被阻塞3天，通常意味着上游有依赖没解开，而这个依赖很可能影响其他父任务。阻塞是横向传导的，逾期是纵向累积的，前者更需要PMO协调。

7. 误区七：父任务只增不减

项目范围变更、方案调整、需求取消之后，父任务被置为"已关闭"之外的处理方式五花八门，有的挂着不动，有的被改名成"（已取消）"继续躺在列表里。

僵尸父任务是父任务体系可信度的第一杀手。我的规则是：任何父任务连续21天无子任务状态变更且无有效沟通记录，自动进入待确认队列，由负责人48小时内确认真实状态，否则强制降级为"暂停"并从主视图移除。

四、专业判断逻辑：粒度、分解、权重与阈值

这一部分是我实际使用的判断框架。它不是教科书式的项目管理理论，而是被真实项目打磨过的取舍标准，每一条都对应过至少两次踩坑。

1. 父任务粒度：两周交付原则

我给客户的父任务粒度标准叫"两周交付原则"：一个父任务从开始到完成，理想工期是1-4周，超过6周必须拆分，少于3天说明粒度太细可以合并。

为什么是两周？因为两周是PMO能够有效干预的最长时间窗口。超过两周的父任务，中途的偏差不容易被识别，等到发现时已经没有调整空间。短于三天的父任务则会带来大量管理开销，且风险消化能力不足。

这个标准的例外是外部依赖型父任务，比如"等待第三方接口联调"，这类父任务工期由外部决定，但必须有一个内部的"跟进动作"作为子任务，否则它仍然会变成僵尸。

2. 扇出比控制：单个父任务挂5-12个子任务

扇出比是我自己造的词，指一个父任务下的子任务数量。我的经验区间是5到12。

少于5个，通常说明父任务还可以合并，或者分解不够；多于12个，负责人的逐条检视成本会显著上升，实测超过15个之后，负责人平均每周只查看其中约6成，剩下的靠"状态没变就是没问题"的默认假设蒙混过关。

3. 完成度计算：权重法为主，关键路径法为兜底

权重法需要估算基础。如果团队有工时估算或点数估算，直接用即可。如果没有，我会用"三档权重法"：把子任务分为高、中、低三档，权重分别为5、3、1，由父任务负责人在分解时一次性标注。

这种做法精度不高，但胜在成本极低，而且比数量平均法准确得多。当父任务处于关键路径上时，额外采用关键路径法交叉校验：如果关键路径上还有未完成子任务，父任务进度上限锁定在70%，无论加权结果是多少。

下面是我给客户写的健康度计算逻辑示意，可以直接改成平台里的自动化规则。

def parent_task_health(task):
1. 加权完成度

total_weight = sum(sub.weight for sub in task.subtasks)

done_weight = sum(sub.weight * sub.progress for sub in task.subtasks)

progress = done_weight / total_weight if total_weight else 0

2. 关键路径锁定

if any(sub.on_critical_path and not sub.is_done for sub in task.subtasks):

progress = min(progress, 0.70)

3. 风险信号

overdue = sum(1 for sub in task.subtasks if sub.is_overdue)

blocked = sum(1 for sub in task.subtasks if sub.is_blocked)

idle_days = task.days_since_last_subtask_change

4. 健康度判定

if blocked >= 2 or idle_days >= 21:

return "RED", progress

if overdue >= 2 or (task.due_date - today).days return "YELLOW", progress

return "GREEN", progress

这段逻辑我用了三年，改动很小。核心在于它把"人为判断"压缩到最少，只留下三个客观输入：进度权重、关键路径、风险计数。能被自动算出来的结论，就不要留给人在周会上争论。

4. 风险字段设计：五个必填项

父任务上的风险信息不能是一段自由文本，那样无法统计。我要求五个结构化字段，前三个必填。

1. 风险类别：枚举值，通常为资源、技术、外部依赖、范围变更、质量、合规六类。
2. 风险等级：高/中/低三档，对应不同的升级路径和响应时限。
3. 应对动作与截止日：必须是可验证的动作，例如"6月12日前完成备用供应商技术评估"，不能是"持续关注"。
4. 影响范围：该风险会波及哪些其他父任务或里程碑，这是横向传导的关键信息。
5. 触发条件：什么情况下风险会升级为问题，用于提前设定阈值。

第三项是最容易被写成废话的一项。我的评审口径是：如果一个应对动作无法在系统里创建为一条有责任人和截止日的子任务，它就不是应对动作，只是表态。

5. 升级机制：按等级设时限，按影响设层级

风险识别出来但没有升级路径，等于没识别。我通常设计双维度升级规则。

这张表的关键不在时限数字，而在最后一列的升级对象必须是有资源调配权的人。如果升级对象还是项目经理，那这个升级机制只是换了个地方开会。

6. 风险闭环：从识别到复盘的六个节点

完整的父任务风险控制流程，我固定为六步，每一步都有明确的产出物和判定标准。

1. 识别：来源包括子任务阻塞标记、逾期统计、负责人主动上报、依赖方通知。产出物是父任务风险字段被填写。
2. 量化：判断风险等级、影响范围和触发条件。产出物是三级评定结果。
3. 阈值触发：系统按健康度规则自动判定红黄绿，红灯项进入PMO待办。产出物是自动生成的干预清单。
4. 升级与协调：按上表路径升级，PMO组织跨方协调。产出物是协调纪要与资源承诺。
5. 应对执行：应对动作被创建为子任务并进入正常追踪。产出物是可验证的完成状态。
6. 关闭与复盘：风险关闭后记录实际影响与耗时，季度汇总进入复盘库。产出物是风险模式库的更新。

第六步是大多数团队缺失的一步，也是长期收益最大的一步。没有复盘的PMO，第二年还会遇到去年同样的风险，只是换了个项目名。

五、案例与数据观察：一次640个父任务的治理复盘

这一节讲一个完整案例。客户是一家年营收40亿左右的装备制造企业，IT与数字化团队约320人，同时运行一个ERP替换项目群和若干产线数字化项目。

1. 治理前的基线

项目群内共有父任务640个，分布在11个项目中，跨6个部门。治理前的基线数据是：僵尸父任务占比58.6%，父任务平均扇出比19.4个，父任务完成度全部按子任务数量平均计算，仅有7%的父任务填写了风险字段。

PMO团队有6个人，每周花在整理父任务状态上的时间是22人小时，仍然只能覆盖约四成父任务的人工核实。

2. 治理动作与顺序

治理我们分三个阶段推进，顺序很关键，调换顺序效果会差很多。

1. 清理存量：冻结所有父任务状态更新两周，逐个确认真实状态与责任人。这一阶段关闭或拆分父任务217个，新增父任务任务86个，最终确定509个有效父任务。
2. 重构规则：上线扇出比告警（超过12个触发提醒）、两周交付原则检查、父任务风险字段必填、健康度自动计算规则。
3. 切换运行方式：周会从"逐个过项目"改为"只过红灯父任务与新增高风险"，PMO角色从数据收集转为干预执行。

工具方面，客户从原来的某项目管理工具迁移到了PingCode。选择理由有三条：一是需要私有化部署，制造企业的研发数据不能出内网；二是需要从原平台平滑迁移历史数据，640个父任务和近万个历史子任务的层级关系不能丢；三是需要支持父任务级别的自定义字段和自动化规则，健康度计算逻辑要能落到系统里而不是靠人算。

迁移过程比我预想的顺利。PingCode提供了从Jira体系迁移的路径，客户此前有部分团队在用Jira管理研发，这部分数据先合并进来再统一治理，避免了二次拆分。整个数据迁移加规则配置用了大约三周，其中规则配置占了两周，说明真正的工作量不在搬数据，而在把管理规则翻译成系统规则。

3. 治理后的数据变化

治理后第12周，我做了同样的抽样核算，结果如下。

我最看重的不是按期达成率提升了23个百分点，而是风险发现提前期从3.5天拉长到14.2天。这意味着PMO第一次拥有了真正意义上的干预窗口。3.5天只够打电话催人，14.2天可以做方案调整、资源调配甚至范围裁剪。

4. 一个具体的父任务样本

我想单独讲一个父任务，因为它集中体现了父任务管理的所有关键判断。

这个父任务叫"完成MES与ERP物料主数据双向同步上线"，治理前它下面挂了47个子任务，责任人填的是IT部门经理，完成度显示78%，状态"进行中"，连续42天无子任务状态变更。PMO每次周会问，得到的答复都是"快了"。

治理时我们做了四件事：

• 按交付物边界拆成4个父任务：主数据标准制定、接口开发、双向同步联调、上线切换与回滚预案。原父任务作为项目集级别的容器保留但不再承担进度统计职责。
• 把责任人从部门经理改为实际负责集成的技术负责人，部门经理改为"资源支持方"角色。
• 重新估算权重，识别出"数据清洗"这一项占整体工作量约35%但只被拆成2个子任务，重新拆为7个子任务并标为高权重。
• 填入两个真实风险：ERP侧提供的物料分类标准未冻结（高风险、外部依赖）；MES侧只有1名工程师熟悉同步逻辑（中风险、资源）。

结果是这个工作包最终延期9天，但延期在计划变更前11天就被识别并走了正式的里程碑调整流程。对比同期另一个未做治理的类似工作包，延期34天且是在交付日前两天才暴露。父任务管理不能消灭延期，但能把延期从"突发事件"变成"已决策事项"。

六、不同情况下的行动建议

父任务管理没有通用方案。下面按团队规模和场景给出四套建议，你可以直接对号入座，也可以组合使用。

1. 20-50人团队：单层父任务 + 手工健康度

这个规模不要上复杂规则。父任务数量通常不超过60个，一个经验丰富的项目经理完全可以靠人工维持。

建议动作是：把父任务粒度定在两周交付原则，强制填写责任人和风险一句话描述，每周花30分钟人工过一遍扇出比超过10个的父任务。完成度直接用关键路径法，不引入权重，因为估算成本高于收益。

这个阶段最大的风险是过度设计。我见过30人团队搞五级结构和十六个自定义字段，最后没人填，全部字段都是默认值。

2. 50-200人团队：规则固化 + 系统自动计算

到了这个规模，人工已经不可能覆盖。必须把健康度判定、扇出比告警、风险字段必填这些规则固化到系统里。

建议动作是：建立三层结构，上线自动化健康度计算，PMO周会只讨论红灯项，建立风险升级时限表。同时开始积累风险模式库，把每次关闭的风险归类记录。

这个阶段的常见失败是规则上线后没有配套的例会改造。规则变了但周会还是逐个过任务，PMO的工作量反而增加，最终规则被废弃。

3. 200人以上或多项目群：分层治理 + 跨项目风险聚合

这个规模的核心矛盾是部门诉求差异导致规则难以统一。我的建议是分层治理：集团层只管父任务的健康度和跨项目依赖，项目层自行决定内部的子任务拆分方式。

集团层的父任务视图只保留四列：父任务名称、责任人、健康度、跨项目影响标记。项目层可以用自己习惯的字段体系，但必须能向上汇总出这四项。

跨项目风险聚合是这个规模独有的需求。一个父任务的风险如果影响其他项目的里程碑，必须能被自动标记并推送到相关项目负责人的待办里，而不是靠PMO在群里喊。

4. 强监管或数据敏感场景：优先私有化部署

制造、金融、能源、军工类客户，数据不能出内网，这直接排除了SaaS形态的选项。选型时必须确认平台支持私有化部署，并且升级、备份、审计日志能力完整。

同时要确认迁移路径。我见过不止一个客户因为原平台数据无法平滑迁移，最终选择新旧并行，结果父任务在两边各有一套，治理难度翻倍。选型时让供应商明确给出迁移方案和时间表，把这一条写进合同，比看功能清单有用得多。

在这一点上，像PingCode这类面向中大型企业、支持私有化部署并支持从Jira平滑迁移的平台，确实比通用工具更适配这类场景，尤其是那些既想替换既有工具、又不愿意承担数据迁移风险的组织。

七、不同情况下的取舍

这一节讲取舍。所有管理动作都有代价，说清楚代价才能做出判断，而不是盲目照搬最佳实践。

1. 粒度精细 vs 维护成本

父任务拆得越细，风险可见度越高，但维护成本也越高。我的经验拐点在扇出比12个左右。超过12个后，每增加一个子任务带来的风险可见度增量，已经小于负责人注意力被稀释带来的损失。

取舍原则是：如果团队没有专职PMO，扇出比上限压到8个；如果有专职PMO，可以放到12个，但必须配套自动化的健康度计算。没有自动化支撑的精细化，最后都会变成形式主义。

2. 自动化计算 vs 人工校准

自动化健康度计算的好处是客观、低成本、可大规模运行，坏处是它只能识别信号，不能理解上下文。一个父任务可能因为下游客户确认延后而被动停滞，系统只能看到"21天无变更"，判定为红灯。

我的做法是自动化负责发现，人工负责裁定。系统判定红灯后进入PMO待办，但必须有一个人工确认动作，确认后可以选择"确认为风险"或"标记为合理停滞"并填写原因。被标记为合理停滞的父任务不计入红灯统计，但会记录，季度复盘时检查标记是否被滥用。

3. 强流程 vs 敏捷弹性

严格的风险字段必填、升级时限、复盘要求，会带来填写负担，尤其在敏捷团队里容易引发抵触。我的取舍是：父任务级别的规则必须强，子任务级别的规则要松。

因为父任务是管理层的观测对象，这里的信息必须结构化、必须可比。子任务是执行层的工具，这里的字段越少越好，让团队用自己舒服的方式工作。把管理要求压在父任务这一层，是成本最低的做法。

4. 自建工具 vs 采购平台

有技术能力的组织容易产生自建冲动。我的判断依据是父任务管理的规则迭代频率。

如果规则相对稳定、只需要基础层级和状态汇总，自建可行，成本可控。但如果涉及自动健康度计算、跨项目风险聚合、权限体系、审计日志、数据迁移这些能力，自建的总拥有成本会远高于采购，而且维护负担会长期占用研发资源。

我自己的经验是，自建的前六个月会很顺利，因为需求清晰。困难出现在第12个月以后，当组织架构调整、流程变更、人员流动同时发生时，没人愿意接手维护那套自建系统，最终它变成了另一个需要被治理的遗留系统。

八、落地检查清单与下一步

最后给一份可以直接用的检查清单。我把它设计成20分钟能过完的形式，建议你先自查，再决定从哪里开始动手。

1. 父任务体系自查清单

1. 随机抽20个父任务，看能否用一句话说出每个的交付物。超过3个说不出来，粒度规则需要重定。
2. 统计父任务扇出比分布，看超过12个的占比。超过30%，说明分解规则没有约束力。
3. 检查父任务负责人名单，看到多少是部门经理及以上职位。超过半数，责任人机制需要下压。
4. 统计连续21天无子任务状态变更且仍为"进行中"的父任务占比。超过20%，僵尸父任务已成规模。
5. 检查风险字段填写率和结构化比例。填写率低于60%或全部是自由文本，风险机制尚未建立。
6. 抽5个已关闭风险，看是否有复盘记录。如果没有，说明组织记忆机制缺失。
7. 记录PMO上周整理父任务状态所用工时。超过10人小时，说明自动化不足。

2. 建议的推进顺序

如果你的自查结果不理想，不要一次性上全套规则。我建议按这个顺序推进，每一步间隔两周观察效果。

• 第一步：冻结状态更新，做一次存量父任务清理。这一步的收益最直接，也最容易获得管理层支持。
• 第二步：上线扇出比告警和父任务风险字段必填。只加约束，不改流程。
• 第三步：引入健康度自动计算，改造周会规则。这是最难的一步，因为它改变的是工作习惯。
• 第四步：建立升级时限表和风险模式库，进入长期运行。

我见过太多团队跳过第一步直接上第三步，结果是新规则套在失真的老数据上，跑了两周就没人看了。父任务治理的起点永远是让存量数据变真实，而不是让新规则变漂亮。

3. 最后一句话

父任务管理的价值不在任务本身，而在于它是PMO唯一能够同时触达执行层和管理层的抓手。执行层在这里汇报真实状态，管理层从这里读取风险和偏差。

这个抓手能不能立住，取决于三件事：父任务是不是有唯一可交付物，责任人是不是真的在负责，风险信息是不是结构化的、能被自动识别的。这三件事做好了，工具的选择反而变成次要问题；这三件事没做好，换什么平台都只是把同样的混乱换个界面重演一遍。

下一步，我建议你今天就去抽20个父任务做第一项自查。20分钟，你会得到一个关于自己组织项目管理成熟度的、相当准确的判断。