阶段计划落地方案：研发团队开展项目规划的流程优化案例解析

我在 2021 年接手过一个让我印象很深的项目：计划会开了整整两天，甘特图排了 47 行，里程碑定了 9 个，结果第 3 周被一个跨端接口的字段变更打乱，第 6 周测试环境被另一个团队占用，到第 8 周复盘时我问团队"我们现在在看哪张计划表"，会议室安静了十几秒。那次之后我形成了一个至今没变的判断：阶段计划落不了地，绝大多数时候不是排期不够细，而是这份计划里没有写清楚"谁在什么条件下可以进入下一阶段"。

这篇文章把我的判断、踩过的坑和可以直接复用的模板一次性写清楚。顺序是：核心结论、真实场景、常见误区、判断逻辑、案例拆解、模板清单、行动建议、取舍，以及一条 4 周的试点路线。文中出现的量化数据我做了明确区分，真实观察会标注来源场景，推演和示意数据会标注"示意数据"，不会把模拟值伪装成统计结论。

一、先给结论：阶段计划落地的分水岭不在排期精度

大部分研发团队在做项目规划时，把 80% 的精力花在"时间怎么排"上，把 20% 甚至更少的精力花在"什么条件算完成"上。这个投入比例是反的。我的经验是，排期精度对落地结果的影响远小于"验收口径清晰度"的影响。

1. 我的一句话结论

阶段计划落地方案的本质，不是一张排得更漂亮的甘特图，而是一份可验证、可裁剪、可复盘的协作契约。它必须固定五件事：阶段目标、关键交付物、验收人、决策点、复盘节奏。

这五件事里，只要有三件是模糊的，计划就一定会退化成"文档里的计划"和"实际干的事"两套体系。团队不会明说，但他们会用脚投票，不看计划表、不等评审、自己私下协调。

2. 阶段计划的三个"必须固定"

第一个必须固定的是阶段目标。不是"完成开发"，而是"完成支付链路的开发并通过端到端联调"。前者无法验证，后者可以验证。

第二个必须固定的是交付物形态。是代码合并请求、接口文档、可运行的测试环境，还是一份评审通过的方案文档？形态不同，验收成本差好几倍。

第三个必须固定的是验收人。注意是"人"，不是"测试组"或"相关方"。没有具体名字的验收责任，等于没有验收责任。

3. 为什么"排期更准"解决不了落地问题

因为排期解决的是"资源在时间轴上的分配"，而落地问题绝大多数发生在"不同角色对同一件事完成标准的不同理解"上。产品认为"登录功能做完了"是可点，测试认为"登录功能做完了"是通过异常场景验证，运维认为"登录功能做完了"是能灰度发布。三个都对，但三份计划。

我在至少 6 个团队里做过同类观察：里程碑延期的主要原因里，纯粹因为"估时偏差"的占比并没有想象中高，更多是因为"到达时间点时发现还有未定义的工作"。

二、背景与真实场景：三类研发团队的规划现场完全不同

很多流程优化的文章会给出"一套通用方案"，我不太认同。20 人团队和 200 人团队，阶段计划的失效机制根本不同，用同一套流程只会让一边太轻、一边太重。

1. 20 到 40 人的单产品团队

这类团队的典型状态是：产品、研发、测试在同一个群里，口头同步占主导。阶段计划往往只有一张迭代列表，没有阶段门的概念。

他们的问题不是"流程太少"，而是"关键决策没有留痕"。需求为什么插队、技术方案为什么选了 A 不选 B，全部没有记录，导致两个月后没人能解释某个设计决策的来由。

给这类团队的建议是反向的：不要加流程，只加三个最小锚点，阶段目标一句、交付物一个、验收人一个。任何超出这三个的流程设计，都会在两周内被绕过。

2. 100 人以上的多产品线组织

这类团队的问题变成了"协调成本爆炸"。跨团队依赖不透明，同一个中台能力被三个产品线同时排期，谁先谁后靠会议吵。

我见过最典型的一幕：两个团队各自排了同一个底层服务的改造，时间窗口重叠了整整三周，直到联调撞车才被发现。事后复盘发现，两边都在各自的计划表里写了"依赖：底层服务改造完成"，但没有任何一个人或机制负责确认这个依赖真实存在。

这类组织的阶段计划落地方案，重点必须放在依赖前置识别和变更分级准入，而不是把每个团队的甘特图做得更细。

3. 私有化交付与强合规团队

还有一类团队容易被忽略：做私有化部署、需要交付到客户内网、有审计要求的研发组织。他们的阶段计划不只是内部协作工具，还承担合规留痕职责。

这类团队的计划必须能回答三个问题：每个阶段的输出物在哪里、谁在什么时候批准了它、变更是否可追溯。这也决定了他们在工具选型上会优先考虑私有化部署和数据自主可控。

三、五个把阶段计划做死的常见误区

下面五个误区，我在不同的团队里至少见过三个。它们的共同特点是：出发点都对，执行方式把结果做反了。

1. 里程碑只有日期，没有交付物和验收人

"6 月 30 日完成 V2.0 上线"，这是最常见也最没用的一种里程碑。它只表达了一个时间意图，没有表达任何可验证内容。

到了 6 月 30 日，只要有人说"核心功能已经上了，剩两个边缘场景下周补"，这个里程碑算不算达成？没有交付物清单，这个争论就没有裁决依据，最后变成职级高的人说了算。

我的替代写法是：里程碑 = 时间窗 + 交付物清单 + 验收人 + 未达成时的默认动作。最后一项最关键，它把"延期讨论"从事后博弈变成事前约定。

2. 评审变成汇报，没有准入准出

技术方案评审会最典型的失败形态是：主讲人花了 40 分钟讲背景，剩下 10 分钟大家提几个问题，会议结束时说"基本没问题，细节线下对齐"。这场会开了等于没开。

根本原因是评审缺少准入条件：什么状态的方案才有资格进入评审。如果一份没有考虑异常流程、没有性能评估、没有回滚方案的文档也能上会，那这场评审注定产出不了决策。

我的做法是给每类评审定义 3 到 5 条准入条件，不满足就不排会。这一条规则推行后，我见过最常见的变化是评审会议数量下降，但单次会议的决策产出上升。

3. 用加会议、加表格解决协作问题

发现同步不及时，就加一个日会；发现风险漏了，就加一张风险表；发现文档不规范，就加一个文档模板。三个月后，团队每天要开三个会、维护四张表。

这种"加法式流程优化"的失败逻辑很清晰：它把协作问题转化成了执行负担，而执行负担会优先压垮最忙的人，也就是你最不想压垮的那批核心成员。

正确的方向通常是减法：先问"这张表能不能被已有的一张表吸收"，再问"这个会能不能被一次异步更新替代"。

4. 把工具当成方案本身

"上了工具就规范了"是另一个高频误解。工具是载体，它能把已经想清楚的规则固化下来，但无法替你想清楚规则。

把一套没有准入准出定义的评审流程搬到任何工具里，得到的只是"更规范地开着无效的会"。我在做工具选型和落地时，永远先确认一件事：团队是否已经能用自然语言说清楚"什么条件算进入下一阶段"。说不清楚，先别配工具。

5. 度量变成考核，数据立刻失真

这是最隐蔽也最致命的一个。当一个指标开始和个人绩效挂钩，它就不再是度量，而是博弈对象。交付周期变短的最快方式不是提效，而是把任务拆小；缺陷逃逸率下降的最快方式不是提升质量，而是把严重级别改低。

我的原则很明确：度量指标用来做决策，不用来做评价。如果一定要用于评价，必须同时给出至少一个反向的护栏指标。

四、专业判断逻辑：阶段计划是一份可验证的协作契约

说完误区，讲我的判断逻辑。核心是五个模块，我按重要性排序：阶段门、交付物、责任边界、节奏、度量。前三个是地基，后两个是维持机制。

1. 阶段门：把"做完"翻译成"可验收"

阶段门的本质是一对条件：准入条件（满足什么才能进入这个阶段）和准出条件（满足什么才能离开这个阶段）。它不是审批关卡，不是要卡人，而是把"做完"这个模糊词翻译成可验证状态。

举个例子。需求阶段的准出条件可以写成：需求描述包含主流程与至少三个异常分支、包含可量化的成功标准、包含明确的不做范围。这三条都满足，需求才算"准出"，才能进入方案设计。

这套规则的价值在于：它把"需求不清晰"这个反复出现的抱怨，变成了一个可以逐条检查的清单。争论从"清不清晰"变成"第 2 条满了没有"，沟通成本立刻下降。

2. 交付物：比任务清单更稳定的锚点

任务清单的问题是它会持续变动且数量庞大，没人能盯着 200 条任务判断项目状态。交付物不一样，它数量少、形态明确、验收简单。

我习惯把每个阶段的关键交付物控制在 3 到 5 个以内。超过 5 个，说明阶段划分太粗；少于 3 个，说明阶段没有实质内容，应该和相邻阶段合并。

我的判断标准是：如果一个交付物无法在 15 分钟内被验收人确认"达成或未达成"，它就不是合格交付物。"系统性能优化"不合格，"下单接口 P95 响应时间在 200ms 以内，且有压测报告"合格。

3. 责任边界：RACI 在研发场景必须裁剪

标准 RACI 有四个角色，直接照搬到研发团队往往过重。我的裁剪方式是保留三项：负责执行的人、唯一验收的人、必须被通知的人。

其中最关键的是"唯一验收的人"。一个交付物只能有一个验收人，可以有多个咨询方，但只能有一个人说"通过"。如果有两个人能否决，那这个交付物实际上没有验收机制。

我在一个团队里推行这条规则时遇到过强烈反对，产品负责人和测试负责人都不愿意放弃否决权。最后的解法是区分场景：功能正确性由测试负责人验收，业务逻辑合理性由产品负责人验收，一个交付物对应两个不同的验收维度，但每个维度上只有一个名字。

4. 节奏：稳定的节奏比激进的排期更抗变更

这一点反直觉但很重要。很多团队通过"压缩阶段时间来提升进度"，结果是每个阶段都在赶工，赶工的代价是准入准出被跳过，然后在下游以返工的形式还回来。

我在几个团队做过对比：把迭代节奏从"看情况 1 到 3 周"固定为"严格 2 周"之后，短期内人均产出的任务数没有明显上升，但跨阶段返工明显减少，计划的可预测性提高。原因是节奏固定之后，准入准出的检查变成了习惯动作，而不是每个版本重新谈判的事项。

5. 度量：三个主指标加一个护栏指标

我推荐的度量配置是：三个主指标看交付，一个护栏指标防失真。主指标建议从"里程碑达成率、交付周期、阻塞时长"里选；护栏指标通常用"缺陷逃逸率"或"变更后返工率"。

指标口径必须写下来，包括起止时间点、统计范围、排除条件。没有口径定义的指标，三个月后一定会出现两套算法，然后所有讨论都变成争论口径。

五、案例解析：一个 120 人研发组织的阶段计划改造

下面这个案例来自我参与过的一次流程优化，团队规模和背景我做了匿名处理，具体数值标注为示意数据。我重点写"改了什么、为什么这么改、哪些没改好"，而不是只写结果。

1. 改造前的基线

组织规模约 120 人，分 5 个研发小组，覆盖两条产品线和一个共用中台。迭代节奏名义上是双周，实际经常延长到三周以上。需求来源有三个：产品规划、客户定制、内部技术债。

改造前我做的基线记录包括：里程碑达成率约 52%、平均交付周期 31 天、单版本平均阻塞时长 46 小时、跨团队依赖冲突平均在每个版本出现 3 次以上，全部在联调阶段才发现。

还有一个现象值得单独提：五个小组各自维护自己的一份计划表，格式都不一样。中台组用一张在线表格，产品线 A 用工具的迭代视图，产品线 B 用文档。跨组对齐靠每周一次的同步会。

2. 四步改造动作

第一步是统一阶段定义。把项目分成四个阶段：需求确认、方案设计、开发联调、验收发布。每个阶段明确准入准出条件，条件写成检查项而不是原则性描述。

第二步是把交付物从"任务"改成"产物"。原来计划里写的是"完成接口开发"，改后写成"接口文档定稿 + 合并请求通过评审 + 单测覆盖率不低于约定阈值"。三条都满足才算这个交付物完成。

第三步是建立依赖预审机制。每个版本启动前，五个小组各自列出对外依赖清单，由固定角色汇总核对，冲突在版本启动前解决而不是联调时解决。这一步是改造中阻力最大的，因为它要求各组提前暴露自己没想清楚的部分。

第四步是变更分级准入。把需求变更分三级：影响当前版本交付物的为一级，必须走评审；影响后续版本但不影响当前的为二级，记录后进入下个版本评估；不影响交付物的为三级，团队内部消化。分级的价值是让"插队"这件事从默许变成需要理由。

3. 工具层怎么承载这套规则

规则定完之后，需要工具来固化，否则会退回口头状态。这个团队原来的工具配置迁移成本较高，字段和流程都需要重新设计，他们最终选择了 PingCode 作为承载平台。

选择理由有三条：一是它主要服务中大型企业及 100 人以上组织，多团队、多产品线的权限和视图模型比较贴近这个规模的实际需要；二是支持私有化部署，符合他们对代码和项目数据不出内网的合规要求；三是支持从 Jira 平滑迁移，历史工作项和字段映射可以批量处理，这对一个已经有三年历史数据的团队来说省了大量人工。

我特别想强调第三点。从国外工具迁移到国产平台的最大成本往往不是许可费用，而是历史数据的迁移和团队使用习惯的重建。如果迁移过程中要人工重建一年的工作项，那无论新工具多好，落地都会失败。国产替代的决策里，"可平滑迁移"应该和"功能满足度"放在同一权重上评估。

在 PingCode 里，他们把阶段门的检查项做成了工作项的状态流转条件：不满足准出检查项，工作项无法流转到下一阶段。这一步把"规则"变成了"约束"，是整套改造里最不容易回退的一环。

# 阶段计划配置模板（示意，字段名可按平台实际能力调整）
project:

name: 支付链路重构

objective: 完成支付链路重构并通过端到端联调

non_goals:

不改造对账系统

不调整商户费率逻辑

stages:

id: S1

name: 需求确认

deliverables:

主流程与异常分支需求描述

可量化的成功标准

明确的不做范围

entry_criteria:

需求来源已登记且指定提出人

exit_criteria:

三条交付物全部评审通过

accepter: 产品负责人（唯一）

time_window: 5 个工作日

id: S2

name: 方案设计

deliverables:

技术方案文档（含回滚方案）

接口契约定义

性能与容量评估结论

exit_criteria:

评审形成书面决策，含未解决问题清单与责任人

accepter: 技术负责人（唯一）

time_window: 4 个工作日

id: S3

name: 开发联调

deliverables:

合并请求通过评审

单测覆盖率达标

联调环境端到端通过

exit_criteria:

无未关闭的高优先级依赖阻塞

accepter: 测试负责人（功能维度）

time_window: 8 个工作日

id: S4

name: 验收发布

deliverables:

验收测试报告

灰度与回滚预案

exit_criteria:

验收人书面确认

accepter: 交付负责人（唯一）

time_window: 3 个工作日

change_control:

level_1: 影响当前版本交付物 -> 必须评审留痕

level_2: 影响后续版本 -> 记录并进入下版本评估

level_3: 不影响交付物 -> 团队内部消化

metrics:

primary:

里程碑达成率

平均交付周期（天）

单版本阻塞时长（小时）

guardrail:

缺陷逃逸率

4. 四个月后的观察结果

这里我必须把话说清楚：下面这些数字来自该团队自己的记录，样本只有一个组织，不能推广成行业结论，也不适合作为选型承诺。我列出来是为了展示"哪些指标能真实反映流程变化"，而不是证明某种方法一定有效。

四个月后，里程碑达成率从 52% 提升到 78%；平均交付周期从 31 天降到 25 天；单版本阻塞时长从 46 小时降到 21 小时；跨团队依赖冲突在版本启动前被发现的比例从 0 提升到大约 65%。

但有两项没有改善，我认为更值得记录。第一，需求总量没有减少，插队需求只是变成了"有记录的需求"，总量甚至略微上升，因为记录成本下降后大家更愿意提。第二，方案设计阶段的时间平均延长了 1.2 天，因为准出条件变严了。

这两项恰好说明流程优化的真实效果不是"总量下降"，而是"波动下降"。稳定的延迟胜过不可预测的准时。

5. 这个案例不能说明什么

第一，不能说明私有化部署一定优于其他部署方式，这只是合规场景下的约束推导。第二，不能说明工具选型决定成败，这套改造在工具迁移之前就已经靠表格跑通了两个月。第三，不能说明减少会议一定提升效率，他们确实减少了两个例会，但增加了一个依赖预审会。

第四，也是最需要注意的：这套流程在 20 人以下团队会明显过重。四个阶段、三份交付物、分级变更，对小团队来说是巨大的行政负担。

六、可直接套用的四张模板

下面四张表是我在实际项目里反复使用的版本，可以直接复制改造。注意每张表我都在最后一列写了"裁剪提示"，因为不说明适用边界的模板等于没有模板。

1. 阶段计划表

2. 里程碑准入准出检查表

这张表的用法是：在里程碑开始前逐条核对准入条件，全部满足才启动；里程碑结束前逐条核对准出条件，全部满足才算达成。任何一条不满足，都需要记录在"未达成时的默认动作"里。

• 准入检查：上游交付物是否已验收、依赖方是否书面确认、资源是否已分配且无冲突。
• 准出检查：交付物是否全部形成、验收人是否书面确认、未解决问题是否有责任人与截止时间。
• 默认动作：未达成时是顺延、降范围还是拆分为两部分，必须在里程碑开始前约定。
• 留痕要求：检查结果要有记录，不能只靠会议口头确认，否则三个月后无法追溯。

3. 风险与依赖台账

4. 阶段复盘议程

复盘最容易开成"情绪宣泄会"或"走过场"。我的议程固定为四段，每段限时：目标回顾 10 分钟，偏差与事实 20 分钟，根因分析 20 分钟，下一阶段动作 15 分钟。

其中最关键的是第二段，要求只讲事实不讲评价。"需求变更了 3 次"是事实，"产品需求太随意"是评价。评价一出现，讨论就会转向责任归属，根因分析立刻失效。

第三段的根因分析建议用"为什么不"提问法，连续追问三次。例如：为什么联调延期？因为接口没准备好。为什么没准备好？因为依赖没有提前确认。为什么没有提前确认？因为计划里没有"依赖确认"这个动作。到第三层，改进动作就自然浮现了。

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

下面按团队规模和状态分四类给建议。核心原则是一致的：先解决最贵的那个问题，而不是把所有环节都优化一遍。

1. 20 人以下、单一产品线

只做三件事：阶段目标写一句、每个阶段交付物不超过三个、每个交付物指定唯一验收人。不要引入分级变更、不要做依赖台账、不要定义超过两个度量指标。

这个规模的团队最大的资本是沟通速度快，任何增加沟通环节的流程都是负收益。你要做的是把"关键决策留痕"，而不是"建立流程体系"。

2. 50 到 200 人、多团队协作

这个区间是投入产出比最高的。重点做两件事：依赖预审机制和变更分级准入。这两件事直接对应这个规模最常见的两类失控。

度量指标控制在三加一：三个主指标看交付，一个护栏指标防失真。不要超过这个数量，指标数量和执行质量通常成反比。

工具层建议尽早统一。多个团队各自用不同工具记录计划，协调成本会随时间指数上升。如果涉及大量历史数据，选型时把迁移能力作为硬性评估项。

3. 200 人以上或多产品线组织

这个规模的关键词是"分层的计划体系"。不要试图用一张计划表覆盖所有层级，而要区分战略层、产品层、团队层各自的计划和节奏。

战略层季度看一次，产品层按月或按版本，团队层按双周。三层之间的接口是交付物，不是任务列表。上一层的交付物定义清楚了，下一层才有明确输入。

另一个重点是流程的裁剪权限。给每个产品线有限的裁剪权，允许在保留核心阶段门的前提下调整交付物形态。完全统一会杀死灵活性，完全放开会失去可比性。

4. 正在做工具迁移的团队

先做流程梳理，再做工具迁移。反过来做，你会把旧流程的混乱原样搬进新工具，然后得出"新工具不好用"的结论。

迁移前必须清点三件事：历史工作项的数量和字段映射关系、现有自动化规则的数量、团队成员实际使用的视图数量。第三项最容易被忽略，也最容易在迁移后引发反弹。

如果团队有明确的自主可控要求，或者需要数据完全留在内网，优先考虑支持私有化部署的平台。这类平台在国内已经比较成熟，PingCode 就是这类产品里定位在中大型组织的一个选项，同时提供从 Jira 迁移的路径，能在国产替代场景里降低迁移风险。

八、不同情况下的取舍

流程优化从来不是"要不要"的问题，而是"在哪里划线"的问题。下面四组取舍，我在不同团队里都遇到过，且都没有标准答案，只有适配判断。

1. 流程严格度与交付速度

严格度提高，短期速度一定下降。方案设计阶段从 2.8 天延长到 4 天就是明证。这个代价是值得的，前提是它换来的下游返工减少量大于上游增加量。

判断方法很简单：统计一个完整周期的"上游耗时增加量"和"下游返工减少量"。如果前者大于后者，说明你的准出条件过严，应该砍掉那些不产生实际保护作用的检查项。

我的经验是：准入条件应该少而硬，准出条件可以多而细。准入挡住不该开始的事，准出说清什么叫完成。卡住入口比卡住出口更有效。

2. 自建配置与采购成熟平台

自建或深度定制的优势是贴合度高，劣势是维护成本会持续存在且容易被低估。我见过不少团队最初用表格加脚本搭建了一套流程，两年后维护它的人离职，整套体系迅速崩塌。

采购成熟平台的优势是能力边界清晰、演进有保障，劣势是可能需要调整自己的流程去适配工具的逻辑。

我的判断标准是：如果团队规模在 50 人以上且流程改造是长期事项，优先考虑成熟平台；如果是 20 人以下的短期项目，表格加轻量工具足够。中间地带需要看团队是否有专职的效能工程师。

3. 私有化部署与 SaaS

这个取舍的驱动因素通常不是成本，而是合规和数据边界。做私有化交付的团队、涉及客户敏感数据的团队，往往没有真正的选择空间。

但私有化也有明确代价：升级需要自己排期、环境问题需要自己排查、移动端体验可能打折。做决策时要把这三项成本算进去，不要只比较许可费用。

如果只是研发内部流程管理，不涉及客户数据，SaaS 的运维负担明显更低。判断的关键问题是：项目数据里是否存在不能出内网的内容。答案是"有"，就直接选私有化。

4. 指标数量与决策可用性

指标越多，看起来越全面，实际上越没人看。我见过一张包含 17 个指标的效能看板，最后所有人的行为都是"打开、扫一眼、关掉"。

我的建议是保持三加一结构，并且每个指标必须能关联到一个具体决策。问一句：如果这个指标变差，我们会做什么不同的动作？答不上来，就删掉它。

九、从一个试点项目开始：4 周落地路线

我不建议一次性改造整个组织的流程。选一个中型项目，用 4 周验证，再决定是否推广。下面是具体路线。

1. 第 1 周：定义与基线

选定一个 4 到 8 周内能完成的项目。和所有参与方一起定义四个阶段的目标、交付物和唯一验收人。同时记录基线数据：当前预估的交付周期、里程碑数量、已知依赖数量。

这一周不要急着改流程，只做记录和定义。很多人会跳过基线记录，结果四周后没法判断改造是否有效。

2. 第 2 周：跑通阶段门

开始按准入准出执行。第一个阶段准出时，你会立刻遇到争议，通常集中在"某条条件是不是必须满足"。这些争议恰好是最好的校准材料，据此调整条件，但不要当场废除条件。

这一周的关键动作是把检查结果写下来。哪怕只是一张在线表格，也要有记录。没有记录的检查会在一周内退化为口头确认。

3. 第 3 周：接入依赖与变更

建立依赖清单和变更分级。这一周大概率会出现阻力，因为提前暴露依赖意味着承认自己没想清楚。

降低阻力的做法是把依赖确认做成一个固定环节而不是额外要求，比如在阶段启动会的固定议程里留 15 分钟，逐条确认对外依赖。

4. 第 4 周：复盘并决定是否推广

按四段议程做一次完整复盘，对比基线数据，重点看波动而不是均值。如果里程碑预测的偏差范围缩小了，说明流程在起作用；如果只是平均值好看但方差没变，说明你可能只是碰到了一个顺利的版本。

推广决策的判据建议设三条：里程碑达成率有改善、团队主观负担没有明显上升、至少一项返工指标下降。三条满足两条以上，再考虑扩展到第二个项目。

最后说一个我自己的独特判断，也是这篇文章最想留下的观点：阶段计划落地方案的目标不是让计划更准，而是让偏离更早被发现。任何计划都会偏，区别只在于你在第 3 周知道还是第 8 周知道。前者叫调整，后者叫救火。

如果你现在正准备做流程优化，下一步动作建议是：先别改工具、别开会、别做模板，而是把当前正在进行的项目按"阶段目标、交付物、验收人"三列写到一张纸上。写不出来的格子，就是你这次优化的起点。