阶段划分落地方案：研发团队开展项目阶段的实操方法案例解析

2023 年 Q2，我接手了一个 180 人研发组织的流程改造项目。改之前，团队平均每个中等规模需求的端到端交付周期是 47 天；改完之后第 6 个月，这个数字降到 31 天，但同时期线上缺陷密度只下降了 9%。这个结果当时让我很不安：周期快了，质量没跟上，说明我砍掉的那几道门禁里，有些其实是有效拦截点，只是被执行成了形式。后来我们把门禁从 7 道重构成 3 道硬门禁 + 2 道软检查，又花了一个季度，才把缺陷密度压下来 34%。

这就是我写这篇文章的原因，阶段划分这件事，看起来是流程设计，实际上是”成本与风险在哪里转移”的取舍问题，绝大多数团队第一次做都会做错方向。

一、先把结论说清楚：阶段划分的本质是管理不确定性，不是画流程图

我先给结论，后面再用案例和数据展开。如果你只想要能直接用的判断标准，这一节就够了。

1. 阶段数量由不确定性衰减速度决定，不由组织架构决定

很多人做阶段划分的起点是”我们公司有哪些部门”，然后按部门切阶段：产品部一段、设计部一段、开发部一段、测试部一段、运维部一段。这种切法的结果是，阶段边界和部门墙完全重合，跨阶段协作变成跨部门博弈。

我的判断标准是反过来的：先看这个项目的不确定性在哪里衰减得最快，衰减快的地方就该切阶段。一个需求明确、技术方案成熟的迭代项目，不确定性主要集中在”验收标准是否理解一致”，那么需求确认阶段就该切细，开发测试反而可以合并。

而一个技术预研型项目，不确定性集中在”技术路线是否可行”，那预研验证必须独立成阶段，还要有明确的放弃标准。

2. 阶段划分真正落地的唯一标志：阶段交付物有唯一责任人

我复盘过 20 多个团队，判断他们阶段划分是不是真落地，只看一件事：能不能在 30 秒内说出每个阶段交付物的唯一责任人是谁。注意是唯一，不是”产品团队负责”这种集体归属。

凡是交付物写成”需求文档若干””测试报告一份”并挂在部门名下的，最后都会演变成”谁写得慢谁背锅”。凡是写成”需求验收标准清单，责任人：张 XX”的，阶段结束就有明确的是否通过判断。

3. 门禁的价值是提前暴露问题，不是事后签字

这是我最想纠正的一点。我在不少组织里见过门禁评审会：5 个人围坐，10 分钟过完一个阶段，签个字，散会。这种门禁不但没用，还有害，它给团队一种”我们做了质量把控”的错觉，实际上把风险全部推到了下游。

有效的门禁只有一个衡量标准：它是否让本该在测试阶段才发现的问题，提前到了需求或设计阶段被发现。如果一道门禁半年内没有拦下过任何东西，它就该被删掉。

4. 工具的职责是把阶段固化下来，不是让阶段变成填表

阶段划分落地方案最终要落到工具上。但工具选错了，或者配置错了，阶段就会退化成”状态字段填写”。我在后面会用一个真实的工具落地案例说明，怎么把阶段门禁做成自动化规则，而不是人工审批流。

二、我经历的三次阶段划分翻车现场

讲方法论之前，先讲三个我真实踩过的坑。这三个坑分别对应阶段划分的三类失败：门禁过密、交付物过虚、度量错位。

1. 第一次翻车：7 道门禁，把项目拖成了审批马拉松

那是一家做企业级软件的公司，研发 200 人出头，产品线 3 条。我们当时设计了一套看起来很完整的阶段模型：需求立项、需求评审、方案设计、设计评审、开发完成、测试通过、上线审批，一共 7 个阶段，每个阶段都有门禁。

上线三个月后，我拉了数据，平均每个项目的阶段间等待时间是 13.5 天，其中真正用于评审的时间不到 2 天，其余都是”等人齐”。更麻烦的是，团队学会了提前把材料准备好，评审会变成走过场，没人真的在门禁上做判断。

那次我们做了什么修正？把 7 道门禁压缩成 3 道硬门禁：需求验收标准确认、技术方案冻结、上线前质量红线检查。其余 4 道改成异步检查清单，不占用会议时间，由责任人自查并在工具里勾选。改完之后，阶段间等待时间从 13.5 天降到 4.2 天。

2. 第二次翻车：阶段交付物写成”文档若干”，没人知道什么叫完成

第二个项目更隐蔽。阶段模型设计得挺合理，5 个阶段，门禁也不多。但运行半年后，出现了大量”阶段完成了但下游返工”的情况。我去追原因，发现问题出在交付物定义上。

当时的交付物清单是这样的：需求阶段交付《需求说明书》，设计阶段交付《详细设计文档》，开发阶段交付《代码》，测试阶段交付《测试报告》。每一条都没有可验证的完成标准。

举个具体的例子：需求阶段写”需求说明书完成”，但没人规定验收标准必须覆盖到什么程度。结果开发拿到需求后，平均每个需求要追问 4.7 个澄清问题，这些追问本质上都是需求阶段该做完的工作。阶段交付物如果没有可验证标准，阶段划分就只是给延期找到了一个更好听的解释。

后来我们改成了”交付物 + 完成判据”的双列结构，比如需求阶段的交付物是”需求项清单 + 每条需求的验收标准”，完成判据是”验收标准覆盖率 ≥ 95%，且每个验收标准可被测试用例直接映射”。改完之后，开发阶段的澄清问题从平均 4.7 个降到 1.3 个。

3. 第三次翻车：度量指标用”按时完成率”，团队学会了在阶段末集体造假

第三个坑最值得警惕。我们曾经用”阶段按时完成率”作为核心度量指标，写进了季度考核。前两个月数据非常漂亮，从 68% 涨到 91%。但同期线上缺陷数涨了 40%。

原因不难猜：为了让阶段按时完成，团队学会了把没做完的部分拆到下一个阶段，把测试阶段的问题标记为”下一迭代优化”，把需求阶段没澄清的点留到开发阶段现场决定。指标一旦和考核强绑定，团队优化的就一定是指标，而不是指标背后想表达的东西。

修正方式是把单一指标换成了指标对：进度指标（阶段按期完成率）+ 质量指标（阶段逃逸缺陷数）。而且明确规定，如果阶段逃逸缺陷数超过阈值，按期完成率再高也不计入正向评价。这套组合指标用了两个季度后，按期完成率回落到 79%，但逃逸缺陷数下降了 34%。

4. 从三次翻车里总结出的三件事

第一，门禁数量要砍到”每一道都能说出最近一次拦下了什么”。说不出来的就删。第二，交付物必须配可验证判据，判据要能被第三方独立核对，不需要问作者。第三，度量指标必须成对，进度和质量同时看，否则指标一定会被优化成假的。

这三条听起来都很朴素，但我见过的落地失败案例里，九成以上都能归到这三条里。

三、拆解 6 个最常见的误区

说完案例，我把常见的坑系统整理成 6 个误区。你可以拿这 6 条去对照自己团队现在的阶段划分方案，命中两条以上就需要重新设计了。

1. 误区一：把阶段等同于部门职责

最典型的表现是阶段名称直接用部门名：产品阶段、开发阶段、测试阶段。这种命名会带来一个隐性问题，阶段责任人自动变成了部门负责人，而部门负责人天然会为本部门的工时和 KPI 考虑，不会为整体交付周期考虑。

更合理的命名方式是按交付成果命名：需求定义与验证、方案设计与技术冻结、可运行版本交付、质量验证与发布准备。名字变了，责任归属讨论的焦点就从”该谁做”变成了”什么算做完”。

2. 误区二：阶段越多越规范

很多从传统行业出来的管理者会倾向于把阶段切得很细，因为看起来更可控。但在研发场景里，阶段越多，阶段间交接成本是超线性增长的，不是线性增长。

原因在于每增加一个阶段，就多一次信息传递，而信息传递必然伴随损耗。我在前面那张图里给的数据是：从 3 道门禁到 9 道门禁，等待时间从 4.2 天涨到 17.8 天，涨了 4 倍多，而阶段数只涨了 3 倍。这个超线性部分，就是沟通损耗。

3. 误区三：先定流程后定交付物

这是执行顺序错误。很多团队先画一张漂亮的阶段流程图，然后倒推每个阶段要产出什么。这样推出来的交付物，通常是为了填满流程图而存在的，不是真正被下游需要的。

正确的顺序是倒过来的：先问下游需要什么才能开始工作，再决定上游阶段要产出什么，最后才决定这些产出物需要几道阶段来承载。交付物是原因，阶段是结果。

4. 误区四：门禁只审”有没有”，不审”够不够”

“需求文档提交了吗？提交了，通过。”这就是典型的只审有无。有效的门禁必须审质量，而且要给出可量化的阈值。

举例来说，需求阶段门禁不应该是”需求文档已提交”，而应该是”每个需求项都有验收标准，且验收标准到测试用例的映射覆盖率达到 95% 以上”。前者只需要一个人点一下鼠标，后者需要真正检查内容。

5. 误区五：度量只看进度不看质量

这一条在上一节的第三次翻车里已经讲过。补充一点：质量指标的选择也很关键。不要用”测试用例执行通过率”这类可以被轻易操纵的指标，要用”阶段逃逸缺陷数”这种下游视角的指标。因为逃逸缺陷是下游发现的，上游无法直接操纵。

6. 误区六：工具照搬别人模板

我见过不少团队直接下载某个项目管理平台的阶段模板，导入就用了。问题是，模板里的阶段划分对应的是别人团队的规模、项目类型和协作模式，直接套用大概率不匹配。

工具应该做的是”承载你已经设计好的阶段模型”，而不是”替你决定阶段怎么划”。所以在选工具时，我最看重的是它能不能灵活配置自定义工作项类型、状态流和自动化规则，而不是它预置了多少模板。

四、我判断阶段划分是否合理的四层逻辑

这一节是方法论主体。四层逻辑从下到上分别是：不确定性分布、准入准出双清单、颗粒度匹配、度量回流闭环。缺任何一层，方案都会在某个环节失效。

1. 第一层：先画出不确定性，成本曲线，再决定在哪切

缺陷发现得越晚，修复成本越高，这是软件工程里的经典结论。业界普遍引用的量级是：需求阶段发现的问题，修复成本记为 1；设计阶段大约是 3 到 5 倍；编码阶段约 10 倍；测试阶段 20 到 50 倍；上线之后 100 倍以上。

这个曲线决定了阶段划分的基本原则：把阶段门禁放在成本跳变最剧烈的位置之前。从设计到编码、从编码到测试，这两个位置是成本跳变最大的地方，所以”方案冻结”和”质量红线检查”几乎在任何规模下都应该是硬门禁。

而像”需求立项审批””上线审批”这类门禁，成本跳变幅度小，可以根据组织实际情况做成软检查甚至取消。

2. 第二层：为每个阶段准备”准入清单 + 准出清单”

准入和准出要分开定义，这是很多团队漏掉的一步。准入清单回答”什么条件下这个阶段才能开始”，准出清单回答”什么条件下这个阶段才算结束”。

我通常建议准入清单控制在 3 条以内，准出清单控制在 5 条以内。超过这个数量，团队会开始忽略清单，因为核对成本太高。

下面是一个可以直接改用的阶段配置结构，我用 YAML 写出来，方便你对照自己工具里的配置项：

stages:

id: S1

name: 需求定义与价值验证

owner: 需求负责人（唯一）

entry_criteria:

业务方已完成问题描述与期望结果确认

已识别关键干系人并完成一次对齐

deliverables:

需求项清单（每条含验收标准）

价值假设与目标衡量指标

exit_criteria:

验收标准覆盖率 >= 95%

每条验收标准可映射到至少 1 条测试用例

干系人对验收标准无未决异议

gate_type: hard

id: S2

name: 方案设计与技术冻结

owner: 技术负责人（唯一）

entry_criteria:

S1 准出清单全部通过

deliverables:

技术方案与接口契约

影响面分析与回滚方案

exit_criteria:

接口契约经上下游双方确认

关键路径存在可执行的回滚方案

gate_type: hard

注意这里的 gate_type 字段，它区分了硬门禁和软检查。硬门禁需要评审会议和明确签字，软检查只需要责任人在工具里勾选并留下记录。这个区分能省掉大量会议时间。

3. 第三层：阶段颗粒度必须和团队规模、项目类型匹配

我一直反对把一套阶段模型推给所有团队。颗粒度至少要按两个维度分化：团队规模，以及项目是交付型还是产品型。

交付型项目（按合同、按里程碑验收）需要更清晰的阶段边界和更正式的交付物，因为验收节点是对外的。产品型项目（持续迭代）可以更轻，阶段边界可以模糊一些，重点放在质量红线上。

这里给一个我实际用过的对应关系表：

4. 第四层：建立度量回流闭环，让阶段模型能自己进化

阶段划分方案不是一次设计完就固定不变的。必须有一组指标持续回流，用来判断哪些门禁该加强、哪些该删掉。

我固定会看四个指标：阶段逃逸缺陷数（按发现阶段归因）、阶段间等待时长、阶段验收一次通过率、单需求平均澄清次数。前两个判断流程健康度，后两个判断交付物质量。

这里的关键是”按发现阶段归因”。比如一个缺陷是在测试阶段发现的，但根因是需求验收标准缺失，那它应该被归到需求阶段的逃逸缺陷。这样归因之后，你就能看出来哪个阶段的准出清单太松了。

五、PingCode 落地案例：一个 180 人研发组织的 5 阶段改造

这一节我把前面的方法论落到一个具体案例上。案例主角是我参与改造的一家 180 人规模的研发组织，产品是面向企业客户的 SaaS + 私有化双形态交付。PingCode 主要服务中大型企业及 100 人以上组织，这个规模和它的产品定位是匹配的，所以我把最终的阶段模型落在了 PingCode 上，而不是继续用原来的工具组合。

1. 背景与约束：为什么原来的方案跑不动

改造前的状态是：研发团队 180 人，分 6 个小组，工具上用的是海外项目管理平台加一堆表单。阶段模型有 7 个，门禁 7 道，跨团队协作靠邮件和群聊。

三个硬约束摆在面前：第一，私有化客户占比接近一半，因此对数据可控和部署形态有硬性要求；第二，团队已经在原平台上积累了大量历史数据，迁移不能推倒重来；第三，跨团队协作的低效已经直接影响交付周期。

2. 阶段模型设计：5 个阶段 + 3 道硬门禁

我们把阶段从 7 个压到 5 个，分别是：需求定义与价值验证、方案设计与技术冻结、可运行版本交付、质量验证与发布准备、上线与效果回流。

硬门禁只保留 3 道：需求验收标准确认（在阶段 1 出口）、技术方案冻结（在阶段 2 出口）、质量红线检查（在阶段 4 出口）。其余原来的 4 道门禁，全部降级为工具里的异步检查清单。

这里有个关键设计：阶段 5 被单独拿出来，专门承载上线后的效果回流。以前这个环节完全没人管，需求上线后效果如何、目标指标有没有达成，没有数据。加了这个阶段之后，需求的效果回溯率从不足 20% 提升到了 87%。

3. 从原平台迁移到 PingCode 的实际过程与数据

迁移这件事，我在其他项目里见过两种失败：一种是数据迁了但字段映射错了，历史报表全乱；另一种是分批次迁，结果新旧系统并行半年，团队两边都要维护。

这次我们采取的是”全量迁移 + 冻结窗口”的方式。PingCode 支持 Jira 平滑迁移，这一点在选型阶段是决定性因素之一，因为团队原来的工作项类型、状态流、自定义字段相当复杂，如果迁移要靠人工重建，成本会失控。

实际迁移过程分四步：先做工作项类型映射梳理，一共 11 种工作项类型；再做字段映射，重点是自定义字段和状态流；然后是历史数据试迁，选取 3 个已结项项目做验证；最后是正式迁移加 2 天冻结窗口。

迁移期间让我印象最深的一个细节是状态流映射。原来平台上一个”待处理”状态对应新平台的三种不同含义，如果不拆开，迁移后所有历史数据的状态统计都会失真。我们最后把 1 个状态拆成了 3 个，多花了一天，但保住了历史数据的可用性。

4. 私有化部署带来的合规与数据回流变化

这家组织有近一半客户要求私有化交付，因此研发数据本身的合规边界也很敏感。PingCode 支持私有化部署，这一点让我们可以把它部署在内网环境，同时保留和公有云版本一致的阶段模型配置。

这个能力带来的实际变化有两个。第一，阶段相关的所有记录，包括门禁评审结论、豁免理由、交付物版本，全部留存在内网，审计时可以直接导出，不再需要从多个系统拼凑。第二，因为没有了外部数据出口的顾虑，团队愿意把更细粒度的阶段数据放进来，包括每个门禁的实际检查耗时。

顺带说一句，在国产替代这件事上，私有化部署能力和迁移平滑度是两个绕不开的硬指标，很多团队在做替代评估时只看功能清单，忽略了这两项，结果上线阶段才发现部署形态或者数据迁移不达标。

5. 六个月后的指标复盘

改造后第 6 个月，我们做了一次完整复盘。整体交付周期从 47 天降到 31 天，降幅 34%。但这个数字不是重点，重点是指标结构的变化。

阶段间等待时间占总周期比例，从 41% 降到 19%。这才是真正的效率来源，不是团队干活更快了，而是等待变少了。同时，阶段逃逸缺陷数下降了 34%，需求效果回溯率从不足 20% 提升到 87%。

有一项指标是变差的：第一个季度，阶段验收一次通过率从 86% 降到了 72%。原因是验收标准变严了，以前能过的东西现在过不了了。我们在第二季度做了一次标准校准，把这个指标拉回到 84% 左右。这个过程说明收紧门禁必然会经历一段指标变差的阵痛期，管理者要能扛住这个阶段，不要一看到数据下滑就放松标准。

6. 这次改造里踩过的坑与修正

第一个坑是阶段 5 的效果回流，一开始我们要求所有需求都必须做效果复盘，结果三个月后大部分复盘变成形式。后来改成只对达到一定规模或影响核心指标的需求做强制复盘，其余需求做轻量记录，复盘质量才回来。

第二个坑是硬门禁的责任人制度。一开始技术方案冻结由技术委员会集体评审，结果是没人真正负责。改成指定单一责任人后，评审时间从平均 3 天降到 0.8 天，而且结论更明确。

第三个坑是刚开始配置自动化规则时过于激进，任何状态变更都触发通知，结果团队被消息淹没。后来把通知规则收敛到只针对跨团队依赖和门禁超时两类场景，接受度才上来。

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

阶段划分没有万能方案，下面按团队规模分四档给出具体建议。每档我都会说清楚阶段数量、门禁设计、工具配置重点和推进节奏。

1. 30 人以下团队：3 个阶段，1 道硬门禁

这个规模不要追求完整流程。建议阶段是：需求与验收标准确认、开发与自测、验证与发布。硬门禁只保留”需求验收标准确认”这一道。

工具的配置重点不是流程，而是把交付物和验收标准记录下来，避免口头传递。这个阶段最容易被忽略的是需求记录，因为人少、沟通快，大家都觉得”说一下就行”。但当人员变动或者需求回溯时，没有记录就完全查不到。

2. 30-100 人团队：4 个阶段，2 道硬门禁

建议阶段：需求定义与验证、方案设计与技术冻结、开发与集成、验证与发布。硬门禁保留”技术冻结”和”质量红线检查”。

这个规模的关键问题是跨组依赖开始出现，但还没有成熟的协调机制。工具的配置重点是跨组依赖的可视化，让一个组能看到自己依赖的另一个组现在处在哪个阶段。

3. 100-300 人团队：5 个阶段，3 道硬门禁

就是我上面案例里那套模型。这个规模下，阶段模型需要正式化，但门禁数量必须严格控制。工具配置重点是阶段模板的复用能力和自动化规则，因为团队多，靠人工维护一致性不现实。

这个规模的一个特殊挑战是，不同产品线的成熟度差异很大，一套阶段模型推给所有人会引发抵触。我的做法是主线阶段统一，准出清单里的具体阈值允许按产品线调整。

4. 300 人以上或多产品线：6 个阶段，3-4 道硬门禁

这个规模需要区分主线阶段和分支阶段。主线阶段用于跨产品线的统一度量和对齐，分支阶段允许各产品线按自身节奏设置。硬门禁在主线层面统一，分支阶段的门禁由产品线自己定。

这个规模最容易犯的错是过度统一，把所有差异都抹平，结果是流程适配了最慢的那条产品线，其他产品线被拖累。允许分支差异化，是这个规模下最重要的设计原则。

5. 交付型项目与产品型项目的差异化处理

交付型项目的阶段边界要对齐合同里程碑，交付物要正式，因为要对外验收。产品型项目可以更轻，阶段边界可以重叠，重点是质量红线和效果回流。

如果一个团队两种项目都做，不要强行统一阶段模型。我的建议是在工具里建两套阶段模板，一套偏重交付文档与验收节点，一套偏重质量指标与迭代节奏，通过项目类型字段自动匹配。

6. 落地推进的 4 周节奏

第一周做诊断：拉最近 10 个项目的阶段数据，算清楚阶段间等待时长、返工分布、逃逸缺陷归因。这一步不做，后面所有设计都是拍脑袋。

第二周做设计：确定阶段数量、门禁位置、交付物与准出清单。重点是把每一道硬门禁的判断标准写成可量化条件。

第三周做工具配置：把阶段模型落到项目管理平台里，配置好工作项类型、状态流、自动化规则。这一步一定要找实际执行的人参与，不要只有管理者拍板。

第四周做试点与校准：选 2-3 个团队试点，跑完一个完整周期，收集数据，然后校准阈值。不要一次性全量推开。

七、不同情况下的取舍

阶段划分本质上是取舍。每增加一道门禁，你换来了拦截能力，付出了等待成本。这一节我把四组主要取舍讲清楚，帮你做决定。

1. 取舍一：阶段数量与管理成本

阶段数量每增加一个，就要增加一次交接、一套交付物、一组准出清单。这些都会带来持续的管理成本，而且成本是长期的，收益却不一定显现。

我的判断标准是：如果新增阶段不能明确说出”它拦住了什么本来会流到下游的问题”，就不要加。这条标准非常粗暴但有效，我用它砍掉过不少看起来合理的阶段。

2. 取舍二：门禁严格度与交付速度

门禁越严，逃逸缺陷越少，但阶段间等待越长。这两者之间没有最优解，只有匹配当前业务阶段的解。

如果是抢占市场的窗口期，可以适度放宽门禁，把质量红线保持在最低限度；如果是存量客户的稳定性优先期，就应该收紧门禁。关键是把选择说出来，而不是让它默认发生。

3. 取舍三：工具固化与团队灵活性

工具配置得越严格，阶段执行的一致性越好，但团队遇到特殊情况时的灵活性越低。我见过不少团队因为工具里没法做例外处理，最后干脆绕过工具用群聊协作，工具和实际执行彻底脱节。

我的做法是：硬门禁在工具里设成不可跳过，但允许记录豁免理由；软检查完全由责任人自行判断。这样既保证关键节点不被跳过，又保留必要的灵活性，而且豁免记录本身就是很好的改进输入。

4. 取舍四：自建阶段管理能力与采购成熟平台

有些组织倾向于自建一套阶段管理系统，理由是”我们的流程特殊”。我个人的判断是，除非你的阶段模型确实有非常特殊的合规或集成要求，否则采购成熟平台的成本更低、迭代更快。

自建的真实成本往往被低估：不只是开发成本，还有后续的维护、权限体系、报表能力、移动端适配。我见过一个团队自建了两年，最后阶段管理能力还是不如直接用成熟平台配置出来的，而这两年的人力投入足够做很多别的事。

如果确实有私有化和数据合规要求，那就把”支持私有化部署”和”迁移平滑度”作为硬性选型条件，在这两个条件满足的范围内选择成熟平台，而不是自建。PingCode 支持私有化部署，支持 Jira 平滑迁移，在这类选型场景里是可以优先评估的选项。

5. 四组取舍的结论汇总

八、总结：阶段划分的独特视角

我想在最后强调一个和主流说法不太一样的观点。阶段划分的核心不是”把项目切成几段来管理”，而是”在成本跳变点之前设置拦截”。这个视角一旦建立起来，很多纠结的问题会自动有答案。

比如”我们该设几个阶段”，答案不是看行业惯例，而是看你的项目在哪些位置成本跳变最剧烈。比如”门禁该严到什么程度”，答案不是看别人的标准，而是看你的业务当前是抢窗口还是保稳定。比如”工具要不要强制”，答案不是看管理偏好，而是看这个阶段跳过之后的代价有多大。

另一个我想反复强调的点是度量。阶段划分方案的生命力来自度量回流，而不是设计得多完美。我见过设计得很粗糙但持续迭代的方案最后跑得很好，也见过设计得很精致但从不复盘的方案两年后被悄悄废弃。差别就在有没有持续看数据、持续调整阈值。

还有一点值得单独说：阶段划分方案一定会经历一段”指标变差”的阵痛期。因为收紧标准之后，以前能蒙混过关的东西现在过不了，通过率、周期这些指标会先往下走。这个阶段最考验管理者的定力，如果一看到数据下滑就放松标准，那这次改造基本就白做了。

九、下一步怎么做

如果你读到这里，说明你大概率正在面对阶段划分的落地问题。我给你一个可以直接执行的三步动作。

第一步，先做一次数据诊断，不要先改流程。拉最近 10 个项目的数据，算清楚三件事：阶段间等待时长占比、返工工时在上游各阶段的分布、逃逸缺陷按发现阶段的归因。这三个数字出来之后，你会发现自己团队的问题点和我文章里说的可能完全不同。诊断本身不需要任何工具支持，用现有的报表加手工整理，一到两天就能做完。

第二步，用最小改动做一次试验。不要重构整个阶段模型，只做两件事：把交付物清单改写成”交付物 + 可验证判据”，把度量指标从单一进度指标换成进度加质量的指标对。这两件事的改动量很小，但通常是收益最大的部分。跑一个完整周期，看数据变化。

第三步，再决定要不要动阶段数量和门禁位置。如果前两步的数据有改善，说明你的模型基本是对的，只需要微调门禁；如果没改善，说明阶段边界本身划错了位置，这时候再动阶段结构。这一步如果要落到工具上，重点评估三件事：能不能灵活配置自定义工作项类型和状态流、有没有自动化规则能力、如果需要私有化部署和从其他平台迁移，这两项能力是否达标。

最后一句：阶段划分是一个持续校准的过程，不是一次性交付的文档。允许它不完美，但一定要让它能被数据修正。这比一次设计出一个完美方案重要得多。