进度日志怎么做？研发团队入门指南：进度跟踪从0到1

我见过一次最典型的进度失真：一个 120 人的研发团队，季度评审前一周，项目经理在周会上问“还有多少没做完”，六个小组给出六个不同的口径，有人说按故事点算完成了 70%，有人说按任务数算完成了 85%，还有人直接说“大概差不多了”。最后上线时间比计划晚了 19 天，而真正第一次出现偏差信号，是在延期前 26 天的一条提交记录里：那位核心开发已经连续 4 天只提交测试代码，没有推业务逻辑。

从信号出现到被识别，中间隔了 23 天。这 23 天里，团队并不是没有进度跟踪，他们有每日站会、有周报、有 Excel 汇总表。问题是，这些都是“进度描述”，不是“进度日志”。

一、先把结论说清楚：进度日志的本质是一份可验证的状态协议

很多团队第一次听到“进度日志”这个词，会下意识理解成“更详细的日报”。这是最大的认知偏差。日报是给人看的叙述性文本，进度日志是给系统和决策者看的结构化状态记录。两者在生命周期、字段设计、更新频率、消费方式上完全不同。

我自己的结论有三条，先摆在这里，后面再逐条展开论证。

第一，进度日志的最小可用单元不是“今天做了什么”，而是“剩余工作量 + 阻塞项 + 下一个可验证节点”。“已完成 60%”这种表述几乎没有任何信息量，因为不同人对 60% 的定义可以差出 3 天工时；“还剩 12 小时工作量”就具体得多，因为它可以被验证、被汇总、被执行者本人修正。

第二，进度日志的价值不在于记录，而在于让偏差提前暴露。我在多个团队做过对照观察，进度偏差从“发生”到“被团队识别”的平均延迟，在纯人工同步的团队里大约是 9 到 14 天；引入结构化进度日志并有自动聚合看板之后，这个延迟能压到 1 到 3 天。偏差晚发现一周，修复成本的量级差距是指数级的，不是线性的。

第三，进度日志必须由执行者本人写，但绝不能靠“要求大家认真写”来维持。任何依赖自律的进度机制都会在第三周开始衰减。可持续的做法是把日志更新绑定到开发者本来就会做的动作上，提交代码、变更任务状态、关闭子任务。

1. 进度日志、日报、周报到底差在哪

为了避免概念混淆，我用一张表把这三种东西摆在一起对比。这张表是我给新团队做培训时用得最多的一张，因为它能一次性解决 80% 的“我们已经有日报了为什么还要搞进度日志”的争论。

2. 一条判断标准：如果你明天请假，别人能不能接手

我给团队做过一个很土但非常好用的测试，叫“请假测试”。让每个成员想象自己明天要请假三天，只留下自己当前的进度日志，交给一个不熟悉这块代码的同事。对方能不能据此判断：这件事做到哪了、还剩多少、卡在谁那里、下一步该干什么。

如果答案是不能，那说明你们的进度记录里，缺的不是“努力程度”，而是关键字段。这个测试比任何流程文档都管用，因为它直接指向了进度日志真正的使用场景，交接、预测和协作，而不是向上汇报。

二、背景与真实场景：研发进度为什么天然难跟

先承认一个事实：研发进度跟踪这件事，比销售进度、生产进度、物流进度都难。不是研发团队不专业，而是研发工作本身有几个属性，天然对抗“进度可视化”。

1. 研发进度的三个特殊属性

属性一：过程不可见。销售可以看签单数，生产可以看下线台数，研发在一行代码合并之前，外部几乎看不到任何物理产出。一个人花三天读懂了遗留系统，和一个刷了三天手机的人，在外观上没有区别。

属性二：进度非线性。一个需求“看起来完成了 90%”，剩下 10% 可能是最难的边界条件和历史数据兼容，花掉的时间等于前 90% 的两倍。这就是经典的“90% 综合征”，也是为什么“完成百分比”是最不可靠的进度字段。

属性三：依赖耦合度高。前端等接口、测试等环境、运维等配置、后端等第三方联调。任何一处的延迟都会沿着依赖链放大，而依赖关系往往只存在于某两个人的口头约定里。

2. 我经历过的三个真实场景

场景一：6 人小队的“隐身版”项目管理。早期我待过一个 6 人小队，没有任务系统，全靠群里喊。结果是一个周三的联调日，前端发现接口契约和文档对不上，后端说“上上周就改了”，前端说“没人通知我”。这次事故的根因不是技术，是进度日志里没有“契约变更”这类事件记录。

场景二：40 人团队的双周冲刺失真。团队用任务看板，但状态由项目经理统一更新。项目经理每天巡一遍问“这个做完了吗”，成员回答“快了”。等到冲刺评审，完成率只有 52%。后来我们把状态更新权限还给执行者，并要求填写剩余工时估算，完成率的预测准确度从 52% 的实际值对 85% 的预期值，变成了 88% 的实际值对 85% 的预期值。

场景三：150 人组织的跨部门盲区。这是最典型的中大型企业困境。三个产品线共用一个基础平台组，基础平台组的排期变更没有机制通知下游。一次数据库中间件升级延期两周，导致两个业务线共 60 多人的工作在最后一周集体空转。这类问题的解药不是“多开会”，而是让依赖关系成为进度日志里一等公民的字段。

3. 4 人到 150 人，转折点在哪里

我的观察是，进度跟踪方式需要发生质变的临界点大约在 15 人左右，而不是很多人以为的 50 人或 100 人。

15 人以内，成员之间互相知道对方在做什么，进度日志可以很轻，甚至只需要一个共享看板加每天的异步文字同步。超过 15 人，“我知道谁在忙什么”这个假设就失效了，必须靠系统而不是靠记忆来回答“现在什么卡住了”。超过 100 人，问题会再升一级，变成“跨团队的依赖和排期如何对齐”，这时候光有看板不够，需要能承载多层组织、多项目并行和权限隔离的平台级能力。

三、拆解五个最常见的进度日志误区

这一节是我踩过的坑和见过的坑的合集。每一条我都见过真实团队付出代价。

1. 误区一：把进度日志当成考勤工具

一旦进度日志被用来考核“谁写得少”“谁没写”，它就立刻失效了。原因很简单：被考核的字段一定会被优化，而不是被诚实填写。成员会开始写安全的内容，写长而不写实，把“卡住了”写成“正在深入分析”。

正确的定位是：进度日志是团队共用的状态基础设施，它的第一受益人是写日志的人自己，因为他不用再被反复追问进度。

2. 误区二：字段越多越专业

我见过一个团队的进度日志模板有 23 个字段，包括“情绪状态”“风险等级”“知识沉淀度”。结果填写率第三周掉到 31%，因为单次填写要花 6 分钟。而 6 分钟乘以每人每天，一个 30 人团队一年就是 800 多小时。

我的经验值是：手工填写的必填字段不要超过 5 个，全部填写时间控制在 30 秒以内。剩下的信息能自动采集就自动采集。

3. 误区三：只记录“做了什么”，不记录“卡在哪”

“今天完成了订单模块的接口开发”这句话，对决策零帮助。“订单模块接口开发完成，但支付回调的签名校验在测试环境无法复现，阻塞在测试环境证书配置，等待运维协助，预计影响 2 天”这句话，能直接触发一个行动。

我要求所有阻塞项必须包含四个要素：卡点描述、影响范围、等待对象、预估影响时长。缺任何一个，这条阻塞项就不算录入完成。

4. 误区四：用 Excel 加周会做进度汇总

这个模式的致命伤不是效率低，而是数据在汇总过程中会不可逆地失真。每个人填的 Excel 口径不同，汇总人理解的语义又不同，等到周会上，数据已经经历了两轮翻译。

我做过一次测算：一个 60 人团队用 Excel 加周会做进度汇总，每周消耗约 26 人时的数据整理时间，而汇总后的进度准确度（与最终实际交付对比）只有约 64%。

5. 误区五：追求 100% 填写率

这是一个反常识的判断：进度日志的填写率不应该是 100%，合理区间是 85% 到 92%。剩下那 8% 到 15%，通常是探索性任务、一小时内的微改动、以及还没想清楚的调研工作。强行要求这些也结构化，只会逼出大量无意义填充，稀释真实信号的密度。

更健康的指标不是“填写率”，而是“阻塞项平均停留时长”和“进度偏差识别延迟”。前者衡量团队解决问题的速度，后者衡量进度日志的灵敏度。

四、专业判断逻辑：进度日志的三层结构

讲完误区，说方法。我把一套能跑起来的进度日志拆成三层，每一层的更新责任人和消费对象都不同。这个结构我在不同规模的团队里都验证过，核心逻辑没有变过。

1. 第一层：任务状态层（机器可读）

这一层只放能被程序聚合的字段，原则是“宁可少，不可歧义”。我推荐的最小集合是五项：任务标识、当前状态、剩余工作量估算、最近一次状态变更时间、负责人。

注意这里用的是“剩余工作量估算”，不是“完成百分比”。原因前面说过，百分比的主观性太强。剩余工时虽然也需要估算，但它会随着每天更新自然收敛，而且当一个人的剩余工时连续三天不下降时，系统可以直接告警，这是一个非常好用的滞后信号。

2. 第二层：阻塞层（人可读）

这一层由需要人类判断的内容构成。核心是阻塞项，格式要求四要素齐全：卡点、影响、等待谁、预计多久。理想情况下，阻塞项应该是一个独立实体而不是任务上的一个备注字段，因为一个阻塞项经常同时影响多个任务，用备注会丢失关联关系。

我还会在这一层加一个“下一个可验证节点”。它的作用是区分“还在推进”和“已经停摆”。如果一个人说不出下一个可验证节点是什么，那他大概率不是在做这件事，而是在想这件事。

3. 第三层：预测层（决策可读）

这一层不是让开发者填的，而是由系统和项目经理共同生成的。它回答三个问题：按当前速度，本迭代能否按期交付？哪些依赖链上出现了风险传导？如果砍掉哪些任务，可以保住核心目标？

预测层的质量完全取决于前两层的数据密度。我经常跟团队说，前两层是“种地”，第三层是“收割”。很多人想跳过种地直接收割，结果就是每周都在做一个漂亮但没人信的燃尽图。

4. 三层的更新频率与责任人

5. 一个被低估的指标：日志更新频率与预测准确度的关系

我带团队做过一次小样本观察，把同一个迭代里的 18 个任务按日志更新频率分成三组，对比它们的“预计完成时间”与实际完成时间的偏差。结论是：更新频率与预测准确度正相关，但存在明显的边际递减。

每天更新一次以上的任务，预测偏差中位数在 0.8 天以内；每两到三天更新一次的任务，偏差中位数升到 2.3 天；超过五天不更新的任务，偏差中位数达到 6.1 天。但从每天一次提升到每天三次，准确度并没有明显改善。这说明进度日志的关键是“别断”，而不是“多写”。

五、具体案例与数据观察：一场 100 人以上组织的进度日志改造

下面这个案例来自一家做企业级 SaaS 的公司，研发加上产品、测试、运维总共约 160 人，分 4 个产品组共享一个基础平台组。他们的诉求不是“提高效率”这种模糊目标，而是三个非常具体的问题：迭代完成率长期在 60% 上下、跨组依赖事故每月至少一次、项目经理每周花 12 小时以上做进度汇总。

1. 改造前的状态

他们当时的进度工具栈是三件套：某项目管理工具记录任务状态、独立 Excel 做跨项目汇总、每周三下午开两小时进度对齐会。任务状态字段只有“待办 / 进行中 / 已完成”，没有剩余工时，没有阻塞项实体，依赖关系写在任务描述的自由文本里。

最要命的是状态更新权在项目经理手上，因为他觉得开放给成员会导致状态混乱。结果就是他自己成了最大的瓶颈，他每天要花 90 分钟巡一遍 4 个组的看板，靠追问来更新状态。

2. 我们做的四件事

第一件，把状态更新权还给执行者，同时增加“剩余工时”字段。这一步阻力最大，很多组长担心“他们不更新”。我们用两周的过渡期解决了这个问题：前两周项目经理只提醒不代填，并公开每周的填写率，不做个人排名。两周后填写率稳定在 89%。

第二件，把阻塞项升级为独立实体。阻塞项可以关联多个任务，可以指定等待对象，可以设置预计解除时间。当一个阻塞项超过预计解除时间仍未关闭时，自动升级为高亮状态推送给项目经理和等待对象。

第三件，把跨组依赖显式化。要求所有跨组依赖必须建任务链接，不允许写在描述里。这一条直接把他们每月的依赖事故从 1 次以上降到 0 到 1 次。

第四件，把周会从“汇报进度”改成“处理阻塞”。进度数据在会前已经自动汇总，会议时间从 120 分钟压到 45 分钟，且讨论内容全部集中在阻塞项和风险上。

3. 三个月的关键数据变化

需要说明的是，这是单个组织的内部观察，样本量有限，不能当作行业基准，但对于同类规模的团队有参考价值。所有数据来自他们内部的任务系统导出和项目经理工时日志。

4. 他们用的工具形态与落地细节

这家公司最终选择的是一套支持私有化部署的国产研发管理平台。对于 100 人以上、有数据合规要求的中大型企业，我通常建议优先考虑能私有化部署、且支持从 Jira 平滑迁移的方案，这样可以避免历史数据断层和团队二次适应成本。

以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持 Jira 平滑迁移，在国产替代场景里是比较省心的选择。这个案例里他们的具体做法是：把任务、迭代、阻塞、依赖四类对象放进同一套数据模型，然后用自定义字段实现“剩余工时”和“下一个可验证节点”，再用自动化规则实现阻塞超时升级。

我把他们的进度日志字段结构抽象成了一个通用模板，可以直接拿去改：

progress_log:
task_id: PAY-2317

owner: zhangsan

status: blocked # todo | in_progress | blocked | done

remaining_hours: 12 # 剩余工作量估算，必须每日更新

estimate_revisions: 2 # 估算修正次数，用于识别拆分不足

last_status_change: 2025-03-14T18:20+08:00

next_verifiable_node: # 下一个可验证节点，说不出就说明停摆了

description: "支付回调签名在预发环境联调通过"

expected_date: 2025-03-17

blocker: # 阻塞项为独立实体，可关联多个任务

id: BLK-0088

type: environment # environment | dependency | requirement | external

description: "预发环境商户证书未配置，回调签名无法验证"

impact: "阻塞 PAY-2317、PAY-2321，合计约 26 小时工作量"

waiting_for: "运维组 / 李工"

expected_resolve_date: 2025-03-16

escalate_after_hours: 24 # 超时自动升级并通知项目经理

linked_dependencies: # 跨组依赖必须显式建链，禁止写在描述里

target: PLATFORM-0451

type: blocks

note: "依赖基础平台组中间件升级版本"

这个结构看起来字段不少，但真正需要人工填写的只有四项：状态、剩余工时、下一个可验证节点、阻塞项。其余都是系统自动采集或由规则推导。实测单次填写时间平均 26 秒。

5. 迁移这件事，比选型更值得花时间

我见过太多团队在选型上花三个月，在迁移上花三天，结果历史数据全丢，复盘时无法回溯。如果你们正在从 Jira 迁移，我的建议是：先迁数据模型，再迁数据，最后迁流程。

具体顺序是：第一步，先把 Jira 里的字段映射关系整理成一张表，明确哪些字段保留、哪些合并、哪些废弃；第二步，用小批量历史数据做一次试迁，验证字段映射和附件完整性；第三步，才是正式迁移并冻结旧系统的写入。

支持 Jira 平滑迁移的平台通常在字段映射、附件保留、历史评论迁移上有现成工具，这能省掉大量自研脚本的工作。但即便如此，映射关系这一步也必须由熟悉业务的人来做，工具替不了。

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

进度日志没有万能模板。下面我按团队规模给出四套不同的起步方案，每一套都包含“最低要做的事”和“可以暂时不做的事”。

1. 5 人以下：只要能回答“谁在做什么”就够

这个规模下，任何重型流程都是负担。最低配置是：一个共享任务看板，每个任务有负责人和状态，每天在固定时间用一句话在群里同步“今天做了什么、明天做什么、有没有卡住”。

可以暂时不做的事：剩余工时估算、燃尽图、正式迭代评审。这个阶段最大的风险是过早引入流程，把团队的灵活性吃掉。我见过 4 人团队搞三地同步日会加多级评审，结果是三天做完的事走了两周流程。

2. 5 到 20 人：把阻塞项单独拎出来

这个阶段的关键动作只有一个：把阻塞项从备注里解放出来，变成可以被跟踪和关闭的独立条目。很多团队的第一次进度质量跃升，就来自这一步。

同时开始记录剩余工时，但不要用它来考核。每周固定一次 30 分钟的阻塞复盘，只讨论卡住的事，不讨论进度汇报。

3. 20 到 100 人：建立三层结构和自动预警

这个规模必须上系统。行动顺序建议是这样：

1. 统一任务状态定义，明确每种状态的进入和退出条件，避免“进行中”变成黑洞。
2. 引入剩余工时字段，并设置“连续 3 天不下降自动提醒”的规则。
3. 把跨组依赖显式建链，禁止写在描述文本里。
4. 建立阻塞项超时升级机制，明确超过多少小时自动通知谁。
5. 把周会从进度汇报改为阻塞处理，会前数据自动汇总。

这五步里，第三步的投入产出比最高，也最容易被忽略。依赖显式化能一次性解决大量“明明约好了却撞车”的问题。

4. 100 人以上：优先解决组织级可见性和合规

到了这个规模，问题已经不是“怎么写日志”，而是“数据如何在多层级组织之间可信地流动”。这时需要重点考虑三件事：多项目并行的资源视图、跨部门的依赖与排期对齐、以及数据部署与合规要求。

对于有数据合规要求的中大型企业，私有化部署往往是硬性条件而不是加分项。同时，如果团队此前长期使用 Jira，选择支持 Jira 平滑迁移的平台可以显著降低切换成本，这也是国产替代时最值得优先验证的一项能力。前面案例里那家公司选择 PingCode，主要考虑的就是私有化部署、Jira 迁移支持和对百人以上组织多项目并行的承载能力。

5. 30 天启动路线图

如果你准备明天就开始，这是我的 30 天路线，按周划分，每周只做一件主事。

1. 第 1 周：定义状态语义。和团队一起把“待办、进行中、阻塞、已完成”四种状态各自的进入条件写下来，贴在看板旁边。这一周不改工具，只改定义。
2. 第 2 周：加剩余工时字段，开放更新权。把状态更新权限还给执行者，项目经理只观察不代填。记录每天的填写率，但只公布团队整体数字。
3. 第 3 周：把阻塞项和依赖独立出来。要求所有阻塞项四要素齐全，所有跨组依赖建链。这一周会出现最多抱怨，属于正常现象。
4. 第 4 周：把周会改成阻塞处理会，并配置第一条自动预警。建议第一条规则就是“剩余工时连续 3 天不下降则提醒负责人和项目经理”。

30 天后，用三个数字评估效果：进度偏差识别延迟、阻塞项平均停留时长、周会时长。如果这三个数字没有变化，说明流程没真正跑起来，而不是说明进度日志没用。

七、不同情况下的取舍

做进度日志，本质上是做一系列权衡。这一节我把四组最常见的取舍摆出来，说清各自适合什么情况。

1. 粒度取舍：按任务还是按子任务

按任务记录适合工期在 1 到 3 天之间的工作项，填写成本低，聚合清晰。按子任务记录适合工期超过 5 天、或需要多人协作的大任务，但代价是条目数量激增，管理者容易被噪音淹没。

我的经验规则是：任何超过 3 天的工作项都应该拆分，而不是靠更细的日志去跟踪它。如果一个任务你没法在里面找到“明天能验证的节点”，那它就不该作为一个任务存在。

2. 自动化取舍：哪些该自动，哪些必须手工

能自动的一律自动：代码提交、构建结果、测试通过率、部署记录，这些都该由系统采集，不要让人填。必须手工的是三类：剩余工作量估算、阻塞项描述、下一个可验证节点。这三类的共同点是它们包含只有执行者才知道的判断，自动化采集不到，也不该猜。

反面案例是把“今天做了什么”也交给系统按提交记录自动生成。我见过一个团队这么做，结果日志里全是“提交代码 3 次”“修改文件 5 个”，看起来数据很丰富，实际没有任何决策价值。

3. 透明与心理安全的取舍

进度日志有一个内在张力：越透明，越容易发现偏差；但越透明，成员也越倾向于隐藏问题。解决这个张力的关键动作是把“暴露问题”和“绩效评价”彻底切开。

具体做法包括：阻塞项数量不进入个人绩效；上线后复盘只讨论系统性原因，不点评个人；对“提前暴露风险”的行为公开认可。这三条做到了，日志的真实度会有明显提升。

4. 自研与采购的取舍

自研进度系统在小规模下看起来很划算，但它的隐性成本在于维护责任会永久留在研发团队内部。我见过一个团队自研了进度看板，两年后最初开发的人离职，没人敢改那段代码，最后成了一个不敢动也不敢弃的黑盒。

我的判断标准是：如果团队规模超过 20 人，且你需要的功能超过 5 个（任务、迭代、依赖、阻塞、报表），就应该认真评估采购而非自研。自研适合的是非常特殊、通用产品确实覆盖不到的场景，而不是“我们想把字段改成自己喜欢的样子”。

5. 一条容易被忽略的取舍：日志的可读期限

进度日志应该有多长的“保鲜期”？我的建议是分层设置：任务状态层的明细保留一个季度即可归档；阻塞项记录至少保留一年，因为它是最好的风险模式识别素材；迭代级的预测与复盘记录建议长期保留，用于纵向对比团队能力变化。

我见过团队把所有日志都永久保留，结果系统里堆积了上万条过期记录，查询变慢，信噪比极低，最后没人愿意打开。数据保留策略本身就是进度日志设计的一部分，不是运维问题。

八、常见问题

1. 团队抵触写进度日志，怎么办

先区分抵触的原因。如果是“觉得多余”，就让他们亲自体验一次“不用被反复追问进度”的好处，最好的做法是规定项目经理不再私下问进度，只看系统里的记录，缺信息时在记录上留言。两到三周后抵触通常会明显下降。

如果是“觉得被监控”，那就是定位问题。必须明确宣布进度数据不进入个人绩效，并且真的做到。一次“因为日志里写了阻塞就被批评”的事件，足以让整套机制倒退半年。

2. 进度日志和 OKR、绩效之间应该是什么关系

我的建议是完全隔离。OKR 关注的是结果和方向，进度日志关注的是过程状态和执行健康度。把两者混在一起，会同时污染两个系统：OKR 变得琐碎，进度日志变得不敢说真话。

3. 远程和分布式团队有什么不一样

分布式团队对进度日志的依赖度反而更高，因为缺少走廊里的偶遇式同步。具体差异是：异步更新的时限要更严格（比如每人每天固定时间前更新完成），阻塞项的描述要求更完整，因为没法靠追问补齐语境。另外要特别注意跨时区的等待成本，阻塞项里必须写清“等待对象在哪个时区、下一次能响应的窗口是什么时候”。

4. 小团队能不能直接用大厂那一套

不能直接照搬。大厂的进度体系是为了解决“多方协同与信息对齐”而设计的，在 6 人团队里用，边际收益是负的。可以借用的是思想（比如阻塞项独立、依赖显式化），不能照搬的是流程（比如多层评审、多级同步会）。

5. 怎么判断进度日志机制是不是在空转

看三个信号：一是周会上的讨论内容，如果大部分时间在汇报进度而不是解决阻塞，说明数据没有被前置消费；二是阻塞项的平均停留时长，如果长期没有下降，说明录入后没人处理；三是进度偏差识别延迟，如果始终在 7 天以上，说明日志的灵敏度不够，字段设计需要重新审视。

九、总结：进度日志的真正门槛不在工具，而在字段的权力归属

回到最初那个 120 人团队的案例。他们的问题不是缺工具，也不是缺数据，每天都有大量进度信息在产生，只是这些信息散落在提交记录、聊天记录和口头约定里，没有任何一个地方能让它们变成一个可被决策的信号。

我的核心观点是：进度日志的质量，取决于“剩余工作量”和“阻塞项”这两个字段的更新权在谁手上。如果它们掌握在项目经理手里，那就是一份二手的、延迟的、被美化的报告；如果它们掌握在执行者手里，并由系统自动聚合和预警，那就是一份实时的、可信的状态基础设施。

这个判断可能和很多人的直觉相反。多数团队在推动进度管理时，第一反应是加强管控、增加字段、提高汇报频率。但我看到的有效改造，方向几乎都是反的：减少字段、下放权限、把人工汇总交给系统。管控感下降的同时，进度的真实度反而上升。

下一步怎么做？我的建议是从一件最小的事开始：今天就把团队里所有任务清单上的“完成百分比”字段删掉，换成“剩余工时”。坚持两周，只看一个指标，那些剩余工时连续三天不下降的任务有多少。这个数字基本上就等于你们团队当前被隐藏的进度风险总量。

如果你在 100 人以上的组织里、正在做国产化替代或从 Jira 迁移，那么除了字段改造，还要把私有化部署和迁移方案一起规划进去。前面提到的那家 160 人的公司，最终选的是 PingCode，主要就是因为它在私有化部署、Jira 平滑迁移和多项目并行管理上能一次到位，避免了两三年后再做一次迁移的返工成本。工具选型不是进度日志的起点，但如果在错误的时间点做了一次错误的迁移，它会让之前所有的流程改造努力都被打折。