我带过四个产品团队，也以顾问身份看过十几家公司的研发过程。有一个数字我自己都觉得刺眼：在这十几年里，真正因为技术难度导致项目延期的情况，在我记录过的延期案例里占比不到两成，剩下八成以上都是进度信息本身出了问题，没人知道真实状态，或者知道的人没说出来，或者说出来之后没人处理。换句话说，大多数"进度跟踪"根本没在跟踪进度，只是在跟踪大家愿意写的状态。
这篇文章不讲甘特图怎么画、燃尽图怎么读，也不列十款工具。我想聊的是一套能落地的进度跟踪操作系统：产品经理到底该跟踪什么、用哪几个指标衡量、指标口径怎么定、异常怎么升级、不同规模的团队该怎么取舍。所有公式和阈值都标注了来源性质，你可以直接拿走改成自己团队的版本。
一、先说结论：进度跟踪失效，很少是工具问题
1. 一个反常识观察
很多团队把进度跟踪做不好归因于"工具不行"，于是换了三轮项目管理软件，问题依旧。我自己的观察是：工具解决的只是"信息放在哪"，而进度失控的根因是"信息该由谁在什么时间更新、异常由谁在多长时间内响应"这两件事没有规范。
下面这组数据来自我个人带团队和做咨询时对 23 个延期案例的记录（属于经验样本，不是行业统计），它说明的是"失控信号从出现到被正式识别"之间的滞后天数。滞后越久，补救成本越高，这一点在所有案例里都成立。
2. 结论一：把"催办"换成"暴露不确定性"
产品经理最常见的动作是催：今天问一句"怎么样了"，明天在群里 @ 一下。催办能带来短期的心理压力，但它不产生结构化信息，你得到的回答永远是"快好了""差不多了"。
我后来给自己定了一条硬规矩：每次跟进的产出必须是可记录的状态变化，而不是一句感受。比如"接口联调从待开始变成进行中""阻塞项从 L2 升级为 L3""验收标准补充了三条"。如果一次沟通没有产生这类可记录的变化，那这次沟通就是无效的。
3. 结论二：指标不是越多越好，5 到 8 个是甜点区
我见过一个团队在仪表盘上放了 27 个指标，结果没人看。原因很简单：指标越多，每个指标被解读的深度就越浅。当 27 个数字同时出现，人脑会自动退化成"看颜色"，红色焦虑一下，绿色就跳过。
我的经验区间是 5 到 8 个核心指标，其中至少 2 个必须是风险类或阻塞类指标。因为进度类指标告诉你"现在到哪了"，风险类指标才告诉你"接下来会不会出事"。只报进度的团队，永远在事后救火。
4. 结论三：规范的核心是升级路径，不是表格格式
很多团队花了大量时间统一周报模板、看板配色、字段命名，但没人定义过"什么情况下必须向上升级"。结果是：看板很漂亮，问题依然烂在个人手里。
判断一套跟踪规范是否合格，我只看一个标准：一个新人加入团队，能否在 10 分钟内说出"我遇到阻塞时，应该在多久内告诉谁"。说不出来，说明规范只是装饰。
二、真实场景：进度是怎么一步步失控的
1. 场景 A：需求在群里"完成"了
这是我最常遇到的一种。产品经理在群里问"这个改动好了吗"，开发回"好了"，产品经理回个"👍"，然后这条需求就消失了。没人更新状态，没人验证，没人记录。
等到两周后要发版，才发现这个改动只改了前端，后端接口还是老的。这时离发版只剩三天，只能加急或者砍范围。整个链条上没有任何一个环节是"坏人"，但结果就是失控。问题出在：口头确认没有被强制转换成状态流转。
2. 场景 B：周报全绿，上线延期三周
有个团队连续六周周报都是绿色，第七周突然宣布延期三周。我当时在做外部顾问，翻他们的周报发现：每周的"进展"栏写的是"按计划推进"，"风险"栏写的是"暂无"。
真实的阻塞其实存在了很久，第三方支付通道的商户号申请卡在对方审核，已经四周。但负责这块的同学认为"这不是技术问题，不好意思提"。风险栏目写"暂无"的次数越多，这个团队的跟踪系统越可疑。
3. 场景 C：阻塞卡了六天没人升级
我复盘过一个延期项目，发现一个接口联调的阻塞从标记到解除花了 9 天，其中前 6 天没有任何升级动作。原因很朴素：负责的开发以为对方在排期，对方以为这件事不急。
这类问题几乎无法通过"加强沟通"解决，因为双方都没有一个明确的响应时限约定。没有时限的阻塞，等于没有阻塞，它在系统里只是一个状态，不是一个需要被处理的信号。
4. 失控的共性：信息流没有唯一事实源
把三个场景放一起看，共性非常清晰：进度信息散落在群聊、口头、个人记忆和过期文档里，没有一个地方是"看这里就够"的。
我后来把这件事总结成一句话：如果一个状态不能在 30 秒内被任意一个干系人查到，那这个状态就等于不存在。这句话后来成了我给团队做跟踪规范时的第一原则。
说明: 该图为示意数据，用于说明为什么进度跟踪必须包含"需求保真"维度，只跟踪任务状态，无法解释"按时上线但做错了"。
三、拆解常见误区：七个让跟踪形同虚设的做法
1. 误区一：把任务完成率当进度
任务完成率是最容易采集也最容易骗人的指标。开发把任务标记为完成，通常代表"我这边写完了"，不代表"能验收"，更不代表"能上线"。我看到过完成率 95%、实际可交付 60% 的迭代。
纠正方式：把"完成"拆成多个明确的状态位，编码完成、自测完成、提测、测试通过、验收通过、上线。每个状态位都有人负责确认，不能由同一人从头标到尾。
2. 误区二：指标堆到二十个以上
指标越多，越容易挑选对自己有利的那个。当一个人可以在一堆数字里选择性地汇报，这套指标体系就已经失去了约束力。
纠正方式：核心指标固定在 5 到 8 个，且必须在季度内保持稳定。想加新指标，先砍掉一个旧指标，逼团队做取舍。
3. 误区三：全靠手工填表
手工填表有两个致命问题：一是耗时，二是失真。我统计过，全手工维护的场景下，一个 12 人团队每周花在填状态上的时间大约是 7 到 9 小时，而数据准确率往往只有七成左右。
只要填报成本和被追责风险挂钩，数据就一定变形。纠正方式是尽可能把状态变更绑定在工作动作上，比如提交代码、流转工单、发起评审时自动记录，而不是让人事后回忆。
4. 误区四：例会变成逐人汇报
我参加过最夸张的一次周会，14 个人，开了 95 分钟，其中 80 分钟是轮流说"我这周做了什么"。会后没有任何决议，没有新增待办。
纠正方式：例会只讨论三件事，当前阻塞、需要决策的事项、对目标的偏差。进度本身应该在会前看完，不占会议时间。
5. 误区五：没有验收标准就开始开发
这是我认为产品经理最该负全责的一条。开发说"做完了"，测试说"不知道算不算对"，产品经理说"感觉不太对"，这种三方都无力的情况，源头是需求提出时没有可判定的验收标准。
我的做法是：任何进入开发的需求，必须有至少三条可验证的验收条件，写不出三条的就不要进排期。这条规则听起来苛刻，但它砍掉的返工远多于砍掉的需求。
6. 误区六：产品经理替团队排期
产品经理排期会带来两个后果：一是排期不真实（因为不了解技术细节），二是责任转移（延期时团队可以说"是你排的"）。
产品经理该做的是定义优先级、边界和验收标准，排期由实际执行方给出，并由其对承诺负责。产品经理对"做对的事"负责，执行团队对"把事做对的时间"负责。这条边界划不清，跟踪永远在打转。
7. 误区七：延期后只调整时间，不调整范围
这是最隐蔽也最伤团队的一条。延期了就把上线日期往后挪，范围一点不动，结果是新一轮延期。
我的原则是：时间、范围、质量三者同时变动时，必须至少锁定一个，并记录是谁在什么时间做的决策。只调时间不调范围，本质是把决策成本转嫁给了未来的自己和用户。
说明: 这张图用来支撑"不要只靠手工填表"的判断，同时说明自动化程度与团队流程成熟度强相关，不能一步到位。
四、专业判断逻辑：产品经理该跟踪什么、不该跟踪什么
1. 先分清四层"进度"
很多人把"进度"当成一个东西，实际上至少可以分成四层，跟踪重点完全不同。
- 项目进度：整体里程碑、关键依赖、资源与预算，通常按周或双周看。
- 迭代进度：一个 Sprint 内的范围完成情况，按天看。
- 需求进度：单个需求从受理到上线再到数据回收的全过程，按状态流转看。
- 任务进度：具体开发任务的完成情况，按小时或天看，这一层产品经理通常不需要直接介入。
我见过最多的错位是：产品经理天天盯任务进度（第四层），却说不清需求进度（第三层）和价值回收（需求上线后的数据）。盯得越细，视野越窄，这是进度跟踪里最普遍的战略性失误。
2. 产品经理对结果负责，项目经理对交付负责
这两个角色的跟踪重点天然不同。项目经理关心"是否按期交付约定的范围"，产品经理关心"交付的东西是否解决了原来的问题"。
所以产品经理的指标体系里，必须有一类指标是项目经理不太会看的：上线后的价值回收指标。比如功能采用率、目标行为转化、客服工单里相关问题的下降幅度。没有这一层，进度跟踪就只是"按时交付了错误的东西"。
3. 需求全生命周期的七个节点
我给团队定义的七个节点是：受理、澄清、设计、开发、验证、上线、复盘。每个节点都有明确的入口条件、出口条件、责任人和可记录的完成证据。
关键在于：节点之间的转移必须是显式的，不能靠"大家都知道了"。我要求每次节点转移都在系统里留下一条记录，哪怕只有一行字。
4. 判断一个指标该不该跟踪的四问
不是所有能采集的指标都值得跟踪。我用四个问题做筛选，四个里有两个答不上来就不加：
- 这个指标变化时，我们会做出什么不同的决策？
- 它的数据来源是自动的，还是需要人工填报？
- 它是否明确指向某一个人的责任范围？
- 它是否会在一个迭代周期内产生可观测的变化？
第 1 问最重要。如果一个指标变化了但没人会因此改变行动，那它就是装饰品。指标的价值不在于被记录，而在于被用来做决定。
五、关键指标字典：七类进度跟踪仪表盘
1. 指标字典怎么定口径
指标最容易出问题的地方不是选错，而是口径不一致。同一个"交付周期"，不同的人算出来的数可能差一倍，原因是起点定义不同，是从需求提出算，还是从评审通过算。
我的做法是给每个指标写一段可执行的口径定义，直接落到数据字段上。下面是一个示例，用来说明"口径定义应该细到什么程度"。所有阈值均为建议值，需要团队自行校准。
— 需求交付周期口径定义（示例，需按团队字段命名调整）
— 起点：需求状态首次变为“已受理”
— 终点：需求状态首次变为“已上线”
— 排除：状态变为“已取消”的需求；中途合并的需求按父需求计算
SELECT
requirement_id,
DATEDIFF('day', accepted_at, released_at) AS lead_time_days,
CASE
WHEN DATEDIFF('day', accepted_at, released_at) <= 14 THEN '健康'
WHEN DATEDIFF('day', accepted_at, released_at) <= 25 THEN '关注'
ELSE '预警'
END AS lead_time_level
FROM requirement_fact
WHERE status != 'cancelled'
AND parent_requirement_id IS NULL;注意最后那个分档逻辑。我不建议直接套用别人的阈值，因为业务复杂度差异太大。更稳妥的做法是先跑一个季度历史数据，取自己的中位数作为基准线，再设置上下浮动区间。
2. 七类指标与采集建议
下面这张表是我实际用过的核心指标集。我一般只从中挑 6 个左右落到看板上，其余作为按需查阅的备选。
| 类别 | 指标 | 示例口径 | 建议频率 | 常见责任方 |
|---|---|---|---|---|
| 进度类 | 里程碑按期达成率 | 按期达成里程碑数 ÷ 计划里程碑数 | 每月 | 项目负责人 |
| 进度类 | 迭代范围完成率 | 已完成并验收的需求点数 ÷ 承诺点数 | 每迭代 | 产品经理 + 研发负责人 |
| 效率类 | 需求交付周期 | 上线时间 − 受理时间（中位数） | 每周 | 产品经理 |
| 效率类 | 研发测试周期 | 提测时间 − 开发启动时间 | 每周 | 研发负责人 |
| 质量类 | 验收一次通过率 | 首次验收通过数 ÷ 提测总数 | 每迭代 | 测试负责人 |
| 质量类 | 缺陷逃逸率 | 上线后发现的缺陷数 ÷ 总缺陷数 | 每月 | 测试负责人 |
| 风险类 | 阻塞项平均滞留时长 | 阻塞解除时间 − 阻塞标记时间 | 每周 | 项目负责人 |
| 风险类 | 依赖满足率 | 按承诺时间满足的外部依赖数 ÷ 总依赖数 | 每迭代 | 产品经理 |
| 协作类 | 跨团队响应时长 | 收到请求到首次实质回复的时间 | 每周 | 各团队负责人 |
| 价值类 | 功能采用率 | 触达目标行为的用户数 ÷ 目标用户数 | 上线后 30 天 | 产品经理 |
| 价值类 | 目标指标达成率 | 实际变化量 ÷ 立项时设定的预期变化量 | 上线后 60 天 | 产品经理 |
| 反馈类 | 用户反馈闭环时长 | 反馈受理时间到给出结论的时间 | 每两周 | 产品经理 |
3. 指标之间的取舍关系
这些指标不是越大越好或越小越好的关系，它们之间存在真实的张力。交付周期缩短，缺陷逃逸率往往上升；验收通过率拉高，可能会拖延上线时间。
没有一组指标可以同时全部最优，管理者的工作就是明确当前阶段优先保哪个、可以牺牲哪个。这个取舍如果不显式说出来，团队就会自行选择，通常选的是最容易达成的那一个。
六、案例观察：90 天把一个"全绿周报"团队拉回来
1. 改造前的基线
这个团队大约 60 人，分四个小组，做的是面向企业的 SaaS 产品。合作开始时，他们的问题是周报全绿但季度目标连续两个季度未达成。
我做的第一件事是拿历史数据算基线：需求交付周期中位数 26 天，阻塞项平均滞留 4.8 天，里程碑按期达成率 58%，周报制作平均每人每周约 40 分钟。注意，这个团队并不懒，他们只是把精力花在了"报告进度"而不是"跟踪风险"上。
2. 第一步：统一字段（第 1 到 3 周）
我们只做了三件事：把需求状态统一成七个节点，把阻塞定义成一个必须标记的独立字段，把每个需求的验收标准设为必填。
这一步的阻力比想象中小。真正难的是让大家理解"为什么验收标准是跟踪的一部分"，因为它决定了提测时能不能判定完成，直接影响返工。
3. 第二步：选出 6 个核心指标（第 4 周）
我们没有一次上全套，只选了六个：需求交付周期中位数、迭代范围完成率、验收一次通过率、阻塞项平均滞留时长、依赖满足率、上线后 30 天功能采用率。
选择逻辑是：前四个用来做过程管控，第五个用来管跨团队协作，第六个用来回答"做完到底有没有用"。六个指标里有两个是结果指标，这是刻意的设计，防止团队只优化过程数字。
4. 第三步：建立分级升级 SOP（第 5 到 6 周）
我们把阻塞分成四级，每一级对应明确的响应时限和升级对象。这一条是整次改造里效果最明显的动作。
- L1 信息类：如文档缺失、口径不清。响应时限 1 个工作日内。
- L2 协作类：如接口未就绪、评审排不上。响应时限 2 个工作日内。
- L3 范围类：如需求冲突、验收标准争议。响应时限 3 个工作日内，需产品经理介入。
- L4 资源类：如人力缺口、外部合规卡点。响应时限 5 个工作日内，需上升到部门负责人。
5. 第四步：改例会结构（第 7 周起）
原来的周会 90 分钟逐人汇报。我们改成 40 分钟，结构固定为三段：超过 48 小时的阻塞项（10 分钟）、需要当场决策的事项（20 分钟）、指标偏差与对策（10 分钟）。
进度本身不再在会上念，会前看板自取。把日报周报从"汇报材料"改成"决策输入"，是会议效率提升最直接的一步。
6. 90 天后的数据
三个月后，上面几个指标都发生了变化。这些数据来自该团队内部系统的统计，属于单一案例，不能外推到所有团队，但方向是清晰的。
7. 这个案例里最反直觉的一点
整个改造过程中，我们几乎没有换工具，只是在原有平台上补充了字段和视图。真正起作用的是规范本身：谁在什么时间更新什么，异常多久内必须升级。
后来他们为了支持私有化部署和更细的权限隔离，把部分项目迁到了 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，是他们当时的国产替代选项之一。但我想强调的是：迁移是改造完成之后的事，不是改造的前提。先有规范，再看工具是否需要换。
七、规范落地四件套：看板、例会、周报、升级
1. 看板列怎么设
我不建议按"待办 / 进行中 / 已完成"三列走。这三列颗粒度太粗，看不出卡在哪。我常用的是七列：待评审、待排期、开发中、阻塞中、待验证、已验证、已上线，另加一个"已复盘"作为归档视图。
其中"阻塞中"必须是独立列，不能靠标签。原因很简单：标签会被忽略，列不会。任何一个进入阻塞列超过约定时限的卡片，都应该自动触发提醒。
2. 例会怎么开
我给的固定结构是四段，总时长控制在 40 分钟内：
- 目标回顾（3 分钟）：本迭代承诺了什么，现在到哪。
- 阻塞处理（12 分钟）：只谈超过 48 小时未解决的阻塞，每个阻塞必须有责任人和截止时间。
- 需决策事项（20 分钟）：当场决策，当场记录。决不了的要明确"谁在什么时候给结论"。
- 偏差对策（5 分钟）：核心指标偏离基线的部分，说明原因和对策。
例会不开成汇报会，关键在会前。会前看板必须更新完毕，否则会议就被迫用来同步信息，讨论时间被吃掉。
3. 周报怎么写
周报最没价值的写法是"本周完成 / 下周计划"。我的模板是五段式，每段都要求有具体信息，不允许写"按计划推进"。
- 里程碑状态：按期 / 有风险 / 已延期，延期必须写原因和影响范围。
- 核心指标变化：只列 6 个指标的本周值和相对基线的偏离方向。
- 阻塞与风险清单：每条带责任人和预计解决时间。
- 需决策事项：写清楚"需要谁在什么时候给出什么决定"。
- 下周关键动作：不超过三条，多了说明没有优先级。
"暂无风险"这四个字，我在评审周报时看到就会追问。一个规模在 50 人以上的团队，一周内完全没有风险，只可能是风险没有被识别出来。
4. 升级机制怎么定
升级机制是整套规范里最容易被跳过、也最关键的一环。它必须回答三个问题：什么情况下升级、升级给谁、多久内必须有响应。
我用的是分级模型，每一级都有明确的超时判定。下面这组数据来自另一个团队的三个月执行记录，展示了分级响应在实践中的表现差异，级别越高，超时率越高，说明高层级阻塞的解决更依赖组织决策而非个人努力。
说明: 这张图用来说明"分级的意义"，如果所有阻塞都按同一时限处理，高层级阻塞必然长期拖尾，低层级阻塞则被过度干预。
八、不同情况下的行动建议
1. 团队 10 人以下
不要上复杂体系。我的建议是只做三件事：一个共享看板（七列可以简化成五列）、一个阻塞标记字段、一次每周 20 分钟的站会。
这个规模下，人不缺信息，缺的是把信息固定下来。小团队最该避免的是照搬大公司的指标体系，那会直接压垮协作节奏。
2. 团队 10 到 50 人
这是最能受益于规范化的区间。建议落地完整七列看板、6 个核心指标、分级升级机制和固定周报模板。
这个规模的特点是：信息开始失真，但还没有正式的项目管理职能。产品经理往往要承担进度跟踪的主要责任，所以指标必须简洁可维护。
3. 团队 50 到 200 人
这个区间需要开始区分角色职责，把过程跟踪交给项目角色，产品经理保留价值类和需求类指标，并把跨团队依赖管理单独拉出来做。
重点要放在依赖满足率和跨团队响应时长上，因为这是这个规模下最大的延期来源。50 人以上的团队，延期大多不是做不完，而是等不到。
4. 团队 200 人以上或多事业部
需要统一指标口径和字段标准，否则跨部门数据无法对齐。这时候工具能力会成为真实约束，需要考虑权限隔离、数据分层和私有化部署能力。
在这个量级上，像 PingCode 这类主要服务中大型企业及 100 人以上组织的平台会更合适，因为它支持私有化部署，对数据合规和权限分级的要求更容易满足。但选型前的第一步仍然是先定义口径，否则只是把混乱搬到了新系统里。
5. 正在从其他工具迁移的团队
我的强烈建议：不要把迁移和流程改造放在同一时间做。两件事同时进行，出问题时你无法判断是规则错了还是系统没配对。
正确顺序是先在新流程上手工跑一到两个迭代，把字段、状态、口径确认清楚，再做数据迁移。如果团队此前长期使用 Jira，选择支持 Jira 平滑迁移的平台能显著降低字段映射和权限重建的成本，PingCode 在这方面的支持是它被不少团队选作国产替代方案的原因之一。
九、取舍：精度、成本与团队自治之间的平衡
1. 跟踪精度与管理成本
跟踪越精细，成本越高。让开发每天更新任务剩余工时，理论上能提高预测精度，实际往往换来敷衍填报和信任损耗。
我的取舍原则是：精度只加在决策会用到的地方。如果团队不会因为剩余工时改变任何决策，那就不要采集它。这条原则帮我砍掉过很多看似专业、实际无用的字段。
2. 指标统一与团队差异
统一口径让数据可比，但不同业务线的节奏差异是真实存在的。B 端企业服务的交付周期天然比 C 端功能迭代长，硬拉齐会逼出造假。
我的做法是：指标定义统一，阈值分线设定。比如交付周期都用同一个起点和终点定义，但各业务线各自设自己的基线区间，并公开说明为什么不同。
3. 自动化与可见性
自动化程度越高，数据越准，但团队对进度的"体感"可能越弱。有团队上了全自动看板之后，成员反而说不清楚自己这块的进度，因为一切都被系统消化掉了。
平衡方式是在自动化之上保留一层人工确认：比如每周固定一次 15 分钟的小组同步，只讨论"系统显示的状态和你实际感受是否一致"。自动化负责准确，人工负责共识，两者不能互相替代。
4. 强控制与团队自治
强控制的跟踪体系能在短期内压出执行力，但长期会抑制主动上报。团队会学会只报安全的信息，风险反而更隐蔽。
我倾向于把跟踪强度分层：过程节点强约束（状态必须更新），风险上报弱惩罚（越早报越好），结果评价宽周期（不看单周波动）。让上报风险变成一件安全的事，是整个体系能不能跑起来的前提。
十、下一步：今天就能动起来的五件事
1. 把"完成"这个词从团队词汇里删掉
从今天起，任何需求都不再回答"做完了吗"。改成回答"现在在哪个状态"。这一步不需要工具支持，只需要一次团队约定，但它是整套体系的起点。
2. 给阻塞加一个必填字段
在现有工具里加一个字段，不要标签：是否阻塞、阻塞原因、阻塞开始时间、解除时间。就这四项。一个月后回看这四条数据，你会比过去一年的周报更了解团队的真实瓶颈。
3. 选 6 个指标，写清口径
参考第五节的表格，先选 6 个，其中至少包含一个风险类和一个价值类。每个指标写清楚起点、终点、排除条件和数据来源，落到字段级别，不要停留在概念描述。
4. 定一条升级规则，只定一条
如果暂时没精力做分级，就先定一条：任何阻塞超过 48 小时未解决，必须由产品经理在当天上报到负责人，并给出预期解决时间。先跑通一条，比设计一套完美的四级机制更有用。
5. 下个迭代复盘时只问一个问题
不问"为什么延期"，而问"哪个信号如果我们早三天看到，结果会不一样"。这个问题会自然地把团队从追责导向拉到信号识别导向上，而这正是进度跟踪真正要解决的问题。
最后说一句我的核心判断：产品经理的进度跟踪能力，不体现在你能多快知道延期，而体现在你能多早看到延期的原因。指标、规范、升级机制，本质上都是为了让那个"早"字变得可操作。至于工具，永远放在规范之后考虑，它是放大器，不是发动机。
常见问题解答（FAQ）
核心关键词
文章包含AI辅助创作：跟踪流程与规范：产品经理进度跟踪最佳实践关键指标，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/471242
读者评论
周报全绿、风险栏永远“暂无”太真实了。我们也是上线前才发现第三方审核卡了四周。问题不在工具，而在没人定义阻塞多久必须升级给谁。
把任务完成率当进度确实容易骗人。开发标记完成只代表写完了，不代表能验收。我们后来拆成编码、自测、提测、测试通过、验收通过，可交付率才看得清。
产品经理替团队排期这条很扎心。排期不是PM拍脑袋，应该由执行方给承诺。PM定优先级、边界和验收标准，否则延期时责任一定扯不清。
半自动采集比全手工靠谱。以前周会逐人问进度，数据还滞后。把状态绑定工单流转和代码提交后，会前看板就能看完，周会只聊阻塞和决策。