进度管理如何做好实际进度？研发团队实操方法与操作步骤

去年第三季度，我帮一家做工业IoT的研发团队做进度复盘。他们有32个研发人员，分4个小组，用的工具不可谓不先进，站会每天开，周报每周交。但我让他们把过去6个迭代的计划完成时间和实际完成时间拉出来对比时，会议室安静了，6个迭代里，有5个迭代的实际交付时间比计划晚了9到17天，但在这5个迭代的中期周报上，进度状态全部显示为"正常"或"略有风险"。

这不是个例。我后来陆续接触了十几个100人以上规模的研发团队，发现一个非常一致的规律：计划进度做得好不好，看的是排期能力；实际进度做得好不好，看的是"你敢不敢让坏消息早上桌"。大部分研发团队的进度管理翻车，不是不会排计划，而是实际进度在传递过程中被一层层"美颜"了，等到瞒不住的时候，已经来不及调整了。

这篇文章不讲甘特图怎么画、燃尽图怎么看，那些工具说明书式的操作网上已经够多了。我要讲的是我实际带团队、做咨询过程中验证过的做法：怎么让实际进度真实地暴露出来，怎么把"实际进度"变成可追踪、可预警、可纠正的一套机制。整套方法拆成6个操作步骤，附上我在团队里实际用过的检查清单和判断标准。

一、先给结论：实际进度管不好，90%不是工具问题

很多研发负责人一想到进度管理出问题，第一反应是"工具不行，换一个"，或者"流程不完善，补一个流程"。我实际看过的情况恰恰相反：大部分团队的工具已经足够好了，缺的是"让真实进度浮出水面"的机制设计。

1. 三个我先说死的核心判断

在展开具体步骤之前，先把三个结论亮出来，后面的所有方法都是围绕这三条展开的。

判断一：实际进度的最大敌人不是延期本身，而是"延期被延迟发现"。一个任务延期3天，如果第一天就暴露，你有充足时间调资源、砍范围、改优先级；如果第7天才暴露，你只剩加班和延期交付两条路。同样的延期，发现时间不同，处理成本差5到10倍。

判断二："完成了百分之多少"是研发进度管理里最没用的一个数字。因为"80%完成"背后可能是"核心逻辑通了但边界情况没处理"，也可能是"代码写完了但一行没测"，这两种80%的风险完全不同。真正有意义的是"完成了哪些可验证的交付物"。

判断三：进度管理的本质是缩短"问题发生"到"问题被承认"之间的时间差。这个时间差越大，团队越像在开盲盒，你永远不知道下一个爆雷在哪里。我见过做得最好的团队，这个时间差控制在24小时以内；做得差的，平均7到10天。

这三条判断不是我拍脑袋想出来的。我统计过自己深度参与过的7个研发团队，把"延期发现时间差"和"迭代最终延期天数"做过一次对应，规律非常明显，发现得越早，最终延期越短，因为你有时间做取舍。

2. 为什么我不建议一上来就换工具

我踩过一次坑。2021年我建议一个团队从表格管理切到一款功能更全的研发管理平台，大家都觉得"终于专业了"。结果三个月后进度问题反而更严重了，因为工具变复杂了，一线研发嫌更新状态麻烦，状态更新率从70%掉到了40%，管理层看到的进度反而更失真。

这件事之后我改了原则：在没解决"状态更新真实性"之前，不要换工具。工具升级应该发生在机制理顺之后，用来放大已经跑通的流程，而不是用来掩盖流程本身的漏洞。工具是载体，机制才是发动机，发动机有问题，换再好的车壳也没用。

二、真实场景：研发团队的"实际进度"到底难在哪

要讲清楚怎么做，得先讲清楚为什么难。研发团队的进度管理，和制造业、工程项目的进度管理有本质区别，照搬那套方法一定翻车。

1. 研发场景的四个特殊性

我总结过，研发进度之所以特别难管，是因为它同时具备四个别的行业不太同时出现的特性。

需求会变。产品经理今天说要A，下周可能变成A加B。需求一变，任务拆解要重做，工期要重估，原来的进度表直接作废。这不是管理不善，这是研发的常态。

技术有不确定性。写业务代码相对可预测，但涉及架构改造、性能优化、第三方对接时，"这个接口能不能调通"本身就带着巨大不确定性。工程师说"三天"，可能一天搞完，也可能三天后才发现路走不通要推倒重来。

任务高度并行。一个研发同时挂着三四个任务太常见了，每个任务的真实推进时间被切得七零八落。你在进度表上看到他在做A，实际上他今天一半时间在救B的火。

交付物难量化。设计画完一张图叫完成，销售签下一单叫完成，但研发"完成"的定义模糊得多，代码写完算完成吗？自测通过算吗？联调通过算吗？定义不清，进度就没法对齐。

这四个特性叠加，导致一个结果：研发进度天生就容易失真，不用特殊机制去对抗，它一定会失真。

2. 一个典型的失真链条

我把一个研发任务从"实际出问题"到"管理层知道"的过程拆开看，通常要经过这么几层：工程师自己先判断，这可能只是个小问题，再花半天也许能搞定；组长问他时，他说"差不多了"；组长报给项目经理时，说"这个任务有点风险，但在可控范围"；项目经理汇总给管理层时，说"整体正常，个别任务略有波动"。

每一层都出于善意做了"美化"和"缓冲"，但结果是：管理层看到的进度，是经过四次衰减后的乐观版本，和真实进度差了将近一周。这就是为什么很多管理者觉得"明明报的都是正常，怎么突然就延期了"。

3. 所以，"实际进度"必须先被定义

我一直跟团队强调一句话：你没法管理一个你没定义清楚的东西。"实际进度"这个词听起来谁都懂，但落到具体任务上，不同人的理解能差出十万八千里。所以在讲具体步骤之前，必须先把它定义清楚。

我的定义是：实际进度 = 已经通过完成标准验证的可交付成果数量 ÷ 计划中的可交付成果总数。注意两个关键词："通过完成标准验证"和"可交付成果"。不是"花了多少时间"，不是"自我感觉完成了多少"，而是实实在在验证过的东西。

这个定义听起来朴素，但它直接决定了后面所有操作步骤的设计逻辑。

三、拆解误区：研发进度管理最常见的四个错误认知

在给出操作步骤之前，我得先把几个流传很广但我觉得完全错误的认知拎出来说清楚。因为这些误区不破，后面的方法你用起来会走形。

1. 误区一：以为把计划排细就能管好实际进度

很多人的逻辑是：计划排得越细，实际执行就越接近计划。于是花大量时间做WBS分解、画甘特图，把一个迭代排到每天每半天。结果是：计划越细，实际偏差越大，因为研发的不确定性根本不支持这么细的预测。

我见过一个团队把任务拆到半天一个颗粒度，结果第二天进度表就全乱了，因为上午那个任务卡住了，后面的全连锁延期。最后大家干脆不看了，进度表成了摆设。

正确的逻辑反过来：计划不需要特别细，但实际进度的追踪颗粒度要细。计划可以是粗线条的目标，实际追踪必须精细到能及时发现偏差。

2. 误区二：以为天天开站会进度就真实了

站会是好工具，但我见过太多站会变成了表演。每个人轮流说"昨天做了什么、今天做什么、没有阻塞"，说得流畅，听得舒服，但真实风险一个没暴露。为什么？因为站会的默认期待是"说进展"，而不是"暴露问题"，一旦有人在站会上说"我这卡住了"，气氛就变了。

站会有效与否，不取决于开不开，取决于团队有没有把"暴露问题"当成正面行为。如果组长在站会上听到阻塞就皱眉，那站会必然沦为表演。我后来带团队时，会专门在站会上追问一句"今天有什么可能做不完的"，把暴露风险制度化成一种习惯。

3. 误区三：以为进度表更新了进度就真实了

这是最隐蔽的一个误区。进度表上任务状态都更新了，看起来很勤快，但更新的内容是不是真实？我抽查过某团队的状态更新，发现一个规律：大部分人的状态更新是把昨天的话改个日期发上去，真正遇到问题的任务，状态反而是更新得最少的。

为什么？因为遇到问题的任务让人心虚，越心虚越不想碰它，越不碰它状态越模糊，越模糊越容易被忽略，形成恶性循环。所以进度表"更新率"高，不等于"真实性"高。

4. 误区四：以为进度和质量可以分开管

研发进度管理里最容易被忽略的一个真相是：只盯进度不盯质量，最后一定进度质量双输。因为为了赶进度把测试压缩了、把代码质量放松了，表面上看任务按时"完成"了，但后面几周会以返工、Bug、线上事故的形式加倍还回来，把下一个迭代的进度也拖垮。

我坚持的一个原则是：没有通过质量验证的任务，不算完成，不进进度统计。哪怕进度表上不好看，也比虚假的漂亮要强。

四、专业判断逻辑：做好实际进度管理的六个操作步骤

前面讲了这么多背景和误区，现在进入核心。这六个步骤是我在多个团队实际落地、反复调整后沉淀下来的，按顺序执行效果最好。每一步我都会给出"做什么、怎么做、常见坑、检查标准"。

1. 步骤一：把任务拆到"可追踪颗粒度"

做什么：把一个迭代的目标拆成一个个颗粒度合适、可独立追踪的任务。

怎么做：我的经验标准是，单个任务的预估工时控制在0.5天到3天之间。超过3天的任务必须继续拆，因为超过3天的任务，进度跟踪会变得很模糊；低于0.5天的任务不值得单独跟踪，合并处理。

拆的时候有个技巧叫"纵向切片"而非"横向分层"。比如做"用户注册功能"，不要拆成"前端开发、后端开发、数据库设计、测试"（这是横向分层，每个都要等其他人），而是拆成"手机号注册跑通、邮箱注册跑通、第三方登录跑通"（这是纵向切片，每个都能独立交付和验证）。

常见坑：把任务拆成"开发50%、测试30%、联调20%"这种百分比形式，这种拆法没法追踪，因为没人知道"开发50%"到底是什么状态。

检查标准：随机抽3个任务，看能不能一句话说清楚"这个任务完成时，能看到什么、能验证什么"。说不清就是没拆到位。

2. 步骤二：为每个任务定义明确的完成标准（DoD）

做什么：为每一个任务定义"什么叫完成"的具体标准，也就是DoD（Definition of Done）。

怎么做：DoD不能是"功能实现"这种模糊的词，要具体到可检查。以研发任务为例，一个完整的DoD通常包含这几项：

• 代码已合入主分支（不是在自己分支上）
• 单元测试覆盖率达标（团队自定阈值，比如核心逻辑80%）
• 经过至少一名其他成员的Code Review
• 在测试环境验证通过，且关键路径有自动化测试
• 相关文档/接口说明已更新

这个DoD一旦定下来，任务状态就只有两种：满足DoD（完成）和不满足DoD（未完成）。中间那些"差不多了""快好了"的状态，全部算未完成。这一条是治"80%永远完不成"的最有效手段。

常见坑：DoD定得太理想化，每个任务都要满足十条标准，结果谁都不想更新状态。我的建议是先定3到5条最关键的，跑通后再逐步加。

检查标准：一个任务被标记为"完成"时，团队里另一个人能不能在5分钟内验证它是真的完成了。能，DoD就合格。

3. 步骤三：建立"双线进度视图"

做什么：同时维护两条进度线，里程碑线和迭代线，两条线的关注点不同，不能混在一起看。

怎么做：里程碑线是粗线条的，管的是"这个季度我们要交付什么关键成果"，关注跨迭代的大目标。迭代线是细线条的，管的是"这两周我们要完成哪些任务"，关注具体任务流转。管理层主要看里程碑线，团队主要看迭代线，两条线每周对齐一次。

为什么要分开？因为如果只有一条线，要么管理层被琐碎任务淹没，要么团队被大目标压得没有掌控感。我见过很多团队把季度目标和日常任务放在同一张表里，结果就是没人能一眼看清整体态势。

常见坑：两条线之间没有明确的映射关系，导致迭代线跑得很好但里程碑还是延期。解决办法是每个迭代任务都要挂到某个里程碑上，不挂的不做或者单独排。

检查标准：随便挑一个里程碑，能不能在5分钟内说清楚它由哪几个迭代的哪些任务支撑、当前完成到什么程度。能，双线视图就跑通了。

4. 步骤四：设置进度偏差的预警阈值和触发机制

做什么：给进度偏差设置明确的预警线，超过就自动触发应对动作，而不是等人来发现。

怎么做：我的经验阈值是这样定的（不同团队可微调）：

这套阈值机制的关键不在阈值本身，而在阈值一旦触发，必须有人响应，不能沉默。我见过团队设了阈值但没人管，触发了也就触发了，等于形同虚设。

常见坑：阈值设得太敏感，天天红色预警，大家麻木了。我建议先跑三个迭代，根据实际情况调整阈值，让它维持在"一周触发2到3次"的频率比较合适。

检查标准：随便翻一个月的预警记录，看看每次触发是否都有明确响应动作和处理结果。有，机制就是活的。

5. 步骤五：用短周期同步机制暴露真实进度

做什么：建立每日、每周、每迭代三个层级的同步节律，让真实进度以固定的频率浮出水面。

怎么做：我实际用过、效果最好的组合是这样的：

每日15分钟站会。注意，站会不是汇报会。我要求每个人只回答两个问题："距离你的任务DoD还差什么"和"今天有没有可能做不完的"。第二个问题是我特意加的，专门用来把风险逼出来。第一个问题问的是差距，不是做了什么，因为说"做了什么"容易自我加分，说"还差什么"更接近真相。

每周30分钟进度对齐会。只拉里程碑线，看整体态势，识别本周新出现的风险。会上不追究细节，只做"要不要调整"的决策。

每迭代1小时复盘会。回顾这个迭代的完成情况，重点分析那些偏差超过2天的任务，不是追责，而是找出规律：是估算习惯问题，还是任务拆解问题，还是外部依赖问题。

常见坑：三个会开成了三个汇报，没有人做决策。我坚持一个原则：凡是会上暴露的问题，会上要有一个明确的下一步动作和责任人，否则这个问题不该在会上说。

检查标准：统计一下过去两周站会上提到的阻塞问题数量。如果一个都没提到，那大概率不是没阻塞，而是没人愿意说。

6. 步骤六：偏差发生后的纠正流程

做什么：设计一套偏差发生后的标准处理流程，让纠正动作可预期、不靠临场发挥。

怎么做：我把纠正流程分成四步，按顺序执行：

1. 先确认偏差的影响范围。这个任务延期会不会影响别的任务、会不会影响里程碑，影响多大，这一步是定性判断，不超过10分钟。
2. 再分析偏差的根因。是估算不准、需求变了、外部依赖卡住，还是资源冲突？不同根因处理方式完全不同。估算不准靠校准习惯，需求变化靠变更流程，外部依赖靠提前沟通，资源冲突靠优先级重排。
3. 第三步才是做取舍。在赶工、砍范围、延期、加资源四个选项里选。我一般按这个优先级：先考虑砍范围（保核心），再考虑加资源（看有没有余量），再考虑延期（提前沟通），最后才考虑赶工（因为赶工透支的是下个迭代）。
4. 最后是记录和跟踪。偏差处理完成后，记录下原因和处理方式，作为后续估算参考。这一步经常被省略，但它才是让团队越做越准的关键。

常见坑：一遇到偏差就想着"加班赶回来"，结果这个迭代赶回来了，下个迭代累垮了。赶工是最后手段，不是第一反应。

检查标准：看过去3个迭代的偏差处理记录，如果大部分偏差都是靠"赶工"解决的，说明纠正流程需要优化。

五、真实案例：一家工业软件研发团队的进度管理改造

讲到这里都是方法，可能有点抽象。我拿一个具体案例来走一遍完整流程，这样你能看到这些步骤是怎么串起来落到实处的。

1. 改造前的状况

这家团队做工业MES系统，研发人员62人，分5个小组。2023年年中的时候，他们的问题很典型：迭代平均延期7天，管理层周会上永远听到的是"基本正常"，交付承诺经常在最后一周才知道要延期。

我做了一次现状诊断，发现三个关键问题：任务颗粒度太粗（平均单个任务预估4.5天）、没有DoD、进度全靠周会上口头同步。这三个问题正好对应我前面讲的步骤一到步骤五。

2. 改造动作和推进节奏

改造分三个阶段，总共花了两个半月。我没有一次性把所有机制推下去，因为那样团队会抵触，而是分步走。

第一个月，先解决"任务颗粒度"和"DoD"两个基础问题。我带着5个组长逐个review任务拆解，把超过3天的任务全部重拆，同时和团队一起制定了第一版DoD（5条标准）。这个月没有引入任何新工具，就在原有工具上调整。

第二个月，引入预警阈值和双线视图。先在两个小组试点，跑顺了再推到全部5个组。预警阈值一开始设得比较宽（延期3天才触发黄色），跑了两周觉得反应太慢，收紧到2天。

第三个月，固化同步节律和纠正流程。站会内容从"做了什么"改成"还差什么"，每周对齐会固定时间固定议程，偏差纠正流程做成一页纸贴在工位上。

这里我提一下工具的选择。这家团队改造后期因为要上私有化部署并逐步从原来的海外工具迁移，评估过几款国产研发管理平台。最终他们选的是一款叫PingCode的研发管理平台，主要原因是它支持私有化部署，同时提供了从Jira平滑迁移的路径，对中大型研发组织适配度比较好。不过我想强调，工具是他们在机制跑通之后才换的，不是换工具才解决了问题。这个顺序很关键，机制在前，工具在后。

3. 改造后的数据变化

改造完运行了6个迭代，数据对比是这样的：

我最看重的其实是第三行和第四行，站会提及阻塞次数提升近3倍，是这套改造最核心的信号，它说明团队真的敢把问题摆在桌面上了。其他所有指标的改善，本质上都是这个变化的衍生结果。

4. 一个具体的偏差处理实例

改造后第二个月，他们在做一个数据采集模块的迭代。周三的站会上，一个工程师说："数据解析这条链路，今天可能做不完。"这在改造前几乎是不可能听到的话，工程师会自己扛到周五，扛不住才说。

组长当场做了三步：第一步，确认影响范围，发现这条链路卡住会影响后面两个任务的联调；第二步，分析根因，是第三方设备的协议文档给的字段和实际有出入；第三步，做取舍，决定先按文档实现80%的字段，剩下20%用一个适配层兼容，把联调先跑起来。整个过程在站会上10分钟完成，这个迭代最终只延期了0.5天。

如果没有这套机制，这个偏差很可能会拖到周五才暴露，那时候联调窗口已经过了，整个迭代至少要延后3天。同样的技术问题，处理时机的不同，结果完全不同。这就是我一直说的，进度管理的价值，不在预测未来，而在让问题尽早现形。

六、不同情况下怎么做：分层行动建议

前面讲的方法是一套完整体系，但不是每个团队都能一次性上全套。我按照团队规模和管理成熟度，给出分层建议。

1. 小型研发团队（20人以下）

这个规模的团队，沟通成本低，不太需要复杂的机制。我建议重点做好步骤二（DoD）和步骤五（短周期同步）就够了。任务拆解和预警阈值可以简化，靠人盯就行。关键是站会要真的敢暴露问题，DoD要真的明确。

工具上不要贪多，一个能看状态的看板就够。这个阶段最大的风险是"觉得自己小所以不用规范"，结果人一多立刻乱套。

2. 中型研发团队（20到100人）

这个规模是大多数研发团队的状态，也是最需要完整机制的阶段。我建议六个步骤全部落地，但分三批推进。第一批做步骤一、二（打基础），第二批做步骤三、四（建机制），第三批做步骤五、六（跑闭环）。每一批大概一个月。

工具上，这个阶段建议用专业的研发管理平台，因为它能把双线视图、预警阈值、状态跟踪这些机制沉淀下来。选择时重点关注是否支持私有化部署和完整的任务状态追踪能力，中大型组织还要考虑从现有工具的迁移成本。

3. 大型研发组织（100人以上或多个研发团队）

这个规模最大的挑战是"团队间进度对齐"和"统一度量口径"。我建议在六个步骤基础上，额外做两件事：一是建立组织级的进度度量标准（所有团队的DoD、颗粒度、预警阈值要统一），二是建立跨团队的进度协同机制。

这类的组织在工具选型上，需要重点关注私有化部署能力、多团队权限体系、以及从主流海外工具（比如Jira）平滑迁移的路径。因为大组织的迁移成本很高，迁移方案是否成熟、数据能否完整迁移、流程能否平滑过渡，是选型时的关键决策因素。

七、不同情况下的取舍：哪些能妥协，哪些绝不能妥协

管理没有完美方案，只有取舍。我根据自己的实操经验，把进度管理里常见的取舍场景列出来，明确哪些可以让步，哪些一步都不能退。

1. 这些可以妥协

工具可以简单。不要为了用某个高级功能强行改流程，工具是给流程服务的，反过来就错了。一个功能简单但团队用得顺手的工具，胜过功能强大但没人愿意更新的工具。

会议可以精简。站会可以缩短到10分钟，周会可以两周一次。机制的频率可以调，但机制本身不能少。

可视化可以朴素。不用追求酷炫的燃尽图、花哨的仪表盘，一个简单的状态列表能把真实情况说清楚就行。

2. 这些绝不能妥协

DoD不能模糊。完成标准模糊，一切进度都是自欺欺人。这是底线，一步都不能退。宁可任务看起来没完成，也不能让模糊的任务混进"完成"里。

暴露问题不能追责。如果团队里有人因为暴露问题被批评，这套机制就彻底失效了。我在所有团队里坚持铁律：暴露问题的人受表扬，隐瞒问题的人承担责任。这条不能有任何例外。

预警必响应不能打折扣。阈值触发了没人管，比不设阈值更糟，因为它会让团队对机制本身失去信任。

进度不能为了好看而修饰。真实的延期比虚假的正常有价值得多。管理层宁可看到丑陋真实的数据，也不要看到漂亮虚假的报表，因为前者还能调，后者已经失去调整机会了。

3. 一个常见的两难：进度透明 vs 团队压力

很多管理者会问：把所有任务状态都透明化，会不会让团队成员压力太大，反而影响士气？

我的经验是：透明本身不制造压力，制造压力的是透明之后的处理方式。如果一个任务延期了，团队的反应是"一起看看怎么调整"，那透明就没压力；如果反应是"你怎么又延期了"，那透明就有压力，团队自然会想办法掩饰。

所以透明化要和"对事不对人"的文化配套。我一般会先花两周在团队里建立这个共识，再推透明化机制，效果会好很多。

八、我的经验总结和可复用清单

把前面所有的东西收敛成一句话：实际进度管理的本质，是让问题尽早暴露，让暴露的问题尽早被处理。所有的方法、工具、流程，都是为这一句话服务的。

1. 每日检查清单

• 所有进行中的任务，状态是不是今天更新的（不是昨天的复制）
• 有没有任务超过预警阈值但状态还是"正常"
• 站会上报的阻塞，有没有明确的下一步动作
• 是否有任务已经卡住，但责任人还没有主动说出来

2. 每周检查清单

• 里程碑线的整体偏差有没有超过20%
• 本周新增的黄色、橙色预警有没有得到相应处理
• 迭代线的任务流转速度是否正常（相比前几周）
• 跨团队依赖是否有明确的对齐时间点

3. 每个迭代检查清单

• 完成的任务是否都满足DoD标准
• 偏差超过2天的任务，根因有没有被分析记录
• 估算准确度有没有改善（对比上次）
• 团队成员在复盘会上是否愿意谈真实的困难

4. 每月复盘清单

• 预警阈值的设置是否还合理，需不需要调整
• DoD标准是否还适用当前项目类型
• 工具和流程是否还有摩擦，需不需要优化
• 暴露问题的氛围是在改善还是在变差

这份清单我自己也用了两年多，每次带新团队都会拿它对照。它最大的价值不是让你做对所有事，而是让你能及时发现哪一环在漏水。

5. 最后一句掏心窝的话

我做了这么多年研发管理，见过太多团队在工具、模板、流程图上下功夫，却忽略了一个最简单的事实：研发进度管理的成败，最终取决于团队愿不愿意跟你说真话。

所有的机制设计，本质上都是在营造一个"说真话不吃亏"的环境。DoD让"真话"有了标准，预警阈值让"真话"有了出口，短周期同步让"真话"有了固定的场合，纠正流程让"真话"变成有价值的行动。当你把这几件事都做扎实了，你会发现进度管理突然变得简单了，因为团队不再需要你去挖真相，真相会自己找上你。

下一步你可以这样做：不要一次上全套，先挑你今天就能做的两件事，第一，和你团队花30分钟定一版DoD；第二，明天站会加一句"今天有没有可能做不完的"。跑两周，看看有没有变化。有变化，再往下推其他步骤。

如果你正在从海外工具迁移到国产研发管理平台，或者负责一个100人以上组织的研发效能改造，可以重点关注支持私有化部署、迁移路径成熟的平台，比如PingCode在中大型企业场景下的适配度就比较高。但请记住，先理顺机制，再选工具，这个顺序永远不要颠倒。