项目阶段如何做好阶段？研发团队实操方法与操作步骤

2023 年底，我给一家 400 人规模的研发组织做项目复盘，拿到一个反常识的数字：他们把项目切成 9 个阶段，每个阶段都有准入准出标准、有评审会、有交付物清单，流程文档厚达 60 多页。但过去 12 个月里，仍有 6 个项目在“测试阶段”才发现核心链路走不通，被迫回炉重做，平均延期 47 天，其中一个项目直接砍掉重来。

问题不在阶段多不多。我把这 9 个阶段的准出标准逐条摊开看，发现没有任何一条是用来回答“这条路到底走不走得通”的。它们全都在回答“活儿干完了没有”。这是绝大多数研发团队在阶段管理上的根本错位：用完成度代替不确定性，用动作代替证据。

这篇文章来自那次复盘的完整输出，加上我后来在 11 个研发团队（30 人到 1200 人不等）身上做的对照观察。它不讲阶段管理的定义，只讲一件事：一个研发团队，到底怎么把“项目阶段”这件事做对。

一、核心结论：阶段不是时间刻度，是风险刻度

先把结论摆出来。我对“项目阶段如何做好阶段”这个问题的答案，浓缩成四条判断。如果你只读一段，读这四段就够了。

1. 每个阶段必须消解一类特定风险，而不是承包一段工期

阶段这个词最容易被误读成“时间切片”，第一个月做需求，第二个月做设计，第三个月写代码。这种切法在瀑布时代能跑通，因为需求相对稳定、技术方案相对确定。但今天的研发项目，最大的成本不是工期，是“我们把三个月投在了一个不成立的假设上”。

所以我判断一个阶段设计得好不好，第一眼看的是：这个阶段的准出标准里，有没有一条是“如果结果不达标，我们就必须改方向”。如果没有，这个阶段本质上是工期，不是阶段。

2. 每个阶段只回答一个决策问题

我见过最典型的问题阶段长这样：准出标准写了 14 条，涵盖需求确认、技术方案评审、接口定义、测试用例覆盖、安全扫描、性能基线、文档归档……问负责人“这个阶段最想验证什么”，答不上来。

一个阶段只能有一个主决策问题。“这个方案在真实流量下能不能扛住”是一个问题；“需求做完了没有”是另一个问题。两个问题混在一个阶段，结果是两个都问不清楚，评审会上谁也说服不了谁，最后靠项目经理拍脑袋放行。

3. 准出标准必须可证伪，不能是动作清单

“完成需求评审”是动作，不可证伪，会开完了就是完成了，哪怕结论是“下次再议”。“压测 P95 延迟 ≤ 800ms，重复 3 轮方差小于 5%”是可证伪的，因为它可能不达标，而且不达标时你知道该做什么。

这条判断标准是我从一次失败的项目里学到的。那个项目的阶段准出清单有 23 项，19 项是“完成 XX 评审/输出 XX 文档”，只有 4 项带数字。结果就是 23 项全绿，项目照样延期两个月。

4. 阶段长度由反馈周期决定，不由日历决定

很多团队按“月度/季度”切阶段，因为这样对报表友好。但阶段的合理长度，取决于你从“做出改变”到“看到真实反馈”需要多久。如果一次完整验证需要 6 周，你把阶段切成 4 周，那这个阶段永远拿不到真证据，只能拿“进度百分比”交差。

下面这张图解释了为什么阶段设计比阶段数量重要得多：越靠后发现问题，修复代价越高，而阶段管理的全部价值就是把发现问题的时点往前拽。

二、真实场景：三类研发团队的阶段现状

在给出方法之前，我想先把现实摊开。过去两年我深度接触的研发团队，在阶段管理上大体分成三类。每一类都有它的合理性和它的天花板。

1. 类型 A：文档驱动型，阶段齐全，执行走样

这类团队通常来自传统行业或有强合规要求的业务，阶段划分完整、模板齐备、评审会一场不落。典型症状是：流程文档比代码更新得快，但没人真的照着它做决策。

我在一家做金融系统的团队看到过极端例子：阶段评审会的 PPT 由项目经理代写，技术负责人第一次看到内容是在会议室里。评审结论清一色“通过，注意 XX 风险”。三年下来，没有一个阶段被判定为“不通过”。

这类团队的阶段，功能已经从“风险闸门”退化成“合规仪式”。它不是没价值，但它的价值是给审计看的，不是给项目用的。

2. 类型 B：敏捷纯化型，只有迭代，没有阶段

另一类团队反着来。他们信奉“计划赶不上变化”，于是彻底放弃阶段概念，只保留双周迭代加一个模糊的“大版本”概念。日常节奏很顺，团队士气也好。

问题出现在两类节点上：一是架构级决策，比如要不要引入新的存储引擎、要不要拆微服务；二是跨团队依赖，比如前端等着后端接口冻结、测试等着环境就绪。这两类事情都有一个共同特征：一旦做错，返工代价是几个迭代的量级，但迭代节奏里没有地方承载它们。

3. 类型 C：双轨混合型，阶段管决策，迭代管交付

第三类是我认为最接近正确答案的：用迭代管日常交付，用阶段管不可逆决策。阶段不再是“一段工期”，而是“一组决策的集合点”。一个阶段可能横跨 5 个迭代，也可能只有 3 天。

这类团队的关键特征是：阶段的粒度跟着风险走，不跟着日历走。一个探索性项目可能第一个阶段只有 2 周，目的就是验证“技术可行性”；一个成熟产品的增量版本，可能整条链路只有 2 个阶段。

三类团队的对照，我整理成下面这张表。

三、六个常见误区，一条条拆开看

在说“怎么做对”之前，先说“怎么在做错”。下面六个误区，是我在不同团队里反复见到的，每一个都带着具体的代价。

1. 误区一：阶段切得越细越可控

这是我见过频率最高的错误。项目经理的直觉是：切成 9 段比切成 4 段更容易监控。但每一段都要有准入、准出、评审、交付物，管理开销是指数级增长的。

更麻烦的是，阶段切得太细，每一段都拿不到足够的真实反馈。一个 3 周的设计阶段，可能连一次完整的接口联调都跑不完，最后只能拿“设计文档完成度 90%”交差。

2. 误区二：准出标准越多越严谨

我做过一个小统计：在 11 个团队里，准出标准条目数与“团队实际逐条核验的比例”呈明显负相关。当条目数在 5 条以内时，逐条核验率约 82%；到 15 条以上时，逐条核验率掉到 30% 以下。

原因很朴素：人的注意力是有限资源。当准出清单长到没人能记住，团队就会退化成“看着差不多就过”。这时候清单越长，越像是在给放行提供免责凭证。

3. 误区三：阶段评审开成进度汇报会

典型议程是：项目经理讲进度 20 分钟，各模块负责人轮流讲“已完成/进行中/风险”，技术负责人总结，领导讲话。两小时过去，没有任何一个决策被做出。

我后来要求团队把议程倒过来：先讲证据，再讲分歧，最后才讲进度。证据是“我们拿到了什么数据”，分歧是“哪条证据还不能支撑放行”，进度是“如果现在放行，剩下的工作量是多少”。这个顺序一换，会议时长能压掉三分之二，因为进度汇报本来就不需要把所有人叫来。

4. 误区四：一套阶段模板套所有项目

探索型项目（技术预研、新业务验证）和交付型项目（已有产品的合规改造）的风险结构完全不同。前者最大的风险是“假设不成立”，后者最大的风险是“依赖没对齐”。

用同一套阶段模板，结果是要么探索型项目被文档压死，要么交付型项目因为缺少依赖对齐节点而持续空转。阶段模板必须按项目的不确定性类型分档，至少分两档。

5. 误区五：阶段完成 = 交付物签收完成

这是文档驱动型团队的典型病。阶段的定义变成“把所有该交的文档交齐”，于是团队的精力从“把事做对”转向“把材料做齐”。

我见过一个团队，阶段准出要求提交 11 份文档，其中 4 份在项目结束后再没人打开过。真正的判断标准应该是：这个阶段产出的证据，后面哪个阶段的哪个人会真的用它做决策？如果答案是没有，这份交付物就该删掉。

6. 误区六：阶段目标写成“完成 XX 功能”

“完成订单模块开发”不是阶段目标，是任务描述。阶段目标应该是“验证订单模块在峰值 3000 TPS 下的稳定性”，或者“确认新计费模型对现有 12 类客户合同都成立”。

两者的区别在于：前者做完就是做完了，后者做完可能得到“不成立”的答案，而“不成立”恰恰是阶段管理最有价值的产出。因为它让你在花掉 300 人天之前知道了这件事。

四、专业判断逻辑：一个好阶段的四个构成要素

拆完误区，说判断逻辑。我评估任何一个阶段是否合格，只看四个要素。这四个要素缺一个，这个阶段就会退化成工期。

1. 要素一：这个阶段消解的是哪一类风险

研发项目的风险大体可以归成五类：需求风险（做的东西没人要）、技术风险（做不出来）、依赖风险（别人不给力）、质量风险（做出来不能稳定运行）、合规风险（做出来不能上线）。

每个阶段必须明确指向其中一类。如果一个阶段同时指向三类风险，它大概率哪一类都消解不了。我习惯让团队在阶段卡片上只写一个风险标签，写不下就说明该拆或者该合并。

2. 要素二：这个阶段要回答的那一个决策问题

决策问题必须是一句能用“是/否/条件成立”回答的句子，不能是“评估一下”“研究研究”。好的决策问题长这样：

• “在现有网关架构下，核心下单链路能否在 P95 ≤ 800ms 完成一次全流程？”
• “新计费模型能否无歧义覆盖现有全部 12 类客户合同？”
• “第三方支付通道在 3000 TPS 下的失败率是否低于 0.1%？”

判断标准很简单：把这个问题的答案写下来，如果答案是“否”，团队知道下一步该改什么。如果答“否”之后大家面面相觑，说明问题问得不对。

3. 要素三：可证伪的证据形式

证据大致可以分四级，可信度从低到高：

1. 观点级：某人认为可行。可信度最低，但在早期探索时有时是唯一选择。
2. 文档级：设计方案、评审纪要。能对齐认知，不能证明可行性。
3. 实验级：原型、压测报告、小流量灰度。能证明“在特定条件下成立”。
4. 生产级：真实用户真实流量的数据。可信度最高，代价也最大。

阶段设计的艺术在于：根据这个阶段的纠错成本，选择刚好够用的证据级别。纠错成本高的决策（架构选型）必须上到实验级；纠错成本低的决策（页面文案）观点级就够。

4. 要素四：退出成本与 Kill 条件

这是最容易被忽略的要素。一个好阶段必须提前定义：如果证据不达标，我们有哪几个选项，每个选项的代价是什么。

我通常要求团队在阶段开始时写下三种结局：Pass（继续原方案）、Conditional Pass（带条件继续，条件必须在下一个阶段内闭环）、Kill（改方向或降级需求）。其中 Kill 条件必须是具体的数字，不能是“如果情况不乐观”。

下面这张图是我常用的阶段设计检查表，把四个要素落成可打分的诊断项。

五、案例与数据观察：一次真实的阶段改造

讲完逻辑，说一个我实际参与过的改造案例。这家公司做企业级 SaaS，研发团队约 320 人，产品线 4 条。改造前的状态是典型的“类型 A + 类型 B 混合体”：有阶段，但阶段是形式；有迭代，但迭代不承载架构决策。

1. 改造前的基线数据

我先做了 6 周基线测量，得到四组数据：

• 阶段评审平均时长 168 分钟，其中进度汇报占 62%，证据讨论占 11%。
• 阶段准出清单平均 16.4 条，逐条核验率约 28%。
• 缺陷在测试及上线后发现的占比 61%。
• 项目经理每月花在阶段材料整理上的时间约 26 小时。

第三项是最要命的。61% 的缺陷在后端被发现，意味着前面的阶段基本没有起到风险前置的作用。

2. 改造动作

改造核心是三件事：一是把 9 个阶段合并成 5 个，按风险类型而不是按专业分工切；二是准出标准从“动作清单”改成“指标 + 证据链接”，条目数从 16.4 降到平均 6.2；三是把阶段评审议程改成“证据 40 分钟 + 决策 15 分钟 + 进度 5 分钟”。

工具层面，这家公司原本用的是本地部署的老旧研发管理系统，配置能力弱，准出标准只能写死成固定表单，改一次要提工单。他们在评估后迁移到了 PingCode。选择它的原因很具体：PingCode 主要服务中大型企业及 100 人以上组织，320 人的规模正好在它的目标区间内；支持私有化部署，满足这家公司的数据合规要求；同时支持从 Jira 平滑迁移，历史项目数据不用重录。

迁移后最直接的改变是准出标准变成了可配置的工作项校验规则。团队把“压测 P95 ≤ 800ms”这类指标做成带阈值的字段，不达标时工作项无法流转到下一个阶段状态。这一步把“逐条核验率”从 28% 拉到了 91%，因为核验动作从“人去翻清单”变成了“系统卡住流程”。

下面是一段阶段准出标准的结构化配置示例，我们当时就是照着这个模板把 5 个阶段的标准重新写了一遍。

stage: 可行性验证阶段
risk_type: 技术风险

decision_question: "在现有网关架构下，核心下单链路能否在 P95 exit_criteria:

id: EC-01

statement: "压测报告显示 P95 延迟 sample_size: ">= 5000 次请求"

falsifiable: true

evidence_owner: 后端负责人

evidence_ref: "性能测试报告 v2"

id: EC-02

statement: "3 台 8C16G 节点重复压测 3 轮，轮间方差 falsifiable: true

evidence_owner: SRE

evidence_ref: "压测原始数据表"

id: EC-03

statement: "核心链路不存在单点依赖，任一非核心服务不可用时主流程降级成功率 >= 99%"

falsifiable: true

evidence_owner: 架构师

evidence_ref: "故障注入实验记录"

gate_decision:

pass:

condition: "EC-01 / EC-02 / EC-03 全部达标"

conditional_pass:

condition: "EC-01 达标且 EC-02 方差在 5%-8% 之间"

action: "允许进入下一阶段，但方差问题须在下一阶段前两周闭环"

kill:

condition: "EC-01 连续两轮不达标，或 EC-03 降级成功率 action: "触发架构重选评估或需求降级评审"

3. 改造后的数据

改造运行 9 个月后，我拿到了新的数据。这里要说清楚：这是单一样本的前后对比，没有对照组，所以不能当成普遍结论，只能作为“这条路可能走得通”的参考。

最后一项指标我想多说一句。改造前，“不通过”比例是 1%，团队觉得这是“执行到位”的证明。改造后变成 21%，一开始管理层很紧张，以为项目质量在下滑。我解释了很久：一个从来没有拦下过任何东西的闸门，不是好闸门，是装饰。21% 意味着这套标准真的在某些节点上拦住了不该往下走的东西。

4. 一个反例：另一家团队为什么失败了

同期还有一家 180 人的团队尝试了类似改造，半年后回退到原状。复盘原因有三条：一是他们把阶段从 7 个减到 4 个，但准出标准一条没减，导致每个阶段要验证的东西反而更多；二是没有工具支撑，准出核验仍然靠人工，两个月后执行率掉回 30%；三是管理层在第一次出现 Kill 判定时介入，要求“再给一次机会”，闸门信誉一次性归零。

第三条最关键。阶段闸门的有效性依赖“判定被尊重”这一前提。如果 Kill 结论可以被上级一句话推翻，那这个闸门在下一次评审时就没有人认真对待了。

六、研发团队阶段管理的操作步骤

前面是判断，这里是动作。下面这套 8 步流程，是我在多个团队里跑过、迭代过的版本，可以直接拿去做。

1. 第一步：列出项目的不确定性清单，按代价排序

不要先想阶段怎么切，先想“这个项目最可能在哪几件事上翻车”。把每一条写成一句话，然后给两个维度打分：发生概率（1-5）和一旦发生的返工代价（以人天估算）。

排序后的清单，就是阶段划分的原料。代价最高的三条，必须各自拥有一个阶段。

2. 第二步：用风险聚类切阶段，而不是用专业分工

“需求阶段 / 设计阶段 / 开发阶段 / 测试阶段”是按专业分工切的，这是最差的切法，因为它默认每类风险均匀分布。正确的切法是按风险聚类：把同类风险归到一个阶段，用一个决策问题覆盖。

比如一个典型的 5 阶段结构可能是：

3. 第三步：为每个阶段写一句决策问题

写完之后做一次自检：把这个问题拿给一个不在项目里的人看，他能不能在 30 秒内说出“如果答案是 A 就继续，答案是 B 就停”。如果他说不出来，重写。

4. 第四步：把准出标准压到 5-8 条，且至少一半带数字

我给团队的经验值是：单个阶段的准出标准控制在 5 到 8 条，其中带可量化阈值的不少于一半。超过 8 条的，逐条删；删不掉的就拆到下一个阶段去。

每条标准都要填三个字段：判定条件、证据形式、证据负责人。没有证据负责人的标准，基本等于没有标准。

5. 第五步：给阶段长度设上限，但不设下限

上限的意义是防止“探索无限延长”。我通常建议单阶段不超过 6 周，超过就说明风险没有拆开，需要再聚一次类。下限不设，因为一个只用了 3 天的阶段，如果它成功消解了一个高代价风险，它就是一个好阶段。

6. 第六步：把阶段评审议程倒过来

固定议程模板如下，团队可以直接抄：

1. 证据核对（占 40% 时间）：逐条过准出标准，只看证据，不看解释。达标就是达标，不达标就是不达标。
2. 分歧澄清（占 35% 时间）：只讨论有争议的条目。争议点必须落到“还缺什么证据”上，而不是“我觉得行不行”。
3. 决策（占 15% 时间）：在 Pass / Conditional Pass / Kill 中三选一，当场记录，当天同步。
4. 进度同步（占 10% 时间）：只讲放行后剩余工作量和关键路径。这部分如果不涉及放行决策，可以异步发邮件。

7. 第七步：把准出标准配置进工具，让它自动卡流程

这是执行率能不能维持的关键。人工核验的标准，三个月后一定会退化。把阈值做成字段、把证据做成必填附件、把不达标做成流转阻断，是唯一能长期维持的办法。

具体到操作层面，需要工具具备三个能力：一是工作项状态流转可配置校验规则；二是自定义字段支持数值比较；三是阶段视图能一屏看到所有条目的达标状态。中大型组织的私有化部署场景下，这类配置能力往往是选型时最容易被忽略、上线后最容易被抱怨的部分。

8. 第八步：每个阶段结束后做 30 分钟复盘，更新模板

复盘的唯一议题是：这个阶段哪一条准出标准事后证明是没用的，哪一条是漏掉的。有用的保留，没用的删掉，漏掉的补上。阶段模板应该是活的，每季度迭代一次，而不是写进制度就三年不动。

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

同一套方法，在不同团队规模、不同项目类型下，动作顺序是不一样的。下面按常见的四种情形给建议。

1. 情形一：30-80 人团队，项目节奏快，没有专职 PMO

（1）不要引入完整阶段体系，先做“关键决策点”

这个规模下，流程开销是最稀缺的资源。我的建议是只保留 2 到 3 个关键决策点，通常是“开工前”“大规模投入前”“上线前”。每个决策点只问一个问题，只保留 3 条准出标准。

（2）用轻量工具，不要上重型平台

这个阶段团队的核心矛盾是“跑得快”，不是“管得细”。工具选择以配置成本低、上手快为准。等规模过百、跨团队依赖变复杂再考虑平台化。

2. 情形二：100-500 人团队，多产品线并行，跨团队依赖重

（1）建立统一的风险分类和阶段模板库

这个规模下，最大的问题是“每条产品线各自为政”，导致跨线协作时无法对齐。建议先统一五类风险的定义和对应的阶段类型，再允许各产品线裁剪。

（2）优先解决“依赖对齐”这一类风险

我观察到的规律是：100 人以上的团队，延期主因从“做不出来”变成了“等不到”。所以 P3 依赖对齐阶段应该被单独拎出来，配明确的接口冻结时间和责任人。这个规模的团队通常需要平台化工具支撑，PingCode 这类面向中大型组织的平台在私有化部署和跨项目管理上的配置能力会更匹配，同时也保留了从 Jira 平滑迁移的路径，降低替换成本。

（3）把阶段准出做成自动化校验

这个规模下人工核验一定会失效，因为参与的人太多、口径太杂。必须把关键阈值写进工具流转规则。

3. 情形三：探索型 / 预研型项目

（1）阶段要短，Kill 条件要狠

探索型项目最大的浪费是“明知不成立还继续投入”。建议阶段长度控制在 2 到 4 周，Kill 条件提前写死，到点就判，不延期。

（2）证据级别可以放宽，但必须明确标注

预研阶段很多时候只能拿到观点级或实验级证据。这不丢人，但必须在评审记录里明确标注“本阶段证据级别为实验级，样本量 200，不构成生产结论”，防止后面的人误用。

4. 情形四：合规 / 强监管行业项目

（1）阶段数量和交付物不能随意精简

这类项目的阶段有外部约束，能优化的是“准出标准的质量”，不是“数量”。把动作型标准改造成证据型标准的空间仍然很大。

（2）把审计要求和项目决策需求分开对待

我建议做两套清单：一套给审计，一套给项目决策。两者可以共用数据源，但用途不同。混在一起的结果通常是项目决策被审计要求绑架，评审会变成材料核对会。

八、不同情况下的取舍

方法论的难点从来不是“知道该怎么做”，而是“知道在该放弃什么”。下面是我最常被问到的五组取舍，说说我的判断逻辑。

1. 取舍一：阶段数量多 vs 少

多阶段的收益是风险早发现，代价是管理开销和证据不足即放行。我的临界判断是：如果一个阶段无法在 6 周内拿到足以支撑决策的真实证据，它就不该独立存在。应该和相邻阶段合并。

2. 取舍二：严格闸门 vs 灵活放行

严格执行闸门的收益是风险可控，代价是可能错过窗口期。灵活放行的收益是速度，代价是技术债累积。我的建议是按决策的不可逆程度分档：不可逆决策（架构选型、数据模型、对外接口协议）严格；可逆决策（UI 交互、内部实现）灵活。

3. 取舍三：证据级别高 vs 低

生产级证据最可信，但获取成本最高，而且有些决策在早期根本拿不到生产级证据。判断方法是算一笔账：获取更高一级证据的成本，是否小于错误决策的期望损失。如果是，就该上；如果不是，就用现有级别证据加明确的假设标注放行。

4. 取舍四：自建工具 vs 采购平台

自建的收益是贴合度高，代价是长期维护成本被严重低估。我见过三个团队自研阶段管理模块，第一个版本都很顺，两年后全部面临“没人维护、配置改不动、迁移困难”的困境。

我的判断线是：如果阶段管理不是你的核心竞争力，就不要自建。选采购平台时重点看三件事：状态流转规则是否可配置、自定义字段是否支持数值阈值、是否支持私有化部署。中大型组织还应该额外确认历史数据迁移的平滑度，从旧系统迁移往往比新系统上线本身更耗人。

5. 取舍五：阶段管理的投入深度 vs 团队自主性

管得太细会压制团队自主性，管得太松会失去风险控制。我的经验值是：阶段管理只约束“决策”和“证据”两件事，不约束“怎么做”。

换句话说，团队可以自己决定用什么技术方案、怎么分工、怎么排期，但必须在阶段闸门上提交规定的证据、接受规定的判定。这条边界一旦划清，团队的抵触情绪会下降很多，因为他们感到被管的是结果，不是过程。

九、总结：阶段管理的独特价值在于“允许说不”

写到这里，我想把整篇文章压缩成一句判断：一个研发组织的阶段管理水平，不体现在它的流程文档有多少页，而体现在它的闸门一年里拦下过几次。

如果过去 12 个月，你们所有阶段评审的结论都是“通过”，那不管流程多完备，这套阶段管理都是失效的。反之，如果偶尔有阶段被判定为需要改方向、降需求甚至终止，哪怕流程很轻，它也是活的。

回到最初那个 400 人团队的案例。他们最后收缩到 5 个阶段，准出标准平均 6.2 条，其中 3 条以上带数字。9 个月后，缺陷前置发现率提升，评审时间缩短，但最有价值的改变是：团队终于有了一个制度化的场合去说“这条路可能走不通”，而且说这句话不会被当成不配合。

这是我理解的阶段管理最独特的地方，它不是用来管进度的，进度有更轻的工具；它是用来给“停下来”这件事提供合法性的。项目越复杂、投入越大，这个合法性越值钱。

1. 如果你现在就要动手，按这个顺序做

1. 本周：把当前项目的所有阶段拿出来，逐个问“这个阶段消解哪一类风险”，说不出来的标记出来。
2. 下周：把标记出来的阶段两两合并，目标收缩到 6 个以内。
3. 两周内：为每个阶段写一句决策问题，找不参与项目的人做 30 秒自检。
4. 三周内：重写准出标准，压到 8 条以内，带数字的不少于一半，每条指定证据负责人。
5. 一个月内：改掉评审议程顺序，先证据后分歧再决策，进度最后。
6. 一个季度内：把可量化的准出标准配置进工具流转规则，让不达标无法流转。

2. 三个可以直接拿去用的自检问题

• 过去 12 个月，我们有几个阶段被判定为“不通过”或“有条件通过”？如果是 0，问题在哪？
• 我们的准出标准里，有几条是“如果结果不达标，我们就必须改方向”的？
• 如果一个阶段被判定为 Kill，这个判定会被尊重吗，还是会被上级一句话推翻？

这三个问题的答案，比任何流程文档都更能说明一个研发团队的阶段管理到底做得好不好。