项目类型最佳实践：研发团队项目立项最佳实践，常见问题

2023 年下半年，我参与复盘了一家 400 人规模研发组织的 23 个严重延期项目。复盘之前，管理层普遍认为是”执行不力”或者”需求变更太多”。但当我们把每个项目的立项文档、评审记录、里程碑基线全部摊开对齐之后，结论完全反过来了：23 个项目里有 17 个，延期的种子在立项评审通过的那一刻就已经埋下了。

有的是验收标准写得像口号，比如”系统性能显著提升”，到了验收阶段没人能判断到底算不算完成；有的是技术方案只停留在 PPT 上，立项时没人验证过那个核心链路能不能跑通；还有 4 个项目，立项文档里连”谁最终拍板”都没写，于是每个变更都要开一次跨部门会。

这件事让我形成了一个比较固执的判断：研发团队的立项质量，和后面半年的项目健康度，相关性远比大多数人想象的高。而立项做得差，往往不是因为团队不认真，是因为所有人都在用同一套模板，去处理完全不同类型的项目。这篇文章就把我对研发项目立项的完整方法论、踩过的坑和可落地的做法写清楚。

一、核心结论：立项不是审批动作，而是给不确定性定价

1. 立项的本质是”风险定价”，不是”资源申请”

大部分团队把立项理解成一道行政关卡：业务方写个申请，技术负责人签个字，PMO 排个期，立项就结束了。这种理解下，立项文档的核心内容自然变成”我要多少人、多少时间、做哪些功能”，也就是一份资源申请书。

但研发项目真正的风险从来不是”资源要不到”，而是“我们以为自己知道要做什么，其实并不知道”。立项环节唯一不可替代的价值，就是在这个信息最便宜的时刻，把不确定性识别出来、标注出来、并且给它定一个价格。价格可以是”先花两周做技术预研”，也可以是”限定 3 个月，做不出来就停”。

所以我一直跟团队说：立项文档写完，如果没有人因为某个风险而改变计划（比如砍范围、加预研、调里程碑），那这份立项文档就是白写的。

2. 立项模板必须跟着项目类型走，而不是跟着部门走

我见过太多公司按部门定制立项模板：前端团队一套、后端团队一套、数据团队一套。这是完全错误的分法。真正决定立项深度的，是项目的类型，它的不确定性有多高、做错了能不能退回来、外部干系人有多少、合规要求有多强。

一个给银行做的定制交付项目，和一个内部效率工具的预研项目，用同一份立项模板，必然导致前者立项太轻（验收标准没锁死，后期扯皮），后者立项太重（花了三周写文档，结果方向被证伪了）。

3. 立项通过率 100%，通常是流程失效的第一个信号

有次我接手一个研发组织的流程诊断，看到上一季度立项评审通过率是 100%，连续 4 个季度都是 100%。管理层的解读是”我们的立项质量高”。

我的解读完全相反：一个从未否决过任何项目的立项流程，本质上只是一个盖章流程。因为立项评审的真正产出不只是”通过”，还包括”有条件通过”（比如限定范围、限定时间、追加预研）和”暂缓”。如果这三个结果从来没有出现过第二种和第三种，说明评审会上没有人真的在质疑。

正常情况下，我建议的健康区间是：无条件通过 50%-60%，有条件通过 30%-40%，暂缓或否决 5%-15%。当然这个比例要按行业和业务阶段调整，但 100% 一定是不健康的。

4. 一份能用的立项文档，最少要回答 6 个问题

我不主张立项文档写得多厚，但我主张这 6 个问题必须全部有明确答案。缺任何一个，后期都会以某种形式还回来。

第 3 条和第 6 条是最容易被忽略的，也是我复盘时发现收益最高的两条。“不做什么”决定了范围会不会失控，”什么时候停”决定了一次失败会不会变成持续的沉没成本。

二、背景与真实场景：研发项目的四种类型，立项难点完全不同

1. 交付型项目：最怕验收标准含糊

交付型项目是我们最熟悉的一类：有明确客户或明确业务方，有合同或内部结算关系，有交付时间点。这类项目的不确定性其实不高，需求边界相对清晰，技术路线大致成熟。真正的风险集中在末端验收。

我见过一个典型场景：一个为内部业务部门做的订单系统改造项目，立项文档写的是”实现订单全流程线上化”。开发做了 4 个月，交付时业务方说”我说的线上化是指连审批环节也在线上”，而审批模块压根不在立项范围里。最后追加了 2 个月工作量，项目从”按期交付”变成”严重延期”。

这类项目的立项关键动作只有一个：把验收标准写成可测量、可复现、双方签字确认的形式。宁可立项时多花两天和业务方逐条对齐，也不要把争议留到验收会上。

2. 平台/基建型项目：最怕没有第一个真实消费方

平台型项目，比如统一认证、消息中心、数据中台、CI/CD 平台，的立项难点完全不同。它们的不确定性来自”价值难验证”：平台建好了，业务方不用，你也说不清到底哪里做错了。

我在 2022 年见过一个典型的失败案例：某团队立项做一个统一配置中心，立项文档写得非常漂亮，架构图、容量规划、灰度方案一应俱全。结果上线 8 个月，只有 2 个内部系统接入，而且都是项目组自己推动的。真正的原因在立项阶段就存在：没有任何一个业务团队在立项时承诺”我会成为第一个接入方”。

所以平台型项目立项，我会强制要求写清三件事：第一个真实消费方是谁、他们承诺在什么时间点接入、接入后的衡量指标是什么。如果这三件事写不出来，这个项目就应该降级为预研，而不是直接立项开发。

3. 探索/预研型项目：最怕没有时间盒和止损点

探索型项目的立项逻辑和前两类几乎相反。它的不确定性极高，但你恰恰没法在立项阶段把不确定性降下来，唯一合理的做法是限定投入上限，用小成本换取信息。

我见过最离谱的一次，是一个 AI 能力预研项目立项时写了 6 个月排期和 12 人配置，还附了一份详细到功能点级别的 WBS。这就完全搞反了：连技术路线都没验证，你怎么可能排得出功能点级别的工作量？

这类项目的立项文档应该只有一页：要验证的假设是什么、验证方法是什么、多长时间出结论、结论有三种（成立/不成立/部分成立）分别对应什么后续动作。其他内容都是过度设计。

4. 合规/改造型项目：最怕证据链不完整

还有一类经常被忽视的项目：因为外部合规要求、监管要求或内部审计要求而必须做的改造项目。比如等保改造、信创适配、数据出境合规改造。

这类项目的立项难点不在技术，在证据链。因为它的成功标准不是”功能上线”，而是”能通过审计”。立项时如果没有把需要留存的证据、需要做的验证记录、需要签字的确认单据一一列出来，很容易出现”活干完了但审计过不了”的尴尬。

我一般建议这类项目在立项文档里直接附一张”证据清单”，把每个合规条款和对应的证据产出物一一对应，作为项目验收的一部分。

三、七个常见误区：我见过的立项翻车现场

下面这七个误区，是我在超过 80 个研发项目立项评审和复盘里反复见到的。它们不是”水平不够”造成的，而是流程设计和组织习惯造成的，所以改起来反而更难。

1. 误区一：全公司一套立项模板打天下

这是最高频的问题。一套模板通常是为了”统一管理”而设计的，结果就是简单项目被过度文档化，复杂项目被简化到关键风险无处安放。

我见过最极端的例子：一家 600 人的公司，立项模板有 19 个必填字段，其中 11 个字段对所有项目都填”不适用”。同时，模板里居然没有”验收标准”这一项。

2. 误区二：把工作量估算当成立项的核心

很多立项评审会，80% 的时间花在争论”到底是 60 人天还是 80 人天”。但工作量估算在立项阶段本来就不可能准，尤其是需求还没细化的时候。

立项阶段真正需要确定的是量级和上限，不是精确数字。我通常建议给出一个区间（比如 3-5 人月）和一个上限触发条件（超过上限要重新评审），而不是纠结于一个点的估计值。

3. 误区三：只写”要做什么”，不写”不做什么”

这一条我在上一节已经提到过，但在误区清单里必须单独列出来，因为它造成的损失最大。立项文档里的”不做什么”清单，是后续所有范围变更讨论的锚点。

我做过一个小样本统计：在 47 份立项文档中，写了明确”不做清单”的有 18 份。这 18 个项目在后续执行中，平均范围变更次数是 2.7 次；另外 29 份没写的，平均是 6.1 次。

4. 误区四：没有退出条件，项目一旦立项就”只能成功”

这是组织心理层面的问题。一旦项目立项、资源投入、对外承诺，团队就很难主动承认”这条路走不通”。没有预设的退出条件，失败只会以”无限期拖延”的形式出现。

我的经验是：把退出条件写进立项文档，反而让项目更容易被批准。因为决策者最怕的不是项目失败，而是项目烂尾，一个明确说了”3 个月不达标就停”的项目，风险是封顶的。

5. 误区五：干系人写”全体成员”或”老板”

“干系人：项目组全体成员、业务部门、公司领导”，这种写法等于没写。立项文档里的干系人部分，唯一有价值的信息是：谁对哪一类决策有最终拍板权。

我通常要求用一张简单的表说清楚：范围变更谁拍板、技术方案谁拍板、上线时间谁拍板、预算追加谁拍板。这四类决策人必须是具体的名字，不能是部门。

6. 误区六：立项一次性，中途不做基线变更

很多团队把立项当成”一次性事件”。但实际上，一个 6 个月的项目，中途发生重大变更几乎是必然的。问题不在于变更，而在于变更之后没有重新建立基线，导致所有人还在拿旧的里程碑做参照。

比较健康的做法是：立项建立初始基线，重大变更（范围、时间、预算任一超出阈值）触发一次”轻量重立项”，只更新受影响的部分，不做全量重写。

7. 误区七：立项资料散落在邮件、IM 和本地文档

这条看起来是工具问题，实际上是流程问题。当立项文档散落在 5 个地方时，它就不再是一份”共同参照物”，而只是某个人电脑里的一份存档。后续任何人想查”当初这个范围到底是怎么定的”，都要靠人肉搜索。

我坚持的一个基本原则是：立项文档应该和项目工作项在同一个地方，并且能被查询、被引用、被关联到具体需求上。这一点在下面讲工具落地时会展开。

四、专业判断逻辑：用两个维度决定立项的”重量”

1. 维度一：不确定性，你真的知道要做什么吗

不确定性主要来自三个方面：需求是否清晰、技术路线是否验证过、外部依赖是否可控。我给每个方面打 0-10 分，加总后映射到低、中、高三档。

• 低不确定性：需求有明确参照物，技术是团队已经做过的，外部依赖在自己控制范围内。
• 中不确定性：需求方向清楚但细节待定，或者技术需要一个验证期，或者依赖外部团队配合。
• 高不确定性：需求本身还在探索，或者技术路线存在多个未验证选项，或者依赖不可控的第三方。

2. 维度二：可逆性，做错了能不能退回来

可逆性比不确定性更容易被忽略，但它对决策的影响可能更大。一个高不确定性但高可逆性的项目（比如做一个内部工具的原型），失败了无非是浪费几周；而一个低不确定性但低可逆性的项目（比如一次数据库架构迁移），做错了可能是灾难性的。

判断可逆性我通常问三个问题：已经投入的资源能否回收、对外承诺能否撤回、数据或架构变更能否回滚。三个答案都是”能”，就是高可逆；有一个”不能”，就要按低可逆处理。

3. 四档立项分级与对应产出物

把不确定性和可逆性交叉，就得到四档立项深度。这是我推荐给团队的实际操作框架。

这套分档最大的价值不是”分出四个等级”，而是让团队有理由拒绝不合理的流程要求。当一个 A 档项目被要求写 20 页立项文档时，团队可以直接说：这是 A 档，一页纸就够。反过来，一个 C 档项目想跳过技术方案评审，也同样有据可依。

4. 立项评审必须问清的 9 个问题

不管哪一档，只要开评审会，我都会准备这 9 个问题。它们的作用不是”走流程”，而是在 30 分钟内把真正的风险逼出来。

1. 这个项目如果失败了，最可能的原因是什么？
2. 这个原因有没有办法在立项后两周内验证？
3. 验收标准能不能被一个第三方独立判定？
4. 这个项目明确不做什么？
5. 谁对范围变更有最终拍板权？
6. 如果范围扩大 30%，预算是够的还是需要重新评审？
7. 关键依赖方有没有书面确认交付时间？
8. 什么条件下我们会停止这个项目？
9. 项目结束后，哪三份文档是必须留下的？

我在实践中发现，第 1 个问题和第 8 个问题最容易让会议冷场，因为它们要求有人明确说出”我们可能会失败”和”我们可能会停”。而正是这种冷场，往往比任何风险评估表都更真实。

五、案例与数据观察：47 份立项文档告诉我的事

1. 写清”不做什么”的项目，范围蔓延率低了一半

前面提到的那组数据值得再展开一下。我把 47 份立项文档分成两组：写了明确”不做清单”的 18 份，和没写的 29 份。除了范围变更次数（2.7 次 vs 6.1 次），另外两个指标差异也很明显。

• 平均延期率：有不做清单的组 14.3%，无不做清单的组 31.0%。
• 验收争议次数：有不做清单的组平均 0.8 次，无不做清单的组平均 2.4 次。

需要说明的是，这两组项目的规模和复杂度并不完全一致，所以不能把差异全部归因于”不做清单”这一项。但差异幅度足够大，足以支持一个操作层面的结论：写一份不做清单的成本大约是 30 分钟，可能的收益是以周计的返工时间。

2. 有退出条件的项目，反而更容易被批准

这一条和直觉相反，但我在两个不同组织里都观察到了同样的现象。2019 年我推动团队在立项文档里加入”退出条件”字段时，第一反应是担心”写了退出条件，评审会更容易被否”。实际结果是：带退出条件的立项申请，平均决策周期缩短了约 40%，且被要求补充材料的次数明显减少。

原因其实很直白：决策者最担心的不是失败，而是没有边界的失败。一份明确写了”3 个月不达标就停、已投入不超过 X”的申请，把一个开放式风险变成了一个封闭式风险，决策反而变简单了。

3. 用 PingCode 把立项流程真正落地的做法

上面讲的方法论，如果只停留在文档层面，很难长期坚持。因为人在压力下一定会走捷径，评审会开成过场，文档写完就没人再看。我的经验是：流程必须落到工作系统里，才有约束力。

PingCode 是我在中大型研发团队里用得比较多的一套研发项目管理平台，它主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，在国产替代场景里是比较稳妥的选择。下面说说我们具体是怎么用它承载立项流程的。

（1）用工作项类型区分四档立项，而不是用一个”项目”概念装所有东西

很多工具里所有项目都是同一种对象，导致 A 档轻立项和 C 档重立项在系统里长得一模一样。我们在 PingCode 里为不同分档配置了不同的工作项类型和字段集：A 档只保留目标、验收标准、不做清单三个字段；C 档则强制要求填写风险项、退出条件、决策人矩阵。

这样做的直接好处是，填表这件事本身就变成了风险识别动作。一个 C 档项目如果”退出条件”字段空着，系统直接不允许提交评审。

（2）用里程碑 + 基线，把”什么时候该重新评审”变成可见信号

立项之后最容易失控的地方是”变更了但没人重新评审”。我们在 PingCode 里把初始里程碑设为基线，当实际排期偏离基线超过预设阈值（我们用的是 15%）时，自动触发一个”重立项评审”工作项，指派给对应的决策人。

这个机制上线后，我们统计过一组对比：上线前，重大变更后完成重新评审的比例约为 22%；上线后提升到 79%。关键变化不是团队变自觉了，而是系统把这件事从”需要有人记得”变成了”自动派单”。

（3）用需求与立项文档的双向关联，解决”当初怎么定的”问题

我把立项文档作为工作项附件挂在项目根节点上，同时要求所有需求必须关联到立项文档中的范围条目。这样后续任何人看一个需求，都能直接追溯到它来自立项范围的哪一条。

这个做法最大的收益出现在争议场景里：当业务方说”这个功能当初就说好了”，我们可以直接在系统里查这条需求有没有关联到立项范围。把”记不记得”变成”查得到”，争议处理时间平均缩短了一半以上。

立项卡最小字段模板（YAML 形式，便于在工具中配置）
project:

code: PRJ-2024-0731

tier: C # A/B/C/D 四档

owner: 张工 # 唯一责任人

decision_maker: 李总 # 范围变更唯一拍板人

goal:

problem: 客服团队日均 200 次重复咨询

metric: 重复咨询次数降至 50 次/日以内

deadline: 2024-11-30

scope:

in:

知识库检索

智能推荐话术

out: # 必填，不得为空

多语言支持

移动端 App

risk:

top_risk: 检索准确率不达标

verify_by: 立项后 2 周内完成 500 条真实会话压测

threshold: 准确率 >= 82%

exit:

condition: 第 8 周准确率仍低于 75%

action: 终止开发，转为规则引擎方案

evidence:

需求确认单（业务方签字）

压测报告

上线验收记录

4. 从 Jira 平滑迁移时，立项数据的修复顺序

近两年我参与过几次从 Jira 迁移到国产研发管理平台的实施，一个共同的教训是：大部分团队迁移时把注意力放在”任务和缺陷能不能搬过去”，却忽略了立项层面的数据结构。结果迁完之后，历史项目在系统里成了一堆没有层级、没有关联的散点。

如果你正在做类似的迁移，我建议按这个顺序处理，避免返工：

1. 先梳理项目层级：把原来的”史诗-故事-子任务”映射到新平台的”项目-需求-任务”，确认每个历史项目都有一个明确的根节点。
2. 再补立项属性：为历史项目补上分档、责任人、决策人、验收标准这些关键字段。允许历史数据不完整，但至少要标注”未填写”而不是留空。
3. 然后迁移关联关系：附件、评论、关联链接往往比字段更重要，尤其是立项文档和需求之间的关联。
4. 最后做一次抽样校验：随机抽 10 个项目，人工核对迁移前后的完整性，再决定是否需要二次迁移。

整个过程中，选择支持平滑迁移方案的平台会省掉大量手工工作。PingCode 在这方面提供了比较完整的迁移路径和私有化部署选项，对数据敏感的中大型组织来说，这一步的前期评估成本远低于迁完再返工的成本。

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

1. 20 人以下团队：立项就跑一页纸

小团队最大的资本就是决策快，千万不要为了”规范”引入重流程。我建议的做法是：所有项目统一用一页纸立项，内容包括目标、验收标准、不做清单、责任人四项。

评审也不用开会，由技术负责人和业务方在半天内异步确认即可。如果项目超过 3 个月，在第 6 周强制做一次复盘，判断是否继续。这个阶段最该保护的是速度，而不是文档完整性。

2. 20-100 人团队：分档立项 + 强制退出条件

这个规模的团队开始出现”项目之间抢资源”的问题，所以立项必须承担资源分配的职责。我的建议是引入 A/B/C 三档（暂不需要 D 档预研前置），并且无条件要求所有 B 档及以上项目填写退出条件。

评审形式上，A 档不需要评审，B 档由一个固定的小组（技术负责人 + 业务负责人 + 一名资深工程师）评审，C 档才需要跨部门。同时建议开始做立项文档的集中存放，哪怕只是统一在一个平台里建一个”立项”项目。

3. 100-500 人团队：模板分类 + 里程碑基线

这个规模是立项流程最容易失效的区间。人多了，靠口头同步已经不可能；但专门设一个 PMO 又容易被业务方视为”官僚机构”。

我的建议是两条腿走路：一是按项目类型（交付/平台/探索/合规）建立四套差异化模板，而不是一套通用模板加备注；二是把里程碑基线固化到工作系统里，让偏离自动触发重评审，而不是靠 PMO 人工盯。

这个阶段还有一个容易被忽略的动作：建立立项数据的季度回顾。每季度抽 10-15 个项目，对比立项时的假设和实际结果，把偏差原因归类。这比任何流程培训都更能提升团队的立项判断力，因为这些结论来自他们自己的项目。

4. 500 人以上或多产品线：立项组合管理

到了这个规模，单个项目的立项质量已经不是主要矛盾了，项目组合的结构才是。常见的问题是：所有资源都被交付型项目占满，平台型和探索型项目永远排不进去，三年后技术债集中爆发。

我的建议是把立项评审上升为组合评审：每季度看一次所有立项申请的类型分布和资源占用比例，并设定一个明确的配比目标。比如交付型不超过 60%、平台型不低于 20%、探索型不低于 10%、合规型按实际需求。

这个配比不是拍脑袋定的，需要根据业务阶段调整。但关键是必须有一个明确的数字，否则平台和探索类项目在资源竞争中永远排在最后。同时建议把立项申请统一到一个平台里管理，保证组合视图是实时且准确的，而不是靠每季度人工汇总 Excel。

七、取舍：立项永远是在成本和风险之间做交换

1. 流程严谨 vs 立项速度

这两者不可能同时最大化。我的判断标准是看错误的代价有多高：如果做错了最多损失两周，那就选速度；如果做错了要返工三个月或者影响外部承诺，那就选严谨。

实操上，我建议给团队一个明确的默认值，而不是每个项目单独讨论。比如”所有项目默认按 B 档处理，只有满足特定条件才升到 C 档或降到 A 档”。有默认值，决策就快。

2. 文档完整 vs 团队负担

我见过团队为了追求”文档规范”，要求所有项目都写 15 页立项文档。结果就是文档变成复制粘贴，写的和做的完全两回事。

我的取舍原则是：宁可字段少，也要每个字段都有人真的看。与其有 20 个必填字段但没人读，不如只有 6 个字段但每个字段都在评审会上被追问。判断标准很简单：如果删掉一个字段，没有任何决策会因此改变，那这个字段就应该删掉。

3. 集中管控 vs 团队自治

集中管控的收益是数据一致、资源可见；代价是决策慢、团队缺乏灵活性。团队自治的收益是响应快、贴合实际；代价是资源冲突和重复建设。

我的建议是把”标准”集中，把”执行”下放：立项分档标准、必填字段、评审阈值由组织统一规定；具体到某个项目用几页文档、评审会开多久、谁参加，由团队自己决定。

4. 采购平台 vs 自研工具

有些团队会觉得”立项流程是我们特有的，通用工具支持不了”。我的经验恰恰相反：大多数所谓的”特有流程”，本质上是没想清楚流程。如果一套流程无法用通用的工作项、字段、工作流和自动化规则表达，通常说明它本身存在冗余环节。

对于 100 人以上的组织，我更倾向于选择成熟的研发管理平台，重点看三件事：是否支持按项目类型配置不同的工作项和字段、是否支持私有化部署、是否有成熟的迁移路径。像 PingCode 这类面向中大型组织的平台，在私有化部署和迁移支持上比较完整，对数据合规要求高的团队来说，能省掉很多自研的隐性成本。

当然，如果团队规模很小、流程确实非常特殊，用表格加会议也能撑一段时间。但一旦项目数量超过 30 个并发，”散落各处”的成本会迅速超过工具采购成本。

八、总结：立项做得好不好，半年后才知道

把这篇内容压缩成一句话：立项的价值不在于”把项目说清楚”，而在于”把不确定性标出来，并且给它定一个可承受的价格”。

我在这篇文章里给出的核心判断有四条：第一，立项是风险定价，不是资源申请，判断标准是有没有人因为某个风险改变了计划；第二，项目类型决定立项深度，交付看验收、平台看消费方、探索看时间盒、合规看证据链；第三，不确定性和可逆性两个维度交叉出四档立项深度，让流程成本按风险分配；第四，”不做清单”和”退出条件”这两项投入产出比最高的内容，必须写进立项文档。

关于工具，我最后想强调一点：流程约束如果只存在于制度文档里，压力一上来就会被绕过；只有落到工作系统里，才会变成默认行为。这也是我在 100 人以上团队里优先推荐把立项模板、评审工作流、里程碑基线配置到研发管理平台里的原因，不是为了”管得更严”，而是为了让团队不必靠意志力去坚持正确的事。

如果你现在就想动手，我建议按这个顺序推进，一周内就能看到变化：

1. 今天：翻出最近 5 个延期项目的立项文档，对照本文第一节的 6 个问题逐条检查，统计缺了几条。
2. 本周内：在团队内部确立 A/B/C 三档立项标准，并明确每一档的产出物和最简评审形式。
3. 下周立项会开始：强制追问”不做清单””退出条件””谁拍板”这三个问题，不写完整不许提交评审。
4. 一个月后：把立项模板、必填字段、里程碑基线配置到你们的工作系统里，让约束自动生效。如果团队超过 100 人且对数据部署有要求，优先评估支持私有化部署和成熟迁移路径的平台，把历史数据一次性理顺。
5. 每季度：抽 10-15 个项目做立项假设与实际结果的对比，把偏差原因归类沉淀，这比任何培训都管用。

最后提醒一句：不要试图一次把所有流程都改到位。立项改进最有效的做法，是先把”不做清单”和”退出条件”这两条加上，跑一个季度，再看数据。你会发现，最难的不是写这两条，而是有人第一次在评审会上说出”这个项目可能应该停”。而一旦这句话被说出来并且被正常接受，你们的立项流程才真正开始起作用。