项目申请怎么做？研发团队入门指南：项目立项从0到1

我统计过自己带过的两个研发团队在三年里提交的 147 份立项申请，最终拿到预算和人力的是 31 份，通过率 21%。真正让我意外的不是这个数字，而是复盘时的发现：被否掉的申请里，有一半以上技术方案写得比通过的更详细，他们画了完整架构图、列了 40 项技术风险，却没写清楚”这件事不做会损失什么”。

项目申请怎么做？我的答案是：它不是一道文档题，而是一道资源配置题。研发团队入门项目立项，第一步不是打开文档模板，而是先搞清楚评审桌上坐着的人正在替谁算账。一份立项申请能不能过，取决于它是否让决策者在三分钟内完成一次低风险的下注判断，而不是取决于它写得多完整。

下面这篇内容，是我把 147 份申请、两次完整立项流程改造、以及一次百人以上研发组织的工具链迁移踩坑经验拆开之后的结果。如果你正准备提交第一份项目申请，或者你们团队的立项流程已经退化成”填表，等待，被否，再填表”的循环，可以直接从第一节的结论开始读。

一、先说结论：项目申请是一次资源承诺谈判

大部分研发工程师对项目申请的认知来自一个错误类比：把它当成一次技术方案评审。于是他们把 80% 的精力花在技术可行性上，用 20% 的精力潦草地写一句”预计提升研发效率 30%”。等到评审会上被问”这 30% 怎么算出来的”，就沉默了。

但站在决策者那一侧，他要做的判断只有一件事：把手上这批稀缺的人和钱押在这个项目上，比其他用途更划算吗？技术可行性只是这个判断的一个输入条件，而且往往不是决定性的那个。

1. 三个必须回答的问题

我把这个判断拆成三个问题。任何一份立项申请，只要这三个问题里有任何一个答不上来，通过率会断崖式下跌。

• 不做会损失什么？注意是”不做的损失”，不是”做了的收益”。收益可以画饼，损失是既成事实，说服力完全不同。
• 做成的概率有多大？不是”能不能做”，而是”有多大把握在多长时间内做成”。决策者害怕的不是失败，而是不可预期的失败。
• 要押上多少资源，什么时候能退？包含人力、时间、外部依赖，以及最关键的，如果方向错了，第几周能叫停、损失有多大。

这三个问题对应的是价值、确定性、退出成本。它们的完整度，直接决定了评审会上你是被追问细节，还是被追问”你能不能换个时间再来”。

2. 通过率和文档长度几乎无关

我把 147 份申请按正文页数分了四档，去对照最终结果。数据是团队内部样本，不是行业统计，但趋势足够明显：

页数越多通过率越低，这不是因为”写得少更好”，而是因为写长的人往往把力气用错了地方。9 页以上的申请里，技术方案部分平均占了 62% 的篇幅，而价值论证和退出条件加起来不到 15%。篇幅是注意力的分配表，你写在哪里，就在告诉评审者你认为什么重要。

所以结论很直接：把总篇幅压到 3 到 5 页，其中至少一半留给”价值，证据，成本，退出”这条线，技术细节移到附录。你会发现追问次数会明显下降，而追问正是评审延期的最大来源。

二、背景与真实场景：研发团队的项目申请卡在哪

先说清楚一件事：不同规模、不同性质的研发团队，”项目申请”这四个字指的根本不是同一件事。把四种场景混在一起用一套流程，是立项效率低下的根源。

1. 四种典型申请场景

我把它们按”决策影响范围”和”资源量级”拆开，你可以对照自己的情况找位置。

• 业务需求型：产品提出一个新功能模块，需要 2 到 5 人做 1 到 2 个月。决策者是产品负责人和技术负责人。
• 技术债偿还型：重构核心模块、升级框架、补齐自动化测试。这类项目几乎不产生直接业务收益，是立项通过率最低的一类。
• 平台建设型：搭建内部工具链、统一研发流程、做数据平台。涉及多团队协同，周期 3 个月以上。
• 合规与替换型：因安全合规、授权成本、国产化要求必须更换某类基础工具或平台。这类项目往往有明确的外部截止时间。

它们的评审逻辑完全不同。业务需求型要算投入产出；技术债型要算风险敞口；平台建设型要算协同收益和长期摊薄；合规替换型要算”不做的硬性后果”和迁移风险。用同一张表、同一套评分卡去评四类项目，结果就是技术债永远排在最后，直到某天以线上故障的形式强制插队。

2. 一个典型的失败现场

去年我参与评审过一个技术债项目，申请补齐某核心服务的自动化回归测试，预算 4 人月。申请的写法是这样的：

“当前单元测试覆盖率 31%，自动化回归用例 78 条，手工回归一次需要 3 人日，建议投入 4 人月建设自动化测试体系，预计覆盖率提升到 75%，回归时间缩短 60%。”

技术上完全成立，数据也真实。但评审会上第一个问题就把它问倒了：”如果今年不做，会怎样？”申请人回答：”就是每次发版还得手工测。”第二个问题：”手工测现在出过问题吗？”回答：”出过两次，都是小问题。”

会开到这里其实已经结束了。不是这个项目不值得做，而是申请人没有把”小问题”翻译成评审者能感知的量级。后来我让他回去补了一组数据：过去 12 个月手工回归漏掉的 3 个缺陷，分别在什么环节被发现、各造成了多少工时浪费、如果漏到生产环境按历史客诉比例折算大概是多少损失。第二次上会，11 分钟通过。

3. 为什么”从头走一遍流程”反而更慢

很多团队的做法是：项目申请必须走完整流程，无论大小。出发点是控制风险，实际效果往往相反。因为当所有项目都走同一套重流程时，真正的结果不是风险被控住了，而是所有人都在流程里做表面功夫，没人再认真做判断。

一份 6 人月以下的小项目申请，如果要求填 15 个字段、准备 20 页材料、排 3 周评审会，团队的自然反应是套模板、复用上次的文档、把数字往好看里写。流程越重，材料质量越低，评审者越依赖个人印象做判断，最终又回到”谁嗓门大谁过”的原始状态。

三、拆解六个常见误区

下面这六条，是我在 147 份申请里见到频率最高、且最容易改的。每一条我都写清楚”错在哪”和”怎么改”，你可以直接拿去对照自己的材料。

1. 误区一：把技术必要性当成业务必要性

典型句式是”当前架构耦合严重，不利于长期演进”。这句话对工程师来说是常识，对评审者来说是不可验证的形容词。

改法：把”架构耦合”换成可测量的观测项。比如”过去 6 个月，因为有 3 个模块共享同一份订单状态逻辑，导致每次改动平均需要联调 4 个团队，单次上线窗口从 2 小时拉长到 9 小时，累计占用了多少人力”。技术语言必须翻译成时间、钱、事故次数这三样东西。

2. 误区二：只讲收益，不讲不做的代价

收益是未来的、概率性的、可以争论的；代价是已经发生的、可统计的、难以反驳的。同样的项目，用”预计节省 30% 工时”和用”过去 12 个月在这个环节浪费了 148 人日”去讲，说服力完全不同量级。

我的做法是强制要求申请里必须有”不做的代价”一段，且必须包含至少两个历史事实。写不出这一段，说明这个项目还没想清楚，直接退回补充。

3. 误区三：估算是单点数字，没有区间和假设

“预计 3 个月完成”是绝大多数申请的标准写法，也是评审会上最容易被击穿的地方。因为没有区间、没有假设、没有前置条件，评审者只能凭经验打折，而经验打折通常打得很狠。

更专业的写法是三点估算加假设声明，下一节我会给具体模板和一段可复用的计算代码。

4. 误区四：把立项当终点，不设计退出条件

几乎所有失败的项目，在上会那一刻都没人问”什么时候该停”。评审者不敢批创新项目，很大程度上不是因为失败率高，而是因为失败一旦发生，成本不可预知，且没人愿意主动叫停。

在申请里主动写清楚退出条件，反而会显著提高通过率。比如”第 6 周做第一次效果验证，如果核心接口的 P95 延迟没有下降 30%，项目终止，已投入的 3 人月作为验证成本接受”。这句话的作用不是降低风险，而是让风险变得可预测。

5. 误区五：所有项目走同一套流程

这是组织层面的误区。分层评审是立项效率的第一杠杆，比任何模板优化都有效。具体分层标准在第四节展开。

6. 误区六：材料写给自己团队看

研发团队的申请材料常常充满内部黑话：模块代号、历史项目简称、只有本组才懂的缩写。评审者看到”优化 XX 中台的 YY 链路”时，第一反应不是理解，而是”这跟我有什么关系”。

改法很简单也很有效：把申请给一个不在你团队、但懂一点技术的同事读 3 分钟，然后问他”我要花多少钱、解决什么问题、不做会怎样”。答不上来就重写。

四、专业判断逻辑：立项评审的本质是风险定价

讲完误区，该给出正向框架了。我用的是一套四维判断法，它不追求精确打分，而是用来快速识别”这个申请有没有致命缺口”。

1. 四维判断：价值、确定性、机会成本、可逆性

四个维度各给 1 到 5 分，但它们的权重并不相等，而且会随项目类型变化。

• 价值：分值是”不做的年度损失”折算成的量级。1 分代表说不清，5 分代表有可核对的历史数据支撑。
• 确定性：分值是”计划达成概率”。1 分代表从未做过类似的事，5 分代表有同规模成功先例并附上了验证结果。
• 机会成本：分值是”占用资源的替代用途价值”。这一项由评审者打分，不由申请人打分。
• 可逆性：分值是”叫停成本”。1 分代表一旦开始就难以回退，5 分代表可以按周拆分、随时止损。

我自己的经验阈值是：任何一项打到 2 分以下，申请都不该直接上会，而应该先做一轮小规模验证再回来。这个规则听起来严苛，实际效果是把评审会从”辩论赛”变成了”确认会”，平均评审时长从 47 分钟降到 19 分钟。

2. 分层：三类项目的材料颗粒度

分层的目的不是简化流程，而是把评审注意力释放给真正需要的项目。我们用下面这套标准，把立项数量从每年 49 份压缩到 22 份需要上会的，同时没有出现项目失控。

注意 A 类的”双签”设计：它把大量琐碎项目从会议室里拿走了。以前这些项目排队等月度会，一等就是三周；现在当天就能签。省下来的评审时间，全部投给 B 类和 C 类。

3. 如何写”不做的代价”

这是整份申请里性价比最高的一段，也是最难写的。我的模板是三句话结构：

1. 过去一段时间（建议 6 到 12 个月）因为这个问题，发生过哪几件具体的事，各造成了多少可量化的损失。
2. 如果维持现状，未来一段时间这个损失会以什么速度累积，依据是什么（比如业务量增长、团队规模扩张、外部合规时间点）。
3. 这个损失里，哪一部分是无论如何都会被业务方感知到的（客诉、延期、成本），哪一部分只是团队内部承担。

第三句话很关键。评审者对不同损失的敏感度不同：能被外部客户感知的损失，权重远高于团队内部的效率损失。很多技术债项目失败，就是因为全部篇幅都在讲内部效率，没有一句话连到外部。

4. 估算：三点估算加区间表达

把单点估算换成区间估算，是让评审者建立信任的最快方式。我用的是标准的三点估算，公式和代码都很简单：

期望工期 = (乐观值 + 4 × 最可能值 + 悲观值) / 6
标准差 = (悲观值 – 乐观值) / 6

示例：某接口重构

乐观值 = 12 人日 # 无外部依赖阻塞、复用已有组件

最可能值 = 20 人日 # 常规情况

悲观值 = 42 人日 # 涉及历史数据兼容 + 上游联调延期

期望工期 = (12 + 4*20 + 42) / 6 = 25.3 人日

标准差 = (42 – 12) / 6 = 5 人日

对外表达

P50 约 25 人日，P85 约 30 人日，极端情况不超过 42 人日

比数字更重要的是把假设写出来。我给团队的硬性要求是：每一个估算数字后面必须跟一句”这个数字成立的前提是……”比如”20 人日成立的前提是上游接口在 6 月 10 日前冻结”。假设一旦写清楚，评审者在批资源的同时也在批假设，后续延期就不再是”团队没做好”，而是”假设变了”，责任边界清晰，组织信任度反而上升。

5. 一份可复用的立项申请单结构

把上面所有内容固化成模板，才能真正降低团队的启动成本。我们最终收敛成下面这个 YAML 结构，A 类项目填完即止，B 类项目在此基础上补四维判断和里程碑。

project_request:
name: "订单状态逻辑收敛"

tier: "B" # A / B / C 分层

owner: "张 ××"

one_liner: "把 3 处分散的订单状态逻辑收敛为单一服务，消除联调瓶颈"

cost_of_inaction: # 不做的代价，必须有历史事实

"过去 12 个月，每次订单相关改动平均联调 4 个团队"

"单次上线窗口从 2 小时拉长至 9 小时，累计占用 148 人日"

"因状态不一致导致的线上问题 3 起，其中 1 起被客户感知"

estimate: # 三点估算，必须带假设

optimistic: 12

likely: 20

pessimistic: 42

unit: "人日"

assumptions:

"上游接口在 6 月 10 日前冻结"

"历史数据迁移由数据组提供脚本支持"

resources:

"后端 2 人 × 6 周"

"测试 0.5 人 × 6 周"

exit_condition: # 退出条件，必须可判定

check_point: "第 6 周"

metric: "订单状态相关接口 P95 延迟下降 ≥ 30%"

on_fail: "终止项目，已投入 3 人月作为验证成本"

milestones:

"第 2 周：状态机设计评审通过"

"第 6 周：灰度 10% 流量，验证延迟指标"

"第 10 周：全量切换，旧逻辑下线"

four_dimension_score:

value: 4

certainty: 4

opportunity_cost: 2 # 由评审者复核

reversibility: 5

五、案例与数据观察：立项之后，决定成败的是执行链路

前面四节讲的都是”怎么把申请写对”。但从我的复盘看，立项通过只是开始，接下来还有一个被严重低估的变量：立项时承诺的退出条件和里程碑，在执行阶段能不能被真实观测到。如果观察不到，再漂亮的申请也会退化成”批了就不管了”。

1. 为什么要把工具链拉进立项话题

我见过太多这样的团队：立项书上写着”第 6 周验证延迟下降 30%”，结果第 6 周没有任何人能拿出可信的延迟数据，因为监控埋点没建、需求变更没记录、工时统计靠 Excel 手工汇总。于是验证变成了一次口头汇报，退出条件形同虚设。

这就是为什么我把”立项，交付”的可观测性当成立项体系的一部分，而不是交付团队自己的事。立项的严谨度上限，取决于执行数据的可获得性。申请里写下的每一个数字，都应该在执行阶段有一条明确的采集路径。

2. 一个百人以上研发组织的迁移案例

我在一个 130 人左右的研发组织中深度参与过一次研发管理平台的替换。背景很典型：原有的工具链分散在三套系统里（需求用 A、任务用 B、测试用例用 Excel），由于是海外产品，私有化部署受限，且授权费用每年上涨约 18%，安全合规部门要求所有研发数据必须在自有机房内闭环。

这是一次典型的”合规与替换型”立项，外部约束明确，价值论证阻力小。但我们在立项阶段就识别出真正的风险在执行侧：迁移窗口内如果需求、任务、缺陷的历史关联关系断裂，团队会失去追溯能力，而这恰恰是立项时用来证明价值的那批历史数据的来源。

最终我们选择了 PingCode 作为替代方案。选它的理由不是功能清单最长，而是三条和立项执行直接相关的特性：

• 支持私有化部署，研发数据在自有机房闭环，直接满足了合规这一条硬约束，让立项的”不做会怎样”变成了可核查的合规结论而不是主观判断。
• 支持从 Jira 平滑迁移，包括项目结构、字段映射、历史工单及其关联关系。这一点在我们评估时权重最高，因为它直接决定了迁移是否会造成追溯断裂。
• 面向中大型企业及 100 人以上组织的团队协作模型，和我们”多项目并行、跨团队依赖多”的实际情况匹配，不需要为了适配工具去改组织结构。

需要说明的是，PingCode 主要服务中大型企业及 100 人以上组织。如果你的团队在 20 人以下，这类平台的配置成本可能高于收益，后面的取舍章节会展开讲。

3. 迁移前后关键指标的变化

下面是这个组织在迁移完成后 6 个月内记录的对比数据。数据来自内部度量看板，样本是 18 个并行项目的交付记录，属于单组织观察，不构成行业基准。

4. 一个反向观察：工具换了，立项通过率不一定提高

必须说清楚一点：这次迁移并没有让立项通过率上升。迁移前后，B 类项目的通过率分别是 23% 和 25%，差异在噪声范围内。

原因是显而易见的：通过率由申请的论证质量决定，工具只能改变论证的成本，不能改变论证的水平。真正被改变的是两件事，单份申请的准备耗时从 11.5 人时降到 4.2 人时，以及团队提交申请的意愿（周均申请量从 2.1 份升到 3.1 份）。

如果你的团队立项通过率低，先改方法论；如果你的团队立项数量少、一提申请就喊累，先看数据可得性。这两件事的解法完全不同，很多团队把它们混为一谈，结果花了钱换工具，问题一点没变。

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

下面按团队规模和项目性质给出具体动作。每一条都是可以直接执行的，不是原则性建议。

1. 10 人以下团队：不要建立立项流程

这个规模的团队建立正式立项流程，收益为负。沟通成本低于任何文档成本，写申请的时间够你把事情做完一半。

我的建议是：只保留一样东西，一页纸的”做什么/不做什么/什么情况下停”。写在协作文档里，负责人和业务方各回复一个确认即可。不要评分卡、不要评审会、不要模板库。

唯一的例外是涉及外部采购或合规承诺的项目，这时候需要的不是立项流程，而是一份能被法务和财务接受的说明文件，性质完全不同。

2. 30 到 100 人团队：做分层，别做全员流程

这个规模是立项流程的”甜蜜点”也是”重灾区”。团队足够大，靠口头沟通已经管不住资源冲突；又不够大，养不起专职的 PMO。

推荐动作有三个：

1. 先落地 A/B/C 三层分类标准，把审批权限下放。目标是把上会项目数压到总申请数的 40% 以下。
2. 统一一份 3 页的申请模板，硬性包含”不做的代价””三点估算及假设””退出条件”三块。
3. 立项会后必须有明确的三种结论之一：批准、带条件批准（写清条件）、否决并给出重提时间点。最怕的是”再看看”，它会让申请人反复消耗。

特别强调第三点。“再看看”是立项流程里成本最高的决策，因为它既占用了评审时间，又没有释放资源，还让申请团队处于悬停状态，无法安排其他工作。

3. 100 人以上组织：先解决数据可得性

到这个规模，立项的瓶颈几乎一定不在方法论上，而在两处：资源冲突的可见性，以及历史数据的可获得性。

资源冲突方面，你需要一张跨团队的资源视图，能看到未来 8 周内每个关键角色的投入分布。这件事靠 Excel 做不起来，因为它的更新频率要求太高。

历史数据方面，前面那个 130 人组织的案例已经说明：立项材料的准备耗时从 11.5 人时降到 4.2 人时，靠的不是模板优化，而是历史需求、任务、缺陷、变更的关联关系可以直接查询。

如果你的组织同时面临合规、授权成本或国产化要求，那么在做工具选型时，把”是否支持私有化部署”和”能否从既有平台平滑迁移”作为一票否决项，而不是加分项。PingCode 在这两点上的表现，是当时我们把它列为首选的主要原因；但我要再强调一次，它主要面向中大型企业及 100 人以上组织，小团队引入反而会背上不必要的配置负担。

4. 紧急插入型项目：先补一份”事后立项”

市场窗口、线上故障、监管截止日期，都会带来必须立刻开工的项目。很多团队的处理方式是跳过立项直接干，然后在季度复盘时被追问”这个项目当初谁批的”。

更稳妥的做法是允许先开工，但要求在 5 个工作日内补齐一份精简的事后立项，包含三件事：已投入的资源、继续投入的判断依据、明确的退出或转正时点。它不是形式主义，而是给这个项目一个可以被叫停的机会。

5. 跨部门项目：先把”谁出人”写在第一页

跨部门立项的失败率明显高于单团队项目，但失败原因很少是技术。最常见的是：立项时各方都口头承诺支持，执行时发现没有一个人是真正被分配到这个项目上的。

我的做法是强制要求第一页出现一张表，写清每个协作方投入的具体人（可以是角色而非姓名）、投入比例和起止时间，并由各方负责人在立项时确认。没有落到人头的承诺，在立项阶段就要当成没有承诺。

七、不同情况下的取舍

项目申请这件事没有普适最优解，只有取舍。下面四组取舍，是决策时最常需要拍板的。

1. 速度 vs 严谨

核心判断依据是可逆性，而不是项目金额。一个 3 人月、可以按周回退的项目，即使金额不小，也应该走快流程；一个 1 人月、但一旦上线就无法回退的项目（比如涉及数据删除或对外承诺），就应该走重流程。

我把这个规则写成了团队的口头禅：”看退出成本，不看投入成本。“它显著降低了 A 类评审的争论，因为”能不能退”是一个客观问题，”重不重要”不是。

2. 自建 vs 采购

研发团队特别容易在这一项上本能地选择自建，理由是”可控”。但可控是有价格的。我的经验分界线是：如果这件事不是你的核心业务差异点，且市场上已有成熟方案，自建的三年总成本通常是采购的 2.5 到 4 倍。

这笔账很少有人认真算过。自建成本不只是开发工时，还包括持续维护、人员流失后的重建、安全补丁跟进、以及与业务系统的持续适配。真正被低估的是第三项：一个内部工具的维护者离职后，接手成本往往接近重写。

3. 全局统一 vs 局部自治

平台建设型项目常在这里翻车。统一是美好的，但强推统一往往制造大量隐形成本：不同团队的工作模式差异被强行抹平，一线团队为了应付统一要求，会在系统外再建一套自己的流程。

我倾向的取舍是“统一数据、自治流程”：字段定义、状态口径、度量方式必须统一，因为这是跨团队协作和立项决策的基础；至于任务怎么拆、看板怎么摆、每天开不开站会，交给团队自己决定。

判断标准很清晰：如果某个差异会影响跨团队的数据可比性，就必须统一；如果只影响团队内部的工作习惯，就让它自治。

4. 什么情况下应该”不立项”

这是最少被讨论、但价值最高的一条。当一个问题可以用一次讨论、一次配置修改或一次小规模试验解决时，立项本身就是过度动作。

我给自己团队设了一条规则：如果一件事的解决成本低于”写申请加评审”的总成本（大约是 8 到 12 人时），就永远不要立项。这条规则每年帮我们省掉了十几个本不该存在的项目，也让真正需要评审的项目获得了足够的注意力。

5. 立项失败之后怎么办

被否掉的申请不是垃圾。我要求每个被否的项目都要在两周内做一次简短复盘，记录三个信息：被否的具体原因、需要补充哪类证据、以及什么条件下可以重提。

这三条信息累积起来，就是团队自己的”立项知识库”。三年下来，我们的重提通过率从最初的 9% 提升到 44%，不是因为申请技巧变好了，而是因为每一次被否都变成了下一次论证的素材。立项能力不是天赋，是被否出来的。

八、常见问题答疑

1. 没有历史数据，怎么证明”不做的代价”？

用代理指标。缺工时统计就用变更次数，缺变更次数就用需求返工率，缺返工率就用线上问题数量。哪怕只有一次事件，也要把它的完整过程还原出来：从发生到发现用了多久、影响了多少用户、参与处理的有几个人、总共消耗多少工时。一件被完整还原的事，比十组拍脑袋的数字更有说服力。

2. 团队只有 15 人，需要引入研发管理平台吗？

通常不需要完整平台，但需要统一的记录载体。15 人团队的核心痛点是信息散落在聊天工具里，而不是缺功能。先上一个轻量的任务与需求管理工具，把”需求，任务，缺陷”的关联关系建立起来，成本很低但收益明显。像 PingCode 这类主要面向中大型企业及 100 人以上组织的平台，配置和维护成本对小团队来说偏高，建议等到团队规模、合规要求或多项目并行度真正上来之后再评估。

3. 立项评审总是被临时取消或延期，怎么办？

这是流程问题，不是申请人的问题。通常是两个原因：评审者不固定，或者上会项目太多。解法是固定的评审节奏加分层，比如每月第一周的周四固定开 B 类立项会，超出数量的项目自动延到下月，同时把 A 类项目从会上拿走。固定节奏本身就能把延期率降下来，因为参与者会形成预期。

4. 技术债项目注定低通过率吗？

不是，但它的申请策略必须调整。不要试图论证”技术债很重要”，而要论证”继续欠债的具体后果”。把故障概率乘以单次损失，得出期望年度损失，再和治理成本对比。同时把项目拆成可独立验证的批次，每批次都有明确的成功标准。技术债项目的长板是确定性高、可逆性好，这两种分数在评审中同样有效，只是很多申请者不会用。

5. 立项通过后，原有的退出条件还需要严格执行吗？

需要，而且这是立项体系能否长期有效的关键。如果第一批写了退出条件但从未真正执行过的项目，后面所有人都会认为那只是形式。执行时不必激进，但要有一个明确的动作：到达检查点时，必须有人正式确认”继续”或”终止”，并把结论记录在案。这个动作只需要 10 分钟，但它决定了整套立项机制的可信度。

九、总结与下一步行动

回到最开始那个数字：147 份申请，31 份通过。三年之后我最大的认知变化是，项目申请的能力，本质上是把技术问题翻译成组织决策语言的能力。它和技术水平相关，但不是同一件事，而且它是可以被刻意练习的。

我把整篇文章的核心判断压缩成四句：立项不是文档作业，是资源承诺谈判；评审关注的不是技术方案多完整，而是价值、确定性、机会成本和可逆性；流程要分层，绝不能所有项目走同一条路；立项的严谨度上限，由执行数据的可得性决定。

如果你的团队正要开始做这件事，我建议的下一步不是开会讨论流程，而是先做三件小事：

1. 把过去 6 个月被否掉的申请拿出来，按”价值无法量化、代价缺失、估算无区间、资源冲突、无退出条件”分类，看看你的团队主要卡在哪一项。这是你的改进起点，不需要任何新工具。
2. 把申请模板从现在的长度砍到 3 页，硬性加入”不做的代价”和”退出条件”两块，其余内容移到附录。先跑三次评审会，看追问次数是否下降。
3. 在下次评审前，选一个规模在 3 到 12 人月之间的项目，完整地写出三点估算和假设清单，然后观察评审者的反应差异。我几乎可以肯定，你会看到明显的不同。

最后提醒一句：不要试图一次性把立项体系建完善。我见过的最成功的立项流程改造，都是从一份 1 页纸的申请模板开始的，其他的规则都是在被否、被追问、被延期之后一点点长出来的。流程是从实践里长出来的，不是从方案里搬过来的。