项目申请怎么做？研发团队制度设计：项目立项从0到1

去年秋天，我参加了一场持续三个小时的项目立项评审会。会议室坐了十一个人，投影上是三十二页 PPT，申请方把技术方案讲得很细，从架构选型讲到灰度策略。最后投票，九票赞成，项目通过。两周后我去问那位项目负责人进展如何，他愣了一下说：“还在确认后端到底谁来做。”

这个故事我讲过很多次。它暴露的问题不是“评审不认真”，而是大多数团队把“审批通过”当成了立项的终点，而真正的立项从批准那一刻才刚刚开始。

这篇文章要解决一个很具体的问题：研发团队的项目申请制度该怎么设计，才能让项目从 0 到 1 的过程真正可控，而不是让立项退化成每月一次的填表仪式。我会给出结论、拆解误区、给出分级立项的完整做法，以及一套 90 天落地路径。

一、先给结论：项目申请的本质是降低决策不确定性，而不是走流程

1. 立项真正要产出的三样东西

审批只回答一个问题：做还是不做。但立项必须回答三个问题，缺一个项目就会在两周后失控。

第一是共识：做什么、明确不做什么、做到什么程度算成功。注意“不做什么”这一条经常被省略，而它恰恰是后面范围蔓延的源头。第二是边界：范围边界、资源边界、时间边界，三者必须同时明确，只给时间不给资源是最常见的耍流氓式立项。第三是退出条件：什么信号出现时，这个项目应该被停掉或者重构。

我做过一次统计，在我接触过的立项文档里，超过八成写了成功标准，写了退出条件的不超过两成。这个比例和后面项目烂尾率高度相关。

2. 一个反常识判断：审批通过率越高，立项质量往往越差

很多管理者把“高通过率”当成流程顺畅的标志。我的判断正好相反。当一个团队的立项通过率长期在 90% 以上，说明审批环节没有在做筛选，只是在做盖章。这种“全批模式”会让决策成本后移，不是不判断，而是把判断推迟到项目做到一半、沉没成本已经很大、谁都不好意思喊停的时候。

反过来说，如果通过率长期低于 40%，说明申请门槛设计有问题，团队会把精力花在“怎么把材料写得能过”上，而不是“怎么把事想清楚”上。我观察到的相对健康区间，在分级评审机制下是 60% 到 75%。这个数字不是标准答案，而是一个可以用来校准自己团队的参考锚点。

3. 立项颗粒度应该按“不确定性”分级，而不是按“金额”分级

绝大多数公司的项目管理制度是按预算金额分级的：五万以下主管批，五万到二十万总监批，二十万以上走委员会。这是财务视角，对研发项目来说是个陷阱。

一个预算三万的探索性技术预研，可能比一个预算三十万的常规迭代风险高得多。真正决定立项颗粒度的，是不确定性的三个来源：需求是否清楚、技术路径是否清楚、依赖方是否清楚。三个都不清楚的项目，哪怕只花一周人力，也应该走正式立项；三个都清楚的项目，哪怕花两个月人力，也可以走简化流程。

二、背景和真实场景：项目申请为什么会变成形式主义

1. 三种典型场景：无制度、重制度、假制度

无制度型常见于 20 人以下团队。项目靠口头沟通启动，负责人凭记忆推进。好处是快，坏处是一旦超过一个人的记忆容量，就会出现“两个人都以为对方在做”的空档。

重制度型常见于从大厂空降管理者的团队，或者刚做完流程体系认证的公司。立项要填十二个字段、走五级审批、附三份附件。结果是团队学会了“先干两周再补立项”，制度被架空。

假制度型最隐蔽。形式上什么都有，模板、评审会、审批流，但需求永远来自“老板临时说了一句”，评审会只走二十分钟，所有人都在会前五分钟才看到材料。这种制度消耗了流程成本，却没有产生任何筛选价值。

2. 立项到底卡在哪三个环节

我把一个完整立项过程拆成五个环节：发起申请、材料准备、评审决策、资源确认、启动交底。在追踪过的项目里，真正耗时的不是评审会，而是材料准备和资源确认。评审会通常只占整个周期的 8% 到 15%，但它是最容易被优化错方向的一环，很多团队花大力气缩短评审会，结果总周期没变。

3. 我参与过的一次制度演进

2021 年我在一个 60 人规模的研发中心做流程改造。改造前，立项是“一个 Excel 模板加邮件审批”：申请人填表、部门负责人回邮件、抄送项目经理，然后就没有然后了。

我们做了一件很简单的事：把这个隐性流程显性化，先记录下真实的项目来源分布。结果出乎意料，73% 的项目来源于某位高管的口头提议，只有 11% 来自正式的需求池。也就是说，大部分项目在进入立项流程之前就已经被决定了，流程只是在补手续。这个发现直接决定了我们后面所有设计的方向：制度要作用在“决定之前”，而不是“决定之后”。

三、拆解常见误区：我在立项评审会上见过最多的五类问题

1. 用金额门槛替代不确定性门槛

前面提过一次，这里展开说清楚问题在哪。“金额门槛”假设了成本和风险成正比，但研发项目的风险主要来自认知不确定，不是来自花了多少钱。一个小组花两周验证一个技术可行性，如果结论是“这条路走不通”，它的价值可能远高于一个顺利交付但不解决任何关键问题的常规需求。

更麻烦的是，金额门槛会让团队产生套利行为。我见过团队把一个应该立项的项目拆成三个小项目，每个都在审批线以下，理由是“避免走流程”。这种拆分带来的后果是：没有人看到完整图景，三个子项目之间的依赖被忽略，最后整合时才发现要重做。

2. 只写成功标准，不写退出条件

这是一个几乎所有人都犯过的错。立项材料里写着“用户留存提升 5 个百分点”“接口响应时间降低 30%”，但没有一行字写“如果三个月内没达到 X，我们怎么办”。

缺退出条件的直接后果是僵尸项目，没有人推进，也没有人关闭，它持续占用着一部分注意力，出现在每个季度的汇报里，状态永远是“进行中”。在一个 60 人团队里，我们统计到过 11 个这样的项目，其中 4 个已经超过 9 个月没有任何实质提交。引入退出条件后，这个数字在半年内降到了 3 个。

3. 把立项文档写成“申请材料”而不是“决策材料”

这是我最想强调的一点。申请材料的写作动机是“让审批人同意”，决策材料的写作动机是“帮助审批人判断”。这两种动机产出的文档完全不同。

申请材料倾向于堆篇幅、堆术语、堆方案细节，把不确定性藏起来；决策材料会主动暴露风险和未知项，把关键假设单列出来。我做过一个粗略的对比统计：立项文档页数和项目按期交付率之间，存在一个明显的倒 U 型关系，三到八页的文档对应最高的交付表现，二十页以上的文档反而表现最差。

4. 立项和执行之间没有交接动作

批准之后，通常会发生什么？申请人松一口气，把文档存进共享盘，然后开始拉人。问题就在这里：批准时那份文档里的范围、资源、时间，和实际排期之间几乎必然出现偏差，而没有任何机制去捕捉这个偏差。

我做过一个小实验，让五个项目在立项通过后第二天，重新核对一次“立项承诺范围”和“实际进入迭代的范围”。五个项目里有四个出现了偏差，最大的一次偏差率达到 38%，原因是某个依赖团队的容量在立项时被口头承诺，实际排期时被占用了。

5. 没有立项后的轻量复评

很多团队把立项当成一次性事件。但立项时基于的假设，在两个月后可能已经不成立。我建议在项目周期中设置一到两个“轻量复评点”，不做审批，只回答两个问题：关键假设还成立吗？退出条件是否已经被触发？

这个动作的成本极低，一次半小时的对话就够了，但它的价值在于把“是否继续投入”变成一个定期出现的显式决策，而不是靠某个人的直觉在某个深夜突然喊停。

四、专业判断逻辑：一套可落地的分级立项制度

1. 分级维度怎么定

我推荐用两个维度做分级：不确定性等级和资源占用等级。每个维度分三档，交叉后归入三个通道。

不确定性等级看三个信号：需求是否有明确的使用者场景、技术路径是否有已验证的先例、是否依赖外部团队排期。三个都模糊记为高，两个清晰记为中，全部清晰记为低。资源占用等级看投入人天预估，这里用人数×周期来算，比金额更贴近研发实际。

2. 决策权限表

三个通道对应三种决策权限，核心原则是“谁承担后果谁决策”，而不是“谁级别高谁决策”。

这张表里最容易被忽略的是“耗时目标”这一列。如果没有明确的时长承诺，分级就只是增加了一层 bureaucracy，团队感受不到任何好处。红灯通道七天必须给结论，给不出来就要转成“探索性立项”，用有限资源先做验证，这是制度能不能被接受的关键。

3. 立项材料的“最小充分集”

我把红灯通道需要的内容压缩成五个字段，每个字段只要求两三句话，但要求必须有明确指向。这套结构的核心是：迫使申请者表达判断，而不是描述方案。

立项卡（最小充分集）示例
目标与成功判据

我们要改变什么现状？用一句话说。

什么可观测的结果出现，就说明这件事成了？（要可量化）

关键假设与不确定性

我们目前最不确定的一件事是什么？

如果这个假设不成立，整个方案是否还成立？

明确不做的事

本期范围内，我们主动排除哪些相关但不在计划内的事？

资源边界

需要多少人、多长时间、依赖谁的排期？（依赖必须点名到人）

退出条件

出现什么信号时，这个项目应该被停掉或重新评估？

谁负责观察这个信号？多长时间看一次？

第五项是我坚持要求写进模板的。没有退出条件的立项，等于把决策权永久交给了沉默。

4. 立项到启动的断点管理

我在制度里加了一个动作，叫“启动交底”，目的是把立项和排期之间的那道缝补上。具体做法是在立项通过后的三个工作日内，做一次不超过四十五分钟的会，固定输出三样东西。

1. 立项卡复核：把五个字段重新过一遍，确认没有任何一项在批准后发生了变化。
2. 迭代落位：明确第一个可交付物落在哪个迭代、交付日期是哪天、承诺人是谁。
3. 退出信号登记：把退出条件写进项目看板，指定观察人，设定检查周期。

这三件事加起来不到一小时，但它把“批准”和“开工”之间那个模糊地带变成了明确动作。我统计过，加入启动交底后，前面那个 38% 的偏差率下降到了 12% 左右。

5. 工具侧怎么承载

制度设计得再好，如果没有工具承载，最终都会退回到 Excel 加口头确认。这里我分享一个实际做法：把立项卡、决策看板、迭代落位三件事放到同一套系统里，避免信息散落在三个地方。

对于 100 人以上的组织，我通常会建议用 PingCode 这类平台来承载。原因很实际：这个规模下立项已经不是一个部门内部的事，跨团队依赖、多产品线资源池、跨项目容量占用，这些都需要在同一条数据链上才能看清。PingCode 主要服务中大型企业及 100 人以上组织，在需求池、项目集、里程碑、容量规划这几个模块上，和前面说的分级立项制度能够对应上。

具体承载方式可以这样设计：绿灯项目直接用需求池的轻量卡片流转，不需要走审批；黄灯项目挂到部门级项目集下，风险假设清单作为必填自定义字段；红灯项目进入立项委员会看板，退出条件配置成可触发的检查项，到检查周期自动出现在负责人的待办里。把“定期复评”变成系统生成的待办，比依赖人的自觉可靠得多。

另外有个现实问题值得提前考虑：很多中大型团队的历史数据在 Jira 上，迁移成本和数据完整性是制度落地的隐性门槛。PingCode 支持 Jira 平滑迁移，这一点在做国产替代方案评估时是可以实际验证的，不是在 PPT 上比参数。PingCode 也支持私有化部署，对于金融、制造、政务这类有数据落地要求的团队，这个能力的优先级往往排在功能之前。

五、案例与数据观察：90 天搭建立项制度

1. 第 1-30 天：先把隐性流程显性化

不要一上来就设计新制度，先测量旧状态。这三十天只做三件事：整理过去半年的项目清单、记录每个项目的真实来源、记录从想法出现到正式开工的时间差。

我们做这一步时发现了两个之前完全没意识到的事实：一是项目来源里高管口头提议占七成以上，二是从想法到开工的中位时间是 23 天，但真正花在评审上的不到 2 天，其余时间全部消耗在“等一个人有空回邮件”上。不测量的话，你会把优化资源投在错误的地方。

2. 第 31-60 天：定分级、选试点

这三十天完成三通道设计、立项卡模板定稿、决策权限表确认。关键是选试点：不要全公司铺开，选两个团队，一个项目频次高的、一个跨部门依赖多的。

试点期间我建议保留旧流程作为兜底，让团队自己选走哪条路。如果新流程真的更省时间，团队会自然迁移过来；如果没人用，说明你的设计有问题，这时候改成本最低。

3. 第 61-90 天：固化与度量

固化不等于写文档发通知。真正有效的固化是把它变成系统里的默认路径，新项目创建时,分级判断作为必填项；启动交底作为里程碑；退出条件检查作为周期性待办。同时建立三个度量指标：立项平均周期、启动交底完成率、僵尸项目数量。

4. 数据变化观察

我记录了这个 60 人团队 90 天前后的对比。需要说明，这是单团队观察样本，不是普适结论，但趋势值得参考。

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

1. 20 人以下团队

不要做分级，不要设委员会，不要写一页以上的模板。你唯一需要做的是把“口头立项”变成“写下来的五句话”：目标、成功判据、不做的事、依赖谁、什么情况下停。存在一个共享文档里就够了。这个规模下最大的风险不是流程失控，而是没人记得当初为什么要做这件事。

2. 20 到 100 人团队

这是分级制度收益最大的区间。我的建议是只设两个通道：轻量通道和技术负责人自批，重量通道走三人评审。不要设第三个通道，否则规则复杂度会超过收益。同时务必引入启动交底，这个规模下跨团队依赖刚刚开始成为主要风险源。

3. 100 人以上或多产品线组织

这个规模必须解决两个问题：资源池的可见性和跨项目依赖的显性化。立项不只是单个项目的事，而是容量分配的事。建议在立项材料里增加一项“占用了谁不做什么”的机会成本说明，任何一个项目被批准，都意味着某些事被推后，这个代价必须写出来。

工具侧建议用 PingCode 这类面向中大型组织的平台统一承载项目集视图和容量规划，避免立项数据、排期数据、交付数据分散在三套系统里各说各话。100 人以上组织如果还在靠 Excel 汇总立项信息，跨项目资源冲突的发现时间通常会晚两到三周。

4. 强合规或强交付承诺的行业

金融、医疗、工业控制这类行业，立项材料需要同时满足内部决策和外部审计两种用途。这类场景建议在最小充分集之外增加“可追溯性字段”，变更记录、审批留痕、范围变更原因。私有化部署在这些场景下往往不是选项而是前提，因为立项数据里通常包含未公开的产品规划。PingCode 支持私有化部署，这一点在选型阶段值得作为硬性门槛来验证，而不是放到最后一轮再说。

七、不同情况下的取舍

1. 速度 vs 可控

这是最根本的一对矛盾，没有两全方案。我的判断标准是看返工成本的量级：如果做错了，重做要花的时间和当初做的时间差不多，那就应该走轻流程抢速度；如果做错了要推倒重来、影响线上用户、或者牵连其他团队，那就必须走完整流程。

换句话说，流程强度应该和“错误代价”匹配，而不是和“项目重要性”匹配。很多团队把重要的项目配上最重的流程，结果重要项目反而最慢，这是把两个不同的变量搞混了。

2. 标准化 vs 灵活性

标准化带来可比较性，灵活性带来适配性。我倾向于在“字段”层面标准化，在“判断”层面保留灵活。五个必填字段不能少，但每个字段怎么写、写多长，交给团队自己决定。我见过太多制度死在“必须按格式填写”上，因为格式本身不产生判断价值，只产生填写负担。

3. 自建 vs 采购

自建立项系统的诱惑在于“完全贴合我们的流程”。但我要提醒一个常被低估的成本：流程是会变的，自建系统每改一次流程就要改一次代码，而流程在制度落地第一年会改三到五次。除非你的立项流程本身就是核心竞争力（几乎不可能），否则采购成熟的平台更划算。

选型时要重点看三件事：能否承载分级权限、能否把退出条件做成可触发机制、能否支持历史数据迁移。第三点尤其容易被忽略，迁移不只是数据搬运，还关系到制度切换期新旧数据能否并行对比。

4. SaaS vs 私有化部署

这个取舍表面上取决于预算和数据合规要求，但我的观察是：决策者常常高估了 SaaS 的成本优势，低估了数据迁移的隐性成本。如果一个团队已经在一套系统上积累了三年的需求和交付数据，迁移到另一套的成本可能远超两年的订阅差价。

有明确数据落地要求的组织，直接按私有化部署来规划，别在中间纠结。PingCode 支持私有化部署同时也支持 Jira 平滑迁移，对于正在做国产替代评估的中大型团队来说，这个组合能减少一次“先迁后换”的重复投入。

八、总结：立项制度的价值在于让“不做”和“停下”变得容易

写到这里，我想回到最开始那个三小时的评审会。那个会的问题不在于开得久，而在于它只产出了一个“通过”的结论，没有产出共识、边界和退出条件。九票赞成之后，十一个人各自带着不同的理解离开了会议室。

如果让我用一句话概括这整套制度设计的核心，那就是：好的立项制度，不是让项目更容易被批准，而是让“不该做的项目”更容易被拒绝，让“该停的项目”更容易被停下。大多数团队的制度只做了前一半，甚至只做了批准这一件事。

另一个我想强调的判断是：不要试图一次性设计出完美制度。立项制度的成熟度是长出来的，不是设计出来的。先测量旧状态，再定最小可行的分级规则，选两个团队试点，用 90 天看数据，然后调整。这个过程里最重要的不是规则本身，而是团队是否真的开始在被要求表达判断。

下一步我建议你做三件具体的事。第一，翻出最近半年的项目清单，统计一下真实来源分布，看看有多少项目在进入流程之前就已经被决定了。第二，找三个正在进行中的项目，问负责人同一个问题：“什么情况下你会停掉这个项目？”如果答不上来，就从补退出条件开始。第三，把立项模板砍到五个字段，如果砍完之后发现信息不够用，再逐个加回来，但要为每个增加的字段说明它帮助了哪个决策。

这三件事花不了一周，但它们会把立项从一次仪式变成一次真正的判断。