阶段怎么做？项目经理入门指南：项目阶段从0到1

带过项目的人几乎都被问过同一个问题：“这个项目现在到哪个阶段了？”但真正让项目失控的，往往不是答不上来，而是答得太顺，顺到没有人停下来追问一句：上一个阶段到底结束了没有，凭什么说它结束了。

我做项目交付八年，带过二十多个从 0 到 1 的项目，也以外部顾问身份复盘过几十个失败案例。一个反常识的观察是：阶段管理崩掉的项目，绝大多数不是因为阶段分得太少，而是因为阶段分得很漂亮，却没有任何一个关口真的做过决定。流程图挂在墙上，评审会开成汇报会，交付物写成“完成需求分析”，于是每个阶段都“基本完成”，项目整体却在持续偏移。

这篇指南解决的就是入门项目经理最需要的那件事：从 0 到 1 的项目，阶段到底怎么切、每个阶段怎么定义、关口怎么评审、失败怎么止损。我会给出可以直接抄走的模板、判断标准和取舍规则，也会说明不同组织规模该配多重的阶段治理。全文的判断都来自我自己带项目的记录和复盘数据，样本有限，但足够真实。

一、先给结论：项目阶段是“承诺的开关”，不是“进度的刻度”

如果把项目阶段理解成进度条上的刻度，你会得到一个漂亮的甘特图和一个失控的项目。刻度只描述“走了多远”，开关才决定“还能不能继续往前走”。这两件事在管理上的分量完全不同。

1. 阶段 = 一组活动 + 一个可验证交付物 + 一道决策关口

这个定义里，三个要素缺一不可。只有活动没有交付物，阶段就没有终点；只有交付物没有关口，阶段就没有约束力；只有关口没有活动，阶段就是空壳审批。

很多团队有“需求阶段”，却没有“需求基线”，于是需求阶段事实上永远不会结束，因为没人能说清什么叫做完了。这是我在复盘里见到频率最高的一类结构性缺陷。

交付物必须是“可以被第三方验证的产物”，而不是一段描述。合格的例子：签字的接口协议、通过压测的报告、可回滚的发布包、外部依赖方的书面确认函。不合格的例子：完成需求分析、推进方案设计、跟进开发进度，这些是动作，不是产物，任何人都无法验收。

2. 从 0 到 1 的项目，我建议的最小阶段集是五段

市面上有把项目切成十几个阶段的模板，那是给大型基建工程用的。软件与数字化类项目，从 0 到 1 的场景，我实践下来最稳的是五段：机会验证、方案定义、交付构建、上线移交、复盘收尾。

关键不在名字，在于每一段都要回答一个不同的问题。如果两个阶段回答的是同一个问题，它们就该合并。这是我判断阶段数量是否合理的第一条标准。

3. 判断阶段做得好不好，只看三个数字

阶段治理是否有效，不需要靠感觉评价。我只看三个指标：关口返工率、阶段溢出率、决策等待时长。

• 关口返工率：阶段关口评审通过后，交付物仍需回退修改的比例。这个数字高，说明评审是走过场。
• 阶段溢出率：阶段实际耗时 ÷ 计划耗时。持续大于 1.3，说明阶段边界的估算不可信，或者阶段划分本身有问题。
• 决策等待时长：从提交关口评审到拿到明确“通过／不通过”结论的平均天数。这个数字高，说明关口没有真正的决策人。

在我带过的团队里推行关口规范化前后，这三个数字的变化非常明显，也是我说服管理层投入时间去建关口机制的唯一依据。

二、真实场景：一个“看起来无懈可击”的阶段计划是怎么崩的

抽象的道理讲完了，我讲一个具体的项目。这个项目我是在第 40 天接手的，接手时的状态是“整体进度正常”，两个月后被发现预算偏差已经接近 12%。

1. 我接手时看到的计划表

那是一家约 120 人的组织，替换一套核心业务系统，预算约 860 万元，计划周期 9 个月。前任项目经理留下的计划表非常专业：7 个阶段、14 个里程碑、21 项交付物、每个阶段都有明确的起止日期。

我花了一个下午逐条看交付物，越看越不安。21 项交付物里，有 15 项的验收描述是“完成 xx 文档”“推进 xx 方案”，只有 6 项是可以被第三方直接验证的。更致命的是，7 个阶段里没有一个阶段写明了“如果验证不通过会怎样”。

2. 第 37 天，第一次真正的偏差出现

项目第 37 天，也就是“方案定义”阶段名义上结束的那一周，需求变更累计已经到 14 项。其中 9 项是在方案定义阶段之后提出的，涉及已开工的模块，返工工时累计约 480 人时。

但当时的周报上，这个阶段的完成度写的是 92%。差异从哪来的？因为“完成度”是各小组自行填报的主观百分比，没有交付物作为锚点。百分比是可以填的，交付物是不能填的。

3. 真正的问题出在哪

我在复盘时把问题归结为一句话：这个项目不缺阶段，缺的是关口。它的每个阶段结束都只是“时间到了”，而不是“条件满足了”。评审会照开，但会上只汇报进度，不做“继续／暂停／终止”的决策，也没有人有权限否掉一个已经投入了 300 万的项目。

下面两条曲线很能说明问题。虚线是需求变更的累计数，实线是返工工时的累计数。可以看到，两条曲线真正的陡升都发生在方案冻结之后，而不是之前。

三、拆解七个常见误区

上面那个项目踩的坑，我在其他项目里几乎原样见过。把它们归纳一下，是七个高频误区。我按在中大型项目里出现的频率从高到低排列。

1. 误区一：把阶段当成百分比进度条

“需求阶段完成 80%”这句话本身没有信息量。80% 是谁填的？依据是什么？剩下 20% 是什么？没有交付物锚点的百分比，只是一种情绪表达。

我要求团队用“交付物清单打勾制”替代百分比：阶段有 6 项交付物，完成 4 项就是 4/6，剩下 2 项要写清卡在谁那里。这个改动很小，但它把主观判断换成了可核对的事实。

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

我见过把项目切成 11 个阶段的计划，结果每个阶段平均只有 3 周，团队有近三分之一的时间在准备评审材料。当管理动作的产出低于它的成本时，这个动作就该被砍掉。

一个简单的检验方法：如果一个阶段的存在，不能让任何人在这个节点上做出一个“继续／调整／停止”的实质决策，那它就不该是一个阶段，最多算一个里程碑。

3. 误区三：交付物写成“完成需求分析”

这是最隐蔽也最普遍的一条。动作型交付物无法验收，于是阶段永远“基本完成”。我给自己团队定了一条硬规则：交付物描述里不允许出现“完成”“推进”“跟进”这类动词，必须是一个名词性的产物。

“完成需求分析”改成“需求基线 v1.0，含 42 条验收级需求，业务与技术双方签字确认”。改完之后，阶段能不能结束就变成了一件不需要争论的事。

4. 误区四：关口只对时间，不对证据

很多团队的阶段评审实际上是一次进度汇报。会议材料里全是甘特图截图和完成度数字，没有一份交付物实体。这样的会议，开得再勤也不会降低风险。

我的做法是：关口评审材料的第一页必须是交付物清单和证据链接，第二页才是进度。如果第一页不齐，会议直接取消，不占用任何人的时间。

5. 误区五：阶段与预算、合同付款脱钩

阶段是天然的资金与风险分段。如果阶段的完成不触发任何资金动作，它对甲乙双方就都没有约束力。在客户项目里，这一点尤其关键：付款节点必须与阶段退出准则严格绑定，而不是与日期绑定。

我吃过这个亏。一个项目里付款节点写的是“6 月 30 日前支付二期款”，而不是“方案基线通过评审后支付二期款”，结果 6 月 30 日基线还没冻结，钱已经付了，后面再谈变更就完全没有筹码。

6. 误区六：用瀑布的阶段去套敏捷迭代

这不是说敏捷不能有阶段。敏捷的项目同样有立项、有上线、有移交，只是阶段内的交付是迭代的。问题出在把“每周一个迭代”当成“每周一个阶段”，于是每周都要走一次关口评审，团队疲于应付。

正确的组合是“粗阶段＋细迭代”：阶段仍然按机会验证、方案定义、交付构建、上线移交、复盘收尾来切，但交付构建阶段内部按两周一个迭代滚动，只在阶段级别设关口。

7. 误区七：没有收尾阶段，项目永远“差最后 5%”

这是我见过最贵的一个误区。项目上线后没人正式宣布结束，团队被抽走一半去支援新项目，剩下的人既不敢释放资源，也没法结项关账，于是这个项目在报表上永远是“进行中”，持续消耗管理注意力。

收尾阶段必须有独立的交付物和结项审批。没有结项，就没有资源释放；没有资源释放，下一个项目就永远缺人。

把这七个误区和中大型项目里的出现频率放在一起看，会发现一个规律：越是“看起来专业”的团队，越容易踩前两条；越是“救火型”的团队，越容易踩后三条。

四、专业判断逻辑：阶段该怎么切

讲完误区，回到最核心的问题：到底怎么决定切几刀、切在哪里。我给团队用的是一套可复用的判断逻辑，不依赖具体方法论，瀑布和敏捷都能用。

1. 四个切分信号：出现任何一个，就该考虑设阶段边界

阶段的切分不是凭经验拍的，它有四个客观信号。只要命中其中一个，我就倾向于在这里设一道边界。

• 风险密度突变：从低风险工作切换到高风险工作。比如从需求梳理切到架构选型，从开发切到上线。
• 不可逆承诺出现：某个决定一旦做出就很难回头，比如技术栈冻结、接口协议对外公布、合同签署。这类承诺之前必须有阶段边界。
• 外部依赖顶点：需要外部方交付或确认的最迟时点。比如第三方接口文档必须到位、供应商必须进场。
• 交接对象变化：从一拨人手里交到另一拨人手里。开发交测试、交付交运维、乙方交甲方，交接点天然就是阶段边界。

用这四个信号去检验，你会发现大多数项目自然落在 4 到 6 个阶段之间。少于 4 个，边界太粗，风险没有拦截点；多于 7 个，管理成本会反过来吞噬收益。

2. 每个阶段必须回答的五个问题

阶段名称定下来之后，我不会马上排时间表，而是先填五个问题。这五个问题填不满，这个阶段就是虚的。

1. 进入条件：上一阶段交出了什么，我们才能开始这一阶段？
2. 核心活动：这一阶段主要消耗人力的三件事是什么？
3. 交付物：能被第三方验证的产物清单，每项都要有明确的责任人和格式。
4. 退出准则：达到什么条件可以宣布本阶段结束？必须是可判定的，不能是“基本完成”。
5. 失败预案：如果退出准则在约定时间内无法达到，是回退、缩减范围，还是直接终止？

第五个问题是最容易被跳过、也最值钱的一个。一个没有失败预案的阶段，本质上只是把风险往后推了一格。

3. 关口评审的“三票制”

关口的本质是决策，不是汇报。为了不让评审会变回汇报会，我用三票制：业务票、技术票、交付票，三票都通过才算过关。

• 业务票：由业务负责人投，判断价值假设是否仍然成立、范围是否需要调整。
• 技术票：由技术负责人投，判断方案风险是否可控、技术债是否可接受。
• 交付票：由项目经理投，判断进度、成本、资源是否支撑下一阶段。

这三票里，业务票拥有一票否决权，但必须书面说明理由。这一条是为了防止项目在“已经投入很多”的压力下硬着头皮往下走，沉没成本不该成为继续投入的理由。

4. 可以直接抄的阶段定义模板

下面这份 YAML 是我们团队在用的阶段定义模板，把它复制到项目文档里填一遍，阶段的基本质量就有保障了。

phase:
name: 方案定义

goal: 把“要做什么”变成“签过字的基线”

entry_criteria:

机会验证阶段输出《可行性结论》且业务负责人签字

本阶段预算池已分配到项目账户

deliverables:

需求基线 v1.0（含变更控制流程与 CR 模板）

技术方案评审记录（含被否决的备选方案及原因）

外部接口协议清单（依赖方已书面确认）

交付估算 v2.0（误差收敛到 ±20% 以内）

exit_criteria:

需求基线冻结，后续变更一律走 CR 流程

关键外部接口获得对方书面确认

三票制评审通过（业务票 / 技术票 / 交付票）

gate_reviewers: [业务负责人, 技术负责人, 交付负责人]

fail_plan: 若基线无法在 2 周内冻结，退回机会验证并重新评估范围

max_duration: 6 周

模板里最值得强调的是 max_duration 这一行。阶段必须有最长时长，否则它会被无限拉长，而一个永不结束的阶段等于没有阶段。

5. 粗粒度还是细粒度：用雷达图对比一次

经常有人问我，三阶段和七阶段哪个好。答案是看你的组织规模和项目风险。粗粒度换速度，细粒度换可控性，没有免费的午餐。

下面这张雷达图是我用同一批项目数据做的模拟对比，五个维度上，两种划分方式各有明显短板。

五、案例与数据观察：从 0 到 1 的项目阶段怎么落地

讲到这里都是方法和逻辑。接下来是我实际落地时最有价值的部分：怎么把阶段关口从 Excel 搬进工具，让它变成流程里绕不过去的一环。

1. 关口写在文档里没有用，写在流程里才有用

我们试过纯文档管理：阶段定义写在 Confluence 里，交付物链接贴在里面，评审靠邮件。结果是三周之后没人看了，交付物链接失效，评审记录散落在各个邮件串里。

后来我们把阶段关口搬进了工具。具体做法有三条，都是踩坑之后改出来的：

• 阶段作为独立的工作项类型，而不是任务标签。每个阶段是一个可追踪、可指派、可挂交付物的实体。
• 退出准则写成状态流转的必填校验。交付物没挂全，阶段状态就不能从“进行中”改成“已完成”，这是系统级拦截，不靠人的自觉。
• 关口评审记录自动关联到阶段实体。谁投的票、什么时候投的、否决理由是什么，全部留痕，方便复盘时回溯。

我们后来把主力工具换成了 PingCode，一个很现实的理由是它主要服务中大型企业及 100 人以上的组织，阶段、里程碑、交付物、评审这几层结构是原生支持的，不需要我们自己在任务看板上拼装。对于超过 100 人的组织，工具能不能承载“阶段，交付物，关口”三层结构，比它有没有花哨的看板更重要。

2. 100 人以上组织为什么更依赖私有化和权限模型

这一点我在小团队时完全没意识到。团队到了 120 人以后，项目文档里会自然出现薪酬相关的成本数据、客户合同条款、供应商报价，以及尚未公开的产品路线图。

这些内容放进公有云 SaaS，法务和安全部门会直接亮红灯。所以我们在选型时把私有化部署作为硬性条件。PingCode 支持私有化部署，这是我们最终选择它的关键原因之一，另一个原因是它支持从 Jira 平滑迁移，我们历史上有七年的 Jira 数据，不可能推倒重来。

迁移这件事我建议的顺序是这样的，我们实际走了一遍，比预想顺利：

1. 先迁用户与组织架构，确认权限模型对得上。
2. 再迁项目与工作项类型，重点校验阶段、里程碑这类自定义结构是否被正确映射。
3. 然后迁历史缺陷与需求，保留原始编号，避免追溯链断裂。
4. 最后迁看板、仪表盘和自动化规则，这些是使用习惯的载体，放最后迁能减少一线抵触。
5. 迁移后跑两周双轨期，新旧并行，确认数据一致后再下线旧系统。

我在这里的判断是：国产替代的决策点不在功能清单的长短，而在迁移成本和历史数据保真度。一个功能更强但迁不动、要重新录入三年数据的平台，实际落地成功率远低于一个能平滑承接历史数据的平台。

3. 工具承载阶段之后，我的时间分配发生了什么变化

阶段关口进工具之后，最大的收益不是流程更规范，而是我的时间结构变了。以前我大概四成时间在催进度、两成半时间在手工收集状态，真正用于风险处理和干系人沟通的时间不到三成。

现在催进度的占比降到了两成以下，因为状态是从流程里自动流出来的，不需要我去问。省下来的时间我没有用来做更多项目，而是全部投入到风险识别和干系人沟通上，这两件事才是项目经理真正不可替代的价值。

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

方法论讲完，我给四类不同处境的项目经理准备了可以直接执行的行动清单。你可以先找到最接近自己的那一类，照着做第一周的动作。

1. 10 人以下小团队：轻治理，重清单

小团队不要搞关口评审会，那会拖慢你最宝贵的速度优势。你需要的是一份共享的交付物清单，三个到四个阶段，每个阶段三到五项交付物，用一张在线表格维护就够了。

具体动作：这周就把当前项目切成四段，给每段写三行字，这一段要产出什么、谁来验收、什么情况算失败。写完贴在团队能看见的地方。不要做成文档，文档没人看；做成清单，清单会被打勾。

2. 10 到 100 人团队：建立三票制和三段式关口

这个规模是最尴尬的区间：口头默契开始失效，但重型流程又承受不起。我的建议是只在三个最关键的位置设正式关口：立项闸门、方案基线冻结闸门、上线验收闸门。其余阶段用轻量检查代替正式评审。

同时开始把阶段和交付物搬进项目管理平台。这个规模还不需要私有化部署，但需要保证交付物、阶段状态、评审记录三者在同一个系统里，而不是分散在文档、邮件和即时通讯工具里。

3. 100 人以上组织：关口制度化，工具承担约束力

到了这个规模，靠人的自觉已经不可能维持阶段纪律了。你需要把退出准则变成系统里的硬校验，让阶段在交付物不全的情况下根本没法标记完成。

这个阶段我强烈建议把数据主权问题前置讨论。涉及成本数据、合同条款、未公开路线图的项目，私有化部署基本是必要条件。同时要评估历史数据迁移成本，如果团队有多年积累的历史项目数据，选型时的第一问应该是“能不能平滑迁过来”，而不是“功能列表有多长”。

4. 客户与外包项目：阶段必须绑付款

这类项目的最优策略完全不同。阶段划分的首要目标不是内部管理，而是商务风险控制。每个阶段的退出准则都应该直接对应一份可交付的验收物和一笔付款。

一个具体的动作：把合同里的付款节点表拿出来，逐条核对是否写的是“通过 xx 验收后付款”，而不是“xx 月 xx 日前付款”。只要还是后者，就趁着关系好的时候改，不要等到延期时再谈。

我还建议在这类项目里，把每个阶段的失败预案写进合同附件。不是不信任对方，而是当延期真的发生时，双方都有一份事先约定的处理方式，不用临场博弈。

把四种情况的建议放在一起看，会看到一个清晰的规律：组织越大、外部依赖越多，阶段就越要制度化；组织越小、内部协作越密，阶段就越要轻量化。用错强度的代价，往往比不设阶段还大。

七、不同情况下的取舍

做项目管理的年头越长，我越确信一件事：阶段管理的大部分难题不是技术问题，而是取舍问题。下面四组取舍，是我在不同项目里反复面对的。

1. 阶段数量 vs 管理成本

每增加一个阶段，你大约要付出三类成本：评审材料准备时间、评审会议占用时间、以及阶段切换时的上下文切换损耗。在一个 60 人的项目里，这三项加起来大约是每阶段 40 到 60 人时。

判断标准很直接：这个阶段能拦下的风险，折算成钱之后，是否大于这 50 人时的成本？拦不下的，就合并掉。我通常把这条线设在项目总预算的 1% 左右。

2. 文档厚度 vs 决策速度

文档写得越厚，决策越慢，但返工越少。这两者的平衡点在哪里？我的经验是看变更成本：如果一次需求变更的返工成本超过 30 人天，就值得把文档写厚；如果只有 3 人天，写厚就是浪费。

换句话说，文档厚度应该由不可逆程度决定，而不是由流程规定决定。接口协议、数据模型、对外承诺这三类文档我要求写得尽可能厚；界面文案、内部工具的使用说明写得能看懂就行。

3. 工具治理 vs 团队自治

把阶段和关口写进系统，会带来一致性和可追溯性，代价是一线团队的自由度下降，通常也会伴随一到两周的抵触期。这件事没有两全其美的方案。

我的取舍原则是：状态流转设硬约束，工作方式不设硬约束。也就是说，交付物没挂全不能标记阶段完成，这条是系统强制的；但一个任务怎么拆、什么时间提交代码、用什么方式沟通，这些交给团队自己决定。

这条原则的底层逻辑是：治理应该管结果的可验证性，而不是管过程的动作。管过程的治理，通常会演变成形式主义。

4. 强关口 vs 快速试错

强关口适合不可逆的决策场景：合同签署、架构选型、数据迁移、对外发布。这些地方返工成本极高，值得用严格的关口拖慢节奏。

快速试错适合可逆的探索场景：界面方案、增长实验、内部工具的功能取舍。这些地方关口反而有害，因为它会让团队为了过评审而保守，失去探索的价值。

这张表我自己贴在工位上。每次有人提出“这个要不要走评审”，我先问一句返工成本量级，答案通常就出来了。把治理强度与返工成本挂钩，是避免流程僵化最有效的一招。

八、常见问题速答

1. 敏捷项目还需要阶段吗？

需要，但阶段和迭代是两层东西。迭代是交付节奏，阶段是承诺节点。一家公司可以两周一个迭代，同时只在立项、上线、移交这三个地方设阶段关口。把迭代当阶段，是敏捷落地中最常见的自伤行为。

2. 阶段计划排出来之后，业务方一直不签字怎么办？

不要等。把“未签字”这件事本身当成一个风险项写进风险登记册，指定到人、设定截止日期。同时给业务方两个选项：要么在约定时间前签字，要么明确接受延期的后果。让不决策的成本显性化，比反复催促有效得多。

3. 项目已经开工了，阶段混乱还有救吗？

有救，但不要推倒重来。我的做法是：先把当前所在的一个阶段补完整，写清交付物、退出准则、最晚结束时间，然后往后每个新阶段按标准流程走。已经过去的阶段不必补文档，那是沉没成本。把力气花在还没发生的边界上。

4. 阶段关口评审一般开多久合适？

我的基准是：30 人以下的项目 60 分钟，100 人左右的项目 90 分钟，超过 200 人的项目拆成技术评审和业务评审两场，各 60 分钟。超过 120 分钟的评审，产出的决策质量会显著下降，因为大部分人已经疲劳了。

5. 有没有什么信号说明我的阶段划分是错的？

三个信号。第一，某个阶段连续三个项目都超出计划时长 50% 以上，说明它的边界划错了位置。第二，阶段评审会上大部分时间在讨论本阶段内部的事，说明前面那个阶段没关严。第三，团队说不清当前阶段的退出准则，说明这个阶段只存在于计划表里。

6. 阶段文档要写多详细才算够？

一个实用的判断标准：换一个从没参与过这个项目的人来看，他能不能仅凭这份文档判断出“这个阶段能不能结束”。能，就够了；不能，就还差东西，通常是差在退出准则的判定标准上。

九、写在最后：下一步你可以做的三件事

整篇文章的核心观点其实可以浓缩成一句话：项目阶段的本质不是把时间切段，而是把承诺分段。每经过一个阶段，团队对“要做什么、能不能做到、值不值得继续”的认知都应该发生一次实质变化。如果没有变化，这个阶段就白设了。

第二个我想强调的独特视角是：阶段治理的强度必须与返工成本挂钩，而不是与项目重要程度挂钩。很多团队一遇到重要项目就加流程，结果最重要的项目反而被流程拖慢。正确的做法是找到那些真正不可逆的节点，在那里把流程加到最重，其余地方尽量轻。

第三个视角关于工具：阶段纪律靠人维持是有上限的，超过 100 人的组织必须靠系统护栏。把退出准则写成状态流转的硬校验，让不合规的完成变得在技术上不可能，这比开十次宣讲会都管用。选型的时候，把“能不能承载阶段，交付物，关口三层结构”“能不能私有化部署”“历史数据能不能平滑迁过来”这三问放在功能清单前面。

接下来这一周，你可以做三件事。第一件，把你现在手上的项目切成四到六段，每段写三行：要产出什么、谁来验收、什么算失败，先不要做表格，就写在纸上。第二件，翻出最近一次阶段评审的会议记录，看看里面有多少内容是在看交付物、多少是在看进度条，如果后者占了大半，你的关口就需要重建。第三件，挑一个返工成本超过 100 人天的决策点，给它补上一次正式的关口评审，把三票制的规则讲给相关的人听。

这三件事加起来大概占用你半天时间。半天之后，你就从“知道阶段应该怎么分”，变成了“手上有一个正在运转的阶段结构”，这两者之间的距离，正是入门项目经理和专业项目经理之间的差距。