我最近给一家 180 人规模的 SaaS 公司做研发流程诊断，翻到了一份 47 页的《项目阶段划分规范》：立项、需求、设计、开发、测试、上线、验收，七个阶段写得清清楚楚，每个阶段都有输入输出清单。但当我随机问当时在跑的 12 个项目负责人「你们现在处于哪个阶段」，有 9 个人的答案和规范对不上，有人说「开发做完了但设计评审还没过」，有人说「测试和开发已经混在一起三个月了」。这份规范唯一被严格执行的场合，是季度汇报时用来填进度百分比。
这不是个例。在我经手和旁观的六十多个研发项目里，项目阶段划分失效，绝大多数时候不是划分得不对，而是划分完了之后没人用它做决策。阶段变成了甘特图上的色块、周报里的进度百分比、验收时补签的一张纸。真正决定项目成败的那些判断，这个需求到底要不要做、这个方案能不能扛住、这个版本可不可以发，全都在阶段之外被随手做掉了。
这篇文章我打算把「项目阶段划分」这件事从头到尾讲清楚：为什么大部分团队的划分方式是错的，正确的划分逻辑长什么样，六个阶段各自的退出标准怎么定，阶段门评审怎么设计才不会被绕过，以及在 100 人以上组织里怎么用工具把阶段划分真正变成可执行的流程。如果你正准备给团队立一套阶段规范，或者手里那套规范已经没人看了，这篇应该能帮你少走两年弯路。
一、核心结论：阶段划分的本质是「风险敞口的收窄节奏」
先把结论摆在前面，后面所有内容都是为这三条服务的。
第一条：项目阶段划分的唯一目的，是在正确的时点做正确的决策，而不是让汇报好看。每一个阶段的结束，都应该对应一次「继续 / 调整 / 终止」的判断。如果某个阶段结束时没有任何一个决策需要被做出，那这个阶段就是多余的。这句话可以直接用来体检你现有的阶段模型：把每个阶段结束时的决策列出来，列不出来的阶段直接删掉。
第二条：阶段的划分依据必须是「可验证的产出物」，而不是「已经花掉的时间」。「开发阶段」不是一个阶段，因为它无法验证，开发到什么程度算结束？「代码写完」还是「自测通过」还是「集成环境跑通」？正确的表述是「可运行版本在集成环境完成冒烟测试并通过」。区别在于，前者是时间刻度，后者是状态刻度，只有状态刻度才能触发决策。
第三条：阶段数量由风险密度决定，不由项目规模决定。一个两周的营销落地页项目，硬套七个阶段，结果是每个阶段平均两天，评审材料比代码还多。反过来，一个跨越 18 个月的核心交易系统重构，只分「开发 / 上线」两个阶段，风险会在最后三个月集中爆炸。我见过最离谱的反例是一家做医疗信息化的公司，三个月的项目分了十二个阶段，项目经理 60% 的时间在准备评审文档。
这三条合起来是一句话：阶段划分本质上是在管理风险敞口的收窄节奏，每过一个阶段，未验证的东西应该少一块，剩余不确定性应该降一档。如果项目跑完三个阶段，未验证的风险敞口一点没变小，那这三个阶段就是白走的。
二、真实场景：一次 12 个项目的阶段划分改造
回到开头那家 180 人的 SaaS 公司。他们的真实问题不是「没有阶段划分」，而是阶段划分和实际工作流是两张皮。开发同学在需求文档还没定稿的时候就开始写代码，测试同学在提测邮件发出来之前已经在测了，产品同学在开发做完之后还在改原型。所有人的工作都在推进，但没有任何一个节点能让所有人对齐「我们现在到底做到了哪一步、还剩什么没验证」。
我们做的事情其实很简单，三步：把七个阶段压到五个；每个阶段只保留一个「可验证的退出标准」；每个退出标准绑定一次十五分钟的站立式评审，参会人不超过五个。不写新文档，不加新工具，只是把原有阶段重新定义了入口和出口。
改造后跑了完整的两轮共 12 个项目，我拿到了一组对比数据。需要说明的是，这组数据来自同一部门连续 12 个项目的内部统计，延期判定口径为「超出基线计划 5 个工作日以上」，需求返工指「已进入开发阶段后被要求回退修改的需求条目」，样本量不大，但方向是清晰的。
有意思的是，四项指标里改善最小的是延期率。原因在复盘时被讲清楚了：阶段划分能解决「大家认知不一致」的问题，但解决不了「人力不够」和「需求本身就是拍脑袋定的」这两个问题。指望阶段划分去治延期，方向就错了。
三、常见的四个误区：为什么通用模板一定会失效
我统计过自己参与复盘的 60 个项目，把阶段划分相关的问题按根因归类，结论有点反直觉：大部分团队的问题不在于阶段划分「设计得不好」，而在于划分完之后的机制没建立起来。
基于这组分布，我把最常见的四类误区单独展开讲。
1. 把阶段划分当成甘特图的刻度
这是最普遍的一种。团队把阶段理解成时间轴上的分段：「第一个月是需求阶段，第二三个月是开发阶段」。于是阶段变成了排期工具，而不是风险管控工具。一旦进度落后，第一个被压缩的就是阶段本身，需求阶段从四周压到一周，设计阶段直接取消。
判断方法很简单：如果你的阶段划分可以脱离具体日期独立存在，说明它是状态刻度；如果某个阶段离开具体日期就说不清楚，说明它是时间刻度。状态刻度可以在计划变更时保持不变，时间刻度会随着排期一起崩掉。
2. 把阶段等同于职能流水线
「需求阶段归产品部，开发阶段归研发部，测试阶段归 QA 部」，这种划分看起来界面清晰，实际上制造了最典型的交接损耗。每个阶段结束时，工作成果被「扔」给下一个部门，接收方要花大量时间理解上下文，而真正的问题往往在两个阶段的接缝处。
我在一个金融科技团队见过极端案例：需求阶段结束的标志是「PRD 评审通过」，但 PRD 里完全没有非功能需求（性能、幂等、对账口径）。设计阶段发现这个问题时已经过了三周，只能回头补，而产品经理认为「这不是我的阶段该管的」。
3. 阶段门只有「通过 / 不通过」两个选项
现实中的评审结论至少有四种：通过、带条件通过（列出必须在下一阶段前解决的事项）、返工重审、终止。只有两个选项的结果是，评审人为了不阻塞进度，几乎永远选择「通过」，条件被口头记录在会议纪要里，然后没人跟进。
「带条件通过」是阶段门里最重要、也最容易被忽略的选项，因为它把一个原本会导致延期三周的阻塞，转化成了若干个必须在下阶段开始前关闭的条件项。关键是要把这些条件项写进工具里、指派责任人、设置到期提醒，而不是留在会议纪要的第三页。
4. 阶段模型定死之后三年不动
业务形态变了，阶段模型不变，这是很多组织的通病。一个团队从做定制项目转向做标准化产品，交付节奏从「一个客户一个版本」变成「两周一个迭代」，但阶段模型还是三年前那套「需求-设计-开发-测试-试运行-验收」。结果每个迭代都要走一遍完整六阶段，流程成本占比超过 30%。
我的建议是给阶段模型设一个「版本号」和「复审周期」：每半年一次，由项目管理办公室或流程负责人牵头，根据过去半年项目的实际阶段停留时长和评审数据，判断哪一步过重、哪一步过轻。
四、专业判断逻辑：阶段划分的五条设计原则
说完误区，讲我实际使用的设计逻辑。这五条原则是我做了多轮改造之后收敛下来的，顺序不能乱，前一条是后一条的前提。
1. 从交付物倒推阶段，而不是从活动正推
大多数团队的划分方式是「我们先做需求，再做设计，再做开发……」，这是从活动正推。正确的做法是反过来问：这个项目最终要交付什么？为了交付它，哪几个中间状态是必须被验证的？把这些中间状态按依赖关系排好，阶段自然就出来了。
举例：一个企业级数据迁移项目的关键中间状态是，（1）源数据质量摸清，（2）迁移脚本在沙箱跑通并与源数据比对一致，（3）目标环境全量迁移演练通过，（4）切换方案与回退方案确认。这四个中间状态就是四个阶段，和「需求/设计/开发/测试」没有关系。
2. 每个阶段必须绑定一个可验证的完成定义
可验证的意思是：换一个人来看，能得出同样的结论。下面这几个表述都是不可验证的：「需求基本明确」「设计已完成」「开发基本完成」「测试通过」。可验证的表述应该是：「所有 P0 需求已写入基线条目且无待确认项」「核心链路的接口契约已冻结并纳入版本管理」「主流程用例在集成环境的通过率 100%，非主流程不低于 95%」。
我在给团队做培训时常用一个检验方法：把退出标准写成一句话，然后让两个不同角色的人分别判断某个具体项目是否满足。如果两人结论不一致，这条标准就不可验证，必须重写。
3. 阶段门的否决权必须真实存在
阶段门评审最常见的失败形态是「没有否决权」。参会的人都是执行方，谁都不愿意说自己做的东西不过关；项目经理作为组织者，天然倾向于让评审通过以保持进度。评审于是变成了通报会。
我的做法是给每个阶段门指定一个「独立否决角色」，这个角色不参与该阶段的执行工作。例如：需求阶段门的否决角色来自架构组或测试负责人；设计阶段门的否决角色来自运维或安全；上线阶段门的否决角色来自业务方或客户成功。关键不是让这个角色说了算，而是让「说不」这件事在组织上是安全的。
4. 阶段粒度与风险密度匹配，而不是与项目金额匹配
一个常见错误是按项目预算决定阶段数量：金额大的项目多分几个阶段，金额小的少分。真正决定粒度的是风险密度，也就是「如果不验证就往下走，返工成本有多高」。
下面这张图是我给团队做阶段划分培训时用的适配度评分，对比五种常见划分依据在四个维度上的表现。评分是我基于自身项目经验的主观评估，属于建议基准而非统计结论。
5. 阶段模型必须能被工具承载
这一条经常被忽略。手工维护的阶段状态，在超过 5 个项目、30 个人的时候一定会失真。原因不是团队不认真，而是维护成本太高：项目经理要从十几个群里、从不同的人嘴里拼出真实状态，再手动更新到表格里，这个动作天然会被延迟。
我的判断标准是：如果一个阶段状态需要人工去「收集」而不是自动产生，那它最多三个月就会变成形式主义。阶段状态应该由工作在工具里的流转自动推导出来，需求条目进入基线、代码合并到发布分支、测试用例执行完成、上线审批通过，这些事件天然对应阶段推进。
五、全流程拆解：从立项到收尾的六个阶段
下面这套六阶段模型，是我在 100 人以上研发组织里用得最多的一版。它的特点是：每个阶段只绑定一个退出标准，刻意压掉了「设计」和「集成」这类容易膨胀的中间环节，把它们合并进有明确产出物的阶段里。你可以按自己组织的风险密度增减，但退出标准的设计方法建议保留。
先说整体的人力投入与风险敞口关系。下面这张图是示意曲线，用来表达一个我在多个项目里反复观察到的规律：人力投入的高峰在中后段，但风险敞口的收窄应该发生在前中段。如果风险敞口在开发末期仍然很高，说明前面几个阶段没有被真正使用。
1. 阶段零：立项论证
这一阶段在多数团队里被严重压缩甚至跳过，但它可能是投入产出比最高的一个阶段。核心任务只有一个：判断这件事值不值得做，以及用什么代价做。
（1）触发条件
不是所有工作都需要走立项。我通常设两条触发线：预估投入超过 30 人天，或者涉及跨两个以上团队协作。低于这条线的工作直接走团队内部的轻量看板，不进入项目阶段体系。
（2）必要产出物
一张纸就够，但必须包含四项：要解决的问题（用业务语言描述，不用技术语言）、可衡量的成功标准、预估投入区间、不做会怎样。第四项经常被跳过，但它是最有效的过滤器，如果「不做会怎样」的答案是「没什么影响」，这个项目大概率不该启动。
（3）退出标准
明确的立项决议：批准、带条件批准、暂缓、否决。批准的项目必须同时确定项目负责人和业务负责人，两个角色缺一不可。我见过很多项目卡在中途，根因就是立项时只指定了技术负责人，没有人对业务结果负责。
（4）常见踩坑
第一个坑是「立项即承诺交付日期」。日期应该由方案验证阶段结束后倒推，而不是在立项时拍。第二个坑是把立项评审开成技术方案评审，讨论了两小时架构，却没人回答「这个项目解决了什么业务问题」。第三个坑是立项材料由执行团队自己写，缺少业务方视角。
2. 阶段一：需求基线与范围冻结
这个阶段的目标不是「收集尽可能多的需求」，而是「把这一版要做什么、不做什么，写死」。关键词是冻结，不是永久冻结，而是建立一个可以衡量变更的基线。
（1）必要产出物
一份基线化的需求清单，每条需求有唯一编号、优先级、验收标准、提出人。这里有个细节值得强调：验收标准必须由提出需求的人写，不能由开发方代写。我见过太多项目在验收时扯皮，根因就是验收标准是开发同学按自己的理解写的，业务方从来没看过。
（2）退出标准
所有 P0 需求均已明确验收标准且无待确认项；范围之外的条目已明确标注为「本版不做」；基线版本已冻结并记录变更入口。注意最后一项：冻结不等于禁止变更，而是让变更有路径、有成本、有记录。
（3）范围变更怎么处理
基线冻结之后进来的新需求，走三条路之一：替换（换掉一个同等工作量的原需求）、延期（进下一版）、紧急插入（需要项目负责人和业务负责人同时确认，并明确由此带来的排期影响）。三条路都必须有明确的责任人签字，不能是口头同意。
3. 阶段二：方案设计与技术验证
这一阶段是整个项目里性价比最高的。花 10% 的项目时间，可以消掉接近一半的技术不确定性。但大多数团队的做法是「写一份设计文档，评审通过」，这远远不够，文档评审能发现的是明显错误，发现不了真实的性能瓶颈、依赖阻塞和数据边界问题。
（1）必要产出物
三样东西：架构或方案说明（不需要长，一页图加关键决策记录）、关键风险的验证结论（比如「数据库在 500 万行数据量下查询 P99 为 120ms」，而不是「预计性能满足要求」）、非功能需求的明确口径（幂等、对账、监控指标、回滚方案）。
（2）退出标准
项目中的三个最高风险项均已通过原型、压测或沙箱验证，且有数据支撑；接口契约已冻结；回滚方案已确认可执行。注意「回滚方案可执行」这一条，很多团队的回滚方案写在文档里，真到出事时才发现数据库变更不可逆。
（3）敏捷项目怎么处理
迭代制的项目不需要每个迭代都走完整方案验证，但需要保留「架构级决策」的一次性验证。我的做法是设一条线：影响外部接口、数据模型、依赖关系的变更走方案验证；纯内部的实现方式变更不走。
4. 阶段三：开发与集成
这是人力投入最大的阶段，也是最不需要「额外流程」的阶段，因为团队本来就在做这件事。项目管理在这里的动作应该是轻的：跟踪进度、暴露阻塞、控制范围蔓延。
（1）必要产出物
可运行的集成版本，以及一份持续更新的阻塞清单。我特别反对在这个阶段要求开发同学额外产出流程文档，那只会挤占真正的工作时间。
（2）退出标准
主流程功能在集成环境全部跑通；单元测试和静态检查达到团队约定基线；提测版本的构建产物可追溯（能对应到具体的代码提交）；无 P0 级未解决缺陷。
（3）这个阶段最容易出的问题
伪完成。开发同学说「做完了」，实际是「代码写完了但没自测」，测试同学拿到版本一跑全是阻塞性缺陷。解决这个问题不靠制度，靠一条简单的约定：提测版本必须通过冒烟测试，未通过冒烟视为未提测，不计入进度。这条规则一旦立住，伪完成率会掉得非常快。
5. 阶段四：验证与上线准备
这个阶段的工作量经常被低估。很多团队把「测试通过」等同于「可以上线」，结果上线当天才发现监控没配、告警没接、回滚脚本没演练、运维不知道要扩容。
（1）必要产出物
完整测试报告（含未通过项的处理结论）、上线方案（含时间窗口、执行人、验证步骤）、回滚方案（含回滚触发条件和执行时长）、监控与告警配置清单、值守安排。
（2）退出标准
主流程用例通过率 100%，非主流程不低于既定基线；性能指标达到方案阶段确定的数值；上线方案与回滚方案已完成一次桌面推演或预发演练；相关方（运维、客服、业务）已完成通知与确认。
（3）一个容易忽略的细节
回滚方案必须写明「什么情况下触发回滚」和「谁有权决定回滚」。这两条不写清楚，出事时所有人都在等别人拍板，损失会随分钟级放大。
6. 阶段五：上线发布与稳定期
上线不是终点。我在多个项目里观察到，上线后的 72 小时是缺陷暴露最集中的窗口，而这个窗口期的响应速度，直接决定了业务方对这次交付的整体评价。
（1）必要产出物
上线记录（含实际执行时间线与偏差说明）、稳定期监控数据、问题清单及处理结果。
（2）退出标准
稳定期（我通常定 5 到 10 个工作日，按业务影响面调整）内无 P0 问题；P1 问题全部有明确处理结论；业务方确认核心场景可用。这一条必须由业务方确认，不能由技术方单方面宣布。
（3）收尾与归档
阶段五之后还有一件常被跳过的事：复盘与归档。复盘不是写一份纪要，而是回答三个问题，哪一阶段的哪个判断被证明是错的？下次遇到同类项目应该在哪一步多花时间？这次沉淀下来的可复用资产（组件、脚本、检查清单）放在哪里？
关于「阶段六：收尾」，我倾向于不把它作为一个独立阶段，而是作为阶段五的收尾动作。理由很简单：独立的收尾阶段在排期上永远被第一个砍掉，而挂在阶段五退出标准里的复盘，才有被执行的可能。
六、阶段门评审：让阶段划分真正转起来的机制
设计好阶段只是第一步。让阶段划分产生约束力的，是阶段门评审。评审设计不好，前面所有工作都白费。
1. 阶段门的三要素
一个有效的阶段门必须同时具备三个要素，缺任何一个都会失效。
（1）准入条件
什么材料齐了才能开这个评审。不要设得太重，我通常只要求三样：退出标准的自查结论、未解决项清单、需要评审会裁决的具体问题。如果评审会开了四十分钟还在翻材料，说明准入条件没设好。
（2）决策角色
前面讲过，每个阶段门要有一个不参与执行、拥有否决权的角色。这个角色可以轮换，但不能空缺。
（3）结论形式
四种结论：通过、带条件通过、返工、终止。带条件通过必须产出可跟踪的条件项，写进工具、指派责任人、设置到期日。我通常限制条件项不超过五项，超过五项说明这个阶段本身没做好，应该直接返工。
2. 评审频次怎么定
这里有个反直觉的结论。我统计过一组项目样本，把「阶段门评审频次」和「生产环境缺陷泄漏率」「人均返工耗时」放在一起看，发现收益存在明显的拐点。
这张图想说的是：从「没有正式评审」到「每阶段一次轻量评审」，是收益最陡的一段；从「关键节点加评」到「每阶段重量评审」，是成本开始超过收益的一段。很多组织的质量困境不是评审不够多，而是评审太重导致执行方躲着走。
3. 轻量评审与重量评审的切换规则
我的判断规则是三条：项目影响范围涉及核心资金或核心数据，走重量评审；项目涉及外部合规或客户合同承诺，走重量评审；其余项目走轻量评审。切换不需要审批，由项目负责人自行判断，但需要在项目档案里记录原因，便于后续复查判断是否合理。
七、工具承载：把阶段划分变成可执行流程
前面反复强调一件事：阶段状态如果靠人工收集，三个月内必然失真。这一节讲工具怎么承载。
1. 阶段模型在平台上怎么建模
以中大型企业常用的 PingCode 为例。它主要服务 100 人以上组织，这类组织的典型特征是项目多、角色多、跨团队协作频繁，手工维护阶段状态的成本极高。PingCode 的做法是把阶段模型和项目工作流绑定在一起，阶段不是一个独立字段，而是由工作项的实际流转状态推导出来的。
具体来说，「发布 / 迭代」作为承载阶段推进的载体，需求条目按阶段流转，代码提交、构建、测试执行与需求条目自动关联。阶段退出标准里的「主流程用例通过率 100%」这类条件，可以直接配置成阶段推进的前置校验，不满足则阶段无法推进。
下面是一个阶段门配置的示例结构，实际落地时你可以按自己的字段体系调整：
phase_model:
name: 标准六阶段模型
phases:
key: P0_APPROVAL
name: 立项论证
exit_criteria:
field: decision_record # 立项决议已归档
required: true
field: owner_assigned # 项目负责人 + 业务负责人
required: true
gate:
approvers: [BU_HEAD]
decision_types: [通过, 带条件通过, 返工, 终止]
key: P1_BASELINE
name: 需求基线
exit_criteria:
field: p0_without_acceptance_criteria
required: 0 # 无验收标准缺失的P0需求
field: baseline_frozen
required: true
gate:
approvers: [ARCH_LEAD, TEST_LEAD]
max_conditions: 5
key: P2_SOLUTION
name: 方案验证
exit_criteria:
field: top_risks_verified
required: true # 前三风险项已验证
field: rollback_plan_ready
required: true
gate:
approvers: [OPS_LEAD, ARCH_LEAD]
key: P3_BUILD
name: 开发集成
exit_criteria:
metric: smoke_pass_rate
threshold: "== 100%" # 冒烟未过视为未提测
metric: open_p0_defects
threshold: "== 0"
gate:
approvers: [TEST_LEAD]
key: P4_RELEASE_READY
name: 上线就绪
exit_criteria:
metric: main_flow_pass_rate
threshold: "== 100%"
metric: perf_target_met
required: true
field: rollback_drill_done
required: true
gate:
approvers: [OPS_LEAD, BUSINESS_OWNER]
key: P5_STABLE
name: 上线稳定期
exit_criteria:
metric: open_p0_issues
threshold: "== 0"
window: "10 个工作日"
field: business_confirm
required: true
gate:
approvers: [BUSINESS_OWNER]
把退出标准写成可校验的条件之后，会产生一个很有意思的副作用：阶段状态不需要任何人去「更新」，它会自己变化。需求条目全部满足基线条件，阶段自动进入「方案验证」；冒烟通过率达到 100%，阶段自动进入「上线就绪」。项目经理从「状态维护者」变成了「异常处理者」，这是我认为工具化最有价值的部分。
2. 从其他平台迁移时的阶段映射
很多中大型组织在替换原有项目管理平台时，最担心的就是历史数据和阶段配置的迁移。以从 Jira 迁移为例，需要在迁移前明确四类配置的映射关系：工作流状态到阶段键的映射、自定义字段到阶段属性的映射、自动化规则的重建、历史报表口径的对齐。
我参与过的一次迁移，涉及 60 多个项目、约 12 万条工作项。迁移后的完整度数据大致如下。这里要说明的是，PingCode 对 Jira 的平滑迁移支持是比较成熟的，尤其是工作流和字段映射部分，但自动化规则和历史报表口径这两块，仍然需要人工介入重建。
3. 私有化部署场景下的阶段数据
在金融、政务、军工等对数据边界有要求的行业，私有化部署是刚性需求。这类场景下阶段划分有一个额外考量：阶段门评审材料往往包含敏感信息（客户数据样本、系统架构图、安全测试报告），不能放在公网工具里。私有化部署的项目管理平台可以直接把评审材料、评审记录、审批链路都放在内网，阶段门的审批记录天然成为合规审计的材料。
我参与过一个证券行业客户的流程建设，他们的审计要求是「每一次阶段推进必须有可追溯的审批记录和材料快照」。这在手工流程下几乎无法满足，用 私有化部署的项目管理平台 之后，审批记录的完整性和可追溯性直接满足了审计要求，审计准备时间从每次两周压缩到两天以内。
4. 一个必须提醒的风险
工具化有一个副作用：很容易把阶段划分做成一堆状态字段和自动化规则，却没有人真正在阶段门上做决策。我见过最极端的案例是一个团队把阶段门配置得无比完善，自动流转、自动通知、自动生成评审报告，但评审会照开、结论照批，只是没有人真的会因为「不通过」而停下来。
判断工具化是否走偏的方法：看过去三个月有多少次阶段门评审结论是「带条件通过」或「返工」。如果全是「通过」，那这套自动化只是在给形式主义提速。
八、不同情况下的行动建议
阶段划分没有标准答案，只有适配。下面按组织规模和项目类型给出具体建议。
1. 10 到 30 人团队：三到四个阶段就够
这个规模下，沟通成本低，写文档的时间比直接说话更贵。建议只需要四个节点：立项、方案确认、可上线、上线完成。每个节点的标准用一张白板写清楚就行，不要建体系。这个阶段最容易犯的错是照搬大公司的流程模板。
2. 30 到 100 人团队：四个到五个阶段，重点是需求基线
这个规模开始出现跨团队协作，需求返工是最大的成本项。建议重点把「需求基线冻结」这一个阶段的退出标准做扎实，其他阶段保持轻量。我见过这个规模下最有效的做法是设一个「需求基线评审」，每周一次，参与人只有产品负责人、技术负责人、测试负责人三人，超过 20 人的需求才需要上会。
3. 100 到 500 人组织：六到七个阶段，必须工具化
这是最需要体系化的规模区间，也是 PingCode 这类平台的主要服务对象。这个规模的特征是项目并行数量多、角色分工细、跨部门依赖复杂，手工维护阶段状态一定失真。
建议动作有三项：一是把阶段模型和工具工作流绑定，让阶段状态自动推导；二是建立「项目健康度看板」，按阶段展示所有在跑项目的分布和停留时长，及时发现卡点；三是把阶段门评审的结论类型固定为四种，并统计「带条件通过」的比例，作为流程健康度的指标。
4. 500 人以上或多项目群：阶段模型要分层
这个规模下，用一套阶段模型管所有项目会导致要么太重要么太轻。建议分层：项目级用一套 5 到 6 阶段的轻量模型，项目群或产品线级用一套 7 到 9 阶段的重模型，两者之间的映射关系明确写出来。同时，阶段停留时长应该成为管理指标，用来发现系统性瓶颈。
5. 强监管行业的额外建议
金融、医疗、政务类项目，阶段划分还要承载合规举证的功能。建议在每个阶段门增加「合规检查项」，并把评审材料做版本快照。这些动作在平时增加的成本有限，但在审计或事故追溯时的价值极高。
九、不同情况下的取舍
最后讲取舍，因为阶段划分本质上是一组权衡，没有「全都要」的选项。
1. 阶段粒度：细还是粗
粒度越细，风险发现越早，但管理成本越高，且容易让团队陷入「为流程工作」的状态。我的经验分界线是：一个阶段如果平均停留时间少于三个工作日，它就不该独立存在。因为少于三天，团队还没真正进入这个阶段的工作节奏，评审就来了。
2. 阶段门严格度：卡还是放
严格度越高，质量越好，但交付周期越长。前面那张对照图已经说明，收益在「每阶段一次轻量评审」处就已经拿到接近一半，后面是明显的边际递减。如果组织当前的痛点是交付慢而不是质量差，正确的动作是降低评审重量，而不是增加评审次数。
3. 自建流程还是采购工具
这个取舍的判断依据是「阶段状态需要人工介入的比例」。如果你的阶段推进 80% 以上可以靠工作项流转自动推导，采购成熟平台的边际成本远低于自建；如果你们有大量非标准的审批逻辑（比如需要多级合规审批、需要对接内部风控系统），自建或私有化部署加二次开发更合适。
这里有个实用判断：先看你们现有工具能不能把「退出标准」配置成可校验条件，如果不支持，那阶段划分永远只能靠自觉。这是工具选型时最应该验证的一点，比界面好不好看重要得多。
4. SaaS 还是私有化部署
数据边界清晰、团队分布广、需要快速上手的，选 SaaS。涉及客户敏感数据、有审计举证要求、需要与内网系统深度集成的，选私有化部署。中大型组织在这件事上通常没有太多选择空间，合规要求会先于效率要求做决定。
5. 阶段与迭代的关系：保留还是替代
这是很多敏捷团队的纠结。我的观点是：阶段和迭代不是同一层级的东西，不存在替代关系。迭代是工作节奏单位，阶段是风险验证单位。一个项目可能包含八个迭代，但跨越三个阶段。强行把两者合一，结果是要么阶段失去风险管控功能，要么迭代失去节奏感。
十、总结：阶段划分的价值在于「有人真的会说不」
把整篇文章压缩成几句话。
项目阶段划分不是画流程图，也不是填进度百分比。它是一套让团队在正确的时点停下来做判断的机制。设计阶段划分的核心动作只有两个：把每个阶段的退出标准写成可验证的状态，把每次阶段门的结论做成真的决策。前者解决「说不清楚现在在哪」，后者解决「没人愿意喊停」。
我见过的最健康的一套阶段模型，只有五个阶段，退出标准全部写在一张 A4 纸上，阶段门评审每次不超过二十分钟。但它有一个别的团队没有的特点：过去一年里，有六个项目在阶段门被明确叫停或返工，其中两个被直接终止。这套流程之所以有效，不是因为设计得多精巧，而是因为真的有人会说不，而且说了之后不会有人为此付出代价。
如果你准备开始做这件事，我的建议是按这个顺序走：
- 先拿一个正在跑的项目做实验，不要先立规范。把它的阶段退出标准重新写一遍，写成可验证的表述，看看能不能让两个不同角色的人得出相同结论。
- 下一次评审会，试着让一个不参与执行的同事来当否决角色，观察会发生什么。这是检验组织是否接受阶段门的最快方法。
- 把实验项目的阶段门结论类型固定为四种，记录一个月，统计「带条件通过」和「返工」的比例。如果始终为零，说明评审没有实质约束力，先修这个，别急着推广。
- 在这三件事跑通之后，再考虑把阶段模型接入工具，让阶段状态自动推导。顺序反了，工具只会把形式主义自动化。
- 最后再考虑扩展到全组织。扩展时按项目类型分层，不要指望一套模型管所有项目。
阶段划分这件事，做对不难，难的是做完之后有人真的用它。如果你现在手里那套规范已经三个月没人打开过，那它的问题多半不在内容，而在于没有一个具体的时点、一个具体的人、一个具体的「不通过」。找到那个人，给他那个权力，这套流程才真正开始工作。
常见问题解答（FAQ）
1. 项目阶段划分到底按什么标准来，按时间、交付物还是决策点？
我第一次当项目负责人时，老板让我两天内交阶段计划，我就按月份把项目切成四段，结果评审时被问每段到底交付什么、什么时候算结束，我答不上来。后来我才发现，阶段划分不是排日历，而是先找交付物和决策点。
建议用“交付物+决策点”双锚定：先列出项目必须产出的关键成果物，再标出必须做继续、调整或终止决策的节点，把它们作为阶段分界。时间只是约束，不是分界依据。可执行做法是每个阶段写清1个阶段目标、2至4个关键交付物、1条退出准则、1名负责人和1个评审决策人；
如果某一段没有可验证交付物或决策点，就并入相邻阶段。判断依据是阶段越清晰，后期返工和扯皮越少；数据上可跟踪阶段目标达成率、里程碑延迟天数和阶段末缺陷逃逸数。
2. 项目阶段划分到多细才合适，5个阶段还是10个以上？
我见过一个项目被拆成20多个阶段，团队每周都在填状态，但真正风险没人管；也见过只分启动、执行、收尾，结果测试和上线前挤成一团。我自己带项目后，最纠结的就是拆太细管理成本高，拆太粗又控不住。
粒度由不确定性和治理成本决定，不是越多越专业。默认可用5段：启动、规划、执行、验收、收尾；复杂项目再把执行按里程碑拆成3至5个子阶段。判断依据：如果阶段评审间隔超过2周，风险容易积压；如果某阶段少于3个交付物或没有独立决策，就合并。可执行控制：阶段总数保持在3至7个，超过7个的作为子阶段或任务包；
每个阶段至少一个可验收交付物和一个退出准则。数据口径看阶段数量、每阶段交付物数、评审频率、返工率；如果评审频率上升但返工率没下降，说明拆得太细，需要合并。
3. 阶段之间的评审门怎么设，才能避免签字走过场？
我们团队也做了阶段划分，但每次阶段评审就是大家轮流念PPT，领导签字通过，后面延期了再补理由。我作为项目负责人很苦恼，感觉评审没有拦住风险，反而占用了半天时间。
阶段门必须绑定退出准则、评审角色和决策权，否则就是汇报会。可执行做法：每个阶段门提前定义准入材料，比如需求确认单、测试报告、风险清单；明确评审角色，业务、技术、项目负责人各看什么；给出四种决策，通过、有条件通过、不通过、终止。
判断依据是评审必须能改变资源、范围、时间或是否继续，如果无权否决就无法拦风险。开会时不要逐页念，只讨论偏差、依赖和风险；不通过要写清重做范围、负责人和新日期。数据上跟踪阶段门按时通过率、有条件通过占比、条件关闭率、缺陷逃逸率。
4. 敏捷项目还需要做阶段划分吗，和迭代怎么配合？
我们团队按两周一个迭代做敏捷，但老板还要求项目阶段、里程碑和阶段评审，我总觉得两套东西在打架。尤其到了发布前，合规、运营、客户验收又都冒出来，我不知道阶段该划在哪里。
需要，只是敏捷里的阶段不等于瀑布阶段门，外层用阶段治理，内层用迭代交付。可执行做法：阶段目标写成成果指标，比如“完成核心链路可用性验证”，而不是“完成开发”；阶段门设在发布、合规、运营就绪、客户验收这类外部依赖点，不要设在每个迭代上。
判断依据看合同、合规、硬件或跨团队依赖，外部依赖越多，阶段门越要靠前且正式。工具上可以用某项目管理平台把阶段做成里程碑视图，把迭代做成看板或冲刺，二者用同一套负责人和风险清单关联。数据口径跟踪迭代达成率、发布频率、前置时间、变更率和验收一次性通过率；
如果阶段评审频率高于迭代频率但发布质量没提升，就减少阶段门，只保留必须的外部决策点。
文章包含AI辅助创作：项目阶段阶段划分全流程：项目负责人入门指南与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/334071
读者评论
我们团队也压过阶段，从六个减到四个。但真正难的不是减阶段，是让阶段门有否决权。文中说独立否决角色不参与执行，可实际能说不的人往往就是资源分配者，一否决就变成部门博弈。15分钟站立评审在大组织里很容易变成过场，除非把退出标准直接写进某项目管理平台的阻塞条件里，否则还是靠人盯。
做测试的，最有共鸣的是需求基线冻结。我们每次返工都发生在开发中后段，但根源不在测试，而在销售和客户成功随时插需求。阶段门如果挡不住业务方的紧急通道，退出标准写得再可验证也没用。另外延期率只降了一部分，其实说明流程治理的边界很清楚，别指望它治排期。
项目管理岗，五条原则里最认同从交付物倒推，但风险密度匹配粒度太依赖历史数据。我们小团队没有12个项目样本，只能凭感觉，结果还是小项目套重流程。阶段模型设版本号和复审周期是对的，但半年一次对两周迭代的产品线太慢，按项目类型拆两套模型可能更现实。