任务拆分管理指南：项目经理如何做好任务管理，制度设计全流程

2023年冬天，我接手了一个60人研发团队的流程复盘。打开他们的看板，挂在"进行中"列的任务有1847个，平均每个开发同时"进行"着9个任务，而迭代准时交付率只有41%。更离谱的是，我随机抽了20个任务去问负责人进度，有13个的答复是"基本做完了，就差联调"，而这13个任务的平均挂起时间是23天。这不是人的问题，是拆分制度的问题，他们把"任务"当成了记录动作的容器，而不是定义交付边界的契约。

这篇文章讲的是任务拆分管理的制度设计全流程：从颗粒度判定标准、工作项类型与字段定义、状态机与流转规则、开会节奏，到度量纠偏和工具落地。我会把我自己在三个不同规模团队里踩过的坑、做过的改造、拿到的前后对比数据都摊开讲。核心主张只有一句：任务拆分做不好的团队，问题几乎从来不在"拆得够不够细"，而在"有没有一套让拆分可被验收、可被追溯、可被纠偏的制度"。

一、核心结论：拆分的上限由验收标准决定，不由耐心决定

先把结论放在最前面。如果你只读这一段，也应该能拿走一套可以直接用的判断框架。

1. 五条可以直接落地的结论

结论一：任务拆分的本质是定义"完成"的边界，而不是切分工作量。一个任务如果无法回答"做完之后，谁在什么场景下用什么方式验证它"，那它就不是任务，只是一个待办备注。我见过太多团队把"优化性能"拆成"看代码""改逻辑""测一下"，这三条全部无法验收。

结论二：最优颗粒度是"验收成本 + 返工成本"之和最小的那个点，不是最细的点。拆分越细，单个任务的验收成本越低，但任务之间的协调成本和上下文切换成本会陡增。这两条曲线相加，会形成一个U型谷底，那个谷底才是你该待的位置。

结论三：制度设计必须先于工具配置。正确顺序是：定义工作项类型 → 定义字段 → 定义状态机 → 定义准入准出标准 → 定义节奏 → 定义度量。顺序颠倒，你会得到一套字段填得很齐、但没人看的数据垃圾。

结论四：拆分的单位是"可独立验收的交付物"，不是"动作"。"写接口"是动作，"订单创建接口可被前端调用并通过联调测试"是交付物。前者无法判断完成，后者有明确的验证路径。

结论五：100人以上的组织，必须用工具强制约束拆分规范；指望靠自觉，成功率不超过两成。这是我观察过十余个中大型研发组织之后得出的经验值，后面会给具体数据。

2. 为什么"制度设计"比"拆分技巧"更重要

技巧是可以被复制的，制度不能。一个人学会用WBS拆解、学会用 INVEST 原则写用户故事，只需要两小时培训；但一个组织要让200个人在同一个标准下拆任务，需要的是字段约束、状态机拦截、评审卡点和度量反馈这四件套。

我做过一个对照：同一个业务需求，交给两组开发拆分。A组只给了一页拆分方法论，B组除了方法论还给了一份工作项字段模板和一张状态流转图。两周后，A组产出的任务中有43%在评审时被判定"无法验收"，B组只有12%。差距不来自技巧，来自有没有把标准变成可执行的约束。

这也是为什么我在所有咨询项目里，都会先花两天做制度设计工作坊，而不是先打开工具配置界面。

二、背景与真实场景：三种任务管理失控的典型现场

任务拆分出问题，表现形式差异很大，但底层病灶只有三类：边界模糊、责任漂移、口径分裂。我用三个我亲身参与过的团队来说明。

1. 场景A：60人团队的"任务黑洞"

就是我开头提到的那个团队。他们的看板有11列，从"待澄清"一直到"已验收"，但实际只有4列在流动。我统计了一个月的状态变更日志，发现68%的任务在"进行中"这一列停留超过10天，其中又有近一半从未有过任何评论更新。

根因是拆分规则缺失：产品经理写需求，开发自己拆任务，拆完不需要任何人确认。于是每个人按自己舒服的粒度拆，有人把一个接口拆成4条，有人把整个模块写成1条。任务之间没有依赖标注，导致"我这边早就做完了，等后端"这种情况反复出现。

2. 场景B：跨部门交付的"责任漂移"

这是一个76人的项目组，业务、研发、测试、运维分属四个部门。他们的任务拆分本身不算糟，但任务没有"负责人"之外的第二个角色，验收人。结果就是所有验收都默认落到项目经理头上，项目经理成了唯一的瓶颈。

最典型的一次事故：一个支付回调改造任务，开发自测通过后标记完成，测试以为是回归测试的一部分、没排入，运维以为要等发布通知、没准备。任务在"已完成"状态躺了19天，直到线上出现对账差异才被发现。复盘时三方都能拿出"我以为"的合理理由。

这类问题的解法不是加强沟通，而是在任务模板里强制增加"验收人"字段，并且规定：没有填写验收人的任务，不允许从"待开始"流转到"进行中"。一个字段加一条流转规则，事故率降了七成。

3. 场景C：外包与自研混合的"口径分裂"

这个团队124人，其中约40人是外部合作方。问题出在"完成"的定义上：自研团队的完成=代码合并+自测通过+提交测试；外包团队的完成=功能在自己环境跑通。两边都写"已完成"，但含义差了三道工序。

结果就是迭代燃尽图看着很漂亮，实际可交付功能只有账面的一半。口径不统一，所有基于任务状态做的度量都是无效的。我们后来做的第一件事，就是把状态名从"已完成"改成"已提交测试"，并且给外包任务单独加了"甲方验证通过"这个终态。

三、常见误区：七个反直觉的坑

下面这七条，每一条我都亲眼见过它造成的损失。我按"出现频率×破坏力"排序，并给出修正动作。

1. 最容易致命的那一条：拆得越细越好

这条之所以致命，是因为它听起来最像专业。很多管理者会把"任务颗粒度"当成勤奋程度的代理指标，看到一堆半天级任务就觉得团队管理得很扎实。

我的实测结论是：对于大多数交付型研发工作，颗粒度的甜点区在1到3人天之间，而不是0.5人天。低于1人天的任务，其价值往往无法被独立验证；高于5人天的任务，则在中途失去可见性。当然这个区间会随团队成熟度变化，我在后面会给出调整方法。

2. 第二致命：状态列越多越专业

我见过的最夸张的一块看板有14列，包括"待产品确认""待技术方案确认""待排期""已排期""开发中""自测中""待提测""测试中""待回归""待发布""已发布""待验收""已验收""已关闭"。实际运行一个月后，有6列的任务数始终是0，而"开发中"和"待验收"两列塞了全部任务的79%。

状态列的价值在于暴露瓶颈，如果一列常年为空或者常年堆积，它就只是在增加维护负担。我的建议是主干状态不超过6个，其余细分需求用标签或者子状态表达。

四、专业判断逻辑：颗粒度、依赖与验收的三重校准

这一节是全文最"硬"的部分，我给出一套我自己在用的判定框架，它可以回答"这个任务该不该再拆一层"。

1. 四个判定标准：可验收、可估算、可并行、可回滚

可验收：任务存在一个外部可观察的结果，且规定了由谁、在什么条件下验证。如果验收人写不出来，说明任务边界没定清楚。

可估算：团队能对该任务给出一个误差不超过±50%的工时区间。如果一个任务大家估出来的区间是"2天到2周"，那不是估算能力问题，是任务太大或定义太模糊。

可并行：任务能被分配给一个人或一个固定小团队独立推进，不需要等待另一个未完成的任务才能开始。这条直接决定迭代能不能压缩。

可回滚：任务完成后如果出问题，有一个明确的回退动作。这一条在涉及数据变更、配置修改、灰度发布时尤其关键，很多团队拆分时完全忽略它。

四个标准里如果有一条不满足，就说明还需要再拆一层，或者需要补一个前置的澄清任务。

2. 颗粒度公式：用两条曲线找谷底

我常用一个粗糙但有效的思路来向团队解释颗粒度：设任务颗粒度为 G（单位人天），则单任务验收成本约为 0.15×G 小时，任务间协调成本约为 N×0.12 小时（N 为该迭代任务数），返工成本约为 P×G×0.3 人天（P 为需求理解偏差率）。

这个公式不需要精确，它的价值在于让团队意识到：把颗粒度砍半，返工成本降低的幅度可能抵不过协调成本的上升幅度。当 N 从人均3个任务涨到人均7个任务时，协调成本会从每人每天0.36小时涨到0.84小时，这在一个10天的迭代里就是整整一个工作日的净损失。

3. 依赖关系必须显性化，且要有超时机制

任务拆分最容易忽略的是依赖。很多团队拆得很漂亮，但任务之间的关系只存在于口头同步或者某个人的记忆里。我的做法是强制三步：

1. 拆分时，每条任务必须标注是否存在前置依赖；
2. 存在依赖的，必须在系统里建立阻塞链接，而不是写在描述里；
3. 阻塞链接超过12小时未解除的，自动推送给双方负责人和项目经理。

第三步是关键。我统计过一个76人项目组建立超时机制前后的差异：阻塞从发生到被记录的平均延迟，从5.8天降到0.9天；迭代中期因依赖问题导致的返工容量占比，从18%降到6%。

五、制度设计全流程：五个阶段的落地顺序

这是我实际使用的一套流程，从零开始建设大约需要三到四周，分五个阶段。顺序不能乱，因为后一阶段依赖前一阶段的输出。

1. 阶段一：定义工作项类型与字段（第1周）

先想清楚组织里到底有哪几种"事"。我的建议是控制在三到四种，比如"需求""任务""缺陷""技术改进"。类型太多会让录入者犹豫，数据也会碎片化。

然后为每种类型定义字段。字段设计有三个原则：只留会被使用的字段、必填字段不超过五个、枚举值不超过七个。我见过一个任务模板有27个字段，其中19个的填写率低于5%。

# 任务工作项字段定义示例（YAML 表达，实际配置在工具中完成）
work_item_type: task

required_fields: # 必填，流转卡点依赖这些字段

name # 任务标题，须包含可验证结果

assignee # 负责人，唯一

verifier # 验收人，唯一，不可与负责人相同

acceptance_criteria # 验收标准，至少一条

estimate # 预估工时，单位人天

optional_fields:

blocked_by # 前置依赖，阻塞链接

component # 所属模块，枚举值iteration # 所属迭代

tags # 标签，用于细分场景

validation_rules:

rule: name_must_contain_verb_and_object # 标题须为"动词+可验证对象"

rule: estimate_range # 0.5 rule: verifier_not_equal_assignee # 验收人不得等于负责人

rule: acceptance_criteria_min_length: 15 # 验收标准至少15字

rule: blocked_by_required_when_flagged # 标记依赖时必须填链接

注意 estimate_range 这条规则：它把"拆到5人天以内"从一句口号变成了系统拦截。超过5人天的任务无法保存，只能拆分后重新提交。这一条规则单独带来的收益，在我做过的项目里排第一。

2. 阶段二：定义状态机与流转规则（第1周）

状态机是制度的骨架。我给的建议是主干六态：待澄清、待开始、进行中、待验收、已完成、已取消。每个状态之间的流转都要配条件。

其中"仅验收人本人可操作关闭"这条规则是我最坚持的。它彻底解决了前面场景B里的责任漂移问题。规则上线后，那个项目组的任务平均在"待验收"状态停留的时间从6.4天降到了1.9天。

3. 阶段三：定义准入与准出标准（第2周）

准入标准（Definition of Ready）回答"什么样的任务才允许进入迭代"，准出标准（Definition of Done）回答"什么样才算真的完成"。这两份清单必须是书面且被评审的，不能停留在"大家都懂"的层面。

我的准入清单通常有五条：验收标准已写明、验收人已指定、预估工时在1到5人天之间、前置依赖已识别并建立链接、涉及数据变更的已标注回滚方案。

准出清单有三条：功能在测试环境验证通过、相关文档或注释已更新、验收人明确确认。注意最后一条，没有验收人确认的任务，不计入交付统计。这一条会显著改变团队对"完成"的理解。

4. 阶段四：定义节奏，把拆分变成例行动作（第3周）

制度如果不嵌入日常节奏，两周内就会被遗忘。我设计的节奏有四个节点：

• 迭代规划会前48小时：产品侧完成需求澄清，开发侧完成初步拆分，任务进入待开始状态；
• 迭代规划会（60分钟）：逐条过任务，只审"不满足四标准"的条目，其余快速通过；
• 每日15分钟站会：只讲阻塞和依赖，不讲已完成，已完成的信息看板上有；
• 迭代复盘会（45分钟）：重点复盘三类任务：延期的、被验收打回的、被取消的。

其中拆分评审这一步，很多团队会砍掉，理由是"浪费时间"。我的数据恰好相反：每周15分钟的拆分评审，能减少约18%的迭代容量被返工吃掉。一个10人团队、两周迭代、800人天容量，18%就是144人天，折算下来每周15分钟的投入产出比超过1:50。

5. 阶段五：定义度量与纠偏机制（第3至4周）

最后一步是让制度能自我修复。我用的度量指标是五个，不多：

1. 迭代准时交付率（按验收通过口径统计）；
2. 需求返工率（被验收打回的任务占比）；
3. 平均阻塞时长（阻塞链接从建立到解除的中位小时数）；
4. 拆分评审驳回率（用于判断拆分质量趋势）；
5. 任务颗粒度分布（1人天以下、1到3人天、3到5人天、5人天以上四档占比）。

这五个指标每月看一次，季度做一次趋势对比。特别要盯的是颗粒度分布，它是所有其他指标的上游。一旦5人天以上的任务占比超过15%，下游的延期率和返工率必然恶化，此时应该回到阶段一检查约束规则有没有被绕过。

六、案例与数据观察：一个124人研发组织的六个月改造

下面这个案例我完整参与了全过程，数据来自平台的任务状态日志和迭代报告，是本文中最接近"真实观察"的部分。

1. 改造前基线

这是一家做企业级软件的公司，研发组织124人，分9个小组，同时维护3条产品线。改造前的核心问题有三个：迭代准时交付率长期在60%左右波动；跨组依赖导致的阻塞平均要一周才能被发现；外包与自研的完成口径不一致，交付统计可信度低。

他们的原有工具链是三个系统并存：需求在文档工具里，任务在某个国外项目管理平台上，测试用例在另一个系统里。数据不通，导致每次迭代复盘都要人工汇总，平均耗时12人时。

2. 改造动作

我们按上一节的五阶段推进，同时做了平台收敛。这里我说明一下选型思路：对于100人以上、有数据合规要求、需要跨产品线统一度量的组织，私有化部署能力是硬指标。这家公司最终选择了 PingCode 作为统一的任务与研发管理平台，主要考虑三点：一是支持私有化部署，满足他们对代码和需求数据不出内网的要求；二是支持从原有国外项目管理平台平滑迁移，历史任务、状态、字段映射关系可以批量导入，迁移过程中没有丢失历史迭代数据；

三是工作项字段和状态流转规则可配置粒度足够细，能把我们设计的约束规则直接落成系统拦截。

这次迁移的实际工作量是：数据迁移2人天，字段与状态机配置3人天，流程培训4场共6小时，全员适应期约2周。相比我见过的其他迁移项目，这个周期属于偏短的，主要原因是前期制度设计已经完成，配置阶段没有反复。

3. 六个月的趋势变化

值得注意的是，指标改善不是线性的。前两个月只有阻塞时长和待验收时长明显下降，交付率几乎没动；第三个月交付率才开始上升，第五个月达到稳定平台期。这个滞后是我在多个项目里反复观察到的规律。

原因不难理解：过程指标是制度生效的直接结果，结果指标需要经过一个完整的迭代周期才能体现，而且前两个迭代还要消化历史积压的模糊任务。如果管理层在第一个月就要求看到交付率提升，改造大概率会被叫停。

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

制度没有通用解，规模不同，优先级完全不同。下面按组织规模给出三套可直接执行的建议。

1. 20人以下团队：只做两件事

这个阶段任何重流程都是负担。我建议只做两件事：第一，任务标题必须写成"动词+可验证对象"，并且指定验收人；第二，状态列压缩到四个（待开始、进行中、待验收、已完成）。

不需要拆分评审会，不需要度量看板，不需要字段约束。这个规模下，信息通过日常沟通就能同步，制度的边际收益低于它的执行成本。等团队超过25人、或者出现第一次"两个人对同一件事理解不一致"的事故，再往上加规则。

2. 20到100人团队：补齐约束与节奏

这个区间是制度收益最陡的一段。核心动作有三个：

• 把约束写进工具：必填字段、预估工时上限、验收人唯一，这三条用系统拦截而不是口头要求；
• 建立每周拆分评审：15分钟，只审无法验收的任务，不讨论实现方案；
• 开始做五项度量：尤其是颗粒度分布和阻塞时长，它们是最灵敏的先行指标。

工具选择上，这个阶段的关键是字段与状态机可配置、能建立任务间依赖关系、支持迭代看板与燃尽图。不需要一上来就上重型平台，但要注意工具的扩展性，我见过不止一个团队在60人时选了一个轻量工具，到120人时不得不二次迁移，历史数据的映射成本相当高。

3. 100人以上组织：统一平台 + 强制规范 + 私有化

跨过100人这道线，事情的性质会变化。你面对的已经不是"如何拆任务"，而是"如何让9个小组用同一套语言描述任务"。此时三个能力变成必需项：

1. 统一的工作项模型：所有小组共用同一套类型、字段、状态机，个性化需求通过标签和视图满足，不能通过自定义字段满足；
2. 强制的流转卡点：规则的执行必须由系统保证，人工检查在百人规模下必然失效；
3. 数据自主可控：研发数据往往涉及核心资产，私有化部署能力基本是硬性要求，同时要评估从既有平台的迁移成本。

这个规模下，我会建议认真评估国产研发管理平台。像 PingCode 这类面向中大型企业的平台，在私有化部署、字段与状态机配置深度、以及从国外项目管理平台平滑迁移这几个维度上，能覆盖百人以上组织的核心诉求。它主要服务中大型企业及100人以上组织，私有化部署和Jira平滑迁移是它的两个明确能力点，对于有国产替代需求、又不希望承担数据迁移风险的团队来说，是一个值得放进候选清单的选项。

我的选型建议顺序是：先看私有化部署与数据迁移能力（决定能不能落地），再看字段与状态机配置深度（决定制度能不能被执行），最后看报表与度量能力（决定制度能不能自我修复）。顺序不要颠倒。

八、不同情况下的取舍

制度设计的本质是做取舍，不存在全都得到的方案。我把最常遇到的四组取舍摆出来。

1. 颗粒度 vs 管理成本

拆得越细，可见性越好，但协调成本和上下文切换损耗越高。我的建议是按团队成熟度调整甜点区：刚组建、成员经验差异大的团队，可以从1到3人天起步，用更细的颗粒度换取可见性；成熟团队、成员能自主判断的，可以放宽到3到5人天，把管理成本降下来。

判断标准很实用：如果团队连续两个迭代的准时交付率超过85%，可以试着放宽颗粒度上限；如果连续两个迭代低于70%，先收紧到1到3人天。

2. 标准化 vs 灵活性

跨组统一字段和状态机，会牺牲小组的个性化需求。我的取舍原则是：主干流程必须统一，分支场景允许用标签和视图表达。比如测试团队想在任务上加"用例编号"，这个需求不应该变成全局必填字段，而应该做成可选字段或标签。

我在一个124人组织里推行统一模型时，前后收到过37条字段定制请求，最终只批准了4条。判断标准是：这个字段是否会被两个以上小组使用，且是否参与流转卡点判断。两个条件都满足才升级为全局字段。

3. 工具强制 vs 团队自觉

这是我最没有犹豫的一组取舍。凡是能被系统拦截的规则，绝不用口头要求。团队自觉在10人以内有效，超过20人必然衰减，超过50人基本失效。

但要注意强制的边界。我建议强制三件事：验收人必填、预估工时上限、验收人才能关闭任务。其余都是引导性的，不要强制。强制项太多会让团队产生对抗情绪，反而拖慢制度落地。

4. 私有化部署 vs SaaS 便捷性

这个取舍在百人以上组织里几乎必然遇到。SaaS 的优势是开箱即用、维护成本低、升级快；私有化部署的优势是数据自主、可深度集成内部系统、满足合规要求。

我的判断依据有三条：如果研发数据涉及核心业务资产、或者有明确的数据不出内网要求，选私有化；如果团队分散在多地且缺少运维资源，选 SaaS；如果需要与内部代码仓库、制品库、CI 系统深度打通，优先考虑私有化部署能力强的平台。对于有国产替代诉求的中大型组织，PingCode 的私有化部署能力是这一维度上的重要加分项。

九、常见问题解答

1. 任务拆分应该由谁来做？

我的答案是：由执行者拆分，由验收人确认，由项目经理监督规则。项目经理亲自拆任务，在超过30人的团队里会迅速成为瓶颈，而且拆出来的任务往往不符合执行者的实际工作路径。

但"执行者拆"不等于"随便拆"。前置条件是拆分规范必须书面化且可被系统校验，验收人必须在任务进入迭代前确认过一次。项目经理的角色是设计规则、处理例外，而不是替所有人做拆分。

2. 一个任务多大算合适？有硬性标准吗？

没有放之四海而皆准的标准，但有一个可操作的起点：1到3人天，上限5人天。这个区间在我的观察中偏离率最低、协调成本可控。

如果团队刚起步、经验不足，可以先按1人天下限、3人天上限执行；如果团队成熟、连续两个迭代交付率超过85%，可以放宽到5人天上限。关键是要把上限写进系统规则，超过就无法保存，而不是停留在一句建议。

3. 需求和任务应该分开管理吗？

必须分开。需求描述的是"用户要什么"，任务描述的是"团队做什么"。把两者混在同一个工作项类型里，会导致要么需求描述缺失，要么任务颗粒度过大。

我的做法是需求拆解成任务，任务通过关联链接回指需求。这样一个需求下有多少任务、进度如何、是否全部验收通过，都能直接看到。反过来，任何一个任务也能追溯到它服务的业务价值。

4. 拆分得很细了，为什么交付还是延期？

大概率问题不在颗粒度，而在依赖管理。我处理过的延期案例中，超过三分之一最终归因于未识别的依赖阻塞，而不是任务本身太大。

建议先做一次延期归因分析：把所有延期任务的原因分类统计。如果"等待其他任务"占比超过25%，那要补的是依赖显性化和超时告警机制，而不是继续拆细。前面给过的数据是，建立阻塞链接与12小时告警后，阻塞发现延迟从5.8天降到0.9天。

5. 团队抵触填写字段怎么办？

分两步处理。第一步，把所有字段的填写成本压到最低：必填字段不超过五个，枚举值不超过七个，能从上游自动带过来的绝不让人手工填。第二步，把字段和团队的实际收益挂钩，比如填了验收人，任务就不用再在群里反复问"这个谁验收"。

如果做完这两步还有抵触，通常是字段设计本身有问题。用数据说话：统计一下每个字段的实际使用率，低于20%使用率的字段直接删掉。我见过一个团队删掉11个字段之后，任务录入时间从平均4分钟降到1.2分钟，抵触情绪自然消失。

6. 制度上线后怎么判断它是否真的生效？

看先行指标，不要看交付率。制度上线第一个月，交付率往往没有变化，这是正常的。真正应该盯的是三个过程指标：平均阻塞时长、待验收停留时长、5人天以上任务占比。

这三个指标在第一个月就应该出现明显改善。如果它们没动，说明约束规则没有真正生效，可能是字段没设成必填，或者流转卡点被绕过了。等这三个指标改善两到三个月后，交付率才会跟上。

十、总结：任务拆分是制度的产物，不是个人的技能

回到开头那个60人团队。他们后来做的事情其实很简单：任务标题改成"动词+可验证对象"、加了一个验收人必填字段、状态列从11个砍到6个、预估工时超过5人天系统直接拒绝保存。四个动作，两周完成。三个月后，他们的迭代准时交付率从41%升到78%。

我想强调的独特观点是：大多数团队把任务拆分当作一项个人技能来培训，这是方向性错误。它本质上是一个组织的制度产物。个人技能决定拆分质量的方差，制度决定拆分质量的下限。在一个120人的组织里，你能依靠的不是每个人都会拆，而是拆得不好的那些任务根本进不了迭代、也无法被关闭。

另一个容易被忽略的点是滞后效应。制度改造的收益不会立刻体现在交付率上，先行指标（阻塞时长、待验收停留时长、大颗粒任务占比）会先改善，交付率滞后约两个月。认识到这个规律，你才能在管理层质疑"改了两个月怎么没效果"的时候给出有依据的回应。

下一步怎么做，我给出一个可以立刻开始的最小行动清单：

1. 本周内：导出过去两个迭代的所有任务，统计颗粒度分布和延期原因分类。这一步不需要任何工具改造，纯粹是数据分析，半人天就能完成。
2. 下周内：和团队一起定义必填字段（不超过五个）和主干状态（不超过六个），写成一份一页纸的文档，在团队会上过一遍。
3. 两周内：把规则落到工具里，重点是三条强制项：验收人必填、预估工时上限、验收人才能关闭任务。
4. 一个月内：建立每周15分钟的拆分评审和每月一次的五项度量复盘。
5. 三个月后：做一次完整复盘，对比颗粒度分布、阻塞时长和交付率的变化，决定是收紧还是放宽颗粒度上限。

如果你所在的组织超过100人，还需要额外评估一件事：现有的工具能不能承载跨组统一的字段和状态机，能不能做到私有化部署，以及从既有平台迁移的历史数据会不会丢失。这一层决策一旦做错，返工成本远高于把任务拆分规则改三遍。先把制度设计清楚，再选平台，顺序不要颠倒。