追踪管理指南：产品经理如何做好进度跟踪，入门指南全流程

我带过一个做供应链中台的项目，上线前三天，联调环境里还躺着 11 个未合入的分支。而就在两周前的那份周报上，这个项目的状态是绿色，完成度写着 85%。当我问项目负责人这个数字是怎么算出来的时候，他愣了一下说：“大概吧，需求清单上大部分都点了完成。”那次上线延期了 19 天，延期通知发出去的那个下午，团队里没人觉得意外，只有管理层觉得意外。也是从那时候起，我不再相信任何没有证据链的进度数字，开始系统性地重做自己的进度跟踪方法。

这篇内容就是这套方法的完整拆解：产品经理到底该跟什么、怎么跟、跟到什么程度就该停，以及在不同团队规模下应该做哪些取舍。

一、先给结论：进度跟踪是一套决策系统，不是一份汇报流程

如果你只记住一句话，我希望是这句：进度跟踪的目的不是知道大家干了多少活，而是在关键节点上做出正确的资源投放和优先级决策。前者是信息收集，后者才是管理动作。绝大多数做不好进度跟踪的产品经理，问题恰恰出在把这两件事混为一谈，他们收集了大量信息，却没有产出任何一个决策。

1. 一个反常识判断：跟踪频率和项目健康度不成正比

很多新手产品经理的本能反应是：进度不稳，那就多问几次。每天站会不够，就改成早晚各一次同步；周报不够，就上加日报。我在实际项目里做过对比观察，同一个业务线下的三支团队，A 组每天站会加每日线上更新，B 组每周两次同步，C 组每周一次同步加里程碑评审。三个季度下来，按期交付率分别是 74%、76%、71%，差距在噪声范围内。但团队额外投入的沟通时间，A 组比 C 组高出将近 60%。

这个观察说明一个很重要的事情：频率解决的是信息时效问题，解决不了信息质量问题。如果成员汇报上来的是“进展顺利”“快完成了”这种模糊信号，你一天问三遍也问不出真实风险。真正影响交付的，是有没有一套机制能让阻塞在 24 小时内被识别、被记录、被指派、被关闭。

2. 你真正要拿到的四个决策输出

合格的进度跟踪，每个周期结束时必须能回答四个问题，缺一个都算没跟到位。

第一，哪些事要延期，延多久，影响谁。不是“有风险”，而是“A 接口的联调会从周三推到周五，导致 B 页面无法在月底进入测试”。没有具体对象和时间的风险提示，等于没说。

第二，哪些资源需要重新分配。是加人、换人，还是把某个非核心需求砍掉。产品经理手上最值钱的筹码是优先级，不是催办的话术。

第三，哪些假设已经被证伪。比如原计划“第三方支付接口一周能对接完”，实际用了三周，这个偏差必须写进下一轮排期的前提里，而不是当成一次意外。

第四，哪些变更要重新走评审。不管是需求插入、范围扩大还是验收标准调整，只要影响里程碑，就必须回到变更入口，而不是在群里一句“先做这个吧”就消化掉。

3. 三层机制：目标层、交付层、信号层

把上面这些输出对应到日常动作，我习惯把跟踪拆成三层。这三层不是流程阶段，而是同时存在的三个视角，新手最容易犯的错是只做其中一层。

这三层里，目标层的返工成本最高，信号层的返工成本最低。新手往往把 80% 的精力花在信号层，天天追状态，却从来没回头检查目标层的验收标准是不是写清楚了。结果是所有人在错误的方向上跑得很整齐。

二、真实场景：进度是怎么在管理者眼皮底下失真的

进度失真很少是有人故意撒谎。更多时候，它是几个具体场景叠加出来的系统性偏差，每个场景单独看都不致命，叠在一起就变成了上线前的连环爆雷。下面四个场景，是我在不同项目里反复见到的。

1. 站会念台词：状态更新变成了仪式

典型画面是这样的：每日站会，每个人轮流说“昨天做了 A，今天做 B，没有阻塞”。二十人的会，十二分钟结束，看起来高效。但真正卡住的那个接口对接问题，当事人觉得“我自己能搞定”，或者“说出来显得我能力不行”，于是没人提。等到第三周他实在搞不定的时候，已经没人有时间接盘了。

这不是态度问题，是机制问题。当“没有阻塞”成为默认答案，报阻塞就变成了异常行为，需要额外承担社交成本。好的机制要把报阻塞设计成常态动作，比如在任务台账里阻塞字段是必填项，未填写视为未更新，而不是默认“无”。

2. 周报数字和里程碑严重脱节

我见过的最典型的一份周报是这样写的：“本周完成需求 18 个，累计完成 42/50，完成度 84%。”看上去很漂亮。但当我按里程碑去看时，发现核心的对账模块连冒烟都没通过，测试环境还没部署，接口文档还是第一版。那 42 个“完成”的需求里，有 15 个是前端静态页面，9 个是配置类改动，真正打通业务链路的只有 6 个。

问题出在哪？需求数量和业务价值不是线性关系。把大需求和小需求混在一起数个数，等于把 100 元和 1 元的人民币按张数算总额。按这种口径算出来的完成度，越接近 100%，风险反而越大，因为剩下的往往是那些最难、最长尾、最容易被低估的硬骨头。

3. 跨部门依赖的“沉默黑洞”

产品经理最常见的无力感，来自那些不在自己团队里的依赖项：数据组要给字段、运维要给环境、算法组要出模型、法务要过合规。这些事情的共同点是，你既不能排他的活，也不能考核他的人。于是很容易变成“我上周跟他说了”这种口头跟进。

口头跟进的问题在于，它没有时间锚点，也没有责任人确认。对方可能理解为“有空再说”，你可能理解为“已经排上”。我的做法是把所有跨部门依赖都落成一条带时间、带对接人、带升级路径的记录：谁在什么时间点交付什么，超时后找谁升级。依赖管理的核心不是催，而是让“没做”这件事在系统里变得可见。

4. 需求变更没有入口，全在群里消化

“这个功能加一下，很快的。”“老板说要提前一周上线。”“这个交互改一下，影响不大。”

这类变更如果不在群里被拦下来，就会直接进入执行，没人评估影响、没人重排优先级、没人更新排期。结果就是排期表看起来没变，实际工作量悄悄涨了 20%，等到快上线才发现做不完。变更管理的门槛不需要很高，但必须有：凡是影响里程碑的变更，都要有一条记录，记录里要有影响评估和调整后的排期。哪怕只是一张表、一次十分钟的确认。

三、拆解六个常见误区：为什么越努力越乱

这一节我把最常见、也最容易自我合理化的六个误区摊开讲。它们有个共同特征：短期看起来都在“负责任”，长期都在消耗团队。

1. 把跟踪等同于催办

催办是问“做完了吗”，跟踪是问“现在卡在哪、有什么代价、要不要我出面解决”。前者是状态询问，后者是决策支持。如果你每天发出的消息里全是“进度怎么样了”“记得今天交付”，团队成员会逐渐把你归类成监工，遇到真实问题时反而不愿第一时间告诉你，因为他们预判你会先责问再解决。

2. 用完成百分比替代可验收交付物

“这个需求 80% 完成了。”这句话几乎没有信息量。80% 是按代码行数、按工时、按主观感觉算的？剩下 20% 是一小时还是一周？我现在的做法是彻底放弃百分比，改成二元判断加证据：交付物是否可被验收？验收的证据是什么？是接口文档已评审、测试环境已部署、还是联调已通过。没有证据的节点，就标成未完成。

3. 用工具替代机制

这是新手最容易踩的坑：以为上一套项目管理工具，问题就解决了。工具能解决的是可见性和协作效率，解决不了“谁来决定优先级”“阻塞多久必须升级”这类规则问题。我见过团队把看板做得非常漂亮，字段齐全、泳道清晰，但没人定义过“任务停留在进行中超过五天算不算异常”。工具是机制的承载，不是机制的替代。先想清楚规则，再决定用什么承载。

4. 只向上汇报，不向团队同步

有些产品经理的进度管理实际上是“对上管理”：每周给领导一份漂亮的周报，但团队内部对整体节奏、哪些是重点、哪些可以砍，其实并不清楚。这种信息单向流动的后果是，团队只会对自己那一小块负责，不会主动暴露全局风险。跟踪的产出应该优先同步给团队，而不是优先同步给上级。团队不知道全局，就无法做局部取舍。

5. 过度度量，把工具用成考勤机

我见过用任务完成数、代码提交量、工时填报率来考核成员的团队。短期数字很好看，长期结果是大家开始优化数字本身：把一个任务拆成五条来提交，工时填满但产出不变，遇到难任务先绕开。任何被用作考核的跟踪指标，都会在三个月内失去作为判断依据的价值。跟踪数据用于发现问题，不用于评价人，这条边界必须守住。

6. 把进度跟踪等同于项目管理

进度跟踪只是项目管理里的一条线。项目启动、范围管理、干系人管理、质量管理和结项复盘，都是独立命题。把所有事情都塞进“进度跟踪”这一个筐，会导致你的跟踪表越来越重，最后没人愿意维护。该走正式立项的走立项，该走变更评审的走变更评审，别让进度表承担它不该承担的职责。

四、专业判断逻辑：什么样的进度信号值得信

这一节是全篇最核心的部分。前面讲了要跟什么、别做什么，这里讲怎么判断一个进度信号到底是不是真的。方法可以概括为一句话：把状态色换成证据链，把主观百分比换成可验证事实。

1. 信号可信度的三级分层

我把所有进度信号按可信度分成三级，只有第三级才能进最终的里程碑判断。

一级信号：口头描述。“差不多了”“基本做完”“就差联调”。这类信号的共同特征是动词模糊、时间模糊、无第三方验证。它们可以用于日常沟通，但绝对不能进入里程碑统计。

二级信号：过程产物。代码已提交、文档已更新、设计稿已交付、任务状态已变更。比口头强，但仍不能证明“这个节点可用”，因为提交不等于跑通，文档更新不等于评审通过。

三级信号：可验收事实。接口在测试环境返回预期结果、核心链路端到端跑通、评审记录里有明确的通过结论、验收用例执行完毕。只有三级信号才能把里程碑标记为完成。

判断一个团队的进度管理是否成熟，最快的方法不是看工具，而是随机挑三个“已完成”的节点，问一句“证据在哪”。如果三个里有两个答不上来，那这个团队的进度数据基本不可用于决策。

2. 用四个提问识别进度真伪

我在跟任何项目时，都会在同步会上固定问这四个问题。它们的作用不是施压，而是把模糊信号逼成具体事实。

1. 这个节点的验收证据是什么？逼对方拿出可验证的东西，而不是描述过程。
2. 如果明天就要交付，最可能出问题的是哪一环？这个问题能挖出被隐藏的风险，因为大多数人心里其实有数，只是没被问。
3. 这个依赖如果晚三天，会影响哪个里程碑？把依赖和里程碑挂钩，依赖才有优先级，否则它只是一句口头约定。
4. 这个变更如果做，我们砍掉什么？不做“加不加”的讨论，直接问代价，能大幅降低无效变更。

这四个问题看起来简单，但坚持问一个月，团队对“什么叫做完”的理解会明显收敛。因为它持续传递一个信号：我们在这里只认事实，不认感觉。

3. 把风险和变更分开记账

很多人把风险和变更混在一张表里，结果两类信息互相干扰。风险是尚未发生的可能性，需要跟踪概率、影响和应对措施；变更是已经发生的范围或时间调整，需要记录原因、影响和重新排期。它们的处理逻辑完全不同：风险要定期复查，变更要走审批入口。

分开记账还有一个隐性好处：当变更有了独立入口，团队会自然减少随手改需求的习惯，因为每一次变更都要面对一次影响评估，而不是群里一句话就过去了。

4. 从“状态色”切换到“偏差值”

绿色、黄色、红色这套红绿灯体系，最大的问题是主观性太强。同样是黄色，有人理解为“需要关注”，有人理解为“问题不大”。我现在的做法是用偏差值替代颜色：计划完成时间与实际完成时间差几天，计划交付物与实际交付物差几个。偏差值超过阈值（比如 2 天或超过总工期 10%）自动升级，不需要任何人主观判断颜色。

这套方法听起来冷冰冰，但它对团队其实更友好。因为它把“你是不是没做好”这种人身归因，转换成了“这个节点的偏差是几天”这种事实描述。事实可以讨论，指责只会让人防御。

五、入门全流程：七步法落地清单

前面讲的是判断逻辑，这一节给一套可执行的动作顺序。七步法适合第一次系统搭建进度跟踪的产品经理，按顺序做，每一步的产出都是下一步的输入。不要跳步，尤其不要跳过第一步。

1. 第一步：对齐目标、范围与验收标准

开工前必须回答三个问题：为什么做（业务目标）、做到什么算完成（验收标准）、明确不做什么（范围边界）。验收标准要写成可判定的句子，比如“财务对账差错率低于 0.1% 且支持人工复核”而不是“对账功能可用”。范围边界要写清哪些需求本期不做，避免后期无限扩张。

这一步的产出是一张目标对齐表，包含目标、衡量方式、验收标准、范围外事项、关键干系人。它的作用不是形式合规，而是在后续每一次优先级冲突时提供一个可以回去查的依据。

2. 第二步：拆解里程碑与可交付物

把大目标拆成 4 到 7 个里程碑，每个里程碑绑定一个可被外部验证的交付物。注意这里的单位是交付物，不是“阶段”。“开发阶段完成”不是交付物，“核心下单链路在测试环境端到端跑通”才是。里程碑数量太少会失去监控意义，太多会变成日常任务清单，反而没人关注真正的关键节点。

3. 第三步：建立任务台账

台账不是任务清单，它的核心是异常可见。我在台账里固定保留这几个字段：负责人、计划完成时间、可验收交付物、前置依赖、阻塞状态、阻塞时长、关联风险、变更记录。前四个字段用于计划，后四个字段用于异常捕获。

台账字段定义（示例）

task_id: 唯一标识

owner: 唯一责任人（不写“某某团队”）

due_date: 计划完成时间（精确到日）

deliverable: 可验收交付物描述

depends_on: 前置任务 id 列表

blocked: true / false（默认 false，需主动确认）

blocked_days: 阻塞持续天数（超阈值自动标红）

risk_ref: 关联风险编号

change_ref: 关联变更编号

这里有个细节很关键：责任人是唯一的人，不是团队。写“研发组负责”等于没人负责。这是我在多个延期项目里反复验证过的规律。

4. 第四步：设定同步节奏

同步节奏要因事设会，不要因人设会。站会解决的是“今天有没有阻塞”，周会解决的是“本周目标和偏差”，里程碑评审解决的是“这个节点是否达标”，复盘解决的是“下个周期改什么”。四种会议目的不同，混在一起开就会出现既没效率也没结论的情况。

5. 第五步：跟踪四类信号

进度信号看偏差（计划与实际的差距），阻塞信号看时长（卡了几天、卡在谁那里），风险信号看概率和影响，变更信号看代价。四类信号对应四种处理动作：进度偏差触发排期调整，阻塞时长触发升级，风险变化触发应对方案更新，变更触发影响评估。信号不处理，就等于没收。

6. 第六步：做决策与升级

产品经理要守住一条原则：升级时带方案，不带情绪；带选择，不带抱怨。团队内能解决的，当场定；需要跨团队协调的，带着两个备选方案找对应负责人；需要更高层决策的，写清影响和代价再上报。没有方案的升级，只会把问题原封不动地推给上级。

7. 第七步：里程碑复盘与机制迭代

复盘只做三件事：目标达成情况、偏差原因归类、下一周期要改的一条规则。不要复盘成追责会，也不要复盘出一份二十条的改进清单，那没人执行得了。一次复盘改一条，一个季度沉淀下来就很不一样。

六、具体案例与数据观察：中大型组织为什么更容易失控

前面讲的方法在小团队靠表格就能跑起来。但当组织规模上来之后，问题会从“个人执行力”变成“结构性问题”。这一节我结合在中大型企业里的观察，讲清楚规模带来的三个新变量。

1. 案例背景：一个 120 人研发组织的进度治理

这是一家做企业服务的公司，研发中心 120 人左右，分为五个产品线，共享一套基础平台和测试环境。他们当时的痛点和很多同规模组织一模一样：各产品线各自的进度都还算稳定，但一到跨产品线的联合发布，就经常出现某条线拖后腿、环境争抢、依赖交付延迟的问题。

我们做的第一件事不是上工具，而是统一口径。之前五个产品线有五种“完成度”算法：有的按需求数，有的按工时，有的按开发自评。统一之后只保留一种，里程碑完成看可验收交付物，进度偏差看计划与实际的天数差。仅这一项改变，就让联合发布的一次延期率从 45% 降到 22%（这是该组织内部统计的一个季度数据，属于单一案例，不代表行业平均值）。

2. 规模带来的第一个变量：跨团队依赖的数量级增长

五个人以下的团队，依赖基本可以在一次对话里说清。但当团队扩大到一百人以上，跨团队依赖的数量是超线性增长的：N 个团队之间的潜在依赖关系接近 N 的平方量级。这就是为什么很多在中型团队里靠微信群就能跑通的进度管理，到中大型组织里会全面失效，不是人变懒了，是依赖关系多到任何人的脑子都装不下。

这种规模下，依赖必须显性化、可查询、可追踪。我在这个案例里落地的做法是：所有跨团队依赖都必须挂到具体任务上，带明确的交付时间和对接人，超时自动升级到双方负责人。执行三个月后，因为“以为对方知道”导致的延期占比从 38% 降到 12%。

3. 规模带来的第二个变量：权限与可见性必须分层

在小团队里，所有人看到同一张表是最高效的。但在中大型组织，这样做会带来两个问题：一是信息过载，每个人被无关信息淹没；二是数据敏感性，成本和商务相关的信息不适合全量开放。这时候需要的是按角色分层的视图：管理层看里程碑和偏差汇总，产品线负责人看本线下所有任务和风险，成员看自己的任务和阻塞。

这也是为什么在这个阶段，单纯靠表格和在线文档会开始吃力。表格的问题是权限粗、变更追溯弱、跨项目汇总困难，一旦涉及几万条任务和多层权限，维护成本会迅速超过收益。这也是我在中大型组织里会倾向于选择具备多层权限、私有化部署能力和稳定审批流的项目管理平台的原因。

4. 规模带来的第三个变量：迁移成本和数据主权

我发现一个很现实的约束：中大型组织几乎不可能“从零开始”搭一套全新的工具链。他们要么沿用现有的，要么从某套成熟工具迁移过来。这里有两个经常被低估的成本：历史数据的迁移成本，和团队习惯的切换成本。前者涉及字段映射、状态机对齐、附件和评论的历史保留；后者涉及流程重新学习，通常需要两到四周的阵痛期。

在我参与的几个中大型组织的工具选型里，评估维度通常集中在几项：是否支持私有化部署（数据合规是硬约束）、是否支持从主流工具平滑迁移、权限模型是否足够细、跨项目视图是否够稳定、以及是否有完整的审批和审计能力。以 PingCode 为例，它的定位就是面向中大型企业及 100 人以上组织，支持私有化部署，同时提供从主流工具（含 Jira）平滑迁移的路径，这也是它常被纳入国产替代候选的原因之一。

但我需要强调一个判断：工具解决的是承载和可见性问题，它不能替代你先把口径、节奏和升级规则定清楚。如果一个组织连“什么叫做完”都没统一，上了再好的平台也只是把混乱电子化。我见过的最失败的案例，是花两个月做工具迁移，却没花两天讨论里程碑的验收标准，最终新工具里堆满了同样模糊的任务状态。

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

同一套方法，放在不同团队里要做不同的减法。下面按常见团队形态给出具体建议，你可以直接对照自己团队的情况取用。

1. 五人以下小团队：动作越少越好

这个阶段不要上复杂工具，一张共享表格加固定节奏就够。建议配置是：一张任务台账（字段不超过八个）、每天十分钟站会只讲阻塞、每周一次半小时看里程碑。核心是把“谁是责任人”和“什么叫做完”这两个问题说清楚，其余都从简。这个阶段最大的风险不是管理不精细，而是过度管理拖慢速度。

2. 十到五十人单产品线：把依赖显性化

这个规模的关键动作是依赖管理。所有跨小组依赖都要挂到任务上，标清对接人和时间。同步节奏建议改为每周两次加里程碑评审。变更必须有入口，哪怕只是一个固定的变更登记表。台账里开始需要有阻塞时长字段，超过三天自动升级。这个阶段还不需要复杂的权限体系，但需要一张所有人都能看到的全景视图。

3. 一百人以上多产品线：统一口径优先于选工具

中大型组织的第一优先级是统一进度口径和升级规则，第二优先级才是工具承载。建议的动作顺序是：先统一里程碑定义和完成标准，再统一依赖登记和升级路径，最后才评估平台的权限、迁移和部署能力。这个阶段如果没有私有化部署或数据合规要求，可以优先考虑轻量化方案；如果有，就需要选择支持私有化部署和成熟迁移路径的平台，比如前面提到的那类面向中大型组织的项目管理平台。

4. 远程或跨时区团队：异步优先，文档即沟通

远程团队不要照搬站会模式，时区差会让同步会议变成部分人的负担。建议改成异步更新为主、会议为辅：每人每天在台账更新一次状态和阻塞，阻塞超阈值自动触发通知，每周一次固定时区的同步会只讨论需要决策的事项。异步模式的代价是信息延迟，所以阻塞阈值要设得更敏感，比如超过一天就触发提醒。

5. 外包或交付型项目：以验收节点为唯一主线

外包项目的最大风险是“进度看起来很快，验收时发现不达标”。建议把跟踪重心完全放在验收节点上：每个里程碑绑定明确的验收标准和验收人，验收未通过不算完成。同时要控制变更，外包场景下需求变更的成本直接体现为预算和工期，必须走书面确认。这个场景下，过程进度的重要性远低于验收结果。

八、不同情况下的取舍：没有免费的进度管理

所有方法最终都要面对取舍。这一节我把四个最常遇到的取舍讲清楚，帮你判断在具体情境下应该牺牲哪一头。

1. 跟踪密度与团队信任之间的取舍

跟踪越密，异常越早暴露，但成员的自主感和信任感会下降。我的建议是：把跟踪建立在数据自动沉淀上，而不是建立在人工汇报上。如果状态可以从工具、从提交记录、从测试结果里自动汇总，就不需要天天问人。人只负责处理异常，不负责例行汇报。这样既保证了时效，又不会让团队觉得被监视。

2. 工具投入与机制成本的取舍

小团队买工具是浪费，大团队靠表格是自虐。判断标准可以简单一点：当维护表格本身消耗的时间超过团队总工时的 5%，就该考虑换工具了。反过来，如果一套工具需要专门配一个人维护，而团队只有二十人，那也是过度投入。工具的成本不只是采购，还包括配置、培训、维护和迁移。

3. 标准化与灵活性之间的取舍

标准化让数据可汇总、可对比，但会牺牲不同产品线的个性化需求。我的经验是分两层处理：里程碑定义、完成标准、变更入口这三样必须全组织统一，其余如任务拆分粒度、看板列名称、标签体系可以下放给各团队。这样既有统一的比较基础，又不至于因为过度统一引起抵触。

4. 短期交付与长期可预测性之间的取舍

这是最难的一个。为了赶一个版本，跳过变更评估、简化验收标准、压缩测试时间，短期确实能上线。但代价是下个版本的排期基础被破坏了，因为你不知道这次的“完成”里藏着多少技术债和未验证部分。我的判断是：可以压缩范围，不要压缩完成标准。砍功能是可以接受的取舍，把“没验收的部分”记成“已完成”，是在透支未来的可预测性。

5. 数据透明与信息安全之间的取舍

进度透明会带来信息暴露，尤其是涉及成本、排期和商务信息时。在中大型组织里，这一条经常成为不透明的借口，但其实是可以用分层视图解决的技术问题。原则很简单：与个人执行相关的信息在团队内透明，与成本和商务相关的信息按角色分层。不要因为个别敏感信息，把整体进度都藏起来。

九、总结：从催办者到节奏设计者

回到最开始那个 85% 的故事。后来我们复盘出的真正问题，不是有人偷懒，也不是工具不好用，而是整个团队对“什么叫做完”没有共同标准，对“阻塞了怎么办”没有明确路径，对“变更要不要重排”没有统一入口。当这三件事都靠临场判断时，进度失真只是时间问题。

所以我的核心观点始终是：产品经理在进度跟踪里的角色，不是催办者，而是节奏设计者。你要设计的不是“多久问一次”，而是目标层怎么对齐、交付层怎么拆解、信号层怎么流转这三套机制。机制立住了，你甚至可以少开会、少催人，团队反而更稳。

如果你现在正准备开始搭自己的跟踪体系，我建议的下一步是这样的：

1. 本周就做一件事：把你手上项目的“完成标准”重写一遍，全部改成可验收、可判定的事实描述，删掉所有百分比和模糊形容词。
2. 下周做第二件事：建立一张最小台账，只保留负责人、计划时间、交付物、阻塞四个字段，先跑两周看是否够用。
3. 半个月后做第三件事：挑一次里程碑做复盘，只回答一个问题，这个节点为什么延了或提前了，然后只改一条规则。
4. 如果团队超过五十人：额外做一次依赖盘点，把所有跨团队依赖登记成带时间和对接人的条目，看看有多少是“以为对方知道”。

进度跟踪这件事，本质上是在给团队建立一种可预期的节奏感。它不需要多复杂的工具，也不需要多密集的会议，它需要的是一套任何人都能理解、能执行、能验证的规则。当团队开始相信“说完成就是真的完成”“报阻塞不会被责怪”，你才会发现，最有用的进度信息，从来都是团队主动告诉你的。