很多项目进度跟踪之所以失效，不是因为成员不勤快，而是因为「跟踪」这件事被拆得太碎了：站会上说一句"差不多了"，看板拖到"进行中"，周报里写"按计划推进"，结果到了交付前一周才发现，真正卡住的接口联调已经停了六天，而没有任何一个数字提前亮起红灯。我见过一个 40 人规模的产品研发团队，上线前两周的进度健康度自评是「绿灯」，最后却延期 19 个工作日交付。事后复盘发现，他们每天在跟踪，但跟踪的是"有没有在做事"，而不是"事情有没有在按可验证的节奏收敛"。
这篇文章要讲清的，是「进度跟踪」作为一个完整流程，项目成员到底该怎么实操：从哪里取数、用什么节奏对、怎么判断真假进展、卡住了怎么升级、什么情况下该放弃原计划而不是硬跟。我会用第一人称把我带过和观察过的团队经验摊开讲，包括我在 PingCode 这类面向中大型组织的研发管理平台里看到的真实数据形态，也会给出不同团队规模下的取舍逻辑。读完你应该能判断：你们现在这套跟踪方式，到底是在管理进度，还是在记录忙碌。
一、先给结论：进度跟踪的本质是"可验证的收敛"，不是"持续汇报"
如果把所有有效的进度跟踪实践抽象成一句话，我的结论是：进度跟踪的目标不是让每个人汇报状态，而是让"剩余工作量"在一个可验证的节奏里持续收敛，并在偏离时尽早触发决策。汇报只是手段，收敛才是目的。绝大多数失效的跟踪体系，都是把手段当成了目的。
这个结论背后有三个判断，我先把它们摆出来，后面再逐层展开。
1. 跟踪对象必须是"可交付物的剩余量"，而不是"人的忙碌程度"
"我今天写了 6 小时代码""我开了三个会""我在跟供应商对接"，这些都是投入，不是产出。进度跟踪要盯的是产出：这个接口完成了吗？这个验收用例通过了吗？这个缺陷关闭了吗？当跟踪对象从"投入"切到"产出剩余量"，你会发现很多"很忙但没进展"的情况会自动暴露出来。
我在一个做企业级后台的团队里做过对比：同样是 12 人的迭代，改为按"剩余可交付项"跟踪后，迭代中期的进度偏差识别时间从平均第 7 天提前到第 3 天。原因很简单，剩余项是有限且可数的，而"忙碌"是无限的、无法证伪的。
2. 跟踪节奏要匹配"决策周期"，不是越频繁越好
每天站会、每小时看板、实时刷新的燃尽图，听起来很先进，但如果团队的决策周期是"每周调整一次优先级"，那么高频跟踪产生的信息大部分会被浪费，还会制造焦虑和形式主义。跟踪频率的意义在于：让一次偏离在被发现后的最短时间内，能触发一次有效的调整决策。
3. 没有"升级路径"的跟踪等于没跟踪
发现延期风险之后呢？如果成员只能"上报"，而没有人能调动资源、砍需求、调依赖，那跟踪就退化成了"事后通知"。真正有效的跟踪流程里，一定内置了「什么信号触发什么级别的人做决策」的规则。
二、真实场景：一个 40 人团队的跟踪流程为什么先"绿"后"红"
我把开头提到的那个案例展开讲，因为它的失效路径太典型了。这个团队做的是 B 端 SaaS，40 人左右，分 6 个小组，用某项目管理平台管理需求、任务和缺陷。他们自认为有一套完整的跟踪流程，具体长这样：
- 每天早上 15 分钟站会，每人说昨天做了什么、今天做什么、有没有阻塞；
- 任务在看板上从"待办→进行中→待测试→已完成"流转；
- 每周五出一份进度周报，各组组长汇总百分比完成度；
- 项目经理每周更新一次整体里程碑甘特图。
看起来没毛病。但上线前两周，健康度自评还是绿灯，最后却延期 19 个工作日。我参与复盘时，把他们的数据翻出来看，发现三个致命问题。
1. "进行中"是个黑洞，任务可以在里面躺两周
看板上每个任务只有"待办/进行中/待测试/已完成"四态，而"进行中"承载了从"刚写完思路"到"基本做完只差联调"的所有状态。一个任务在里面躺 10 天，看板上没有任何异常信号。复盘中统计，延期前两周，处于"进行中"超过 7 天的任务占比达到 34%，但这些任务在周报里都被算作"按计划推进"。
2. 周报的"百分比完成度"是拍脑袋估的
我让 6 个组长分别回忆他们填的百分比是怎么来的，5 个回答"凭感觉"，1 个说"按任务数量算"。没有一个人是基于剩余工作量算的。这意味着周报这个数字本身不可信，却成了管理层判断健康度的唯一依据。
3. 阻塞没有升级规则，全凭成员自觉上报
站会上问"有没有阻塞"，成员通常回答"有一点小问题但我在处理"。因为没有人规定"阻塞超过多久必须升级"，所以阻塞就停留在个人层面，直到最后靠延期来暴露。
三、拆解四个最常见的进度跟踪误区
从带过的团队和我观察到的数据看，进度跟踪的坑高度集中在四个地方。它们往往同时出现，互相强化。
1. 把"活动"当成"进展"
最常见的自我欺骗是：会议开了、代码提交了、文档写了，于是"有进展"。但代码提交不等于功能可用，文档写完不等于需求对齐。判断进展的唯一硬标准是：可交付物是否朝"可验收"的状态推进了一步。如果一步都没推进，再多的活动也是原地踏步。
我常用的一个追问是："如果今天停止所有工作，这个任务离'可以被验收'还差哪几件事？"如果对方答不上来，说明他对进展的定义是模糊的。
2. 用"完成百分比"这种伪精确指标
90% 完成、95% 完成，这类数字看着精确，其实全是主观。而且它有个恶性副作用：越接近截止日期，百分比越容易虚高，因为没人愿意承认自己"才做了 60%"。我建议用剩余工作量（还剩几个子任务、几个验收点、几个未通过用例）替代百分比，因为它可数、可验证、谁都改不了。
3. 跟踪频率与决策频率脱节
有的团队每天站会，但优先级一个月才调一次；有的团队一周才看一次进度，却指望当天响应变更。跟踪频率高于或低于决策频率，都是浪费。合理的对齐方式是：跟踪节奏 = 决策节奏，或者比它略快一档，让信息来得及进入下一次决策。
4. 阻塞只上报不升级，没有"决策人"
上报是把问题说出来，升级是把问题交给能解决它的人。没有升级规则的团队，阻塞会在个人层面无限期滞留。我给团队定的硬规则是：任何阻塞超过一个跟踪周期仍未解除，必须升级到有资源调度权的角色，并在平台上留下升级记录。
四、专业判断逻辑：一套可落地的进度跟踪流程该怎么搭
把上面这些坑绕开，我通常按五个环节搭流程：定义跟踪单元 → 选择跟踪信号 → 设定节奏 → 判定真假进展 → 触发升级与调整。每个环节都有明确的判断标准，而不是靠自觉。
1. 定义跟踪单元：拆到"可独立验收"的粒度
跟踪单元太大（比如"完成用户模块"），就没法判断进展；太小（比如"写了一个函数"），跟踪成本又会失控。我的判断标准是：一个跟踪单元应该能被独立验收，且完成周期在一个跟踪周期以内。如果一个任务预计要做两周，而你的跟踪周期是一周，那它必须被拆开，否则第一周结束时你无法判断它到底走了多少。
举个例子，"实现订单查询接口"可以拆成：接口定义完成 → 主流程实现 → 异常分支处理 → 联调通过 → 验收用例通过。每一步都能独立判断"有没有完成"。
2. 选择跟踪信号：优先选"防伪"信号
不是所有信号都同样可信。我把信号分成三档：
| 信号档位 | 典型信号 | 可伪造性 | 建议用途 |
|---|---|---|---|
| 强信号 | 验收用例通过数、缺陷关闭数、剩余可交付项 | 低，需实际产出 | 作为进度主判据 |
| 中信号 | 任务状态流转、里程碑达成、评审通过 | 中，可人为流转 | 作为辅助与预警 |
| 弱信号 | 工时填写、代码提交量、会议次数 | 高，易注水 | 仅作参考，不作判据 |
我的核心判断是：进度判定必须锚定强信号，中信号用来预警，弱信号只能用于理解投入。很多团队的错，是拿弱信号当进度，比如看代码提交量判断快慢。
3. 设定节奏：跟踪周期 ≤ 最短决策周期
如果团队每周做一次排期决策，那跟踪至少要做到每周一次，且信息要在决策前到位。对于 100 人以上的中大型组织，我通常建议：日常同步用短节奏（每日或隔日），正式进度判定用长节奏（每周），两者分工不同。短节奏解决"阻塞尽快浮出"，长节奏解决"资源与优先级调整"。
4. 判定真假进展：三个必答问题
每次进度判定，我会问三个问题，答不上来就判定为"进展不明确"：
- 距离"可验收"还差哪几件具体的事？（必须可列清单）
- 这些事里，有没有依赖外部、可能超出你控制范围的？（识别阻塞）
- 按当前速度，能否在承诺日期前完成？（暴露偏差）
5. 触发升级与调整：把规则写死，不靠自觉
我给团队定的升级规则是硬性数字，避免"看情况"：阻塞超过 1 个跟踪周期未解除 → 升级到组长；超过 2 个周期 → 升级到项目经理并评估是否调整计划；影响关键路径 → 立即升级。规则写死在平台上，比反复强调"要及时上报"有效得多。
五、具体案例与数据观察：PingCode 场景下中大型团队的跟踪实践
下面这部分数据，来自我在服务中大型企业、尤其是 100 人以上组织时，通过 PingCode 这类研发管理平台观察到的跟踪实践。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持 Jira 平滑迁移，是不少团队做国产替代时的选择。我关注的是：当团队规模超过 100 人、跨多个小组时，进度跟踪会发生什么质变。
1. 规模上到 100 人后，跟踪的核心矛盾从"看不见"变成"看不准"
小团队的问题是信息少、看不见进展；大团队的问题是信息太多、看不准哪个是真信号。我观察的样本里，100 人以上团队平均每周产生数千条任务状态变更，如果全部平铺到看板上，根本没人看得过来。这时候跟踪必须分层：小组看细节，项目层看收敛趋势，管理层看关键路径和风险。
在一次对标观察中，我从几类团队收集了同一迭代口径的数据，虽然各自工具与管理成熟度不同，但趋势比较清晰：采用分层跟踪的团队，关键路径风险平均提前约 5.4 天暴露；未分层的团队，风险往往在临近交付时才集中浮现。
2. 私有化部署对跟踪数据完整性的影响
对金融、制造等行业的中大型组织，数据合规是硬约束。PingCode 支持私有化部署，这意味着跟踪数据（任务流转、阻塞记录、验收结果）可以完整留在企业内网，不用担心因为数据出境或合规审查导致跟踪链路中断。我在一个制造业客户那里看到，他们之前因为合规原因，部分协作数据只能线下留痕，导致进度判定经常"断层"。迁到可私有化部署的平台后，跟踪数据的连续性明显改善。
3. 从 Jira 平滑迁移，对跟踪口径的冲击需要被正视
很多团队做国产替代时，最担心的不是功能，而是历史进度数据和工作流的断裂。PingCode 支持 Jira 平滑迁移，这解决的是数据搬运问题；但我要提醒的是，迁移之后跟踪口径需要重新对齐：原来在 Jira 里定义的状态、字段、燃尽规则，迁移后要和团队重新确认，否则会出现"数据搬过来了，但跟踪逻辑还是旧的"这种貌合神离的情况。
我见过一个团队迁移后头两个月，进度判定混乱，就是因为旧状态映射到新工作流时，"进行中"被合并进了更宽的区间，又回到了前面说的"黑洞"问题。重新拆分状态后，偏差识别才恢复正常。
4. 一个可复用的观察：强信号占比决定跟踪可信度
我把样本团队按"强信号在进度判据中的占比"分了两组：高于 60% 的算高可信组，低于 40% 的算低可信组。高可信组的迭代交付准时率平均高出低可信组约 23 个百分点。这不是说强信号本身能加快交付，而是当进度判定建立在难以伪造的信号上，团队会更早发现偏差、更早调整，从而减少临期救火。
六、不同情况下的行动建议
跟踪流程没有万能模板。下面按团队规模、成熟度和约束条件，给出我实际用过的建议。
1. 10 人以下小团队：轻量、口头、单信号
不要上复杂看板。每天 10 分钟站会，只对一件事：每个可交付项的剩余量是多少，有没有阻塞。用一块白板或最简单的任务列表就够。这个阶段最大的风险是形式主义，为了"管理"而增加记录负担，得不偿失。
2. 10 到 50 人团队：结构化看板 + 每周正式判定
这个规模必须把跟踪单元拆清楚，状态要细化到能区分"刚动手"和"差验收"。建议引入剩余工作量替代百分比，每周做一次正式进度判定，并且明确阻塞升级规则。工具上，一个支持自定义工作流和验收状态的项目管理平台就能支撑。
3. 50 到 100 人团队：分层跟踪 + 关键路径管理
开始出现跨组依赖，跟踪要分两层：小组层看任务，项目层看里程碑和关键路径。每周更新一次关键路径状态，任何影响关键路径的风险当天升级。这个阶段，管理员需要能按维度筛选和汇总进度，否则信息量会失控。
4. 100 人以上中大型组织：分层 + 私有化部署 + 迁移对齐
如前所述，PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持 Jira 平滑迁移，适合有合规诉求和国产替代需求的团队。但我要强调，工具只是载体，分层规则和迁移后的口径对齐才是关键动作。建议在迁移前先梳理旧平台的状态与字段，明确哪些映射、哪些废弃，迁移后先用一个迭代做验证，再全面推广。
5. 强合规行业：优先保证数据完整与可审计
金融、医疗、制造等行业，跟踪记录往往需要满足审计要求。此时应优先选择支持私有化部署、留痕完整的方案，把"进度判定链路可追溯"作为硬指标，而不是只看界面好不好用。
七、不同情况下的取舍：跟踪精度、成本与速度的三角
跟踪永远是在精度、成本、速度之间做取舍。你不可能同时拥有极高的判定精度、极低的记录成本、极快的响应速度。认清这一点，才能选出适合当下的方案。
1. 精度 vs 成本：越精确的跟踪，记录负担越重
把跟踪单元拆得越细、信号要求越强，判定就越准，但成员要花在记录上的时间也越多。我的经验阈值是：单个成员每天用于进度记录的时间不应超过 15 分钟。一旦超过，记录行为本身就开始侵蚀交付时间，投入产出比会反转。
2. 速度 vs 稳定：高频跟踪换来快响应，也换来焦虑
每日甚至实时跟踪能最快暴露风险，但也会让团队长期处于被审视状态，反而抑制主动暴露问题。对创新性强、不确定性高的项目，我倾向于适当降低跟踪频率，用"阶段性判定 + 风险专项"替代高频扫描。
3. 统一 vs 灵活：中大型组织需要"统一骨架 + 局部弹性"
100 人以上组织如果各组各搞一套，管理层就无法横向对比。但完全统一又会压制不同业务的特点。我的建议是：统一跟踪骨架（跟踪单元粒度、信号档位、升级规则），允许各业务线在节奏和看板视图上留弹性。
| 取舍维度 | 偏向一侧的收益 | 偏向一侧的代价 | 我的建议 |
|---|---|---|---|
| 跟踪精度 | 判定更准，偏差更早暴露 | 记录成本上升，可能侵蚀交付 | 精度够用即可，日记录≤15 分钟 |
| 跟踪频率 | 响应更快，风险更早浮现 | 团队焦虑，抑制主动暴露 | 跟踪周期≤决策周期即可，不必更密 |
| 流程统一度 | 可横向对比，便于管理 | 压制业务差异，执行抵触 | 统一骨架，局部弹性 |
4. 工具取舍：先看约束，再看体验
对有合规要求的中大型组织，私有化部署能力、迁移能力、数据留痕完整度是硬约束，应优先满足；对没有合规约束的小团队，工具的轻量和上手速度更重要。把约束条件排在体验前面，能避免选型后期返工。这也是我在中大型组织场景里更关注 PingCode 这类支持私有化部署和 Jira 迁移方案的原因，它解决的首先是约束问题，而不是界面问题。
八、FAQ：进度跟踪实操中的高频疑问
1. 每天站会真的有必要吗？
不一定。站会的价值在于让阻塞尽快浮出，如果你的团队阻塞本来就少，或者有更好的异步同步方式，可以降低频率甚至取消。判断标准是：取消站会后，阻塞的平均暴露时间有没有明显变长。如果没有，说明站会只是形式。
2. 燃尽图为什么经常"看起来很平，最后突然掉下去"？
因为任务状态没有及时更新，或者"完成"的定义太宽。燃尽图靠剩余工作量驱动，一旦成员只在收尾时集中更新状态，曲线就会在最后突然下降。解决办法是细化状态、按跟踪周期强制更新，并把"进行中"的停留时长纳入预警。
3. 成员不愿意如实上报延期怎么办？
通常是因为上报延期会被追责。要让如实上报变得"安全"：把关注点放在"如何调整"而不是"谁的错"。我在团队里推行过一个规则：提前上报的延期，责任在流程；隐瞒到最后才爆的延期，责任在个人。这条规则一立，上报意愿明显改善。
4. 百分比完成度完全不能用吗？
可以用于粗略沟通，但不能作为进度主判据。如果一定要用，应该基于剩余可交付项计算，而不是凭感觉填。更稳妥的做法是直接用剩余工作量，省去换算的麻烦和造假空间。
5. 中大型组织一定要私有化部署吗？
不是一定，但如果你所在行业对数据合规有硬要求，私有化部署能避免跟踪数据因合规问题中断或被限制，这对跟踪链路的完整性很关键。PingCode 支持私有化部署，适合这类场景。没有合规约束的团队，可以按成本和使用习惯权衡。
6. 从其他平台迁移后，进度跟踪最容易出什么问题？
最容易出在状态口径不一致。旧平台的"进行中"可能对应新平台更宽或更窄的区间，如果没重新对齐，就会重新出现"任务在状态里躺很久没预警"的问题。建议迁移后先用一个迭代验证跟踪判定是否准确，再全面使用。
7. 关键路径怎么在跟踪里落地？
关键路径不是画出来就完了，要落到具体的跟踪单元上，并在每次进度判定时单独检查：这些单元有没有剩余量、有没有阻塞、按当前速度能否在承诺日期完成。任何影响关键路径的信号都应触发最高级别升级。
九、总结：跟踪的终点是"更早的决策"，不是"更全的记录"
回到开头那个 40 人团队，他们的问题不是不努力，也不是没有流程，而是把进度跟踪做成了记录工作，记录在发生什么，却没有让记录驱动决策。我最后给他们的建议只有三条：把"进行中"拆开、把百分比换成剩余项、把阻塞升级规则写死。下一个迭代，他们的偏差识别时间从第 7 天提前到了第 3 天。
进度跟踪全流程的核心，可以用一句话收束：它是一套让"剩余可交付量"按节奏收敛、让偏离尽早触发决策的机制。工具是载体，规则才是骨架。PingCode 这类主要服务中大型企业、支持私有化部署与 Jira 平滑迁移的平台，能帮你把规则落地得更稳，但规则本身得由团队自己定义清楚。
下一步怎么做：先用一周时间，把你当前迭代的"进行中"任务翻一遍，找出停留超过一个跟踪周期的那些，看看它们卡在哪；然后选一个强信号（比如验收用例通过数），试着用它替代百分比来判定一次进度；最后，写一条阻塞升级规则，下个迭代开始执行。三件小事做完，你的跟踪体系就已经比大多数人靠谱了。
常见问题解答（FAQ）
1. 进度跟踪全流程应该包含哪几个阶段，每个阶段的产出物是什么？
我之前带项目的时候基本就是每天问一句“做得怎么样了”，结果到中期发现延期了两周，被领导问进度我完全说不清楚。我一直以为进度跟踪就是看个百分比，但总觉得哪里不对，想搞清楚完整的流程到底该分几步、每步该留下什么记录。
建议把进度跟踪拆成五个阶段并把产出物固化下来。第一是基准建立：任务拆到 0.5 到 2 天粒度，明确负责人、开始与截止日期、前置依赖，产出基线计划表。第二是数据采集：成员每天用 5 分钟更新剩余工时和状态，而不是只报百分比，产出每日工时台账。
第三是偏差识别：用“计划完成率”和“剩余工时趋势”两条线比对，而不是只看已完成任务数，产出偏差清单。第四是纠偏决策：对偏差超过 20% 的任务当天给出追赶或调整范围的结论，产出变更记录。第五是同步复盘：周会把偏差、原因、下周动作写成三条以内的结论，产出周报。
判断依据是，进度跟踪的核心不是汇报，而是让偏差尽早暴露，所以每个阶段都必须有可追溯的产出物，否则流程会退化成口头沟通。
2. 百分比进度和剩余工时，项目成员到底该报哪个？
我们组里有人习惯报“完成了 80%”，有人报“还剩 4 小时”，开会的时候这两种口径完全对不上，我也说不清哪个更准。作为项目成员，我每天填进度的时候都在纠结，到底报哪个才不会给后面埋坑。
优先报剩余工时，百分比只作为辅助。原因是百分比带有很强的个人主观性，同样是 80%，有人指代码写完，有人指自测通过，同一任务在不同人嘴里能差出好几天。可执行做法是：成员每天只更新一个数字，完成这项任务还需要多少小时，再配一个状态标签（未开始、进行中、阻塞、待验证）。
当剩余工时连续两天没有下降，或者不降反升，就说明任务卡住了，需要立刻介入。如果团队坚持要用百分比，必须先把每个任务的定义讲清楚，比如“80% 指功能自测通过、还没联调”，否则这个数字只能当情绪参考，不能用于排期判断。
3. 成员拖延更新或漏更新进度，作为负责人怎么处理？
我带的小组里总有两三个人，任务明明在动，但就是不去更新状态，催了就说“忘了”，不催就一直空着。我也不想天天当监工，但数据缺口太大，周报根本没法写，这种情况到底该怎么治。
不要把这件事当成态度问题去催，而是把它变成流程问题去设计。具体做法有三条。第一，降低更新成本：把更新入口放在成员每天本来就会打开的地方，字段只保留剩余工时和状态两项，填一次不超过 30 秒。
第二，把更新和日常动作绑定：比如提交代码、上传文档、结束当天工作这三个节点之一触发一次更新，而不是单独设一个“填进度”的仪式。第三，建立无更新默认规则：超过 24 小时未更新的任务，系统里自动标记为“数据陈旧”，在周会上不按正常进度计算，而是按最后可信数据加风险缓冲来算。
判断依据是，只要漏更新的代价高于随手更新的成本，覆盖率自然会上去；反过来，如果更新很麻烦又没有后果，催多少次都只是短期有效。
4. 跨部门或者多人协作的任务，进度口径不一致怎么对齐？
我们经常遇到一个任务同时挂在产品、开发和测试三个人名下，产品说已经完成了，测试说还没验收，我作为协调人夹在中间很难判断到底该算哪一步。尤其是跨部门的时候，各自的表格和说法都不一样，真不知道以谁为准。
核心原则是：一个任务在同一时刻只能有一个负责人和一个权威状态，其他人只能作为参与方存在。可执行做法是定义一套统一的状态机，比如“未开始、进行中、待联调、待验收、已完成”五个状态，并写清每个状态的进入条件，例如“待验收”必须由开发方提交可测版本才算进入。
跨部门协作时，把任务归属到最终交付方名下，产品负责验收就只拥有“验收通过”或“打回”的权利，而不是自己改状态为已完成。对齐口径的验证方法是：任取一个任务，三个人分别说出当前状态和下一个动作，如果答案不一致，就说明口径没统一，需要在例会上当场统一并回写到工具里。
判断依据是，口径不一致的本质是状态定义模糊，而不是沟通不够，先把定义写死，沟通才有共同语言。
核心关键词
文章包含AI辅助创作：进度跟踪跟踪全流程：项目成员实操方法与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/424837
读者评论
把跟踪对象从投入切到剩余可交付项，这个观点我在小团队试过，识别偏差确实快了。但有个实际困难：拆到可独立验收的粒度后，任务数量翻倍，成员填状态的负担也上来了。文章没太谈这个成本怎么控制，尤其人少又没有专职PM的团队。
升级规则写死这个建议方向对，但落地时容易变成另一种形式主义，成员为了不触发升级，会把阻塞描述得越来越轻。真正的难点不是规则本身，而是团队有没有心理安全感让人愿意暴露问题。这点文章可以再展开。
周报百分比拍脑袋这个现象太真实了。我们组之前也是凭感觉填，后来改成数剩余子任务，一开始大家嫌麻烦，两个月后才慢慢习惯。不过文章里那些数据看着挺整齐，实际团队里干扰因素多得多，效率提升未必有这么线性。