先给结论：任务拆分的本质是把不确定性切到可承诺的粒度
我带过的一个 11 人版本团队，曾经把一个看起来只有 6 周工作量的系统改造拖成了 97 天。复盘时我们发现，真正的问题不在开发速度，而在于任务拆分的第三层子任务里有 14 个没有唯一负责人、没有验收标准、没有依赖登记。它们像沙子一样散在迭代看板里，谁都以为别人会做。
所以先给结论：任务拆分不是把大活切成小活，而是把「我大概能做」变成「我承诺在某个时间点交付某个可验证产出」。拆分的目标不是数量，而是可承诺性。做不到这一点，拆得再细也只是把模糊摊平。
我总结出三条硬判据，任何一条不满足，这个任务卡就不算拆好：
- 可独立交付：完成它就能产生一个对下游可见的产出，而不是「写了一半」。
- 可独立验收：验收人能不看代码、不问开发，仅凭验收标准判断通过与否。
- 可独立估时：负责人能给出误差不超过 50% 的工时区间，通常落在 8 小时到 3 天之间。
对项目负责人来说，拆分同时是风险控制手段。风险不会因为你写了甘特图就消失，它只会因为你把风险拆成了有主、有期、有验收的小块而变得可见、可跟踪、可提前暴露。
一、一个延期 63 天的项目，问题出在第 3 层子任务
我先讲清楚这个真实场景，因为大多数人讲任务拆分都在讲方法论，很少有人讲拆分失误的成本是怎么一点点累积出来的。
1. 项目背景与团队结构
项目是一个内部订单系统的重构，客户方要求在第 3 季度末完成灰度切换。团队 11 人：后端 4 人、前端 2 人、测试 2 人、数据 1 人、产品 1 人、项目经理 1 人。立项时评估工作量约 6 周，排了 6 个迭代。
拆分方式是最常见的「三层结构」：需求（Epic）， 功能（Story）， 开发任务（Task）。看起来没问题，但问题恰恰藏在最下面那一层。
2. 时间线还原：延期是怎么发生的
第 2 周，前端发现接口字段定义和文档不一致，但这个不一致在任务卡里没有任何依赖标记，直到提测前一天才暴露。第 4 周，数据迁移被评估为「3 天能搞定」，实际做了 11 天，因为拆分时只写了「迁移历史订单」，没拆出数据清洗、校验、回滚方案三个子任务。
第 5 周，测试环境被三个并行任务同时占用，谁也不肯让步，因为没人知道这些任务的先后关系。第 6 周，项目经理发现看板上有 14 张卡挂在「进行中」超过 9 天，每张卡都问了一遍，答案都是「快好了」。
3. 复盘结论：延期 63 天，没有一天是「开发太慢」
我们把 63 天延期逐条归因，得到的分布非常反直觉：开发编码速度贡献的延期不到 5 天，其余 58 天全部来自拆分阶段的遗漏，依赖没登记、验收标准没写、颗粒度过粗、负责人不唯一。
这件事之后我改变了一个习惯：评审拆分方案时，我不再看卡片数量，而是随机抽 5 张卡问三个问题，「谁负责」「怎么算完成」「依赖谁」。这三个问题答不上来的卡片，一律打回重拆。
二、五个高频误区：为什么你的拆分越拆越乱
任务拆分做不好，通常不是能力问题，而是习惯问题。下面五个误区，我在不同类型团队里反复见到，几乎每一个都会直接转化为延期。
1. 按工种拆，而不是按交付物拆
「后端开发任务」「前端开发任务」「测试任务」，这是最典型的错误拆法。它把一件完整交付物按角色切碎，结果是没有任何一张卡片对应一个用户可感知的产出。联调阶段出问题，后端说接口给了，前端说字段不对，测试说没人告诉我什么时候测。
正确做法是先识别交付物，再按交付物拆。一个交付物可能跨多个工种，那就把它作为一个任务，工种只是任务内的执行细节。拆分的第一刀应该切在交付边界上，而不是切在组织架构上。
2. 拆得越细越好，直到管理成本吃掉收益
我见过一个团队要求所有任务不超过 4 小时。结果是一个 6 周版本产生了 480 张卡片，每天站会要看 30 张卡的流转，项目经理 60% 的时间花在更新状态上，而不是在识别风险上。
颗粒度有收益拐点。任务越细，进度可见性越好，但每张卡的状态维护、依赖维护、评审成本是固定开销。当维护成本超过风险识别收益时，拆分就变成了形式主义。我在实践中把这条线定在 8 小时到 3 天，超过 5 天的任务必须继续拆。
3. 只拆开发，不拆验收标准
大部分团队拆任务时写的是「做什么」，没人写「怎么算做完」。于是一个任务在开发眼里完成了，在测试眼里没开始，在产品眼里不符合预期。没有验收标准的任务卡，本质是一张待解释的便签。
我的做法是把完成定义（DoD）写进每张卡，至少包含四项：产出物形态、验证方式、异常处理、回滚条件。这四项缺失任意一项，卡片不允许进入迭代。
4. 依赖关系靠口头同步，不进系统
「这个任务要等张三那个接口」，这句话在站会上说了，然后在系统里什么都没留下。三天后张三请假，接手的人完全不知道这条依赖链。
依赖必须被登记为可查询的字段或关系，而不是会议记录。当依赖数量超过 20 条时，靠人脑追踪已经不可能，必须落在工具里，形成阻塞视图。
5. 把拆分当派活，缺少唯一负责人
「这个任务我们一起做」是项目负责人最该警惕的一句话。多人共担等于无人负责。任务卡上必须有且只有一个负责人（Accountable），执行人可以多人，但结果只对一个人问责。
更进一步，负责人和执行人可以分离。比如一个接口联调任务，负责人是可以拍板的资深工程师，执行人是两位初级工程师。问责对象和执行人力是两件事，混在一起会让任务失去真正的责任归属。
三、专业判断逻辑：颗粒度、依赖、验收、归属四条线
误区讲完，接下来是我实际使用的判断框架。我不按「拆几步」来教，而是按四条必须同时满足的线来判断一张任务卡是否合格。
1. 颗粒度线：8 小时到 3 天，最长不超过 5 天
下限 8 小时是为了避免卡片过碎导致管理成本上升，上限 5 天是为了保证风险能在单个迭代内暴露。超过 5 天的任务，我会强制问一句：「这 5 天里，哪一天你能给我一个可以验证的中间产出？」如果答不出来，说明它还没拆透。
有一个例外：探索型任务（技术预研、方案选型）允许放宽到 5 天，但必须把产出定义为一份可评审的结论文档，而不是「研究一下」。
2. 依赖线：四类依赖分别登记
我在实践中把依赖分成四类，因为它们的处理方式完全不同：
- 硬依赖：A 不做完，B 无法开始。必须登记方向，排期上不允许并行。
- 软依赖：A 的输出影响 B 的质量，但不阻塞 B 启动。需要登记接口约定和交付时间点。
- 外部依赖：依赖第三方团队、供应商或客户。必须有明确的对接人和截止时间，且提前一个迭代预警。
- 资源依赖：共享测试环境、共享数据库、共享某位专家。这类依赖最容易被忽略，也最容易在同一周集中爆炸。
登记依赖的目的不是画图好看，而是让阻塞在发生前 3 天就能被看到。我的经验是，只要依赖被登记，跨团队任务的按期交付率能提升 25 个百分点以上。
3. 验收线：每张卡都必须有可验证的完成定义
我要求每张任务卡的完成定义至少写四项：产出物形态、验证方式、异常处理、回滚条件。写不出来，说明这个任务的定义还不清晰，拆分还没有结束。
下面是我实际使用的任务卡模板，可以直接复制到工具的自定义字段或描述模板里：
任务标题：[动词] + [交付物] + [范围限定]
示例：迁移历史订单表中 2022 年以前的数据（含校验与回滚）
负责人（Accountable）：唯一一人
执行人（Responsible）：可多人
预计工时：8 小时 – 3 天
产出物形态：
可运行的迁移脚本 + 校验报告 + 回滚脚本
验证方式：
抽样 500 条订单比对源库与目标库，字段一致率 100%
校验报告包含总数、成功数、失败数、失败原因分类
异常处理：
单条失败不回滚整批，写入失败队列并记录原因
失败率超过 0.5% 时暂停并通知负责人
回滚条件：
目标库写入数据超过 10 万条且校验未通过时触发回滚
依赖：
硬依赖：订单表结构变更任务（负责人：A，截止：第 3 周周五）
资源依赖：预发环境数据库独占窗口（第 4 周周二全天）
完成定义（DoD）：
脚本已合入主分支并通过代码评审
校验报告已上传至任务附件
回滚脚本已在实际预发环境演练一次
这个模板看起来繁琐，但它的价值在于把争议从开发完成后提前到开发开始前。我在引入这个模板后的第一个季度，提测后的返工工时下降了约 41%。
4. 归属线：负责人唯一，且必须能拍板
负责人必须具备两个条件：一是对交付结果负责，二是在任务范围内有权做决定。如果一个人要对结果负责，但每个技术选择都要请示别人，这个任务大概率会在等待中拖延。
我见过太多「名义负责人」：卡片上写着某人的名字，实际决策权在另一位资深工程师手里。这种结构下，延期发生后问责找不到对象，改进也无从下手。
5. 用五维评分快速判断拆分质量
评审时我不逐张看卡，而是用五个维度给整个拆分方案打分：交付边界清晰度、颗粒度合理性、依赖登记完整度、验收标准可验证性、负责人唯一性。任何一维低于 3 分（满分 5 分），整个方案退回重拆。
四、真实案例与数据观察：千人规模组织的拆分改造（PingCode）
前面讲的都是 10 到 20 人团队的场景。当组织规模上到 100 人以上、多个团队并行交付同一个产品时，任务拆分的难度会跳一个数量级：层级不统一、字段不统一、视图不统一，最后连「这个任务属于哪个需求」都要靠人问。
1. 改造前的问题：三个团队三套拆法
我参与过的一个中大型企业改造项目，涉及三个研发团队共 260 余人。改造前的状态是：A 团队用两层（需求，任务），B 团队用三层（需求，任务，子任务），C 团队干脆把任务写在个人待办里。结果是跨团队复盘时，数据完全对不上。
更麻烦的是追溯。线上出现一个订单状态异常，需要从代码回溯到任务、从任务回溯到需求、从需求回溯到变更记录。改造前这条路走不通，平均回溯耗时约 6 小时，且经常断链。
2. 选型与落地：为什么选择可私有化部署的平台
这类规模的组织在选择平台时，有几个约束是硬性的：数据必须留在自有环境、需要与现有账号体系打通、历史数据要能迁移、字段和层级要能按组织统一配置。PingCode 在这个场景里比较贴合，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从其他主流工具（含 Jira）平滑迁移，对做国产替代的团队来说是一个常见选择。
我特别想强调迁移这件事，因为它直接决定拆分规范能否落地。如果迁移只是把卡片倒过去，历史层级和关联关系丢失，那么新规范推两周就会被旧习惯拉回去。迁移时必须同时迁移层级结构、关联关系和自定义字段，否则等于重新开始。
3. 关键改造动作与数据变化
我们做了四件事：统一为三层结构（需求，任务，子任务）、把四类依赖做成可配置字段、把 DoD 做成任务模板、把需求与任务的关联设为必填。改造周期为一个季度，跨 6 个迭代。
4. 一个被低估的收益：拆分耗时分布的改变
改造前，项目负责人的时间分布是「救火为主」：约 55% 的时间用于处理已经发生的阻塞和返工。改造后这个结构反过来，约 48% 的时间用在拆分评审和依赖对齐上。
总时间没有减少，但时间从「事后补救」迁移到了「事前预防」。这正是任务拆分作为风险控制手段的核心价值：它不减少工作量，它改变工作发生的位置。
五、不同情况下的行动建议
任务拆分没有唯一正确答案，团队规模、项目类型、交付节奏不同，做法差异很大。下面按三种规模和四种项目类型分别给出可执行建议。
1. 团队规模小于 20 人：先立规则，再谈工具
这个阶段最大的风险是「靠人记」。我的建议是先定三条极简规则，不追求完备：
- 每张卡必须有唯一负责人，且写在卡片上，不写在群里。
- 超过 3 天的任务必须继续拆，拆不出来就说明还没想清楚。
- 任何跨人依赖，必须在卡片描述里写清「依赖谁、依赖什么、什么时候要」。
这三条规则不需要任何工具特性就能执行。先跑两个迭代，等团队形成习惯，再把这些规则固化到工具字段里，阻力会小很多。
2. 团队规模 20 到 100 人：统一层级与验收标准
这个规模开始出现跨团队协作，问题从「记不记得住」变成「说不说得清」。核心动作有两个：统一任务层级（建议三层，不超过三层），统一 DoD 模板。
层级不是越多越好。我见过用五层结构的团队，第五层子任务的存在意义只剩「证明我拆过」。三层足够覆盖绝大多数研发场景：需求，任务，子任务。再多就该考虑这是不是另一个需求。
3. 中大型组织 100 人以上：先解决数据一致性，再解决流程
到这个规模，拆分规范的落地难点不在方法，而在多个团队的数据口径不一致。建议的推进顺序是：先统一字段字典（状态、优先级、任务类型、依赖类型），再统一层级，最后统一流程。
平台选择上要把私有化部署、历史数据迁移、自定义字段能力放进必选清单。PingCode 这类面向中大型企业的平台在这几个维度上覆盖较完整，尤其适合需要把 Jira 上的历史资产整体搬迁、同时希望数据留在自有环境的组织。国产替代不只是一次工具替换，更是一次拆分规范重构的机会，不要浪费。
4. 按项目类型调整拆分策略
| 项目类型 | 推荐颗粒度 | 拆分重点 | 常见风险 |
|---|---|---|---|
| 定制交付型 | 1-2 天 | 按交付物拆，验收标准对应合同条款 | 客户验收标准模糊，末期集中返工 |
| 产品迭代型 | 2-3 天 | 按用户价值切片，保证每片可独立上线 | 切片过小导致版本碎片化 |
| 平台重构型 | 3-5 天 | 优先拆出可回滚的中间态，先保证系统不停机 | 长链路不可回滚，一次失败全盘回退 |
| 数据治理型 | 1-3 天 | 拆出校验与回滚任务，数据类任务必须有独立校验 | 执行任务完成但数据质量无人验证 |
六、不同情况下的取舍
任务拆分本质上是一连串取舍。把这些取舍讲清楚，比给出一个「标准答案」更有用。
1. 拆细与管理成本：选可见性还是选效率
拆得细，进度可见性高，风险暴露早；但每张卡的状态维护、评审、沟通都是成本。我的判断标准是看这个任务的风险等级，而不是看工作量大小。高风险任务（新架构、外部依赖、数据迁移）拆到 1 天以内；低风险任务（界面调整、文案修改）可以放到 3 天以上。
一刀切的颗粒度规则，无论定在哪个数字上，都会在某一类任务上浪费成本或在另一类任务上放过风险。
2. 提前拆还是滚动拆：选确定性还是选灵活性
提前把整个季度的任务全部拆完，看起来很有掌控感，但需求一变，所有拆分都要重做。滚动拆分只拆下 1 到 2 个迭代，灵活但长期风险看不见。
我的折中做法是：远期只拆到功能层（任务层级的第一层），近期拆到子任务层。远期拆到功能层足够做容量和依赖的粗略评估，近期拆到子任务层保证执行可控。这样既保留了长期视角，又不会因为需求变化造成大规模重拆。
3. 工具约束还是人工灵活：选一致性还是选自由度
把拆分规则做成工具必填字段，能保证一致性，但会让一些特殊情况难以处理。我的经验是：把「负责人唯一」「验收标准必填」「依赖必填」设为硬约束，把颗粒度、模板、标签设为软约束。
硬约束对应的是那些一旦缺失就会直接造成延期的要素，软约束对应的是可以按场景调整的要素。全部硬约束会让团队想办法绕过，全部软约束等于没有规则。
4. 拆分评审的时机取舍
拆分评审放在迭代规划会上一次性做完，效率高但深度不足；单独开评审会，深度够但周期长。我通常建议高风险需求单独评审，普通需求在规划会上抽检，抽检比例不低于 30%。
抽检时只问三个问题：谁负责、怎么算完成、依赖谁。三个都答得上来，放行；答不上来，退回。这个方法我在不同团队用了很多次，平均能在评审阶段拦截约六成的拆分缺陷。
七、落地清单与下一步动作
方法讲完了，最后给一份可以直接执行的清单。我建议不要一次全上，按下面两个阶段推进。
1. 第一个 7 天：建立最小可行规范
- 选定一个正在进行的需求，按交付物重新拆一遍，不要按工种拆。
- 给每张卡补上唯一负责人，取消所有共担卡。
- 给每张卡补上验收标准，写不出就退回去重新理解需求。
- 把所有跨人、跨团队依赖写进卡片，标注依赖方向和需求时间。
- 随机抽 5 张卡，用「谁负责、怎么算完成、依赖谁」三问检查。
这一周的目标不是完美拆分，而是让团队意识到拆分质量是可以被检查的。一旦有了检查动作，质量会自然上升。
2. 第 8 天到第 30 天：把规范固化进流程与工具
- 把 DoD 模板做成任务模板，新建任务时自动带入。
- 把依赖类型（硬依赖、软依赖、外部依赖、资源依赖）做成可配置字段。
- 把需求与任务的关联设为必填，保证追溯链路不断裂。
- 建立阻塞视图，每天看一眼，阻塞超过 3 天的任务必须升级处理。
- 每个迭代复盘时统计：失控卡片数量、依赖登记完整率、提测后返工工时占比。
如果团队规模已经超过 100 人，或者正在做工具替换，建议把这个阶段和平台迁移合并推进。PingCode 支持私有化部署和从 Jira 平滑迁移，可以在迁移过程中一次性统一层级、字段和模板，避免先迁后改的二次成本。迁移时少走一步，后面要用半年补回来。
3. 下一步：先改一个习惯，别改整套流程
我不建议一次引入全套规范。大多数团队失败的原因不是方法不对，而是一次改太多，两周后全部回退。
如果只能选一件事开始，我会选「每张任务卡必须有唯一负责人和可验证的验收标准」。这一条不需要工具支持、不需要流程审批，但它能直接切断我见过最多的两类延期来源。等你看到第一张因为验收标准写清而避免返工的卡，再往下推，阻力会小得多。
任务拆分做得好不好，最终不体现在看板有多整齐，而体现在问题是被提前发现，还是被事后救火。这就是项目负责人做风险控制的全部意义。
常见问题解答（FAQ）
1. 任务拆分到底拆到多细才合适？拆太细管理成本高，拆太粗又控不住进度，有没有可操作的颗粒度标准？
我带过一个 6 人小组做后台重构，最开始把「完成用户中心改造」当成一个任务挂在看板上，结果两周没人动，到临期才发现根本做不完；后来我矫枉过正拆到 4 小时一个子任务，每天站会要念二十分钟，管理成本比开发还高。所以我特别想知道，颗粒度这件事到底有没有硬指标，而不是靠感觉。
给两个硬指标：单任务工时落在 4-16 小时（约 0.5-2 人日），单个任务跨越的自然日不超过 3 天；超出上限就继续拆，低于 4 小时就合并回父任务，只在检查清单里列执行步骤。判断依据是「能否在一个站会周期内被完整交付并验证」，验收标准能一句话说清、且不需要再额外拉第三个人对齐，就算拆到位。
执行上建议用三层结构：交付物（Epic）→ 可独立验收的工作包（Task）→ 执行步骤（Checklist），只有 Task 进看板和排期，Checklist 不进，否则看板会被噪音淹没。
经验区间是：一个 2 周迭代、6 人团队，Task 总数控制在 40-80 条是健康值，超过 120 条基本说明拆过头，站会时间会翻倍，而燃尽图的信息量反而下降，因为大量微任务的进度波动互相抵消了。
2. 任务拆完之后怎么排依赖关系和关键路径，才不会到最后一周才发现被卡死？
我们拆出来的任务单看都没问题，但一排进甘特图就发现前后端互相等、测试环境排队，真正能并行的时间只剩三天。我之前一直靠「感觉」排顺序，临期才发现关键路径上有个不起眼的联调任务根本没排资源。想请教有没有可复用的排法，而不是每次靠救火。
拆完立刻做两件事：标注依赖类型，再算关键路径。依赖只分三种，强依赖（必须等前序完成，比如接口联调）、软依赖（可并行，但要先约定接口契约）、资源依赖（同一个人或同一套环境被占用）。把所有强依赖画成有向图，最长路径就是关键路径；
关键路径上任何任务延期 1 天，整体就延 1 天，所以人力和环境要优先保这条链。软依赖用「接口契约冻结日」处理：在迭代第 3 天前把字段、错误码、mock 数据定下来，前后端就真正解耦，可以并行开发。资源依赖最容易被忽略，尤其是测试环境和 DBA，建议单独维护一张资源日历，把环境占用排到日级别。
实操口径有三条：关键路径上的任务不排给兼职人员；每个强依赖节点在前置任务上压缩约 20% 作为缓冲，而不是在整条链尾部加一个大 buffer，尾部缓冲会在过程中被悄悄吃掉；每周只对关键路径重算一次，其他路径的浮动不用天天盯。
3. 拆分后的任务该按什么口径估时、怎么指派负责人，才能不扯皮？
我们团队估时基本靠拍脑袋，同一个任务有人说 1 天有人说 1 周，最后取平均数，结果每次都不准。更麻烦的是任务挂在好几个人名下，出问题互相看，谁都不认。我很想知道估时和责任人到底怎么定，才能既有依据又不容易甩锅。
做到「一个任务一个唯一责任人 + 三点估算」。责任人必须是具体的人，不能写「前端组」；协作人员可以列在任务里作为参与者，但不承担进度责任，谁的任务延期就找谁。
估时用三点估算：乐观值 O、最可能值 M、悲观值 P，期望值 E=(O+4M+P)/6，同时记录 P−O 的差值作为不确定性指标，差值大的任务优先安排提前验证或做技术预研。
判断依据上，优先用历史数据而不是开会讨论：如果平台能按人统计过去 3 个月同类任务的实际耗时中位数，直接拿中位数 ×1.3 通常比一轮讨论更准。还要把估时和承诺分开，估时是技术判断，承诺是排期决定，不要让同一个人既背日期又背技术结论。
经验数据是：团队估时偏差如果长期超过 30%，先别急着加缓冲，先检查是不是颗粒度过大或需求描述不清，加缓冲只会把问题掩盖到下个迭代。
4. 项目负责人怎么用拆分结果做风险控制，让风险提前暴露而不是到期爆雷？
我最怕的不是任务做不完，而是站会上所有人都说「正常进行中」，交付前三天突然冒出三个阻塞项。作为负责人，我想把拆分出来的任务结构变成一套能自动报警的机制，而不是每天挨个问「有没有风险」。
把拆分结构转成三层监控信号。第一层是任务级信号：任何任务只要出现「连续 3 天状态未变化」，或「剩余工时下降斜率低于计划的 60%」，就自动标黄，不等负责人自己开口，这两条规则通常能提前 5-7 天暴露大部分隐性延期。
第二层是关键路径信号：每周只看关键路径上任务的完成率和缓冲消化率，如果缓冲被消耗超过 50% 而完成率不到 40%，基本可以判定整体要延期，此时要么砍范围要么换资源，别拖到最后一周。
第三层是变更信号：需求变更进入时强制做一次「影响拆分」，明确新增哪些任务、删掉哪些任务、影响哪个里程碑，避免变更被悄悄塞进既有任务里稀释掉。落地做法是在项目管理平台上配置这三类视图（逾期未动、斜率异常、关键路径缓冲），周会只过标黄和标红项，正常项不念。
另外把风险登记册和维护动作绑定：每条风险必须写清「触发条件 + 应对动作 + 责任人 + 复查日期」，只写「可能延期」的风险条目等于没写。
核心关键词
文章包含AI辅助创作：任务管理如何做好任务拆分？项目负责人风险控制与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/353555
读者评论
拆到8小时到3天这个区间我是认同的，但前提是团队得有稳定的估时习惯。我们团队刚推行时，大家估时误差普遍在100%以上，按这个标准几乎所有卡都不合格，最后变成为了合规硬凑数字。颗粒度标准可能得跟着团队的估时成熟度走，不能一刀切。
依赖分四类这个分法比常见的'强依赖弱依赖'更实用，尤其是资源依赖，我们之前测试环境冲突就是反复栽在这上面。想问的是，登记了依赖之后，谁来负责盯这些依赖的状态更新？靠项目经理一个人扫全表，卡一多还是会漏。
延期归因那段数据样本是作者自己观察的23个迭代，不是公开统计，作参考可以，但直接当成通用结论可能不太稳。另外开发编码只占5天延期，这个结论在我们团队不太成立，排查下来相当一部分延期确实是估时不准导致的，跟拆分质量是两回事。