项目阶段阶段划分全流程：产品经理协同管理与一文讲清

2022 年秋天，我参与了一家 280 人规模、软硬件混合研发企业的流程诊断。他们的项目阶段划分表做得比大多数互联网公司都漂亮：需求、方案、设计、开发、测试、验收、上线，七个阶段，每个阶段都写明了输入、输出、责任人和评审节点，甚至还配了完整的泳道图。

但当我拉到真实数据时，情况完全相反，项目平均延期 41%，需求返工率 28%，产品经理每周有 11.4 小时花在补阶段评审材料上，工程师有 32% 的等待时间发生在”等上一阶段确认”这个动作上。这张漂亮的阶段表，实际上变成了一台精密的摩擦制造机。

这不是个例。过去几年，我在中大型企业的研发流程改造里反复看到同一个模式：阶段划分表做得越精致，交付反而越慢。问题不在于团队不认真，而在于大多数人对”项目阶段划分”这件事的理解，从第一层就偏了。这篇文章我会把阶段划分的全流程讲清楚：产品经理在每个阶段到底该干什么、协同关系怎么定、门禁怎么设、工具怎么托住流程，以及在什么规模下该做多少阶段。文中会用 PingCode 作为中大型企业场景的具体承载平台来说明落地细节。

一、核心结论：阶段划分的本质是切分不确定性，不是切分时间

先把结论摆出来，后面所有内容都是围绕它展开的。如果你只记住一句话，那就是：项目阶段划分的本质，是把一个项目从”高度不确定”推进到”高度确定”的过程切成若干段，而不是把日历切成若干段。

1. 三个可以直接执行的判断

基于这个本质，我给出三条判断，它们可以直接用来检验你现在的阶段表是不是合理的。

判断一：每个阶段必须对应一次”不确定性的大幅下降”。如果两个相邻阶段之间的不确定性没有明显变化，那这两个阶段就该合并。我见过一个团队把”需求收集”和”需求评审”拆成两个阶段，结果两个阶段的产出物几乎一样，唯一的区别是中间多开了一次会。

判断二：每个阶段必须有一个”能说不行”的人。没有否决权的门禁不是门禁，是汇报会。这是阶段划分失效最常见的技术性死因，我在第三节会展开。

判断三：阶段数量应该由不确定性收敛速度决定，而不是由组织规模、领导偏好或行业惯例决定。成熟业务（比如支付、账务、基础组件）不确定性低，3 到 4 个阶段就够；创新业务（比如新品类、新市场）不确定性高，反而需要更细分的前端阶段，因为早期每一次澄清的价值都极大。

2. 为什么”阶段越多管控越强”是错的

这是我要重点挑战的一个反常识观点：阶段数量和管理强度之间不是线性关系，而是一条先降后升的 U 型曲线。

阶段太少时，缺少必要的决策节点，问题会一直积累到最后才爆发，返工成本极高。阶段太多时，每次评审都要消耗产品经理、技术负责人和业务方的注意力，而这些注意力本身就是最稀缺的资源。更关键的是，阶段越多，”等待上一阶段确认”的空转时间会非线性增长。

下面这组数据来自我在 2023-2024 年参与的多个研发组织流程改造中的观察样本（非公开统计，属于样本推演，仅用于展示趋势，不作为行业基准）。同一业务类型、相近团队规模下，不同阶段颗粒度的结果差异非常明显。

这里有一个很关键的细节：返工率的拐点出现在 7 段左右，而交付周期的拐点出现在 5 段左右。这意味着”质量最优”和”速度最优”对应的阶段数并不相同。这正是阶段划分决策的真实难度所在，它不是一个最优化问题，而是一个取舍问题，我在第七节会专门讲这个取舍怎么算。

3. 阶段划分受三条硬约束

在动手设计阶段表之前，先确认你所在的组织受哪几条硬约束影响，因为约束会直接决定你的设计空间。

• 合规约束：金融、医疗、汽车电子等行业，阶段划分往往由外部标准倒推，门禁证据链必须可追溯、可审计，阶段名和交付物格式的调整空间很小。
• 依赖约束：硬件、供应链、第三方接口等外部依赖，会强制某些阶段必须串行，不能并行压缩。
• 组织约束：如果团队是按职能划分的（前端组、后端组、测试组），阶段边界和部门边界不一致时，跨部门协同成本会显著上升。

我一般建议团队先花半小时把这三条约束写清楚，再去设计阶段。跳过这一步直接抄模板，是后面所有返工的源头。

二、背景与真实场景：阶段划分为什么会在大团队里失效

理解了本质之后，我们来看真实场景。阶段划分的问题几乎不会在 30 人以下团队出现，因为那时候大家坐在同一间屋子里，口头同步就能覆盖所有信息。问题真正爆发，是在组织从”能喊得应”变成”要靠文档对齐”的那个临界点之后。

1. 一个 280 人组织的完整诊断记录

回到开头那家企业。他们当时的状态是：3 条产品线，11 个研发小组，产品经理 14 人，项目经理 6 人，研发 190 余人。阶段表是七段制，听起来很完整。

但我在一周的访谈里发现三件事。第一，产品经理普遍认为自己的职责在”需求阶段”就结束了，后面属于项目组的事。第二，项目经理认为自己是”排期和追进度”的角色，不参与需求判断。第三，工程师不知道当需求出现歧义时，到底该找谁拍板。

结果就是：阶段表把职责切得很清楚，但把决策权切丢了。每个阶段都有责任人，但没有人对”跨阶段的决策”负责。需求在阶段之间传递时，每次传递都会丢失大约 15% 的原始意图，到开发阶段时，工程师拿到的需求描述和业务方最初想表达的内容已经产生了实质性偏差。

2. 产品经理的位置被系统性地放错了

这是我最想强调的一点。在绝大多数失败的阶段划分里，产品经理被放进了”某个阶段”，而不是”贯穿所有阶段”。

正确的理解是：产品经理是每个阶段里”不确定性收敛”的负责人。需求阶段收敛的是”做什么”，方案阶段收敛的是”为什么这么做”，开发和测试阶段收敛的是”做出来的东西是不是想要的东西”，上线阶段收敛的是”是否产生预期价值”。这四个收敛动作，一个都不能少。

而项目经理的角色是节奏和门禁的守门人：确保每个阶段的收敛动作按时发生、证据完整、门禁有明确的通过或不通过结论。两者的协同关系可以概括为，产品经理对”内容正确性”负责，项目经理对”过程有效性”负责。

3. 阶段划分失效的三个早期信号

如果你不确定自己的阶段划分是否已经开始失效，可以对照这三个信号，它们通常比延期更早出现。

1. 阶段评审会变成”过场会”。会议时长稳定在 30 分钟以内，没有人提出反对意见，通过率接近 100%。这说明门禁已经失去筛选功能。
2. 阶段状态靠人问。想知道某个项目在哪个阶段，需要去群里问或者翻聊天记录。这说明阶段状态没有被系统承载，而是活在人的记忆里。
3. 阶段文档量在增长，但决策记录在减少。每次评审都产出十几页材料，但翻遍全文档找不到”当时为什么选择方案 B 而不是方案 A”。这说明阶段在制造文书工作，而不是在沉淀决策依据。

三、常见误区拆解：六个我反复见到的坑

诊断过足够多的团队之后，我发现阶段划分的错误高度集中。下面六个坑，几乎每个出问题的组织都至少踩了三个。

1. 用瀑布的外壳装迭代的内核

最常见的形态是：阶段名叫”需求、设计、开发、测试、上线”，但实际执行是两周一个迭代，每个迭代里都包含需求、开发、测试。结果是两套逻辑打架，阶段要求串行，迭代要求并行。

（1）症状是：项目在”开发阶段”里，却同时在做需求澄清和方案设计。

（2）后果是：阶段状态失真，谁也不知道项目到底在哪个阶段，阶段评审也就失去了判断依据。

正确的做法是分层：阶段用于管理”不确定性收敛”和”对外承诺”，迭代用于管理”交付节奏”。两者是不同维度，不是同一维度的粗细版本。阶段可以是 5 个，迭代可以是 2 周，一个阶段里跑 4 到 6 个迭代，这是完全正常的。

2. 交付物定义停留在名词层面

“需求文档””技术方案””测试报告”，这些是名词，不是交付物定义。真正的交付物定义必须包含三个要素：格式、验收标准、责任人签字方式。

我见过一个团队规定”方案阶段必须产出技术方案文档”，但没规定文档要包含什么。结果有的方案是 3 页 PPT，有的是 40 页 Word，评审根本无法用同一把尺子衡量，最后退化成”看谁讲得好”。

3. 门禁只有汇报权，没有否决权

这是最致命的一条。如果阶段门禁的结论只有”通过”和”通过但补充材料”，那它就不是门禁。

合格的门禁必须能做出三种结论：通过、有条件通过（明确条件和期限）、不通过（退回上一阶段或终止）。我通常建议团队在门禁里明确设置一个”能否决的角色”，通常是技术负责人或产品负责人，并且规定否决必须给出可验证的理由。

4. 产品经理在需求阶段之后”消失”

前面已经提过，这里再强调一次操作层面的细节。产品经理在每个阶段都应该有明确的产出。

这张表的重点是最后两列。很多团队只填了中间两列，于是产品经理自然就”只能管需求阶段”了。

5. 阶段边界对齐部门边界

当一个 200 人组织的部门结构是”前端组、后端组、测试组、运维组”时，有人会自然地把阶段也切成”前端阶段、后端阶段、测试阶段、运维阶段”。这是把组织结构图当成了流程图。

阶段应该对齐的是”交付价值的完整性”，不是”谁负责哪块”。正确做法是：阶段内部包含所有必要角色，阶段之间由交付物衔接。角色是横向的，阶段是纵向的。

6. 阶段数量随负责人换届而变

这条看起来像玩笑，但真实发生频率极高。换一位研发负责人，阶段表就要改一次；换一位产品负责人，门禁标准又要调一次。阶段划分如果不写在制度里、不落在平台配置里，它就只是一种个人偏好。

解决方案是把阶段模型固化到工具层：阶段、门禁、交付物清单、责任人全部在平台上配置成模板，新项目从模板创建。这样阶段划分才从”某人的想法”变成”组织的资产”。

四、专业判断逻辑：用四个坐标系决定阶段怎么切

讲完误区，进入方法论。我不推荐直接抄任何一套阶段模板，因为模板是别人在别人的约束下做出的取舍。更有用的是掌握四个坐标系，用它们交叉定位出适合你的阶段划分。

1. 不确定性坐标系：决定阶段在哪里切

把项目从头到尾的不确定性画成一条下降曲线。在曲线上找”斜率突变”的位置，那就是自然的分段点。

（1）第一段通常是”问题是否存在”，不确定性极高，一次澄清可能推翻整个项目。

（2）第二段是"解是否可行"，不确定性中等，主要靠技术验证和方案对比收敛。

（3）第三段是"做出来对不对"，不确定性中低，靠验收标准和测试覆盖收敛。

（4）第四段是"有没有价值"，不确定性重新上升，因为它依赖真实用户和真实市场反馈。

注意最后一段：上线不是终点，价值验证才是。大多数团队的阶段表在上线就结束了，这等于主动放弃了唯一能验证”这个项目值不值得做”的机会。

2. 决策权限坐标系：决定每个阶段的”谁说了算”

每个阶段必须明确三类决策权：内容决策权（做什么、怎么做）、质量决策权（够不够格通过）、终止决策权（要不要停下来）。

我看到的优秀实践是：内容决策权给产品经理，质量决策权给技术负责人，终止决策权给产品负责人或业务负责人。三者分离，避免”既当运动员又当裁判”。

3. 交付物坐标系：决定阶段之间怎么衔接

交付物不是文档，是可以被下游直接使用的输入。判断标准很简单：如果下游拿到这份交付物后，还需要回头找上游问三个以上问题，那这份交付物就是不完整的。

我在实践中会要求每个交付物必须包含”决策记录”部分，也就是记录”当时考虑了哪些选项、为什么选了现在这个”。这一部分往往比结论本身更有价值。

4. 时间盒坐标系：决定每个阶段允许多长

阶段必须有时间上限，否则它会无限期拖延。经验法则是：单个阶段的时间盒不应超过整个项目周期的 40%，前端探索类阶段建议控制在 15% 以内。

如果一个阶段超期，正确的处理不是延长，而是触发一次门禁复盘：是范围太大、依赖没解决，还是决策没做出来。这三种原因对应完全不同的处理方式。

5. 门禁设计的三条验收标准

设计完阶段，最后一步是设计门禁。我用三条标准来检验门禁是否合格。

1. 可验证：每条通过条件都能用客观证据判断真假。”方案足够清晰”不合格；”方案包含至少两种备选路径及选择理由，且技术负责人签字确认”合格。
2. 可拒绝：门禁必须真的出现过”不通过”。如果一个门禁连续半年 100% 通过，要么条件太松，要么执行不到位。
3. 可回滚：不通过之后的动作必须明确，退回哪里、补什么、谁来跟踪、多久复审。

下面是一份我在实际项目中用过的阶段配置示例（脱敏后），它展示了阶段、门禁、时间盒和责任人如何在一个配置文件里表达清楚。

stages:

name: 机会验证

timebox_days: 10

owner: 产品经理

exit_criteria:

问题陈述包含目标用户、频次、影响面量化

至少完成 5 次目标用户访谈并留存记录

成功指标可测量，且已与业务方确认

gate:

五、案例与数据观察：一家 300 人企业重构阶段划分的完整过程

方法论讲完，我们看一个完整案例。这是我在 2024 年深度参与的一个项目，客户是一家 300 人规模的企业级软件公司，业务覆盖三个行业线，研发人员约 210 人，产品经理 18 人。他们当时的核心痛点是：交付周期长且不可预测，产品经理和项目经理互相抱怨，需求变更没有记录。这也是我推荐中大型企业优先考虑 PingCode 这类国产平台的典型场景。

1. 改造前的基线数据

我们先花了两周做基线测量，得到的数据比客户自己预估的更糟。

• 平均交付周期：96 天（从需求提出到上线）。
• 需求返工率：28%（上线后 3 个月内发生实质性返工的比例）。
• 单次门禁评审平均耗时：3.5 小时，其中约 40% 时间用于协调参会人和对齐背景。
• 阶段状态同步人工耗时：9 小时/周，分布在 6 位项目经理身上。
• 变更记录完整率：约 22%，大部分变更靠口头确认。

2. 阶段重构的具体动作

我们把原来的七段制压缩为四段制：机会验证、方案定义、交付实现、价值验证。同时在交付实现内部保留两周一个迭代的节奏。四个具体动作如下。

1. 合并”需求收集”与”需求评审”为”机会验证”，并引入”问题陈述必须包含量化影响面”的硬性要求。这一条直接淘汰了约 38% 的提案。
2. 把门禁决策权从”集体评审”改为”单人负责 + 集体知情”，每道门禁明确一个决策人。评审时间因此从平均 3.5 小时降到 1.2 小时。
3. 为产品经理定义了跨全部四个阶段的产出物清单，并在平台上配置为必填字段。产品经理在交付实现阶段必须参与变更优先级裁决。
4. 所有阶段状态、门禁结论、变更记录全部在平台上留痕，取消手工周报。

3. 平台承载：流程必须落在工具上才算落地

这是我想强调的经验：阶段划分方案再漂亮，如果没有平台承载，三个月后就会退化回原样。原因很简单，人工维护状态的成本会随着项目数量增长而失控，这个客户在改造前有 47 个在途项目，靠 Excel 和群消息根本管不过来。

他们最终选择了 PingCode 作为承载平台。选择理由有三点，也正好是中大型企业在这个场景下的关键考量：一是 PingCode 主要服务中大型企业及 100 人以上组织，阶段-迭代-工作项的三层模型天然匹配”阶段管收敛、迭代管节奏”的分层设计；二是支持私有化部署，对这家有数据合规要求的企业来说是硬门槛；三是支持 Jira 平滑迁移，他们此前的工作项、迭代、附件和部分历史记录需要延续，不能推倒重来。

实际配置上，他们把四个阶段配置为项目模板，门禁条件配置为工作流的必填校验，未填写”决策记录”字段就无法流转到下一阶段。这一步把制度变成了系统约束，比任何培训都有效。

4. Jira 迁移的实操细节与代价

迁移这件事，我不想讲得太轻松。平滑迁移不等于零成本，这里把真实的工作量拆开讲，方便你评估自己的迁移预算。这家企业总共约 1.2 万个历史工作项、86 个历史迭代、约 240 个自定义字段。

（1）字段映射是最耗时的部分，因为需要业务方逐个确认字段是否还有价值。

（2）工作流重构是最有价值的部分，因为它是把新阶段模型落地的唯一途径，不能交给外部实施方独立完成。

（3）试运行双跑是最容易被砍掉的部分，也是最不该砍的部分。

5. 改造后的数据与三个意外发现

改造后第 6 个月，我们复测了同一组指标。整体改善明显，但有三个发现超出了我的预期。

意外发现一：交付周期的缩短几乎全部来自等待时间的压缩。拆分后发现，纯开发工时只减少了 4%，但跨阶段等待从平均 31 天降到 14 天。这再次印证了第二节的判断，大组织的瓶颈在衔接，不在产能。

意外发现二：产品经理的满意度提升幅度高于工程师。改造前产品经理普遍抱怨”事情太多且不受控”，改造后抱怨变成了”决策责任重但清晰”。原因很简单：当责任边界清楚、且被系统记录时，扯皮空间就消失了。

意外发现三：“决策记录”字段的填写质量在前 6 周很差，之后自行改善。一开始很多产品经理只写一句话，但当他们发现下游工程师真的会去读、并且减少了自己被追问的次数后，填写质量自然就上去了。这说明流程约束需要给一个适应期，不能因为前几周质量差就放弃。

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

案例讲完，我们把视角拉回到你的组织。下面按规模和特征给出四组可直接执行的建议，你可以直接对照使用。

1. 50-100 人：阶段要少，门禁要硬

这个规模下最大的风险是”过度流程化”。我的建议是三个阶段封顶：机会验证、交付实现、价值验证，把方案定义合并进机会验证。理由是这个规模下技术可行性的判断通常可以在几天内完成，单独设阶段收益太低。

但门禁必须硬。尤其是机会验证的出口，一定要有量化的影响面数据。我见过太多小团队因为跳过这一步，在半年后才发现做了个没人用的功能。

这个规模可以先不上平台，但至少要用一个统一的工作项表来承载阶段状态，避免用聊天记录管理项目。

2. 100-500 人：阶段分层，模板复用

这是阶段划分真正产生价值的区间。建议四到五个阶段，并在每个阶段内部定义标准的迭代节奏。关键动作是”模板化”：把阶段表、门禁条件、交付物清单、责任人配置成项目模板，新项目从模板创建，不允许自由发挥。

这个阶段引入平台几乎是必然选择。PingCode 在这个区间的适配度较高，因为它本身就是面向 100 人以上组织的，阶段-迭代-工作项三层模型可以直接表达”阶段管收敛、迭代管节奏”这个分层设计，不需要额外开发。同时支持私有化部署，对有数据边界要求的企业是必要能力。

如果你目前在使用海外工具并且有迁移计划，建议把工作流重构作为迁移的核心任务而不是附带任务，因为它直接决定新阶段模型能否落地。

3. 500 人以上或多产品线：双轨阶段模型

这个规模下用同一套阶段模型管理所有产品线是不现实的。建议采用双轨制：主干阶段统一（保持组织级可比性），阶段内的交付物和门禁标准按产品线差异化。

具体做法是：总部定义阶段名称、数量和时间盒上限，各产品线定义自己的交付物清单和门禁细则。这样既保证了跨产品线的数据可比，又给了各条线必要的灵活性。

4. 强合规行业：阶段与证据链绑定

金融、医疗、汽车电子等行业，阶段划分的自由度低，重点应该放在”证据链完整性”上。建议把每个阶段的产出物直接设计成可审计的证据单元，包含责任人、时间戳、版本和变更记录。

这类场景对平台的要求会更高，私有化部署基本是刚需，同时需要保证所有门禁结论和变更记录可导出、可追溯。

七、不同情况下的取舍：没有”全都要”

行动建议之后，必须讲取舍。因为所有关于阶段划分的讨论，最后都会落在几个无法同时满足的目标上。我在实际决策中通常用四组取舍框架来帮助团队做判断。

1. 阶段数量 vs 管理成本

每增加一个阶段，都会带来固定的管理成本：多一次评审、多一份交付物、多一个状态同步点。根据我的观察样本，单个阶段的管理成本大致在每项目 3 到 6 小时之间，规模越大越高。

取舍的判断标准是：这个新增阶段能否在后续节省超过它自身成本的时间。如果它只能带来”看起来更规范”的心理收益，就应该砍掉。我在第一节给出的 U 型曲线，本质上就是这个取舍的可视化。

2. 门禁严格度 vs 交付速度

这条取舍最容易走极端。门禁太松，问题积累到后期爆发；门禁太严，团队为了过门禁而准备材料，反而挤占了实际工作的时间。

我的经验是前端严、后端松：机会验证和方案定义两道门禁应该严，因为此时变更成本最低；交付实现和价值验证的门禁应该以”是否有明确结论”为标准，而不是以”材料是否完备”为标准。

3. 标准化 vs 灵活性

标准化带来可比性和可复用性，灵活性带来适应不同业务的可能。这两者在 300 人以上组织中会持续摩擦。

我的建议是分层处理：阶段名称、数量、时间盒上限标准化；交付物形式、门禁细则、评审方式灵活化。也就是”框架统一、细节自治”。这样既能做跨产品线的数据对比，又不会让创新业务被成熟业务的流程压死。

4. 自建 vs 采购平台

这是一个经常被低估的取舍。有些团队认为阶段划分是管理问题，用 Excel 就能撑。但我的经验是：当在途项目超过 30 个、跨部门角色超过 5 类时，手工维护的阶段状态一定会失真。

采购平台的成本是显性的，自建和手工维护的成本是隐性的但往往更高。以案例中的企业为例，改造前仅阶段状态同步就消耗 9 小时/周，一年约 450 小时，接近 0.25 个人力。加上返工带来的损失，实际成本远高于平台费用。

对于有私有化部署要求、或者需要从海外工具迁移的团队，选型时建议重点评估三件事：是否支持私有化部署、是否支持平滑迁移（尤其是历史工作项和工作流的迁移能力）、是否具备阶段-迭代-工作项的分层模型。PingCode 在这三点上比较契合中大型企业的需求，也是这类场景下国产替代的常见选择之一。

八、把阶段划分做成可复利资产

文章最后，我想回到最初那个反常识判断：阶段划分不是流程设计问题，而是组织认知问题。它决定了这家公司如何理解”不确定性”，以及如何分配”决策权”。这两件事会随着时间复利。

1. 三个我认为最值得记住的独特观点

观点一：阶段数量的最优解不在质量曲线上，在成本曲线上。返工率的最优点在 7 段附近，交付周期的最优点在 5 段附近，而实际应该选择的是”总成本最低”的那个点。大多数团队只看返工率，所以阶段越加越多。

观点二：阶段划分的失败几乎从不来自阶段太少，而是来自门禁没有牙齿。帕累托数据显示，仅”门禁无否决权”和”交付物定义模糊”两项就贡献了 56% 的失效问题。与其纠结分几段，不如先解决”谁能说不”。

观点三：产品经理不是某个阶段的角色，而是每个阶段不确定性收敛的负责人。把这句话理解到位，产品经理和项目经理的协同关系就自动清晰了，一个对内容正确性负责，一个对过程有效性负责，两者的接口就是门禁。

2. 下一步：未来两周可以做什么

如果你读完之后想动手，我建议按这个顺序推进，不要一次全改。

1. 第一周：测量基线。至少收集四项数据，平均交付周期、需求返工率、跨阶段等待天数、门禁评审平均耗时。没有基线的改造无法验证效果。
2. 第一周：检查门禁权限。把现有每个阶段的门禁决定人写出来，看看有多少个门禁其实没有明确的否决人。这一条改动成本最低，收益最高。
3. 第二周：重写交付物定义。挑出最常出问题的两个阶段，把交付物从名词改成”格式 + 验收标准 + 责任人”的完整定义。
4. 第二周：确认承载方式。统计在途项目数量和涉及角色数，如果在途项目超过 30 个、角色超过 5 类，就认真考虑用平台承载阶段状态，而不是继续用表格。

最后提醒一句：阶段划分的改造，不要一次性推给全公司。选一条业务线、3 到 5 个项目做试点，跑满一个完整周期（通常 2 到 3 个月），拿到数据之后再推广。我见过太多团队一次性全量切换，结果因为初期阵痛被叫停，反而回到更糟的旧流程。

阶段划分这件事，做对了是组织的复利资产，做错了是每个项目的固定税。区别在于你是在切时间，还是在切不确定性。