追踪实操方法：实施团队提升进度跟踪效率的制度设计方法与模板

去年下半年，我陪同一家做制造业 MES 实施的团队做了一次进度跟踪复盘。这个团队 14 个人，同时在跑 6 个客户现场，项目经理每周花在收集进度上的时间接近 26 小时，但项目按期交付率只有 43%，而且延期几乎全部是在交付前两周才被发现的。更反常识的是，他们并不缺工具，他们有用某项目管理平台、有共享表格、有每周固定两小时的例会。问题出在制度：他们的跟踪机制是在"收集信息"，而不是在"暴露偏差"。

这篇文章我想把进度跟踪从"制度设计"的层面拆开讲。它不是一个"要不要用工具"的问题，而是一套关于状态定义、频率分层、责任归属、异常升级和模板约束的组合设计。我会给出我自己在实施团队里反复验证过的模板、字段定义、状态机和判断标准，也会说明哪些做法在什么规模下有效、在什么规模下反而会变成负担。

一、核心结论：跟踪效率不是"填得快"，而是"不需要解释"

先把结论放在最前面，后面所有内容都是围绕这五条展开的。如果你只想要能立刻改的东西，改这五条就够了。

1. 跟踪成本的上限由"状态可判定性"决定

一个任务的状态如果需要人来解释才能理解，它的跟踪成本就永远降不下来。所谓可判定，是指任何人看到这个状态，不需要问第二句话，就知道下一步该谁动作。我在团队里推行的第一条硬规则是：所有状态必须能对应到一个明确的"下一步责任人"，对应不上的状态一律删掉。

"进行中"就是典型的不可判定状态。它既可能是顾问在做配置，也可能是在等客户提供接口文档，还可能是卡在内部评审。这三种情况的下一步责任人完全不同，但它们在系统里长得一模一样。

2. 制度必须覆盖"默认路径"，而不是只覆盖"理想路径"

大多数团队的跟踪制度是照着理想流程写的：需求确认→方案设计→开发配置→测试→上线。但实际执行中，真正的耗时黑洞是"等待客户回复""等待第三方接口""等待内部资源"。这些环节在制度里没有位置，于是它们只能被塞进"进行中"，进度就失真了。

一个制度是否可用，判断标准是它能不能容纳"卡住"这件事本身，而不是假设事情永远在顺利推进。

3. 频率必须分层，统一频率是效率杀手

很多团队犯的错是"一刀切"：所有任务都要求每天更新。结果是顾问把日更变成了应付动作，填写的质量快速衰减到接近噪声。我的做法是把跟踪对象分成三层，对应三种频率：里程碑层级每天看、任务层级每周更新、风险与变更事件驱动。

4. 跟踪的原子单位是"可交付物"，不是"任务"

"完成接口联调"是一个任务，但"客户确认的接口清单 v2"是一个可交付物。任务可以含糊，可交付物很难含糊，它要么存在，要么不存在。把跟踪原子从任务切换到可交付物，是我见过对跟踪效率改善最直接的一次改动。

5. 模板的价值在于约束，不在于记录

我见过太多"看起来很完整"的模板，字段有三十多个，但没人填。模板的设计目标不是把信息记录全，而是让填的人无法填错、让看的人无法误读。一个有效模板的字段数通常在 8 到 12 个之间，超过 15 个字段的进度表，三个月内填报率基本都会掉到 50% 以下。

二、真实场景：实施团队的进度跟踪为什么总是失效

先区分一下场景，因为不同规模的实施团队，失效原因差异很大。把这三类混在一起讨论，很容易得出一个对谁都不适用的结论。

1. 三类典型实施团队及其跟踪特征

第一类是 10 人以下的小型实施组，通常一人多岗，跟踪靠口头和微信群。这类团队的跟踪问题不是"信息不够"，而是"信息不落地"，讨论过的结论没有留痕，两周后没人记得当初承诺了什么。

第二类是 20 到 60 人的中型实施团队，有专职项目经理，有周报和例会。这类团队的核心问题是信息在传递过程中被层层平滑：顾问不想在周报里写"卡住了"，项目经理汇总时也不愿意把坏消息往上抬，最后到交付总监手上的进度永远比实际乐观。

第三类是 100 人以上的大型实施组织，跨多个项目群、多个区域。这类团队的问题变成了"口径不统一"，同名指标在不同项目里的计算方式不同，横向对比失去意义，管理层只能看感觉。

2. 周报失真的三个具体机制

第一个机制是"进度通胀"。顾问在写周报时，倾向于把 60% 完成度写成 80%，因为 60% 需要解释，80% 不需要。这个过程没有任何恶意，但它在每个汇报层级都会被放大一次。

第二个机制是"坏消息延迟"。在一个 30 人的团队里，一个实施顾问发现某项接口对接可能要延期两周，他需要判断：现在说，会不会被认为能力不足？等一周再说，会不会还有转机？这个犹豫期往往就是延期被发现的全部延迟。

第三个机制是"状态占位"。"进行中"这个状态在很多团队里能占到全部任务的 70% 以上，它同时承担了"真的在做""在等别人""快做完了""其实还没开始"四种含义。当一个人看到 70% 的任务都是进行中，他实际上没有获得任何可用于决策的信息。

3. 客户侧依赖是最大的跟踪断层

实施项目最特殊的地方在于，相当一部分工作不在自己团队的掌控内。客户确认方案、客户提供数据、客户安排关键用户参与测试、第三方厂商提供接口，这些环节构成了进度跟踪上最大的盲区。

我发现一个很稳定的规律：凡是没有被显式建模为"等待态"的外部依赖，最后都会以延期的方式在项目末期集中爆发。因为它没有出现在任何人的待办里，也就没有人在它超时时发出提醒。

三、拆解常见误区：为什么很多看起来很规范的制度最后都空转

下面这五个误区，是我在至少二十个实施团队里反复见到的。它们的共同特点是：单看每一条都显得很合理，组合起来却会把跟踪效率拖到谷底。

1. 误区一：把跟踪频率等同于跟踪质量

"每天更新进度"这句话听起来很严格，实际上它把一个连续变量强行二值化了。当所有任务都必须日更时，顾问会发明出大量的微量进展来填格子，比如"已完成 5%""已阅读需求文档"。

更麻烦的是，高频更新会制造出大量噪声数据，让真正需要关注的异常淹没在正常的日常波动里。我做过一个粗略统计：在强制日更的团队里，项目经理平均需要浏览 3 到 4 倍的条目，才能定位同一个真实阻塞。

2. 误区二：状态字段越多，描述越精确

我见过一个有 11 种任务状态的进度模板：待启动、已启动、方案中、方案确认中、开发中、开发完成、测试中、测试完成、待验收、已验收、已关闭。设计者的意图是精确，实际结果是没有人能记住 11 种状态的边界，于是每个人都按自己的理解填。

精确性不是靠状态数量获得的，而是靠状态之间的判定条件是否互斥且完备。我的经验值是：单一工作项类型的状态控制在 4 到 6 个，超过 7 个就开始出现系统性误填。

3. 误区三：用人的自觉替代系统约束

"我们会定期检查大家有没有更新"，这句话背后的管理成本是被严重低估的。人工检查需要有人每周花数小时比对，检查出来之后还要一对一沟通，沟通完了下个月照样有人不填。

凡是能够用工具规则自动执行的约束，都不要交给人去执行。状态超期自动标黄、阻塞超过 48 小时自动提醒、没有可交付物的任务不允许进入测试状态，这三条自动化规则的价值，超过任何一次进度管理培训。

4. 误区四：把甘特图当成进度跟踪工具

甘特图是很好的沟通工具，但它是糟糕的跟踪工具。原因是甘特图展示的是"计划的时间轴"，而跟踪需要的是"实际的偏差与原因"。当你把甘特图当作唯一的进度视图时，所有人关注的都会变成条形图的长度是否好看，而不是任务本身是否卡住了。

我的做法是保留甘特图作为对客户和高层的汇报视图，但团队内部的跟踪视图是按阻塞时长排序的列表，而不是按时间排序的条形图。

5. 误区五：把变更管理和进度跟踪分开管

在实施项目里，延期和需求变更是高度耦合的。如果一个制度只跟踪"任务做没做完"，不跟踪"范围变了多少"，那么进度数据迟早会失去解释力，因为分母一直在变。

我在团队里有一条硬要求：任何里程碑的健康度评估，必须同时给出"已完成比例"和"范围变更量"两个数字。只给前者，等于只报喜不报忧。

四、专业判断逻辑：进度跟踪制度的五个设计支点

前面讲的是问题，这一节讲我实际用来设计的框架。它不是理论模型，而是我在多个项目里调整过若干轮的产物，每条都对应一个具体的配置动作。

1. 支点一：用五态状态机替代自由状态

我最终收敛下来的状态机只有五个状态：待启动、进行中、等待外部、待验证、已完成。关键在于每个状态的"进入条件"和"退出条件"都是可判定的。

• 待启动：还没有被分配责任人，或者依赖的前置任务未完成
• 进行中：责任人本周有明确动作，且不存在外部依赖
• 等待外部：必须由非本团队角色（客户、第三方、其他部门）动作才能推进，且必须填写等待对象和承诺时间
• 待验证：产出物已提交，等待验收方确认
• 已完成：验收方已确认，且产出物已归档到指定位置

这个状态机最大的价值在于，"等待外部"让原本藏在"进行中"里的黑洞显性化了。一旦这个状态被单独统计，团队会立刻发现自己的真实交付节拍受制于多少个外部承诺。

2. 支点二：跟踪频率按对象分层，不按人头统一

我把跟踪对象分成三层，每层用不同的频率和不同的载体。这个分层是整套制度里节省时间最多的一处设计。

1. 里程碑层：每天看，但只看 3 到 7 个数字，不看明细。载体是自动生成的仪表盘，不产生任何额外填报工作。
2. 任务层：每周更新一次，更新时只改状态和阻塞原因，不写描述性文字。
3. 风险与变更层：事件驱动，发生即记录，不做周期性汇总。

关键在于第一层完全不依赖人工填报。里程碑健康度由任务数据自动汇总计算，所以"每天看"不会带来任何额外成本。真正需要人工投入的只有第二层，而周频更新对顾问来说是可以接受的负担。

3. 支点三：把阻塞当作一等公民对象

大多数工具的默认模型里，阻塞是任务的一个属性。我的做法是把阻塞做成一个独立的工作项类型，有自己的责任人、自己的承诺解决时间、自己的超时规则。

这个改动带来的行为变化非常明显：阻塞从"一件说不清的麻烦事"变成了"一个有归属和期限的条目"。当阻塞被单独列表展示、按停留时长排序时，团队每周例会的焦点会自然从"汇报进度"转向"清理阻塞"。

4. 支点四：度量指标只保留三个

指标越多，注意力越分散。我在实施团队里只保留三个核心指标，其余全部作为诊断用的辅助数据，不进周报。

这三个指标的组合能覆盖大部分管理判断：达成率告诉你"能不能按时交"，阻塞时长告诉你"卡在哪里、卡多久"，变更吞吐比告诉你"进度数字还能不能信"。

5. 支点五：模板即契约，字段数量与责任绑定

模板设计的核心原则是：每一个字段都必须对应一个明确的使用者，没有使用者的字段一律删除。我常用的判断方法是问三个问题，这个字段谁填？谁看？看到之后会做什么动作？三个问题里有一个答不上来，这个字段就不该存在。

按这个标准筛下来，我最终保留的字段是 10 个：工作项标题、所属里程碑、责任人、状态、计划完成日、可交付物链接、阻塞原因、阻塞责任人、承诺解决时间、验收人。注意其中没有"完成百分比"这个字段，因为百分比是典型的不可判定信息，它的唯一作用是让人产生"我在精确管理"的错觉。

五、案例与数据观察：一个 14 人实施团队的 90 天改造

下面这个案例是我实际参与过的，数据来自团队内部的周度统计，样本是该团队同期在跑的 6 个制造业客户实施项目。为了保护信息，客户名称和部分绝对值做了模糊处理，但比例关系和变化趋势是真实的。

1. 改造前的基线状态

改造前的 4 周，团队的核心数据是：里程碑计划达成率 61%，阻塞平均停留时长 112 小时（约 4.7 个工作日），范围变更吞吐比 31%，项目经理每周花在收集和汇总进度上的时间是 26 小时。

更值得注意的是顾问侧的负担：每位顾问平均每周花 1.8 小时更新进度，其中约 60% 的时间用在写描述性文字而不是更新状态。这部分投入对决策几乎没有贡献。

2. 三项关键改动

我们没有一次性推翻原有流程，只做了三件事，按顺序推进。

1. 第一周：重定义状态机。把原有 9 个状态收敛到 5 个，并强制要求"等待外部"状态必须填写等待对象和承诺时间。这一改动本身不涉及任何工具配置。
2. 第三周：把阻塞独立成工作项类型，配置超时提醒规则，并按停留时长生成排序视图。例会流程同步改为先过阻塞列表、后过里程碑。
3. 第五周：把跟踪原子从任务改为可交付物，同时上线自动化规则，没有关联可交付物的工作项不允许流转到"待验证"状态。

这里要说清楚一个取舍：第三项改动在推进时遇到的最大阻力不是技术，而是"可交付物应该是什么粒度"。我们最终的约定是一个可交付物必须是"能发给客户或能归档的东西"，比如一份接口清单、一个配置包、一份测试记录。这个定义足够具体，避免了讨论陷入"什么才算交付物"的循环。

3. 90 天后的数据变化

需要说明的是，达成率的提升不全是制度改善的功劳，同期团队还补充了两名顾问，客户侧的需求冻结流程也做了调整。但阻塞停留时长的下降（从 112 小时到 29 小时）几乎完全来自升级机制的建立，这一项的可归因度最高。

4. 工具侧的配置：以 PingCode 为例

这个团队在第 4 个月把整套制度落到了 PingCode 上。选择它的直接原因是团队原有系统在跨项目汇总和权限隔离上不太够用，而实施业务需要按客户项目做严格的数据隔离。

PingCode 主要服务中大型企业及 100 人以上组织，这一点和这个团队后续的扩张节奏是匹配的，他们在半年内从 14 人扩到 40 人以上。另外它支持私有化部署，对于需要把客户项目数据留在自己机房内的实施方来说，这一项在合规评审时往往是硬门槛。

还有一个实际考虑是迁移成本：这个团队之前用 Jira 管理过一段时间，PingCode 支持从 Jira 平滑迁移，字段映射和工作项类型的对应关系可以保留，不需要重新建账。对国内做国产替代选型的实施团队来说，这是一个不需要额外论证的点。

下面是我们在 PingCode 里配置"阻塞"工作项类型时用到的一段自动化规则结构，用 YAML 表示，方便你直接对着改：

work_item_type: blocker
fields:

name: 关联工作项

type: relation

required: true

name: 阻塞类型

type: select

options: [客户依赖, 第三方依赖, 内部资源, 技术风险]

name: 阻塞责任人

type: user

required: true

name: 承诺解决时间

type: datetime

required: true

automation_rules:

trigger: blocker_created

action: assign_to_owner

notify: [阻塞责任人, 项目经理]

trigger: blocker_age_hours > 24

action: mark_warning

notify: [项目经理]

trigger: blocker_age_hours > 48

action: escalate

notify: [交付总监]

add_comment: "阻塞超过 48 小时，需在下次例会前给出处置方案"

trigger: blocker_resolved

action: close_related_check

notify: [关联工作项责任人]

trigger: task_state_changed

condition: target_state == "待验证" and deliverable_link == null

action: reject_transition

message: "进入待验证状态前必须关联可交付物"

这段配置里最关键的是最后一条：它把"必须有可交付物"从一条口头要求变成了一个系统拒绝动作。我们试过只靠制度宣讲，两周后遵守率掉到了 55%；改成系统拦截之后，遵守率稳定在 97% 以上，而且几乎没有人抱怨，因为拦截发生在他自己的操作界面上，不需要经过任何人的检查。

5. 一个反例：另一个团队的失败尝试

同期还有一个 9 人的实施团队照搬了这套模板，三个月后基本废弃。复盘下来有三个原因。

第一是他们项目周期太短，平均 4 到 6 周一个交付，五态状态机的切换频率过高，顾问觉得"还没走完一遍流程项目就结束了"。第二是他们没有专职项目经理，阻塞升级规则里的"通知交付总监"这一层实际上没人接。第三是他们直接引入了全部自动化规则，但没有先做状态定义，导致系统拦截频繁误伤。

这个反例说明：制度的复杂度必须匹配团队的管理密度。人数少、周期短、没有专职管理角色的团队，应该只取状态机和阻塞独立这两条，不要碰可交付物强约束和升级链路。

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

下面的建议按团队规模和管理成熟度分组，你可以对照自己团队的情况直接选一组执行。每组都给出具体的动作顺序，不要跳步。

1. 10 人以下、无专职项目经理的小型实施组

你们的首要目标不是把制度做全，而是让讨论结论可回溯。建议只做两件事。

1. 建立一份共享的"承诺清单"，只记四个字段：谁、承诺了什么、什么时候交、实际交付时间。每次与客户或内部沟通结束后由发起人当场更新，不做事后整理。
2. 每天用 10 分钟同步"承诺清单"里即将到期的项，不做任务列表，不做工时统计。

这个规模下不要引入状态机，也不要配置自动化规则。你们的沟通成本足够低，制度的作用是补上"留痕"这一个缺口就够了。

2. 20 到 60 人、有专职项目经理的中型团队

这是制度收益最大的区间。建议按五周节奏推进，每周只改一件事。

• 第 1 周：重定义状态机，从现有状态收敛到 4 到 6 个，明确每个状态的进入条件
• 第 2 周：把"等待外部"状态单独统计，生成第一份外部依赖清单
• 第 3 周：把阻塞做成独立工作项，建立超时提醒
• 第 4 周：把例会流程改为先过阻塞、后过里程碑
• 第 5 周：把三个核心指标接入仪表盘，取消手工周报汇总

这个节奏的关键是不要在第一周就动工具配置。先让团队理解状态的含义，再让工具承载它，否则工具会变成推行的阻力而不是助力。

3. 100 人以上、跨项目群的实施组织

你们的首要问题通常是指标口径不统一，其次才是跟踪动作。建议的顺序正好相反：先统一口径，再统一动作。

1. 先出一个"指标字典"，明确每个指标的计算公式、数据来源、统计周期和责任人。这一步不涉及工具。
2. 再用统一的工作项类型模板固化到平台上，禁止各项目自行增删核心字段。
3. 最后才是自动化规则和仪表盘的统一配置。

在这个规模下，建议优先选择支持私有化部署、支持跨项目群汇总、并且有成熟迁移路径的平台。PingCode 在这类场景下的适配度较高，尤其是需要从既有系统迁移历史数据、又要求数据不出内网的场景。

七、不同情况下的取舍：哪些该放弃，哪些不能省

制度设计本质上是一组取舍，不是一组最佳实践。这一节我把常见的取舍点列清楚，方便你在资源有限时做优先级判断。

1. 跟踪粒度与跟踪成本的取舍

粒度越细，跟踪成本越高，但风险发现越早。这个权衡没有普适解，但有一个可操作的经验值：单个工作项的预计工期在 3 天到 10 天之间时，跟踪的投入产出比最高。

低于 3 天的工作项，跟踪成本会超过它本身的价值；高于 10 天的工作项，偏差积累时间太长，等到发现时已经来不及调整。按这个标准去拆任务，比按"每人每天一件"去拆要合理得多。

2. 自动化程度与适应性的取舍

自动化规则越严格，执行一致性越高，但应对特殊情况的弹性越低。我的建议是分层设置：

• 不能让步的：进入待验证状态必须关联可交付物。这条会直接影响进度数据的可信度，弹性空间为零。
• 可以设例外的：阻塞超时升级。给项目经理一个"延期升级"的按钮，但要求在系统里填写理由。理由是留痕，不是审批。
• 建议不设的：状态变更审批流。进度更新是高频动作，加审批会直接摧毁填报意愿。

3. 指标数量与解释成本的取舍

三个核心指标是我认为的下限，也是上限。少于三个，无法同时覆盖交付节拍、响应速度和范围稳定性；多于三个，周会时间会被数据解释占满，讨论不到真正的问题。

如果你所在的团队还没有能力保证三个指标的准确性，那就先只保一个：阻塞平均停留时长。它是最难造假、最容易归因、也最能反映团队真实响应速度的指标。

4. 工具统一与团队自主的取舍

大型组织常见的两难：统一平台便于横向对比，但各项目组会觉得不灵活。我的判断标准是看字段层级，核心状态机、阻塞对象、三个核心指标这三项必须统一；视图、看板布局、通知方式可以放开。

把差异限制在展示层，把一致性锁在数据层。这样既保留了项目组的自主感，又保证了管理层拿到的数据口径一致。

八、可直接使用的模板清单

最后把这套制度里最常用的几个模板整理出来，都是可以直接复制使用的结构，不是示意性的框架。

1. 五态状态机定义模板

2. 日站会三问模板

日站会只问三个问题，每个问题不超过一句话，总时长控制在 10 分钟以内。这个模板的作用是防止站会变成进度汇报会。

1. 昨天有哪些工作项进入了"等待外部"状态？等待对象是谁？
2. 当前有哪些阻塞项的停留时长超过了 24 小时？
3. 今天有哪些工作项计划从"待验证"转为"已完成"？

注意这三个问题问的都是状态转换和阻塞，没有一个是问"你昨天做了什么"。后者是汇报，前者才是跟踪。

3. 里程碑健康度评估模板

每周对每个里程碑做一次评估，输出两个数字和一个判断。评估过程不超过 5 分钟，因为数据全部来自系统自动汇总。

milestone_health:
milestone_id: MS-2024-Q3-002

name: "客户A 核心模块上线"

数字一：完成度

deliverable_total: 24

deliverable_done: 17

completion_rate: 0.708

数字二：范围变更

scope_added_hours: 96

scope_removed_hours: 24

baseline_hours: 640

change_ratio: 0.1125

前置阻塞

active_blockers: 3

max_blocker_age_hours: 41

external_dependency_count: 5

健康度判定

health:

completion_signal: "on_track" # on_track | at_risk | off_track

change_signal: "acceptable" # acceptable | watch | overloaded

blocker_signal: "watch" # healthy | watch | critical

overall: "at_risk"

判定规则说明

rules:

"completion_rate 低于计划进度 10 个百分点以上 -> at_risk"

"change_ratio 超过 0.15 -> watch, 超过 0.25 -> overloaded"

"max_blocker_age_hours 超过 48 -> critical"

"任一维度为 at_risk 或 critical 时，overall 不得为 on_track"

最后一条规则是我特意加的：只要有一个维度出现风险信号，整体判断就不允许是"正常"。这条规则用来对抗综合评估里常见的"平均化倾向"，三个维度里两个好一个差，平均下来容易得出"总体正常"的结论，而那个差的维度往往才是真正会出问题的地方。

4. 阻塞升级通知模板

升级通知的内容要短，只包含定位信息和要求的动作，不要包含背景说明。背景在系统里可以点进去看，写在通知里只会降低阅读率。

【阻塞升级】BLK-1042 已停留 52 小时
关联里程碑：客户B 数据迁移（计划完成日 3 天后）

阻塞类型：第三方依赖

阻塞责任人：张工

等待对象：客户方 IT 主管

承诺解决时间：已逾期 28 小时

要求动作：

1. 阻塞责任人在今日 18:00 前更新解决方案或重新承诺时间
2. 若无法在里程碑计划完成日前解除，项目经理需在明日例会前提交范围调整建议

这个模板的关键在于第二段"要求动作"，它明确了责任人和时限。没有这一段，通知就只是提醒，不会产生行为改变。

5. 三条不能省的硬规则

如果你的团队资源有限，只能落地一部分内容，我建议优先保住下面这三条。它们的实施成本低，但对数据可信度的支撑作用最大。

• 等待外部必须填等待对象和承诺时间。这一条让外部依赖从隐形变显性，是后续所有升级机制的基础。
• 进入待验证前必须关联可交付物。这一条把"做完了"从主观判断变成可核验事实。
• 阻塞停留超过 48 小时必须升级到上一层管理者。这一条决定了团队的响应速度上限。

结语

回到开头那个团队。他们最终解决问题的关键，不是换了工具，也不是加了人手，而是把"进度跟踪"这件事从信息收集活动重新定义成了偏差暴露机制。这个重新定义带来了三个具体变化：状态必须可判定，阻塞必须是独立对象，外部依赖必须显性记录。

我想强调一个可能不太主流的观点：进度跟踪制度的目标不是让管理者掌握更多信息，而是让偏差在还来得及处理的时候自己冒出来。这两者的设计逻辑完全不同。前者倾向于增加字段、提高频率、加强汇报；后者倾向于减少字段、降低频率、强化升级链路。

如果你打算下一步就动手，我建议的顺序是：先用本文的状态机模板对照现有系统做一次盘点，把不可判定的状态找出来；然后只做一件事，把"等待外部"单独拎出来统计一周，看看你团队的交付节拍到底受制于多少个外部承诺。这个数字出来之后，你会清楚地知道接下来该改什么。

不要一次改完所有东西。制度是长出来的，不是装上去的。