项目目标如何做好阶段目标？项目负责人效率提升与操作步骤

我接手过一个已经延期 11 周的项目，第一件做的事不是重排甘特图，而是把原计划里那份"第 1，4 周需求调研、第 5，8 周开发、第 9，12 周测试"的阶段表整份推翻。原因很简单：它按时间切，不按交付切。团队每周都在忙，但当我问"这一阶段结束的那一刻，什么算完成"时，会议室里 9 个人给出了 6 种答案。

这不是个例。在我复盘过的几十个项目里，阶段目标失效的第一原因几乎从不是"执行不力"，而是阶段目标本身就没有可验收的定义。它被写成了时间表、任务清单、或者一句"完成开发"，然后所有人用各自的想象去填空白。空白越多，返工越多，负责人的时间就越被拖进救火里。

这篇文章我想讲清三件事：阶段目标到底该怎么定、项目负责人的效率瓶颈究竟在哪里、以及在真实组织里可以怎么落地。我会给出完整的操作步骤、字段模板、判断标准和取舍建议，你可以直接拿去改下一个阶段的计划。

一、核心结论：阶段目标不是时间切片，而是阶段交付契约

先把结论摆在前面，后面所有内容都是围绕它展开的。阶段目标的本质是一份"阶段交付契约"：它规定这一阶段结束时必须交出什么、由谁交出、达到什么标准、在什么依赖条件下、由谁拍板验收。时间只是契约里的一个字段，不是契约本身。

1. 阶段的三种切法，决定了后面所有麻烦

我观察到一个规律：团队怎么切阶段，基本决定了它会遇到什么类型的麻烦。按时间切，麻烦是"到点了但没交付"；按任务切，麻烦是"都做了但拼不起来"；按交付切，麻烦是"要花时间想清楚验收标准"，而这恰恰是最值得花的时间。

按时间切的典型后果是"进度幻觉"。第 8 周到了，所有人都在忙，你只能填个"完成 80%"。这个 80% 站不住脚，因为它没有分母，你不知道剩下的 20% 里藏着多少未暴露的技术风险、多少没对齐的口径、多少跨部门的等待。

按任务切的问题在于，任务天然是"动作"，而目标是"结果"。当阶段目标写成"完成接口联调、完成单元测试、完成文档"，团队会非常自然地用"我提交了"代替"它能用了"。这两者在验收时的差距，往往就是一次全量返工。

2. 三个自检问题，一秒筛掉不合格的阶段目标

我现在带项目时，会拿三个问题去卡每一个阶段目标，任何一个答不上来就说明它还不成立。这三个问题我在不同行业、不同规模的项目里用过，命中率非常高。

• 验收问题：阶段结束那天，如果我拉着一个不懂这个项目的人来，他能不能凭这份描述判断"做完了还是没做完"？
• 降险问题：这个阶段过完，项目最大的那条不确定性降低了吗？还是我们只是把时间用完了？
• 责任问题：这件事如果卡住，第一责任人是谁？他能调动什么资源？升级到谁？

如果三个问题都答得出来，这个阶段目标基本可以用。如果只能答出第一个，那它是个交付任务，不是阶段目标。如果三个都答不出来，那你面对的不是阶段目标，是一句愿望。

3. 效率提升的真正来源：不是时间管理，是损耗管理

很多人把"项目负责人效率提升"理解成个人时间管理：早起、番茄钟、四象限。这些有用，但天花板很低。项目负责人的效率真正的瓶颈在团队协作损耗上，返工、等待、重复沟通、无效会议，这四项加起来通常吃掉负责人 60% 以上的工作时间。

你没法通过"更专注"来消掉一次因为验收标准不清导致的返工，也没法通过"列待办"来消掉一次因为没人拍板造成的三天等待。能消掉它们的，只有把阶段目标相关的规则前置做对。

二、真实场景：阶段目标是怎么一步步失真的

抽象讲方法论价值有限，我更想还原几个我亲历的场景，你看看是否熟悉。这些场景覆盖了从立项到交付的常见断点，也是我后来做优化的切入点。

1. 场景一：立项会上达成共识，两周后各自理解

我在一家做企业服务的公司见过这样的项目。立项会上，老板说"这个季度把客户自助开票做完"，全场点头通过。会后产品理解为"做一个开票申请入口"，研发理解为"打通税务接口"，销售理解为"客户不用找客服了"。

三周后第一次演示，产品展示了一个漂亮的表单，研发说接口还没排期，销售问能不能自动推送发票到邮箱。三个人的理解都不算错，但拼不到一起。问题的根源是：总目标在立项会上被"口头对齐"了，但从来没有被写成任何一份有验收标准的阶段目标。

后来我给这个项目做的第一个动作，是把"完成客户自助开票"拆成四个阶段，并且每个阶段都写清楚交付物、验收标准和不做什么。仅仅这一步，就让后面三次评审会的时间从平均 90 分钟压缩到 35 分钟。

2. 场景二：阶段目标是任务清单的伪装

另一种常见情况是，阶段目标看起来很像目标，实际是任务清单换了个标题。比如"第一阶段：完成需求调研与方案设计"。这句话听起来没问题，但它没有任何可验收的信息。

调研到什么程度算完成？访谈几个人？方案设计是几页文档、要不要评审、谁评审通过？这些问题不回答，团队就只能靠猜，而猜的标准通常是"看起来差不多了"。

我见过一个团队因为这个原因，需求阶段重复做了三轮。第一轮访谈了 5 个客户，第二轮又说样本不够补到 12 个，第三轮发现之前的访谈提纲漏了关键场景。三轮加起来多花了 21 人天，而如果一开始就在阶段目标里写清"访谈 ≥ 10 个付费客户，覆盖 4 类使用场景，输出场景地图并通过业务方评审"，这三轮本来可以合并成一轮。

3. 场景三：跨部门项目里的责任真空

跨部门项目的阶段目标失真最严重，因为它的失败往往不是因为"做不出来"，而是因为"不知道该谁做"。我曾经负责过一个涉及 5 个部门的系统改造项目，某阶段的交付物是"完成数据迁移校验"。

这句话有两个部门都认为自己不负责：数据平台部觉得数据是业务方提供的，业务部觉得校验是技术活。结果这个阶段空转了 9 个工作日，直到我在周会上把它拆成"业务部提供迁移前后的对账口径并签字"和"数据平台部按该口径跑校验并出具差异报告"两条，责任才落地。

这件事给我的教训是：阶段目标里如果没有"责任人 + 决策人 + 升级人"这三个角色，跨部门项目就会出现责任真空，而且它会以一种非常安静的方式消耗时间，没人吵架，但事情不动。

三、拆解常见误区：五个把阶段目标做废的动作

这一节我按"错误表现，真实后果，纠正动作"的方式写，因为我在带团队时发现，直接给方法不如先让人认出自己正在犯的错。这五个误区覆盖了我见过的大多数失败模式。

1. 按时间平均切片，忽略交付物边界

错误表现：项目周期 12 周，就切成 4 个 3 周阶段，每阶段填上"开发""测试"这类词。

真实后果：阶段边界和真实的交付边界错位。一个模块的开发可能 2 周就完成了，另一个卡在依赖上要 5 周，但计划里它们在同一天"结束"。于是要么提前完成的人等，要么延后的人被压。

纠正动作：先识别项目里天然的交付断点，什么时候会有第一个可演示的版本、什么时候能通过第一个合规审查、什么时候能跑通一条完整业务流。用这些断点做阶段边界，再倒推时间。

2. 把阶段目标写成任务清单

错误表现：阶段目标栏里写的是"完成 A 接口、完成 B 页面、完成 C 文档"。

真实后果：团队用"提交了"代替"能用了"。验收时才发现接口能通但性能不达标、页面能开但流程走不通、文档写了但没有可执行的操作步骤。

纠正动作：把每条任务改成"结果 + 标准"的表达。不是"完成 A 接口"，而是"A 接口在 200 并发下 P95 响应 < 300ms，返回结构通过联调验收"。这一个改写动作，能消掉相当一部分末期返工。

3. 只追进度，不追质量和风险

错误表现：周会只问"进度百分比"，没人问"这个阶段最大的风险变了没有"。

真实后果：风险在暗处积累，直到阶段末期集中爆发。此时的修复成本是阶段初期的 5 到 10 倍，因为它已经和其他模块耦合了。

纠正动作：每个阶段目标里强制带一条"本阶段必须消除的风险"，以及一条"本阶段允许新增的已知风险上限"。让风险管理成为阶段目标的一部分，而不是附加动作。

4. 负责人亲力亲为，团队不担责

错误表现：项目负责人因为"进度紧张"，亲自去写文档、调接口、跟供应商，团队反而更被动。

真实后果：短期看似加速，长期造成两个问题：一是团队失去判断力，凡事等指令；二是负责人被拉进执行细节，失去对整体节奏和风险的感知。这是典型的"越忙越乱"。

纠正动作：明确负责人的三项不可替代动作，定阶段标准、解跨部门阻塞、做风险判断。其余全部下放，并且下放时要连"决策边界"一起给出去。

5. 没有变更机制，一改就乱

错误表现：需求变化时，直接口头调整，没人记录影响，下次复盘时说不清为什么延期。

真实后果：阶段目标失去权威性。团队开始"先做着看"，计划变成参考文档，节奏彻底失控。

纠正动作：设一条简单的变更规则：任何影响阶段交付物或验收标准的变更，必须记录"变更内容、影响范围、是否影响本阶段验收、由谁批准"四项。不求复杂，求有记录。

四、专业判断逻辑：阶段目标的五步操作法

前面讲了问题和误区，这一节给可执行的方法。我把阶段目标的制定拆成五步，每一步我都写清了目的、动作和输出物。这五步的价值不在于流程完整，而在于每一步都会产出一个可以被检查和质疑的实物。没有产出的步骤，就是没做。

1. 第一步：澄清总目标与约束条件

目的：把"想要什么"和"在什么条件下要"同时说清，避免后面在错误的假设上做拆解。

动作：拉上关键干系人，围绕五个维度问一遍，范围边界（做什么、不做什么）、质量标准（达到什么水平算合格）、成本约束（预算与人力上限）、时间约束（硬性截止日与可协商部分）、关键干系人（谁验收、谁有权叫停）。

输出物：一页纸的约束清单，明确写出"本项目不做的事"。

我特别强调"不做什么"这一栏。绝大多数项目的范围蔓延，都是从没人正式写下排除项开始的。当我把"本次不覆盖海外主体开票"写进约束清单后，后面至少省掉了两次范围讨论。

2. 第二步：选择阶段划分逻辑

目的：让阶段边界和项目本身的风险结构对齐，而不是和日历对齐。

动作：根据项目类型选一种主划分逻辑，必要时混合。常见有四类：按交付物（适合产品研发）、按里程碑（适合工程实施）、按风险关口（适合合规与安全相关）、按迭代周期（适合需求不确定的探索型项目）。

输出物：阶段划分逻辑说明，一句话写清"我为什么这样切"。

我一般的判断顺序是：如果需求不确定性高，优先按迭代周期切；如果有强外部节点，优先按里程碑切；如果技术风险集中在某几个点，优先按风险关口切。混用可以，但必须有一个主逻辑，否则阶段之间会出现重叠和空洞。

3. 第三步：定义阶段交付物与验收标准

目的：把"完成"变成一个可以被第三方判断的事实，而不是一种感觉。

动作：每个阶段至少写清四件事，交付物是什么形态、完成定义（Definition of Done）包含哪几条、质量门槛是多少、本阶段明确不做哪些延伸。

输出物：阶段目标表，字段包括阶段名、交付物、验收标准、质量门槛、排除项。

这一步是最容易被跳过的一步，也是最值得花时间的一步。我的经验是：在阶段目标上多花 2 小时写清验收标准，通常能在阶段末期省下 20 小时以上的返工和争论。这个比例在不同项目里会波动，但方向是稳定的。

4. 第四步：排依赖、定责任与决策人

目的：消除责任真空和隐性的等待时间。

动作：对每条交付物标注三类角色，执行责任人、验收决策人、升级对象；同时列出跨部门依赖项，标注依赖方的交付时间和承诺人。

输出物：责任与依赖矩阵，以及关键路径清单。

这一步里我最常发现的问题是"决策人缺位"。很多阶段目标里写了谁做，但没写谁拍板。结果执行人做到 80% 卡在某个取舍上，不敢决定，只能等。等待看起来不花钱，实际上是最贵的一种损耗。

5. 第五步：设检查点、预警线与变更机制

目的：让偏差在还能低成本纠正的时候被发现。

动作：为每个阶段设 1 到 2 个检查点，每个检查点明确要看的指标和预警阈值；同时定义变更的触发条件和审批路径。

输出物：检查点清单与变更记录表。

预警阈值必须具体。不要说"进度落后需预警"，要说"当关键路径上的任务连续 2 天未推进，或已完成任务数低于计划的 80%，触发预警"。可判断的阈值才会真的被使用。

五、具体案例与数据观察：一个中大型组织的阶段目标改造

这一节我讲一个相对完整的案例。这家公司规模在 300 人左右，研发约 150 人，属于典型的中大型组织，同时并行 7 到 9 个项目。他们的核心痛点是：阶段目标写在文档里，执行看在板上，两者长期不一致。

1. 改造前的真实状态

我进去的时候，他们每个项目都有一份阶段计划文档，但更新频率平均是 11 天一次。看板上的任务状态是每天更新的。这就形成了两套事实：文档代表承诺，看板代表现实，而没有人负责让两者一致。

结果是每次项目汇报会，前 40 分钟都在争论"到底现在是什么状态"。负责人自己也说不清，因为他手上的信息来自两个不同步的来源。这就是典型的"信息源不唯一"造成的效率损失，它不体现在任何一张工时表上，但真实存在。

2. 改造动作：三件事

我们没有做大动作，只做了三件事，但都做透了。

1. 统一阶段目标的唯一信息源。阶段目标不再是独立文档，而是直接作为项目计划中的一层结构，与执行看板同源。文档改为自动导出，不再手工维护。
2. 给每个阶段加三个必填字段：验收标准、阶段级风险、排除项。不填不允许进入下一阶段评审。
3. 设置阶段健康度看板，把"已完成任务占比""关键路径推进情况""阶段级风险变化"三个维度放在一屏，每周固定时间看一次。

这里我用的工具是 PingCode。选择它的原因不是功能清单长，而是它把"阶段/迭代目标"和"执行任务"放在同一个数据模型里，阶段目标不是文档附件，而是可被追踪的结构。PingCode 主要服务中大型企业及 100 人以上组织，这一点和这家公司的规模与并行项目数量是匹配的。另外它支持私有化部署，也支持从 Jira 平滑迁移，对于当时正在做国产替代评估的他们来说，这两条都省了不少事。

3. 改造后的数据观察

我记录了改造前一个月和改造后三个月的关键指标。数据来自他们内部的月度统计口径，不是行业基准，但内部前后对比是真实的。

这组数据里我认为最有价值的不是"救火时长下降 63%"，而是"一致率从 42% 到 96%"。因为它解释了其他所有变化的来源：当所有人看的是同一份事实，争论会消失，等待会缩短，返工会被提前发现。负责人省下的时间，本质上是从"确认事实"这件事里释放出来的。

4. 阶段目标字段定义示例

如果你想在自己团队里落地，可以直接参考下面这份字段定义。这是我们当时定稿的版本，写成结构化配置的形式，便于对应到工具里。

stage_goal:
stage_name: "阶段名称，例如 第一阶段：可演示版本"

business_goal: "本阶段要达成的业务结果，一句话"

deliverables:

name: "交付物名称"

form: "文档 / 代码 / 配置 / 报告 / 可运行环境"

location: "存储或访问位置"

acceptance_criteria:

"验收标准 1：可客观判断的陈述句"

"验收标准 2：带数值门槛的陈述句"

quality_gate:

performance: "例如 P95 响应 < 300ms @200 并发"

coverage: "例如 核心流程用例覆盖 100%"

review: "例如 通过架构评审与安全评审"

exclusions:

"本阶段明确不做的事项"

roles:

owner: "执行责任人"

approver: "验收决策人"

escalate_to: "升级对象"

dependencies:

item: "依赖项描述"

provider: "依赖方"

promised_date: "承诺时间"

risks:

must_eliminate: "本阶段必须消除的风险"

watch_list: "需持续观察的风险"

checkpoints:

date: "检查点日期"

metrics: "要看的指标"

threshold: "预警阈值"

change_rule: "变更触发条件与审批路径"

这份定义看起来字段不少，但真正填起来，一个有经验的项目负责人两小时内能完成一个阶段的定义。相比它在末期省下的时间和争论，这个投入非常划算。

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

方法不是普适的。我在不同规模的组织里做过类似的事，动作差异很大。这一节按团队规模和项目复杂度分三类给出建议，你可以直接对号入座。

1. 十人以下小团队：只做三件事

小团队最大的优势是沟通成本低，最大的风险是把非正式沟通当成正式约定。所以我不建议上重流程，只做三件事。

• 每个阶段写一句"完成定义"。不用表格，就一句话，但要能被判断。贴在团队可见的地方。
• 每个阶段指定一个决策人。通常就是负责人本人，但要公开说出来，避免大家互相等。
• 每周固定 30 分钟看一次偏差。只看两件事：关键路径推进了吗、最大风险变了吗。

小团队不要引入完整的关键路径、依赖矩阵、变更审批流，投入产出不成比例。等到并行项目超过 3 个、团队超过 15 人，再逐步加结构。

2. 三十到一百人的跨部门项目：建立最小可用的契约结构

这个阶段是大多数组织的"疼痛区"：跨部门协作多，但流程还没成型。我的建议是建立最小可用的契约结构，重点解决责任与依赖。

1. 阶段目标用统一模板，至少包含交付物、验收标准、责任人、验收人四个字段。
2. 建立依赖清单，每条依赖必须有一个承诺日期和一个具体承诺人，不接受"相关部门配合"这类表述。
3. 设置双向升级路径：执行人卡住超过 48 小时，可以升级到项目负责人；项目负责人卡住超过 3 天，升级到项目发起人。
4. 变更必须记录，但只记录影响阶段验收的变更，其余变更不必走流程，避免过度管理。

我特别推荐"48 小时升级"这条规则。它在很多团队里立竿见影，因为它把"等待"从一个隐性行为变成了一个有明确时间上限的显性行为。

3. 一百人以上、多项目并行组织：需要工具承载一致性

到这个规模，靠文档和会议维持一致性已经不现实。核心矛盾从"怎么定阶段目标"变成"怎么让几十个项目的阶段目标用同一套语言、同一个信息源呈现"。这时候需要考虑工具层的能力。

我的判断标准有四条，供你参考：

在满足这四条的产品里，PingCode 是我们在中大型组织场景下比较常用的一种选择，因为它同时覆盖了阶段/迭代目标与执行追踪，并支持私有化部署和从 Jira 平滑迁移。对于正在做国产替代评估的 100 人以上组织来说，迁移路径可预期这一点，往往比功能清单本身更重要。如果你所在的组织规模还没到这个量级，用表格加看板也能跑，不必提前上重工具。

七、不同情况下的取舍

做阶段目标管理，本质是一系列取舍。我见过很多团队试图"全都要"，最后什么都没落地。这一节把四组最常见的取舍摊开讲，并给出我的选择倾向和适用边界。

1. 阶段粒度：粗一点还是细一点

阶段粒度粗，好处是管理成本低、团队自主空间大；坏处是偏差发现晚，到了阶段末期才发现问题，修复成本高。粒度细，好处是反馈快；坏处是评审和同步成本上升，团队容易陷入"为交差而交差"。

我的选择倾向是：阶段数量控制在 3 到 6 个，单阶段时长控制在 2 到 6 周。超过 6 个阶段，管理开销会明显上升；短于 2 周的阶段，往往还没形成可验收的交付物，容易退化成任务清单。

这个区间的边界条件是：如果项目总周期短于 8 周，阶段可以只有 2 到 3 个，甚至可以按交付物直接用里程碑代替阶段；如果项目周期超过 12 个月，建议在阶段之上再加一层"波次"，避免一次规划太多。

2. 文档还是看板：形式之争背后是同步问题

这不是一个二选一的问题，真正要解决的是"信息源唯一"。文档适合承载需要完整阅读的内容，比如验收标准、风险说明；看板适合承载状态流转和每日推进。

问题出在两者分离：文档由负责人维护，看板由执行人维护，两边不同步。我的取舍是：阶段目标的核心字段必须与执行数据同源，文档只作为导出物存在，不手工维护。如果一个工具做不到这一点，那就退一步，把文档更新频率和看板绑定，比如每完成一个检查点必须同步一次文档，并在文档里明确"最后同步时间"。

3. 自建还是采购：看你的规模和维护意愿

五十人以下、项目类型单一的团队，自建一套表格加轻量看板完全可以跑，灵活且零采购成本。但自建的隐性成本在变更上：当你要加一个"阶段级风险"字段、要做跨项目统计、要控制权限时，改造成本会逐次累积。

一百人以上、多项目并行、有合规要求的组织，采购成熟平台的综合成本通常低于自建。这里的关键不是功能多少，而是数据模型是否天然支持"阶段目标与执行同源"。如果产品本身是把阶段目标当文档附件处理的，那你买回来的仍然是一套需要人工同步的系统。

4. 私有化还是 SaaS：先看合规，再看成本

这一条对多数团队来说不是偏好问题，而是约束问题。涉及客户数据、生产系统、财务信息的项目，私有化往往是硬要求；纯内部协同类项目，SaaS 的成本和迭代速度更有优势。

我的判断顺序是：先确认合规底线，再看数据敏感度，最后看运维能力。如果组织没有专门的运维团队，私有化部署的长期成本容易被低估。这也是我在评估工具时会把"私有化部署支持"和"迁移路径"放在同一张表里比较的原因，它们共同决定了切换期的真实成本。

八、可直接套用的模板与操作步骤

这一节给三个可以直接复制使用的模板。我在多个项目里迭代过它们的字段，删掉了很多"看起来专业但没人填"的列，留下的都是实际被使用过的。你可以按自己的项目类型再增减。

1. 阶段目标表：核心交付契约

填写顺序我建议从后往前：先定验收标准，再定交付物，最后定时间和责任人。因为验收标准决定了你需要什么交付物，交付物决定了需要多少时间和什么人。反过来填，很容易被现有资源绑住，做出一份"能完成但没价值"的计划。

2. 里程碑检查清单：每个关口用一次

检查清单的价值在于把"我记得要问"变成"系统会问"。这份清单我在每次阶段检查点上用，大约 15 分钟能过完。

1. 本阶段约定的交付物是否全部可访问？位置是否正确？
2. 每条验收标准是否都有对应的证据，而不是口头确认？
3. 质量门槛是否达标？不达标的项是否有明确的处理方案和时间？
4. 阶段性风险中，必须消除的那条是否已经关闭？
5. 观察清单里的风险是否发生了变化？新增了哪些？
6. 下一阶段的依赖项是否已获得承诺日期和承诺人？
7. 本阶段是否发生了影响验收标准的变更？是否已记录？
8. 责任人、验收人、升级人是否仍然有效？有没有人员变动未同步？

第 8 条是我后来加的，因为吃过亏。有一次关键责任人离职两周后，项目计划里还挂着他的名字，导致一个依赖项无人认领，直到检查点才被发现。

3. 周会与复盘议程：控制会议时长

我把会议拆成两种，绝不混开。同步会处理信息，决策会处理选择。混开的后果是同步信息占掉大部分时间，真正的决策被压到最后 5 分钟草草通过。

复盘会我有一条硬规则：改进项不超过 3 条，且每条必须能被验证。见过太多复盘会产出 12 条改进项，下个阶段一条都没落地。与其列 12 条，不如选 3 条真正影响下一个阶段成败的，盯死它。

4. 从今天开始的最小行动

如果你只有一个小时，我建议按这个顺序做：先给当前阶段写下三条验收标准，再指定一个验收决策人，最后把这两项同步给所有相关人。这一个小时的动作，通常比重新排一遍计划更能改变项目的走向。因为它改变了团队判断"做完了没有"的依据。

九、从下一个阶段开始改

回到最开始那个延期的项目。我推翻阶段表之后的第一个动作，是和 9 个人一起，把"这个阶段结束时什么算完成"写成了一段能被外人判断的话。那段话写了 40 分钟，后面替我们省掉了至少三次返工评审。

如果这篇文章只能留一个观点，我希望是这个：阶段目标的核心不是时间安排，而是把"完成"变成共识。项目负责人的效率提升，也不来自更努力地工作，而来自把返工、等待、重复沟通和无效会议这四类损耗压下去。而压住它们最省力的方式，就是在阶段开始前把标准写清楚。

我也必须说清适用边界。这套方法在需求相对明确、可拆解出交付物的项目里效果最好。如果你的项目是高度探索型、目标本身就在移动，那么阶段目标应该更强调"本阶段要回答什么问题"，而不是"本阶段要交付什么"。方法是工具，不是教条。

下一步你可以这样做：打开你现在正在负责的项目，挑出下一个还没开始的阶段，只做三个动作，写三条可判断的验收标准、指定一个验收决策人、列出两条关键依赖及其承诺日期。三个动作加起来不超过 40 分钟。

做完之后再判断它值不值得推广到其他阶段。我的经验是，多数人在做完第一个阶段之后，就不会再愿意回到"第 1-4 周：需求调研"那种写法了。因为当你真正体验过"阶段边界清晰、没人争论状态"的项目节奏，就会明白负责人最稀缺的资源从来不是时间，而是确定性。