先给结论：任务依赖管理真正要管的只有三件事
我先说结论，免得你读完一大段背景才发现跟自己的问题对不上。任务依赖失控，本质上不是排期能力问题，而是三个字段没填全的问题：唯一责任人、承诺日期、验收标准。这三个字段缺一个，这条依赖就已经处在"薛定谔的完成"状态。
1. 责任人必须是自然人，不能是团队名
我复盘过自己带过的项目，凡是把依赖负责人写成"后端组""数据团队""测试这边"的，兑现率都明显低于写成具体人名的。原因不复杂：团队名意味着"某个人"，而在每个具体的人看来，"某个人"很可能就是别人。这是典型的责任稀释。
如果这条依赖真的需要一组人协作，那就指定一个协调人作为对外唯一接口，其余成员由他内部调度。依赖的责任主体只能有一个，这不是管理洁癖，而是可追踪性的最低要求。
2. 承诺日期和期望日期必须分开记录
这是我最想强调的一点。需求方嘴里说的"我们这边希望 15 号之前能拿到"，和被依赖方明确说出口的"我承诺 18 号交付"，是两个完全不同的东西。绝大多数延期争议，都源于这两者在沟通中被悄悄合并成了一个日期。
我现在的做法是：期望日期和被依赖方的承诺日期分别建字段。当两者差值超过三个工作日，就自动升级为需要项目负责人介入的风险项。承诺日期是被依赖方主动说出口的，而不是需求方单方面写上去的。
3. 验收标准要写到"什么状态算完成"
"接口开发完成"这五个字，在不同角色眼里可以是代码提交、可以是联调通过、可以是文档归档。我见过一条依赖被标记为已完成，结果下游等了三天才发现对方交付的是没有鉴权模块的半成品。
可用的验收标准至少要说清三件事：交付物形态、验收方式、由谁验收。没有验收标准的依赖，等于没有终点线，跑的人不知道什么时候该停。
为什么这三件事在大团队里会被放大成严重问题？因为依赖的数量本身会膨胀。
一、背景与真实场景：依赖是怎么一步步失控的
上面那条延期十九天的项目，事后我把整条链路还原了一遍，发现它并不是某个环节出了大错，而是每一步都只错了 10%，最后叠加成了灾难。这个还原过程比结论更有参考价值。
1. 一条依赖从产生到爆炸的完整时间线
第 1 周，架构评审会上确认商品主数据要由数据平台团队提供标准接口，双方口头约定"月底前搞定"，会议纪要里写了一行"数据接口由数据平台支持"。这是第一次失真：没有责任人，没有具体日期。
第 3 周，业务方临时追加了一个字段需求，接口范围变了。变更只在两个工程师的私聊里确认，没有回到依赖清单里。这是第二次失真：变更未同步。
第 6 周，数据平台团队的主力被抽调去做另一个更高优先级的合规项目。这是第三次失真：资源冲突无人预判。
第 9 周，评审会上被问到谁签字确认，才发现这条依赖在两个团队的看板里都存在，但都没有指定负责人，也没有任何一方把它列入本周待办。
你会发现，这条链路上没有一个人是恶意的，每个人都在做"自己认为对的事"。依赖失控从来不是态度问题，而是流程里缺少强制登记的节点。
2. SF 流程里真正管用的四个登记节点
经过几次调整，我现在把依赖登记压缩到四个必须发生的节点，其他环节可以简化，这四个不能省。
- 拆解完成时登记：任务拆到可估算粒度后，立刻标出对外依赖，此时信息最完整、记忆最新鲜。
- 排期确认时对齐：被依赖方给出承诺日期，需求方确认接受，双方在系统里留下记录。
- 迭代启动时复核：每个迭代开始时，把所有未闭环依赖过一遍，确认承诺日期是否还成立。
- 变更发生时时同步：任何日期、范围、责任人的变化，必须在系统里更新，而不是在群里说一声。
3. 依赖失控的四个根因
把十一个项目的复盘记录汇总后，我统计了造成依赖问题的主因分布。样本量不大，只有 1287 条依赖记录，但趋势足够清楚：跨团队边界无人认领，占了近四成。
4. 依赖不只是一种，按类型分布看会更清楚
很多人一提依赖就想到"任务 A 完成后任务 B 才能开始"，实际上这只是其中一类。我在项目里把依赖分成五类，分类管理的成本远低于一视同仁地强管控。
二、拆解常见误区：五个看着合理、实际有害的做法
下面这五个误区，我在不同团队里都见过，而且提出它们的人通常都是出于好意。问题在于，好意不等于有效。
1. 误区一：把所有任务都设成强依赖
有些项目负责人为了"严谨"，把任务之间全部连上先后关系。结果是关键路径被人为拉长，甘特图看起来密不透风，实际上大量依赖只是"最好按这个顺序"，并非"必须按这个顺序"。
后果是什么？关键路径虚胖，团队失去了对真正瓶颈的判断力。当所有事情都紧急时，就没有事情紧急。我建议只把真正的硬阻塞标为强依赖，其余用弱关联或备注形式表达。
2. 误区二：把依赖等同于排期先后
排期先后只是时间顺序，依赖还包括资源、决策、环境、数据这些维度。一条任务可能在时间上排在前面，但因为要等一个审批结论，实际上根本无法启动。
只按时间排依赖的团队，常见症状是"每个人手上的任务都没超期，但整体就是不动"。因为真正卡住的不是排期，而是那些没有被登记为依赖的隐性等待。
3. 误区三：只盯进度，不盯依赖质量
周报里写"整体进度完成 68%"，这个数字几乎不提供任何决策信息。更值得看的是：有多少条依赖已经到期但未兑现、有多少条依赖的责任人字段还是空的、有多少条依赖的承诺日期已经过了但没有更新。
进度百分比反映的是过去，依赖健康度反映的是未来。项目负责人应该把更多注意力放在后者上。
4. 误区四：依赖变更靠群里吼一声
依赖变更的成本被严重低估。一个日期从 18 号改到 25 号，看起来只是七个数字的差别，但它可能连带影响下游三条任务的排期、一次测试环境的占用、一个客户承诺的交付节点。
变更必须在系统里留痕、必须通知到所有下游责任人、必须重新确认新的承诺日期。这三步少一步，就等于埋了一颗定时炸弹。
5. 误区五：把依赖登记率当成考核指标
这是我自己踩过的坑。有一年我把"依赖登记完整率"做成了团队考核项，结果很讽刺：登记数量短期内涨了三倍，但其中大量是"伪依赖"，比如把"写完文档"和"提交代码"这种同一个人前后完成的事也登记成依赖。
指标一旦变成考核，就会被优化；被优化的方式往往不是你想要的。正确的做法是把它当成诊断指标，用来发现问题，而不是用来评分发奖金。
三、专业判断逻辑：依赖分级与五个关键指标
把误区排除之后，接下来是我认为最实用的部分：怎么给依赖分级，以及用哪五个指标来衡量管理水平。
1. 依赖分级：P0、P1、P2 三级够用
我不建议做四级以上的分级，实践中没人记得住，而且分级越细，判断成本越高，最后大家会随便填。
| 等级 | 判断标准 | 管控动作 | 跟盯频率 |
|---|---|---|---|
| P0 硬阻塞 | 不完成，下游完全无法开工 | 必须有承诺日期、有验收标准、有升级路径 | 每日 |
| P1 强约束 | 可以开工，但不完成会导致返工 | 必须有责任人和承诺日期 | 每周 |
| P2 软耦合 | 只影响效率，不影响结果正确性 | 登记即可，无需专门跟盯 | 迭代复盘时统一看 |
按照我的经验，一个中型项目里 P0 依赖通常不超过总量的 15%。如果 P0 占比超过 30%，说明任务拆解粒度太粗，或者团队在通过提高等级来逃避判断责任。
2. 五个关键指标：定义、算法与参考区间
下面这五个指标是我在不同规模项目里反复验证后保留的。它们共同覆盖了"登记是否完整、承诺是否兑现、响应是否及时、缓冲是否足够、变更是否可控"这五个维度，去掉任何一个都会留下盲区。
| 指标 | 计算方式 | 参考区间 | 异常时的第一动作 |
|---|---|---|---|
| 依赖登记完整率 | 抽检的实际依赖数中被登记的条数 ÷ 抽检总数 | ≥ 90% | 抽查最近一个迭代，补录遗漏项并分析登记节点是否失效 |
| 依赖承诺兑现率 | 按承诺日期交付的依赖数 ÷ 期间到期依赖总数 | ≥ 85% | 分析未兑现项的集中方向，判断是否为承诺过于乐观 |
| 依赖响应时长 | 从依赖提出到被依赖方确认接受的时长 | ≤ 4 工作小时 | 检查是否有明确的接收确认机制，避免依赖"悬空" |
| 关键路径依赖缓冲占比 | 关键路径依赖上的浮动时间 ÷ 关键路径总工期 | 10% – 15% | 低于下限说明无缓冲，高于上限说明排期注水 |
| 依赖变更率 | 发生日期或范围变更的依赖数 ÷ 依赖总数 | ≤ 15% | 超过则回溯变更原因，常见于需求未冻结就进入排期 |
3. 指标不是孤立的，它们之间存在传导关系
单看一个指标容易误判。我观测到的最明显的一条传导链是：响应时长拉长，会导致需求方为了自保而提前催办，进而推高承诺兑现压力，最终体现为承诺兑现率下降和变更率上升。
换句话说，很多团队以为自己的问题是"执行力不够"，实际上根因在响应机制太慢。下面这组数据来自我参与复盘的十一个项目，属于小样本经验观察，用来说明趋势而非绝对结论。
4. 响应时长要看分位数，不能只看平均值
平均值是最容易骗人的统计量。一个团队的平均响应时长可能是 4 小时，看起来很健康，但如果 P90 是 36 小时，说明每十条依赖里就有一条会被晾一天半，这足以毁掉整个迭代节奏。
四、案例与数据观察：百人以上组织为什么必须换工具
说到这里，一定有人会问：这些流程用表格不也能做吗？我的答案是，五十人以下可以，到了一百人以上，表格会开始收"隐性税"。
1. 组织规模跨过 100 人后，依赖管理会发生质变
我给一家制造企业做研发流程梳理时，他们的研发中心约 320 人，分七个产品线，同时并行十一个项目。他们当时用一个共享表格维护跨团队依赖，表格有 47 个页签，最新版本存在三个人的本地电脑上。
问题不在于表格难用，而在于表格无法强制校验，也无法自动通知。责任人字段空着没人知道，承诺日期过了没人提醒，变更之后下游看不到。这些"没人知道"累积起来，就变成了每个季度都要加班的理由。
2. 结构化登记带来的实际变化
这家企业后来把依赖管理搬到了 PingCode 上。选择它的直接原因是三个：支持私有化部署，能满足他们的数据合规要求；支持从 Jira 平滑迁移，历史项目数据不用重来；作为国产平台，在本地化服务响应上更贴合他们的节奏。PingCode 主要面向中大型企业和 100 人以上组织，这跟他们的规模正好匹配。
落地方式并不复杂。他们把任务之间的阻塞关系显式登记，跨项目的依赖通过关联任务串联，路线图上可以直接看到依赖对里程碑的影响。项目负责人每周只需要看一个视图，就能知道哪些依赖已经逾期、哪些承诺日期逼近。
推行两个季度后，他们的数据变化如下。需要说明的是，这组数据来自客户内部复盘与我方项目观察记录，属于特定组织的实施结果，不代表所有团队的普遍水平。
| 观察指标 | 推行前 | 推行后（两个季度） | 变化幅度 |
|---|---|---|---|
| 依赖登记完整率 | 58% | 89% | +31 个百分点 |
| 依赖承诺兑现率 | 66% | 87% | +21 个百分点 |
| 依赖平均响应时长 | 14 工作小时 | 5 工作小时 | -64% |
| 依赖变更率 | 28% | 17% | -11 个百分点 |
| 项目平均延期率 | 34% | 19% | -15 个百分点 |
3. 但工具不是解药，边界必须说清楚
我必须给一个反向判断：如果团队连基本的依赖分级的共识都没有，上任何平台都只会把混乱记录下来，而不会消灭混乱。我见过有的团队把工具用得极其规范，字段一个不落，但 P0 依赖占了总量的 45%，等于给自己造了一个永远红色的看板。
工具解决的是"信息不透明"和"提醒不到位"，解决不了"任务拆得对不对""优先级判断准不准"。这两件事只能靠项目负责人的判断力。先有流程共识，再上工具，顺序不能反。
五、不同情况下的行动建议
同一套方法用在十人团队和三百人组织上，效果完全不同。下面按规模给出我的具体建议。
1. 二十人以内的小团队：只做两件事
这个阶段上工具是负担，登记成本可能高于收益。你只需要做两件事：每天站会时口头确认一遍"今天有没有谁在等别人"，以及把 P0 依赖写在共享文档最上面。
关键是养成习惯：任何人说"我在等 XX"的时候，必须补一句"等谁、等到什么时候"。这句话能让小团队避开大部分依赖事故。
2. 二十到一百人的中型团队：建立登记与承诺双节点
这个规模是依赖问题的高发区，因为已经超出了口头同步的覆盖范围，但还没到必须重投入的程度。建议把依赖登记嵌入迭代规划会，承诺确认嵌入迭代启动会，两个节点固定下来。
指标只看三个就够：登记完整率、承诺兑现率、响应时长。每周花十五分钟看这三个数的趋势，比看一百页周报有用。
3. 一百人以上的大型组织：分级管控加平台化
这个规模必须解决三个问题：跨团队依赖的认领机制、变更的自动通知、以及多项目并行时的资源冲突预判。前两个靠平台，第三个靠定期的跨项目依赖对齐会。
我的建议是每两周开一次三十分钟的跨项目依赖对齐会，只讨论 P0 依赖，每条依赖必须当场确认责任人和承诺日期。会议的唯一产出是一份更新后的 P0 依赖清单，没有这个产出就说明会白开了。
4. 一张可以直接用的自检清单
下面这份清单我在每个项目里都会过一遍，你可以直接拿去用。
- 启动期：所有 P0 依赖是否都有唯一到人的责任人？期望日期与承诺日期是否分开记录？验收标准是否写到"什么状态算完成"？
- 执行期：本周到期的依赖是否已确认？逾期的依赖是否有升级动作？变更过的依赖是否已通知全部下游？
- 收尾期：是否有依赖在最后阶段才被发现？延期天数有多少可归因到依赖？哪些依赖类型最容易出问题？
六、不同情况下的取舍
管理动作都有成本，下面四组取舍是我认为最需要提前想清楚的。
1. 登记粒度 vs 维护成本
登记得越细，信息越完整，但维护成本呈非线性上升。我观测到的经验值是：当依赖粒度细到半天以下时，维护成本会超过它带来的收益，因为更新频率太高，没人跟得上。
2. 强管控 vs 团队自主协同
强管控适合 P0 依赖和跨组织边界的事项，因为它需要明确的升级路径和截止压力。自主协同适合 P1、P2，因为这两类依赖的沟通成本通常高于其风险价值。
我的判断标准很直白：如果这条依赖一旦失约，会导致项目整体延期超过两天，就纳入强管控；否则交给团队自己协调。
3. 自建流程 vs 引入现成平台
自建流程的优点是贴合度极高，缺点是没人维护就会腐化。我见过太多自建表格在半年后变成"只填不改"的摆设。
引入平台的优点是自动化提醒和强制校验，缺点是需要适应期和迁移成本。如果你所在的组织在 100 人以上、项目并行数超过五个、且有数据合规或私有化要求，我倾向于引入平台而不是继续自建。像 PingCode 这类面向中大型组织的平台，在私有化部署和 Jira 迁移路径上相对成熟，能省掉大量磨合时间。
4. 迁移成本 vs 长期收益
迁移是很多人最犹豫的一步。我服务过的企业里，从其他工具迁移到国产平台的平均周期是六到十周，其中真正花在数据迁移上的时间不到三成，剩下七成花在团队习惯切换上。
判断是否值得迁移，我建议只问一个问题：当前工具最大的问题，是配置能解决的，还是架构不能解决的？如果是前者，配置就能改善；如果是后者，比如无法做跨项目的依赖关联、无法私有化部署，那迁移的收益会在一年内显现。
七、常见问题
1. 团队规模小，有必要建依赖清单吗？
有必要，但只需要一个大清单，不需要分项目建。小团队的风险不在依赖数量多，而在人员重叠度高，一个人卡住会影响多条任务。哪怕只记 P0 依赖，也能让你在站会上问对问题。
2. 依赖的承诺日期被反复延后怎么办？
先别急着批评执行方。我通常会做两件事：一是统计延后原因，看是否集中在某类依赖或某个团队；二是检查承诺日期当初是谁定的。如果承诺日期是被依赖方的上级或者需求方单方面定的，那延后几乎是必然结果。
3. 关键路径依赖缓冲占比应该设多少？
我的经验区间是 10% 到 15%。低于 10% 说明基本没有容错空间，任何一个小延迟都会传导到交付日；高于 15% 则要警惕另一种可能，就是团队在通过加大缓冲来掩盖估算能力不足。
4. 依赖变更率降到多少算健康？
15% 以内比较健康。但要区分变更的类型：需求范围变更带来的依赖变更是正常的，而纯粹因为忘记更新或者沟通疏漏导致的变更是可以压缩到接近零的。前者反映业务变化，后者反映流程漏洞，混在一起看会得出错误结论。
5. 工具能否自动识别依赖关系？
目前我看过的平台里，自动识别的能力集中在"同一需求下的任务关联"这类有明显结构线索的场景。真正跨团队、跨系统的依赖，仍然需要人工登记。不要期待工具替你做判断，它更适合做提醒和留痕。
八、结语：依赖管理的本质是让等待被看见
回到开头那个延期十九天的项目。事后我发现，真正的问题不是有人偷懒，而是那条依赖在两个团队之间形成了"责任真空"，双方都以为对方在推进，双方都没有把它列入自己的待办。
所以我对任务依赖的理解，最终收敛成一句很朴素的话：项目管理里最贵的成本不是返工，而是等待，而等待之所以昂贵，是因为它往往不可见。登记、承诺、承诺日期、验收标准、变更同步，这些动作的唯一目的，就是把等待从看不见变成看得见。
三个我最想让你避开的误区：把所有任务都设成强依赖，会让关键路径虚胖；只盯进度百分比而不看依赖健康度，会让你在事故发生时才发现问题；依赖变更不留痕，等于给未来埋雷。
下一步你可以做一件很小的事：打开当前项目，找出所有跨团队的任务，逐条问两个问题，这条依赖的责任人是谁，他承诺的日期是哪一天？只要有一个问题答不上来，那它就是下一个延期十九天的种子。把它补上，比读完任何方法论都管用。
常见问题解答（FAQ）
1. 任务依赖到底分几种？项目负责人上手第一周该怎么快速把所有依赖捋出来？
我刚从执行岗转到项目负责人，第一次排计划时脑子里全是任务，却说不清谁卡着谁。上线前两周才发现有个接口联调必须等第三方排期，一下把整个里程碑顶后了五天，那会儿我才意识到依赖不是画个甘特图就完事了。我想知道有没有一套上手就能用的识别方法，别一上来就让我啃大部头方法论。
先把依赖分四类再谈识别：完成-开始（前置做完后置才能开始，最常见的90%都是它）、开始-开始（两者同步起步，比如联调前后端同时进）、完成-完成（必须同时收口，比如文档和验收）、开始-完成（后置任务的结束取决于前置的开始，实际项目中很少见但排期时最容易被漏掉）。
我的做法是不画复杂网络图，改成一张三列清单：任务名称、前置任务编号、依赖类型，逐行填。填写时只问一句话，「这个任务能不能在没有任何其他任务完成的情况下开工？」答不能，就必然存在前置。
清单填完后做一次反向验证：把每个任务当成前置，看谁挂在它后面，凡是填不出下游的任务要么是真叶子节点，要么就是被你漏了。最后按「是否在关键路径上」标色，关键路径上的依赖必须100%识别清楚，非关键的允许先粗后细。这套动作做一遍，一个20到30个任务的中型项目，两个小时内能出初版依赖清单。
2. 衡量任务依赖管得好不好，最该盯哪几个指标？有没有可参考的合理区间？
我们团队每个迭代都在汇报进度百分比，可我总觉得这个数字没什么用，所有任务都显示80%，结果就是上不了线。老板问我依赖管理做得怎么样，我居然答不出一个具体数字。我想找几个真正能反映依赖健康度的指标，最好带着我自己的项目能直接算的口径和参考线，而不是那种听起来很对但没法量化的说法。
我建议只盯四个指标，多了算不过来。第一是依赖识别覆盖率，口径是「已登记前置任务的任务数÷总任务数」，关键路径上要求100%，整体低于85%说明你的清单是事后补的。第二是依赖延迟影响天数，口径是「下游任务实际开始日减计划开始日」，只看被依赖拖累的那部分，单个依赖超过3个工作日就要进风险清单。
第三是跨团队依赖响应时长，口径是「从提出依赖请求到对方给出明确排期的小时数」，24小时内首次响应、3个工作日内给出排期是我用过比较现实的线，超过就说明接口人机制没落地。
第四是依赖变更频次，口径是「单个迭代内依赖关系被修改的次数」，一个20个任务的迭代控制在3次以内算健康，超过5次基本可以判定是前期识别不足而不是需求变化。这四个指标每周更新一次就够了，别做日报，日报会让人为了好看而修改数据。
3. 前置任务延了，我该顺着依赖链全部顺延，还是想办法把后面的任务抢回来？
上个月一个数据库迁移晚了四天，我第一反应是把下游八个任务的日期挨个往后推，结果整个版本推迟一周，复盘时被问「你为什么默认所有下游都必须等」。我当时确实没想过有些依赖是可以化解的。我想知道遇到前置延期时，项目负责人该按什么顺序判断，哪些能救、哪些只能认。
不要先改日期，先对每条被影响的依赖做一次「能不能解耦」的判断，顺序是从快到慢。第一步看能否并行：比如后端接口没写完，前端能不能先按约定好的契约文档用mock数据开发，这类任务里大约有三到四成是可以用接口契约、桩数据或者静态样例先跑起来的。
第二步看能否拆批：把一次性交付拆成最小可用批次，先拿一部分数据或一个模块跑通链路，剩下部分随后补。第三步才看调整依赖类型：把必须完成-开始的任务改成开始-开始，靠提前介入评审或联调来吃掉等待时间。
这三步走完还剩下的，才是真正要顺延的，此时再改日期，并且只改关键路径上的，非关键路径看浮动时间够不够吸收。改完之后一定要做一件事：把这次延期原因和化解方式写进依赖清单的备注列，同一个原因第二次出现时就不再是意外，而是你的流程漏洞。
4. 跨团队依赖对方总说「排不上」，作为项目负责人我到底该抓什么才能推动？
我们有个依赖要等另一个部门做数据对账，我从月初催到月中，对方每次都说在排，但就是给不出时间。我也不想天天当催命鬼，可进度又压在我头上。我怀疑问题不在对方不配合，而在于我们之间根本没有一个明确的约定。
跨团队依赖推不动，九成不是态度问题，是没有把「请求」变成「有交付物的约定」。我现在的做法是每次提依赖必须带三样东西：明确的输入物（我提供什么、什么时候提供）、明确的输出物（对方交付什么形态、验收标准是什么）、明确的期望时间点。三样齐了再发出去，对方就没法用「在排」这种模糊话回应。
第二件事是锁定接口人而不是锁部门，一定要落到一个具体的人和这个人的备份，否则对方一休假链路就断。
第三件事是给依赖设一个升级节点：约定首次响应24小时、给出排期3个工作日，超过这个时间不升级成部门负责人层面，而是把这个依赖标红写进周报的风险区，让它在更高层级的会议上被看见，这一步比自己反复催有效得多，因为它把问题从「你催我」变成了「计划本身有风险」。
最后，所有跨团队依赖的沟通结论都要落在文字上回传确认，口头答应的时间点不算数，我吃过太多次这种亏。
核心关键词
文章包含AI辅助创作：SF流程与规范：项目负责人任务依赖入门指南关键指标，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/391913
读者评论
把责任人写成团队名导致责任稀释这点太真实了，我们项目里'后端组跟进'最后就是没人跟进，改成具体人名后兑现率明显提升。
承诺日期和期望日期分开记录这个做法很实用，之前延期扯皮就是因为需求方自己填了个日期当成对方承诺，现在两个字段分开建，争议少了很多。
依赖登记率当考核指标那段说到我心坎里了，我们搞过一次登记排名，结果冒出一堆伪依赖，后来改成只做诊断参考才恢复正常。
五个指标里响应时长看P90而不是平均值这点很关键，我们平均4小时看着挺好，但P90经常拖到两天，迭代节奏就是被那几条长尾拖垮的。
P0依赖不超过15%这个参考值有道理，我们之前P0占到四成，后来发现是任务拆得太粗，重新拆解后P0自然降下来了，分级也更有意义。