完成实操方法：研发团队提升任务执行效率的落地方案方法与模板

三年前我被拉去接手一个延期了五个月的研发项目，团队 42 人，项目管理系统用了三年，每日站会开了一年半，迭代延期率仍然超过 60%。我做的第一件事不是开会，而是把看板打开数卡片：14 张卡停在"进行中"，其中 5 张卡的最后一次更新是在 11 天前，负责人那一栏有三张是空的。第二天我问团队"这 5 张卡为什么停了"，得到的是三种回答：等接口、等测试环境、需求还没定清楚。

那一刻我基本确认了一件事：这个团队的效率问题，几乎不在"人不够努力"，而在任务在系统里被堵住了。这也是本文要回答的问题，研发团队到底怎么把"任务执行效率"这件虚事落到可执行的规则、模板和指标上。我会给出一套四层机制模型、六张可直接套用的模板、一套 30/60/90 天推进路径，以及在不同团队规模和工具现状下的具体取舍建议。

一、先给结论：研发任务执行效率的瓶颈，九成不在个人产出，在任务流

1. 三条可以直接带走的结论

结论一：效率的第一现场是"在制品堆积"，不是"人均产出"。我见过的绝大多数"研发慢"，诊断下来都不是人闲着，而是同时在跑的任务太多、每张卡都只完成了 60%、没有一张能真正交付。团队的忙碌感和交付结果之间，被大量未完成的工作隔开了。

结论二：机制必须先于工具。工具只是承载规则的容器。你如果连"什么卡能进入迭代""一张卡什么条件算完成""阻塞超过多久必须升级"都说不清，换成任何工具，结果都一样，只是换了一个更贵的停车场。

结论三：度量口径决定团队行为。你考核工时，团队就会填工时；你考核故事点，团队就会把故事点估大；你只考核按期交付率，团队就会把任务拆得极小、风险藏起来。口径不是统计问题，是行为设计问题。

2. 为什么必须用"任务流"而不是"个人效率"作为口径

个人效率模型假设任务之间互相独立，谁的产出多谁就快。但研发任务的真实特征是：强依赖、强不确定性、验收标准经常在过程中变化。一个后端工程师写完了接口，如果前端没准备好联调，他的产出对交付是零。

所以我判断一个研发团队的效率，看的是任务从"进入迭代"到"满足 DoD"的时间分布，以及这个时间里有百分之多少在真正被处理。这个视角下，"谁慢"这种问题会自然消失，取而代之的是"哪一段在排队"。

3. 三种度量口径的差异

• 个人产出口径：工时、故事点、提交次数。优点是易采集，缺点是容易被博弈，且和交付结果弱相关。
• 团队流速口径：周期时间（Cycle Time）、在制品数量（WIP）、阻塞时长、流动效率。优点是直接指向堵点，缺点是初期采集需要任务状态规则先统一。
• 交付结果口径：按期交付率、返工率、线上缺陷逃逸率、需求从提出到上线的端到端时长。优点是贴近业务，缺点是无法定位到具体环节。

我的建议是三层一起用，但主看第二层。第一层只在个人成长和辅导场景用，绝不进绩效公式；第三层给管理层和业务方看，用来对齐预期。

二、真实场景：三类研发团队的执行堵点，长得完全不一样

1. 20，50 人团队：任务在口头里，不在系统里

这类团队我待过也辅导过不少。特征是：项目管理工具是有的，但它只被 PM 一个人用。开发同学的任务来源是站会上的一句话、群里的一条消息、或者工位旁边拍一下肩膀。等到周末复盘，PM 发现系统里 30% 的卡和实际在做的事对不上。

这类团队的核心问题不是流程太重，而是任务根本没有被显性化。你没法优化一个你看不见的东西。所以对他们来说，第一阶段的目标非常朴素：让每一件正在做的事都有一张卡，卡上有负责人和验收标准。

2. 100，300 人团队：流程齐全，规则缺失

这是我见得最多、也最典型的一类。工具里的工作流配得漂漂亮亮，五个状态、八条流转线、自动化规则一大堆，但你去问"一张卡从'待开发'进'开发中'的条件是什么"，三个人给你三个答案。

更麻烦的是 WIP 没有上限。"进行中"这一列经常堆到 20 张以上，卡在同一个状态里有的走了两天、有的挂了两周，但看板上看不出区别，因为它们长得一模一样。

这类团队的解法是补规则，而不是补流程。流程描述的是"卡可以往哪走"，规则描述的是"卡凭什么往那走"。前者解决合规，后者解决效率。

3. 300 人以上多团队：阻塞卡在组织边界

到了这个规模，单个团队内部往往已经很顺了。真正的延迟发生在跨团队依赖上：A 团队等 B 团队的接口、B 团队等平台团队的权限变更、平台团队等安全团队的评审。

我统计过某家公司一个季度的跨团队阻塞记录，平均每个阻塞从提出到关闭要 6.8 个工作日，而其中真正被处理的时间不到 4 小时，剩下全在"等人看到"和"等人排期"。这就是典型的组织边界损耗。

4. 五类高频堵点的滞留时长

把上面三类团队的问题合并，我归纳出五类最高频的堵点。下面这组数据来自我在 2022，2024 年间参与改造的 9 个研发团队（合计约 780 人）的内部系统导出，样本是 186 个迭代周期，属于经验性样本而非行业普查，请按这个口径理解。

三、常见误区：这六件事做得越认真，执行效率可能越低

1. 误区一：把工具上线当成绩效提升

我参与过一次工具选型的复盘会，结论是"新系统上线三个月，效率提升明显"。我问了一句：哪个指标提升了？对方说"任务创建量提升了 200%"。任务创建量提升，很可能只说明团队被迫多录了一遍数据。

工具上线最多改变的是"信息在哪里"，它不改变"任务凭什么进入迭代""什么算完成"。这两件事没变，工具换十次也只是换个地方堆积。判断工具是否真的起作用，看的是周期时间和阻塞时长，不是使用率。

2. 误区二：把站会开成逐人汇报会

标准的十五分钟站会，很多团队能开到四十分钟，因为形式是"每个人轮流说昨天做了什么、今天做什么"。这种开法的隐含假设是"只要每个人都说了，问题就被看见了"。

但实际效果恰恰相反。人在公开场合汇报进度时，天然倾向于把自己讲得比实际顺利，阻塞会被轻描淡写地带过。我后来把站会规则改成了只回答三个问题：哪张卡卡住了、卡在哪、需要谁在什么时候给答复。会议时间从 40 分钟降到 12 分钟，被记录的阻塞数反而翻了 2.3 倍。

3. 误区三：把故事点、工时当成绩效考核依据

这是最隐蔽也最伤人的一个。团队一旦发现故事点和绩效挂钩，会立刻启动两种行为：一是把估算整体抬高，二是把任务拆得又多又碎，因为碎片化任务更容易"完成"。这两种行为在数据上看起来都很漂亮，实际交付没有任何改善。

我的判断很简单：任何被用于绩效分配的度量，都会在三个迭代周期内失去度量价值。故事点可以用于容量规划，绝不用于评价个人。

4. 误区四：看板不设 WIP 上限

看板的核心机制不是"可视化"，是"约束"。没有 WIP 上限的看板，本质上是一张壁纸。我见过一个 12 人团队，"进行中"那一列同时挂着 27 张卡，每张卡平均每天被摸 6 分钟。

WIP 上限的经济学逻辑是排队论：利用率超过 80% 以后，等待时间会以非线性方式暴涨。团队看起来很满，实际上大量时间花在任务切换上。把 WIP 控制在每人 1 到 1.5 张卡，是我见过提升最快、成本最低的单点改动。

5. 误区五：DoD 只写在 wiki 里，没进卡片的退出标准

很多团队有一份写得很好的"完成定义"，包含代码评审、单测覆盖、文档更新、监控埋点、回滚方案。但这份文档躺在知识库里，没有任何一张卡在执行它。

结果是开发同学认为"代码合了就是完成"，测试同学认为"没冒烟不算完成"，产品同学认为"上线了才算完成"。三方对"完成"的认知不一致，延期就变成了必然。

6. 误区六：复盘只产出感受，不产出规则

"这次沟通不够及时""下次要加强协作""需求变更太多"，这类复盘结论听起来都对，但无法执行。有效的复盘必须产出一条可以写进流程的规则变更，并且指定负责人和生效时间。

我的做法是给每次复盘设一个硬约束：只改一到两条规则，每条规则必须有明确的触发条件和执行动作。"加强沟通"不是规则，"阻塞超过 24 小时必须在群里 @ 指定对接人并同步 PM"才是规则。

四、专业判断：任务执行效率的四层机制模型

1. 第一层：准入机制，决定"该不该做"

准入机制要回答的问题是：一个需求凭什么可以进入迭代？我的判断标准是五个必填项：业务价值描述、验收标准、范围边界、依赖清单、负责人。缺任何一项，这张卡不进迭代，进入待澄清池。

这一层的作用不是卡流程，是把不确定性从执行阶段提前到规划阶段暴露。一个需求在准入时花 2 小时澄清，可能省掉开发阶段 3 天的返工。

2. 第二层：拆解与依赖显性化，决定"能不能并行"

任务拆解的目标不是越细越好，而是拆到 1 到 3 天可完成、且能被独立验收。超过 3 天的任务，中间必然出现"完成度 70%"这种无法验收的状态，而这种状态是看板上最危险的信号。

依赖显性化比拆解更关键。我要求每张卡在"依赖"字段里明确写出依赖对象的卡号或团队名，以及依赖方承诺的提供时间。跨团队依赖必须在迭代开始前完成对齐，而不是开发时才发现。

3. 第三层：在制品约束与阻塞升级，决定"卡住多久"

这一层直接决定任务流的速度。两条规则足够了：每列的 WIP 上限，以及阻塞的升级时限。

WIP 上限我的建议是每人 1 到 1.5 张。阻塞升级我建议设三个时间点：4 小时未响应在群内提醒、24 小时未响应升级到 PM、48 小时未解决升级到部门负责人。超过时限没升级，责任在 PM 而不是在阻塞方。

4. 第四层：DoD 与度量闭环，决定"改不改得动"

前四层如果到位，第四层就只是把它变成习惯。DoD 必须是卡片的退出标准，不是知识库里的文档；度量必须每月复盘一次，而且复盘必须产出规则变更。

我特别想强调一点：度量的目的是让团队自己发现问题，不是让管理者发现问题。如果数据只向上流动不向下流动，团队会把它当成监控，任何指标都会在两个月内失真。

5. 四层的优先级判断：先补哪一层

四层不是必须同时建。我的判断顺序是：

1. 如果任务在系统里都对不上号，先补第一层和第二层，让任务可见、可验收。
2. 如果任务看得见了但仍然大量堆积，补第三层，重点是 WIP 上限和阻塞升级。
3. 如果前两层稳定了但改善停滞，补第四层，让度量闭环驱动持续调整。
4. 任何情况下，不要先补第四层。没有前两层的数据基础，度量出来的是噪音。

五、案例观察：一家 260 人研发组织 12 周的改造记录

1. 改造前的基线

这家公司是做企业级 SaaS 的，研发组织约 260 人，分 14 个小组。改造前他们用的是某海外项目管理工具，已经用了四年，工作流高度定制，字段多到一个卡片要看三屏。

基线数据是这样：平均周期时间 18.6 天，跨团队阻塞平均关闭时长 6.8 工作日，"进行中"列平均堆卡 19 张，迭代按期交付率 47%，提测后返工率 31%。团队规模已经超过 100 人，属于典型的中大型研发组织。

2. 四层机制怎么承载在 PingCode 上

这类组织的诉求和我们前面讲的四层机制能对上，所以工具选型阶段我们重点评估了国内的中大型研发管理平台。PingCode 主要服务中大型企业及 100 人以上组织，这个定位和 260 人、14 个小组的规模是匹配的。

具体的落地方案是这样的：

1. 准入机制：用需求工作项的必填字段做强制约束，业务价值、验收标准、依赖清单三项为空时无法流转到"已就绪"。字段做了分组，默认折叠，避免卡片信息过载。
2. 拆解与依赖：需求与任务、任务与任务之间建立父子与关联关系，跨团队依赖用"依赖"类型的关联项标注，依赖方和被依赖方在同一个视图里可以看到全部上下游。
3. WIP 与阻塞升级：在迭代看板上给"开发中""评审中""测试中"三列设置 WIP 上限，超限时列头变色提示；阻塞状态单独作为一个状态位，配合自动化规则，进入阻塞超过 24 小时自动通知 PM 和依赖方负责人。
4. DoD 与度量闭环：把 DoD 做成完成时的必勾清单，包含代码评审、单测、集成测试、监控埋点、回滚方案五项；周期时间、阻塞时长、返工率通过自定义报表按月输出。

另外这次改造正好赶上他们考虑减少对海外工具的依赖。PingCode 支持私有化部署，支持 Jira 平滑迁移，这一点对他们比较关键，236 个自定义字段、4 年的历史数据、跨 14 个组的工作流，如果没有成熟的迁移路径，光数据搬迁就要耗费一个季度。实际迁移加字段映射用了大约三周，属于可接受范围。

3. 12 周后的指标变化

下面是第 12 周相对基线的变化。数据来自他们内部导出的迭代报表，样本是改造后 6 个完整迭代周期，属于单一组织的观测结果，不能直接外推到其他团队。

4. 这个案例的边界：什么情况下别照搬

我必须说明这个案例的适用边界，否则容易误导。

• 不适合需求极度不稳定、每周都要大改方向的团队。准入机制会变成阻碍，因为需求根本来不及澄清就要上线。
• 不适合 20 人以下的小团队。这个规模下沟通成本本来就低，四层机制的表格填写成本可能高于收益，应该只用其中的 WIP 上限和阻塞升级两条。
• 不适合把度量直接接到绩效的组织。在那种环境下，WIP 上限会被绕过、阻塞会被私下解决而不记录，数据全部失真。
• 不适合没有 PM 或专职协调角色的团队。第三层的阻塞升级必须有人推动，没人推的升级规则等于没有。

六、六张可以直接套用的模板

1. 任务拆解卡模板

这张卡是整个体系的最小单元。我建议把它做成工具的必填模板，而不是另开一份文档，否则填写会流于形式。字段不要多，够用就行。

任务拆解卡
————————————————

任务名称：一句话说清做什么，不要写"优化xxx"

业务价值：做完之后谁受益、受益多少

验收标准：可验证的条件，例如"接口P99<200ms"

范围边界：明确不做什么，防止范围蔓延

依赖项：依赖对象 + 承诺提供时间 + 对接人

工作量估算：以天为单位，超过3天必须再拆

负责人：唯一责任人，不写"前端组"

截止时间：具体日期，不写"本周"

阻塞记录：每次阻塞记录时间、原因、跟进人

常见的填写错误有两个。一是"验收标准"写成"功能可用"这种无法验证的表述，二是"依赖项"写成"依赖后端"。前者导致完成标准不统一，后者导致没人知道等的是谁。我的做法是在模板里直接给正反例，填错的人一眼能看出来。

2. 需求准入检查表

这张表的作用是过滤器，不是流程盖章。六项全过才允许进入迭代，缺项进入待澄清池，由提出方补齐。

需求准入检查表
————————————————

业务价值：能说明不做会损失什么

验收标准：有可验证的通过条件

范围边界：明确列出不包含的内容

依赖清单：列出所有外部依赖及对接人

测试数据：测试环境能拿到必要的测试数据

上线影响：是否涉及数据迁移、兼容性、灰度策略

判定：6项全过 → 进入迭代

1-2项缺失 → 待澄清池，48小时内补齐

3项以上缺失 → 退回需求池，重新定义

我特别想强调"上线影响"这一项。很多团队的延后发现，问题不是功能没做完，而是没考虑到历史数据兼容或者灰度策略，导致上线当天出现事故。这一项前置，成本几乎为零。

3. 站会与阻塞升级模板

站会模板的关键是改变提问方式。不要问"你昨天做了什么"，要问"哪张卡卡住了"。

每日站会模板（限时15分钟）
————————————————

主持人：PM / Scrum Master

每人只回答三个问题：

我手上哪张卡今天会变成完成状态
哪张卡卡住了，卡在什么环节
需要谁在什么时间前给出答复
会后处理：

所有阻塞由 PM 记录到阻塞台账，不在会上展开讨论

阻塞超过4小时未响应 → 群内提醒

阻塞超过24小时未响应 → 升级到PM，指定对接人

阻塞超过48小时未解决 → 升级到部门负责人

我见过最常见的执行偏差是"阻塞在会上展开了讨论"。一旦展开，会议必然超时，而且讨论往往没有结论。正确做法是会上只登记，会后单独立项，两个人十分钟聊完的事不要占用十二个人的时间。

4. 看板列规则与 WIP 上限模板

看板的每一列都要有进入标准和退出标准，同时必须有 WIP 上限。这是我判断一个看板是不是"真看板"的唯一标准。

看板列规则模板
————————————————

列名：待办

进入标准：通过准入检查表

退出标准：已分配负责人并进入开发中

WIP上限：不限

列名：开发中

进入标准：负责人已认领，依赖已确认可用

退出标准：代码合并 + 单元测试通过

WIP上限：团队人数 × 1.2

列名：评审中

进入标准：提交评审请求并指派评审人

退出标准：至少1人通过 + 意见已处理

WIP上限：团队人数 × 0.5

列名：测试中

进入标准：部署到测试环境，冒烟通过

退出标准：DoD五项全部满足

WIP上限：测试人数 × 1.5

列名：已完成

进入标准：DoD全部勾选

退出标准：无

超限处理：先解决阻塞再拉新卡，不允许"临时加一张"

"不允许临时加一张"这条规则听起来很硬，但它恰恰是 WIP 上限能否生效的关键。一旦允许例外，例外就会变成常态。我的建议是把例外次数作为观察指标，而不是直接禁止，这样团队接受度更高。

5. DoD 验收清单模板

DoD 要写在卡片里，不能只写在知识库。下面这份是我用得最顺手的五项版本，适合大多数研发团队。

完成定义（DoD）检查清单
————————————————

代码评审：至少1人通过，无未处理意见

单元测试：新增逻辑有测试，覆盖率不低于门槛

集成测试：主流程在测试环境通过

监控埋点：关键路径有日志或指标，异常可告警

回滚方案：明确回滚步骤和触发条件

特殊场景补充（按需）：

涉及数据变更 → 增加数据迁移验证

涉及外部接口 → 增加对方联调确认

涉及用户可见变更 → 增加产品验收

"回滚方案"这一项最容易被省掉，也最容易在上线出问题时变成灾难。我坚持它是必填项，哪怕只写一句"回滚到上一版本镜像"。

6. 迭代复盘与改进项模板

复盘模板的核心约束是：必须产出规则变更，并且每条变更有负责人和生效时间。没有这两栏的复盘模板，注定只产出感受。

迭代复盘模板
————————————————

本期承诺交付：X项

实际交付：Y项

未完成项及原因：（逐项列出，不写"因为忙"）

数据回顾：

平均周期时间：___ 天

阻塞平均关闭时长：___ 小时

提测后返工率：___ %

进行中列平均堆卡数：___ 张

规则变更（限1-2条）：

变更内容：

触发条件：

执行动作：

负责人：

生效时间：

下期观察指标：

指标名 / 当前值 / 目标值

限制只改一到两条规则是刻意的。改十条规则的团队，通常一条都落不了地。我自己的经验是，只要每条规则都有明确的触发条件和负责人，哪怕一个迭代只改一条，半年后整个流程也会发生质变。

七、落地节奏：30/60/90 天推进路径

1. 第 1，30 天：让任务可见

第一个月的目标只有一句话：每一件正在做的事，在系统里都有一张对应的卡，卡上有负责人、验收标准和截止时间。不要在这个阶段引入任何新指标，也不要开始度量复盘。

具体动作：清理当前所有在办任务，逐张确认是否真的在做；把没有负责人或没有验收标准的卡补齐；先把"进行中"这一列的卡片数压到合理范围，具体手段是暂停拉新卡直到列内数量降下来。

2. 第 31，60 天：让阻塞有人管

第二个月引入阻塞升级规则和 DoD 清单。这两个机制一个管速度，一个管质量，同时上线能互相印证效果。

具体动作：建立阻塞台账，每天记录阻塞的出现时间、责任方和关闭时间；设定 4/24/48 小时三级升级时限；把 DoD 五项做成卡片完成时的必勾清单。这个阶段的观察重点不是平均值，而是阻塞关闭时长的分布形状，如果 90 分位数没有明显下降，说明升级规则没有被真正执行。

3. 第 61，90 天：让数据说话

第三个月开始做月度度量复盘，重点是让团队自己看数据、自己提改进项。管理者的角色从"发现问题"变成"保障规则执行"。

具体动作：按月输出周期时间、阻塞时长、返工率、按期交付率四个指标；每次复盘产出一到两条规则变更；把上个月定的规则变更执行情况作为复盘的第一个议题。

4. 每个阶段的验收标准

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

1. 20，50 人团队：只做两件事

这个规模不要上四层机制，太重。我建议只做两件事：给所有在办任务建卡（含负责人和验收标准），以及设定每人 1.5 张卡的 WIP 上限。

工具上不需要复杂配置，一个简单的看板上手最快。关键是别买一套功能齐全但没人维护的系统，小团队的特点是沟通成本低，把流程做重反而会压制灵活性。

2. 100，300 人团队：补规则而不是补流程

这个规模最常见的状态是流程过重、规则缺失。我的建议是先把工作流精简到五到六列，然后把精力全部投在每一列的进入和退出标准上。

工具选择上，这个规模已经需要支持跨团队依赖视图和自定义报表，同时要开始考虑数据主权和迁移成本。像 PingCode 这类面向中大型企业、支持私有化部署并具备 Jira 迁移路径的平台，在这个阶段通常比轻量工具更合适，因为你要处理的不只是任务卡，还有多团队之间的依赖关系。

3. 300 人以上多团队：优先解决组织边界阻塞

到这个规模，团队内部通常已经没有大问题，瓶颈几乎全在跨团队依赖上。建议设立一个跨团队的依赖对齐机制：每个迭代开始前，所有跨团队依赖必须完成对齐并记录承诺时间；迭代中期做一次依赖健康度检查。

度量上，我建议单独跟踪"跨团队阻塞关闭时长"这个指标，而不是混在总体阻塞里。这个指标对组织效率的指示性最强。

4. 正在从海外工具迁移的团队：先定规则再迁数据

我见过太多迁移失败的案例，原因几乎都一样：先把数据搬过去，再想流程怎么配。结果就是把旧流程的问题原封不动搬到新系统里，还多花了一次迁移成本。

我的建议顺序是：先用两周明确新系统的列规则、字段必填项、WIP 上限和 DoD，然后再做数据迁移。迁移时只迁活跃需求和近一年的历史数据，更早的数据归档导出即可，没必要全量迁进新系统增加噪音。

九、不同情况下的取舍

1. 规则严格度 vs 团队接受度

规则越严格，短期改善越快，但团队抵触也越强。我的判断是规则的数量要少，执行要硬。宁可只定三条规则但严格执行，也不要定十条规则然后大家都打折执行。

如果团队抵触明显，可以先从"只观察不考核"开始，让数据自己说话。多数团队在看到阻塞时长下降后，会主动要求更明确的规则。

2. 私有化部署 vs SaaS

这个取舍中大型组织几乎都会遇到。私有化部署的代价是运维成本、升级节奏受控、需要专人维护；收益是数据完全可控、可以深度定制、不受外部服务波动影响。

我的判断标准有三条：是否涉及敏感数据或受合规约束、是否有专职的运维或平台团队、是否有深度定制需求。三条里有两条满足，就值得考虑私有化。像 PingCode 这类支持私有化部署的平台，在这类场景下是有实际价值的，因为它同时具备 Jira 迁移能力，对国产替代需求的组织来说减少了迁移风险。

3. 度量透出 vs 考核化风险

度量数据要透出给团队，但绝不能直接用于绩效分配。这个取舍不是二选一，而是要建立中间层：数据用于发现问题，绩效用于评价长期能力和协作贡献。两者可以有交集，但不能是直接映射关系。

如果组织文化上做不到这一点，我的建议是宁可少做度量，也不要让度量变成监控工具。失真的数据比没有数据更危险。

4. 一次改到位 vs 小步迭代

一次改到位的诱惑很大，尤其是有管理层推动的时候。但我见过的成功案例，几乎都是小步迭代。

原因是团队的执行习惯需要时间形成，而习惯形成依赖成功体验。一次引入太多规则，团队还没体会到好处就先感受到负担，抵触会迅速积累。30/60/90 天的节奏本质上就是在制造阶段性成功体验。

十、结语：从一张任务卡开始

回到开头那个延期五个月的项目。我们最后没有换系统，也没有引入新的管理框架，做的第一件事是让团队把手上所有任务逐张过一遍：删掉已经不做的、补齐没有负责人的、把超过三天的工作量重新拆开。第二周开始，站会改成只谈阻塞，看板设了 WIP 上限，超限就先解决阻塞再拉新卡。

六周之后，那个项目的迭代按期交付率从 47% 升到了 71%，提测后返工率从 31% 降到 19%。这不是什么奇迹，只是把堵在系统里的任务放出来了。

如果你现在正准备做这件事，我给三个具体的下一步建议。第一，这周之内把团队当前所有在办任务列出来，标出没有负责人和没有验收标准的，先清理这一批。第二，把 WIP 上限设成每人 1.5 张，坚持两周，观察"进行中"列的数量变化和周期时间的变化。第三，把本文的六张模板里挑三张用起来，建议先上任务拆解卡、看板列规则和 DoD 清单，其余的等前三个稳定后再加。

最后提醒一句：任何机制的价值都不在文档里，而在连续执行三十天之后。规则是否有效，看的是第四个迭代周期时团队还在不在用，而不是第一个礼拜有多少人点赞。