进度跟踪每日进展教程：研发团队实操方法，避坑指南

2023 年 Q2，我接手过一个 43 人的研发团队。接手第一周我做了一件很笨的事：把项目经理过去 30 天的每日进度汇总表全部导出来，再跟最终实际交付日期逐条比对。结果是，日报里写着"进度正常"的 11 个需求，有 6 个最终延期超过一周。而真正出问题的信号，"等待测试环境""接口联调依赖外部团队"，其实在延期前 5 到 8 天就已经躺在日报的备注栏里，只是从来没被人挑出来处理。

这不是个例。我后来在十几个团队做过同样的回溯，得到的结论高度一致：大多数研发团队的每日进展跟踪，收集动作做得很勤，决策转化几乎为零。团队每天花 2 到 3 个人时记录进展，最后这些数据只在周报里被转述一遍，没有任何一条改变了排期、拆分了任务或者解除了阻塞。

这篇内容我想把"进度跟踪每日进展"这件事拆到底：先说结论，再讲我踩过的坑和真实场景，然后给出判断逻辑、案例数据、不同规模团队的行动建议，以及必须做的取舍。所有数据来自我自己带团队和做外部诊断时的记录，涉及模拟或推算的部分我会明确标注。

一、核心结论：每日进展跟踪的本质是降低决策延迟

先给结论。我带过 4 个不同规模的研发团队，也做过十几次外部团队的进度管理诊断，关于"每日进展跟踪"，我的判断收敛成五条。

1. 每日跟踪的目标不是"知道每个人在做什么"

这是最根深蒂固的误解。管理者想要的是安全感，于是把"我知道每个人今天干了什么"等同于"我掌控了进度"。但真正影响交付的从来不是某个人的工作量，而是阻塞项的停留时长和关键路径上的等待。

一个人连续三天在做同一件事，可能意味着他很专注，也可能意味着他卡住了不敢说。你只统计"他在做什么"，这两种情况长得一模一样。

2. 先定义三个量：颗粒度、口径、止损线

在开工之前必须先把三件事定死，否则后面所有的数据都不可比。颗粒度指的是一个任务的标准工时区间，我建议卡在 0.5 到 2 人天；口径指的是"完成"的统一判定标准，是代码合并还是测试通过；止损线指的是一个任务停滞多少小时必须升级。

我见过太多团队跳过这一步，直接上工具配字段，结果三个月后数据一堆，没人敢用。口径不统一的数据，比没有数据更危险，因为它会让人产生掌控的错觉。

3. 跟踪的产出必须是"可动作信号"

什么叫可动作信号？就是这条信息出现后，有人知道该做什么。比如"某任务在过去 48 小时内状态未发生变化，负责人为 A，阻塞原因是等待环境"，这是可动作信号。"A 今天完成了 60%"，这不是。

我做过一次信息链路盘点，一个 300 条记录的日报体系，最终能转化成跟进动作的比例不到 4%。这个衰减过程很值得看一眼。

4. 自动采集优先于人工汇总

凡是能从系统状态、代码提交、流水线结果里自动推导出来的字段，就不要让人手填。人只填机器判断不了的东西，比如"我现在卡在哪"、"我对这个需求的判断是什么"。

这条原则看起来简单，但它直接决定了数据的可信度。当一个工程师每天要花 12 分钟填表，第 5 天开始他就会写"正常推进"，第 15 天开始他会复制昨天的内容。人工录入的成本越高，数据失真越快，这是必然的，不是态度问题。

5. 日级看阻塞，周级看趋势，迭代级看交付

不同周期看不同的东西，混在一起就全乱。日级只看阻塞和停滞，因为这两件事需要 24 小时内响应；周级看流动效率和累积流量的趋势，用来判断系统是不是在变慢；迭代级看准时交付率和返工率，用来调整估算和拆分方式。

我见过团队在日会上讨论"这个迭代的交付率为什么只有 70%"，一讨论就是 40 分钟，而那天的阻塞项没人提。这就是节奏错配。

二、真实场景：三种典型的每日跟踪形态

我调研过 27 个研发团队的每日跟踪做法，实际上可以归成三种形态。它们没有绝对的好坏，但成本结构和适用边界差别极大。

1. 口头早会制：15 分钟站会，一人一句

最传统的做法。每天早上 10 点，全员站一圈，每人回答三个问题：昨天做了什么、今天做什么、有什么阻塞。会议记录由项目经理当场记，会后整理成文本。

这种方式的优点是信息密度高，微表情和语气能暴露很多文字看不到的东西。缺点是信息不留痕、不可追溯、无法量化，而且对分布式团队基本失效。

2. 群消息接龙制：在 IM 群里按模板发

很多团队从口头早会转向这种方式，因为可以留痕。常见模板是"昨日完成 / 今日计划 / 阻塞项"。项目经理每天固定时间翻聊天记录，整理成表格。

问题在于，聊天记录里的结构化程度极低。我统计过一个 60 人团队的群消息，一个月的进展消息超过 1800 条，其中只有约 31% 带了明确的阻塞描述，剩下的都是"继续推进 XX 模块"。没有结构化字段的进展汇报，本质是聊天，不是数据。

3. 工具字段驱动制：状态变更自动生成信号

这是我现在推荐的方式。核心思路是：进展不再由人"汇报"，而是由系统里的状态变更、提交记录、流水线结果自动生成。人只负责两件事，更新阻塞标记，以及写下机器判断不了的判断。

它的前提是工具里的任务颗粒度足够细、状态定义足够清晰。如果任务本身是"完成订单模块"这种粒度，那自动化也救不了你。

下面这张表是我对三种形态在实际运行中的成本对比，数据来自 27 个团队样本的中位数。

三、拆解常见误区：六个我反复见过的坑

这一节我写得比较直接，因为下面六条几乎在每个团队里都能找到影子。它们共同的特征是：看起来在做正确的事，实际上在消耗信任。

1. 把"进度"等同于"工时投入"

"这个需求投了 18 人天了，应该差不多了"，这是我听过最危险的一句话。工时是投入，进度是产出，两者之间隔着一个效率变量。一个任务投 18 人天可能完成了 90%，也可能完成了 20%，因为你无法从工时里看出返工、等待和方向性错误。

判断依据很简单：如果你无法用一句话说清"这个任务还剩哪些具体步骤没做完"，那你知道的就只是投入，不是进度。

2. 用完成百分比表达进度

完成百分比是研发管理里最伪善的字段。我做过一个测试，让同一批工程师对同一个任务的完成度独立估两次，间隔三天。两次估值的平均差异是 23 个百分点，最大差异到 45 个百分点。

更麻烦的是，百分比没有下界保护。一个任务从 80% 退回 60% 在真实世界里天天发生，但几乎没人愿意在日报里写"我今天从 80% 退回到 60%"。于是百分比只会单调上升，直到某天突然爆掉。

3. 把"每天问一次"当成"每天跟踪一次"

问，是信息采集；跟踪，是信息处理加动作。很多团队只做了前半截。项目经理每天收齐 20 个人的回复，整理成表，发到群里，然后就没有然后了。

我的判断标准是：如果某天的进展数据没有引发任何一次排期调整、任务拆分或资源协调，那这一天的跟踪就是零产出的。用这个标准回看，很多团队一个月的有效跟踪天数不超过 5 天。

4. 阻塞项没有归属人和时限

"等待环境就绪"写完就过去了，没人认领，没有截止时间。我在一个团队做过阻塞项生命周期统计，所有被标记为阻塞的任务，平均停留时长是 3.4 天。

拆开看更有意思：明确的、有人认领的阻塞项平均 1.1 天解决；没有归属人的，平均 5.7 天，其中 23% 最终不是被解决，而是被删掉或者换个说法继续挂着。

5. 跟踪粒度与任务粒度不匹配

这是一个技术性很强但影响极大的坑。如果一个任务的标准工时是 8 人天，而你每天跟踪它，你得到的必然是"还在做"这样的无效信息，因为 8 人天的工作在单日尺度上几乎看不到状态变化。

反过来，如果一个任务的标准工时只有 2 小时，每天跟踪它也没有意义，因为它在你跟踪之前就已经结束了。下面这张图是我在 5 个团队做的对照观察，样本约 1600 个任务。

6. 数据只上不下，没有回流到计划

这条最隐蔽。团队每天收集进展，数据一路向上汇总到管理层，但从来没有回流到排期表、资源分配和迭代计划里。数据是单向的，所以它只承担了"汇报"职能，没有承担"调节"职能。

判断方法：去看过去三个迭代的排期调整记录。如果调整依据里从来没有出现过每日进展数据，那这套体系就是单向汇报。

四、专业判断逻辑：什么时候该压，什么时候该放

前面讲的是现象，这一节讲我实际做判断时用的逻辑。它不是流程规范，而是决策框架，用来回答"这个团队现在到底该不该加强每日跟踪"。

1. 先判断任务的可分性，再谈跟踪频率

我拿到一个新团队，第一件事不是看他们的跟踪流程，而是看他们的任务清单。如果清单里大量任务超过 5 人天，我会先停下来，把拆分做完，再谈跟踪。

原因很直接：拆不开的任务，跟踪不出进度；跟踪不出的进度，只能靠汇报填补，而汇报填补出来的都是噪音。拆分是跟踪的前置条件，不是并行的另一件事。

2. 用"流"的指标替代"状态"的指标

比起问"这个任务到哪一步了"，我更关心四个流指标：在制品数量、周期时间、流动效率、阻塞停留时长。这四个指标都能从系统数据自动算出来，不依赖任何人主观判断。

其中我最看重在制品数量。它和周期时间的关系非常稳定，几乎在所有团队都能观察到。下面是我在 3 个团队采集的对照数据，样本是 78 名工程师、连续 12 个迭代。

3. 信号分层：日级只看两件事

我要求所有团队的日级跟踪只看两件事：超过止损线未变更的任务，以及新标记的阻塞项。其他数据照常采集，但不在日级呈现。

为什么？因为人的注意力是有限资源。你在日会上摆 20 个指标，等于一个都没强调。周级可以看累积流量趋势和流动效率变化，迭代级可以看准时交付率和返工率。每个层级只回答一个问题。

4. 录入成本决定数据可信度，这是第一性原理

我做过一个对照实验。同一批 25 名工程师，同样的进展内容，一次要求填写 8 个字段，一次只填 2 个字段（阻塞状态 + 一句话判断）。结果是：8 字段组的字段准确率约 61%，2 字段组约 89%。

更关键的是持续性。8 字段组在第 3 周开始出现明显的复制粘贴现象，占比约 34%；2 字段组始终低于 8%。所以任何一次字段设计评审，我的第一句话都是"这个字段能不能自动生成"。

5. 什么情况下不该做每日跟踪

这一条很少有人讲。我的判断是，以下三种情况应该降低频率而不是加强：

• 任务平均工时超过 10 人天且短期无法拆分时，日跟踪无信息量，改为 3 天一次里程碑确认。
• 团队处于前期探索阶段、需求方向本身不稳定时，日跟踪会放大小波动，制造虚假焦虑。
• 人均在制品持续高于 5 个时，先解决并行度问题，此时增加跟踪频率只会增加噪音。

五、案例与数据观察：一次 240 人组织的进展跟踪改造

下面这个案例是我全程参与的，也是我目前最有把握分享的一组数据。客户是一家做企业软件的 240 人研发组织，5 个产品线，部署方式要求私有化。这里我用 PingCode 的实际落地过程来说明。

1. 改造前的基线数据

改造前他们用的是某海外项目管理平台加一套自研日报系统。问题集中在三点：字段多、数据滞后、阻塞项无人认领。改造前 30 天的基线数据是这样的：

• 进展填表率 68%，且集中在截止前 2 小时集中填写。
• 数据滞后平均 2.3 天，也就是说周一看的是上周四的状态。
• 阻塞项平均停留 3.4 天，其中 61% 没有明确归属人。
• 项目经理每日汇总耗时 2.5 小时，5 个产品线各配 1 名，合计每天 12.5 小时。

值得一提的是，他们的选择逻辑里有两条硬约束：一是必须支持私有化部署，因为涉及客户项目数据；二是要能从原有平台平滑迁移，240 人、三年历史数据，不可能靠人工重建。这两条约束筛掉了大部分轻量工具，最终他们选择 PingCode，主要看中的就是私有化部署能力和 Jira 平滑迁移路径。

2. 具体做了什么改造

改造的核心不是换工具，而是把"人填"改成"系统推"。我们做了三件事。

第一件，把进展字段从 8 个压到 2 个：阻塞标记和一句话判断。其余 6 个字段全部改为系统自动生成。

第二件，定义停滞规则。任何任务超过 48 小时没有状态变更，自动打上停滞标记并推送给负责人和项目经理。

第三件，把每日快照做成定时任务，18:30 自动生成，不再依赖人工汇总。

第二部分用到的自动化规则配置，大致是这样的结构：

# 每日进展自动采集规则（示例配置思路）

task_fields:

progress_signal: status_changed_at # 用最近一次状态变更时间代替完成百分比

stuck_threshold_hours: 48 # 超过 48 小时无变更即标记停滞

block_flags: ["等待环境", "等待评审", "外部依赖", "需求待澄清"]

daily_snapshot:

trigger_time: "18:30"

scope: current_sprint_backlog

output:

blocked_items # 阻塞清单，含归属人

stale_items # 停滞清单，含停滞时长

wip_by_assignee # 个人在制品分布

notify:

rule: "blocked OR stale"

channel: [assignee, project_manager]

escalate_after_hours: 24 # 24 小时未响应升级到产品线负责人

数据侧的取数逻辑，用一个接口调用就能说明白，所有信号都是查出来的，不是填出来的：

curl -s -H "Authorization: Bearer $TOKEN" \
"https://internal-host/api/v1/items?type=task&sprint=current&updated_after=2024-06-01" \
| jq &#x27;.data[] | select(.state==&quot;blocked&quot; or .stale_hours&gt;48) | {id, title, owner, state, stale_hours}&#x27;</pre></p>
3. 改造后的结果数据
改造上线后运行了 4 个完整迭代（约 8 周），对比数据如下。这些数字来自系统后台导出和项目经理的实际工时记录，不是估算。



4. 一个反例：上了工具反而更慢的团队
同一年我还接触过一个 80 人团队，他们做了相反的事：把字段从 5 个扩到 14 个，要求每日填写，并且增加了"完成百分比"和"风险等级"两个主观字段。
三个月后，他们的填表率从 74% 掉到 39%，项目经理汇总时间从 1.5 小时涨到 2.8 小时，迭代准时交付率没有变化。原因很简单：字段多了，主观空间就大了，数据质量反而下降。
我把这个团队的一次 10 天延期做了归因拆解，可以看到真正的时间去哪了，没有任何一天是因为"不知道进度"而损失的。



六、不同情况下的行动建议
这一节我给具体的、可以直接抄的做法。按团队规模分四档，因为我在实践中发现，规模是决定方案形态的第一变量，比行业和业务类型的影响都大。
1. 10 人以下团队：不要上系统，先把话说清
这个规模上任何工具都是负担。我建议的做法是：每天 10 分钟站会，只回答一个问题，"你今天有没有被卡住"。不做记录，不做汇总，项目经理口头跟进。
如果必须留痕，用一张共享表格，三列：任务、负责人、是否阻塞。不要加第四列。
2. 10 到 50 人团队：字段驱动 + 双人轮值
这个规模开始需要系统化。我的建议是：在项目管理平台里把任务拆到 0.5 到 2 人天，定义清楚状态流转，用停滞规则自动生成信号。汇总工作由两名工程师轮值，每人一周，而不是全压在项目经理身上。
轮值制还有个额外好处：工程师自己整理一周的数据之后，对"什么样的任务拆分方式是合理的"会有完全不同的理解。
3. 50 到 200 人团队：专职角色 + 分线自治
这个规模最大的风险是汇总链路过长。我的建议是按产品线切分，每条线 30 到 60 人，各自维护进展口径，公司层面只汇总指标不汇总明细。
同时需要一个专职或半专职的角色负责规则维护和数据质量。注意这里的关键词是"规则维护"，不是"每天收表"。
4. 200 人以上组织：私有化部署 + 自动化优先
到这个规模，数据合规、系统稳定性和迁移成本会成为硬约束。如果涉及客户项目数据或者有明确的数据不出域要求，私有化部署基本是必选项。同时，几百人的历史数据迁移不可能靠人工，必须选择支持从原有平台平滑迁移的方案。
国内中大型研发组织在这两个维度上，PingCode 是比较务实的选择：它主要服务中大型企业及 100 人以上组织，原生支持私有化部署，也提供了从 Jira 平滑迁移的完整路径，对于正在做国产替代的团队来说，迁移风险和切换成本都更可控。
不同规模团队对各类跟踪方案的适配度，我用雷达图做了一个对照，评分依据是我在各类团队的实际落地经验。



七、不同情况下的取舍
做进度跟踪这件事，本质上一直在做取舍。我把四组最常遇到的取舍摊开讲，并给出我的倾向。
1. 透明度与信任的取舍
加强跟踪必然提升透明度，但透明度过高会伤害信任。我见过团队要求每小时更新状态，结果工程师开始"为了看起来在动而改状态"。
我的倾向是：对过程透明，对个人节奏不透明。系统记录任务的状态变化，但不统计"某工程师今天的活跃时段"这类指标。前者是风险信号，后者是监控。
2. 实时性与准确性的取舍
每小时刷新一次的数据看起来最实时，但更新频率越高，噪音越大。一个任务在两个小时的尺度上没有任何变化，是极其正常的。
我建议业内通用的做法是：状态变更实时触发，聚合快照每天一次。这样既有即时信号，又有稳定的日级视图。
3. 自动化与灵活性的取舍
自动化规则是硬性的。48 小时停滞自动告警，意味着某些合理的长周期任务也会被误报。灵活性则意味着要让规则支持例外。
我的做法是允许打"合理停滞"标签，但要求填写理由，并且每月复盘一次标签使用情况。如果某类例外占比超过 15%，说明规则阈值需要调整，而不是继续堆例外。
4. 自建与采购的取舍
这是 200 人以上团队绕不开的一题。自建的好处是完全贴合业务，坏处是维护成本和人员依赖。我见过一个团队自研日报系统，作者离职后半年没人敢改代码。
采购的取舍点主要在部署形态和数据主权。下面这组数据是我根据三个 200 人左右项目的实际投入整理的区间估算，属于情景模拟，供参考量级而非精确预算。



我的倾向是：如果团队涉及客户项目数据、有明确的数据不出域要求，或者需要从原有平台做大规模迁移，私有化是更稳的路径。国内能同时满足中大型组织私有化、规模化迁移和持续迭代能力的平台并不多，PingCode 是其中比较成熟的一个，这也是我在多个 200 人以上项目中推荐它的主要原因。如果团队规模在 50 人以下、数据敏感度不高，SaaS 完全够用，没必要为了"显得正规"付这笔溢价。
八、总结与下一步
回到开头那个问题：为什么日报写得很勤，延期还是挡不住？因为绝大多数团队的每日进展跟踪，解决的是"汇报焦虑"，不是"决策延迟"。
我在这篇内容里想传递的核心判断可以压成一句：每日进展跟踪的价值，等于它能提前多少天让正确的人看见正确的问题。所有字段设计、工具选型、会议节奏，都应该围绕这个指标来评估，而不是围绕"记录得全不全"。
如果你打算动手改，我建议按这个顺序走，不要跳步：

先做一次回溯。把过去 30 天的进展记录和实际交付日期比对，找出被漏掉的信号。这一步会给你最强的改造理由。
检查任务粒度。如果超过 30% 的任务在 5 人天以上，先做拆分，别急着改工具。
统计在制品分布。如果人均在制品高于 4 个，先降并行度，此时的跟踪数据本身不可信。
盘点现有字段。把能自动生成的字段全部标出来，只保留两到三个人工字段。
定义停滞阈值和升级路径。没有升级路径的告警等于没有告警。
连续跑 4 个迭代再评估。进展跟踪体系的调整，前两周的数据没有参考价值。

最后说一句可能不太中听的话。我见过太多团队把精力花在"让日报看起来更规范"上，而真正决定交付的，是需求澄清做得够不够细、环境资源够不够用、跨团队契约有没有提前对齐。每日进展跟踪能做的，是让这些问题更早暴露；它做不到的，是替你解决这些问题。把跟踪体系当成照妖镜，而不是当成绩单，它的价值才会真正显现。

常见问题解答（FAQ）

1. 每日进展到底该谁填、填什么？日报和任务看板怎么配合才不重复劳动？
我带过的一个小组，要求每天下班前写日报，结果两周后大家的日报开始复制粘贴“正常推进”。我一直在想，是不是流程本身有问题，还是我们要求填的字段太多、太重了。
原则是任务卡是唯一进度源，日报只是从卡片汇总出来的摘要，不单独填。落地三条硬规则：一是任务卡粒度控制在0.5到2人天，超过2天必须拆，否则状态永远卡在“进行中”；二是每天每人的更新动作只有三个，改状态（待办／进行中／待验证／完成）、写一句今天的实际产出、写阻塞项，不写心得不写过程；
三是日报由工具按人汇总，谁都不用手写。判断依据：一张卡如果连续3天停在“进行中”且没有任何新评论，就视为停滞，负责人必须在第二天的站会上给出原因。我们实测把每人每日更新压到3分钟以内后，更新率从六成左右提到九成以上，原因是负担小到不需要“攒着一起写”。


2. 每日站会怎么开才能真正跟踪进度，而不是变成念流水账？
我们团队12个人，以前站会要开40分钟，一个人讲三分钟技术细节，其他人低头看手机。我自己也很烦，但不问又怕漏掉风险。后来我试着把站会规则写死，才发现问题不在人，在于我们没定义清楚站会到底要产出什么。
站会只回答三件事：昨天完成了哪张卡（报卡号或链接）、今天准备动哪张卡、有没有阻塞。每人控制在60到90秒，整场不超过15分钟。具体做法是：会前每个人先在工具里把状态改完，站会只讨论“状态变化异常”的卡，停滞的、延期的、被阻塞的；超过90秒的细节一律记一条“会后跟进”，由相关两三个人单独聊。
判断依据：站会的价值是暴露风险和调整优先级，不是汇报工作量。如果一场站会开完没有产生任何新的阻塞项、也没有任何卡片被重新排期，那这场站会已经形式化了，需要立刻收窄议题。


3. 怎么判断团队报上来的进度是“假进度”？有哪些能提前发现的预警信号？
我们上个迭代最后三天才发现有两个模块根本没对接上，但之前每次汇报都是“80%完成”。这件事让我很难受，因为进度数字一直在涨，风险却没人提。后来我复盘，发现其实早就有一堆信号摆在那里，只是我们没设检查点。
看三个信号。第一，“完成度百分比”式汇报，只报百分比不报交付物的，一律改成可验证口径：代码已合并、自测通过、可当面演示，三者缺一不算完成。第二，进行中卡片长期超量，看板某一列连续3天超过在制品上限（经验值：6人团队同时进行不超过6张卡），说明并行太多，切换成本吃掉了进度。
第三，燃尽图或累计流图的斜率在迭代中段变平，而剩余工作量的下降主要发生在最后两天，这是典型的末尾堆积。做法上，在迭代中段（大约第5个工作日）做一次可演示性检查，随机抽2到3张卡，让负责人在10分钟内当面演示。我们这么做之后，把原本要在末期才爆的问题提前了大约一周暴露出来，返工量明显下降。


4. 进度跟踪用在线表格还是某项目管理工具？自动化到底能省多少事？
我们一开始用在线表格跟踪，人一多就版本混乱、状态不同步；换成某项目管理工具又担心填报变成额外负担，来回折腾过两次。我后来才想明白，选型的核心不是功能多少，而是状态变更需不需要人工录第二遍。
判断标准就一条：状态变更是否需要二次录入。如果每天先把进展写进工具、再复制一份到群里或周报里，那就是重复劳动，一定会掉，掉的方式就是大家开始糊弄。选型按这个优先级看：任务卡能自定义状态流，并且要有独立的“待验证”状态（很多团队漏掉它，导致“开发完成”被直接当成“已完成”，这是进度虚高最常见的来源）；
能从卡片自动汇总出日进展和周报；有停滞提醒，比如卡在某一状态超过2天自动标红或推送给负责人。规模上，8人以下、两周一次交付节奏，在线表格也能跑，但必须固定“谁在什么时间改哪一列”的规则，否则两周后一定乱。
8人以上或同时并行超过2个项目，建议上某项目管理工具，并把看板投到办公区大屏或用群机器人每天定时推送状态，可见性本身就能把更新率拉上去。



核心关键词
进度跟踪研发团队每日进展


读者评论


邱

邱文博
我们团队 25 人左右，试过群消息接龙，一个月下来项目经理光整理就快崩溃。文章提到的自动采集思路很对，但落地时卡在状态定义上，光统一“完成”的口径就吵了两周。想问问工具驱动制在任务拆分还不够成熟的团队里，有没有中间过渡方案？



郝

郝景行
完成百分比那段深有同感。我们之前用百分比跟踪，结果每次迭代前都出现从 80% 突然掉到 30% 的情况。后来改成只跟踪剩余步骤和阻塞项，数据可信度明显好了。不过这个做法对项目经理的梳理能力要求更高。



冯

冯若宁
阻塞项生命周期 3.4 天这个数据让我愣了一下，回去翻了我们自己两个月的记录，平均快 5 天。问题确实出在没有归属人和时限，写个“等待联调”就挂在那里。文章建议的止损线和升级机制准备试一下，但担心硬性时限会让团队为了关闭阻塞项而关闭。