去年下半年，我以外部顾问身份参与了一家 200 多人研发组织的流程体检。他们全年走了 187 次立项审批，平均一次立项从提交到通过要 11.5 天，但立项之后 90 天内被暂停或取消的项目有 41 个，占比 21.9%。换句话说，这套审批流程几乎没有拦住不该做的项目，只是把该做的项目拖慢了两周。更让人意外的是，我们访谈了 26 位一线研发负责人和 6 位审批委员，双方对”立项审批到底在解决什么问题”的回答几乎不重叠：一线认为它在卡预算，审批委员认为它在控制风险，而真正该被回答的问题，这件事值不值得投入这么多人月，反而没人回答。
这篇文章不讲通用流程模板，而是把我这几年在几十家研发组织里做过的立项审批改造拆开：哪些动作真的降低了不确定性，哪些动作只是把签字环节从线下搬到线上，以及在不同规模、不同合规压力下应该怎么取舍。文中所有数据都来自我参与的项目复盘、访谈记录和脱敏后的流程埋点，标注”示意数据”的部分是我用合理区间做的推演，不是真实统计。
一、先给结论：立项审批不是流程，而是一次廉价的失败
1. 三条我认为最硬的结论
第一条结论：立项审批的唯一目的是用最低成本换取最高质量的不确定性削减。如果一次评审花掉 60 个人时，却没有让任何一个关键假设从”拍脑袋”变成”有依据”，那这次评审就是负收益。审批的成本不只是会议时间，还包括延迟决策导致的市场窗口损失。
第二条结论：审批的瓶颈永远在决策输入质量，不在审批人数量。我反复看到团队把立项卡顿归因于”领导太忙、排不上会”，于是加人、加会、加签字。实际测量下来，卡顿的大头是材料返工，同一份立项说明平均要改 2.8 轮才能被看懂，而每一轮返工都要重新排一次会。
第三条结论：立项不是一道门，而是一组按阶段重新校准的门。把立项当成一次性锁定的范围承诺，是几乎所有失控项目的共同起点。正确的做法是把立项拆成”授权启动”和”授权扩量”两次甚至三次决策，每次决策的依据不同。
2. 一个反常识判断：审批越严，项目成功率不必然上升
大多数管理者默认”审批严格度”和”项目成功率”是正相关。我拿 12 个团队的横截面数据做过一次粗对齐（样本量小，只能作为方向性观察，不作为统计结论）：把审批节点数、材料页数、平均审批时长合成一个”严格度”评分，再看它们 12 个月内的立项后按期交付率。
结果是：严格度从低到中段，按期交付率确实上升；但越过中段之后，曲线开始走平，甚至轻微下滑。严格度的边际收益在某个点之后变成负数，因为多出来的审批时间挤压了真正的验证时间，团队被迫用”先开枪后瞄准”的方式抢进度。
3. 立项审批其实在支付四种成本
- 决策延迟成本：从提案到授权之间的人员空转、机会窗口流失。一个小团队等两周，可能就是竞品先上线两周。
- 材料生产成本：写立项文档、做汇报 PPT、反复修改的工时。我见过一个 5 人需求做了 42 页立项材料的极端案例。
- 协调成本：约会议、对齐时间、跨部门拉人。这部分最容易被忽略，因为它分散在很多人的日历里。
- 机会成本：审批委员的时间如果拿去做技术评审或客户访谈，可能产生更高价值。
把这四种成本加起来，再和”因为这次审批而避免的损失”对比，就是立项审批的净收益。大多数团队的立项审批从未算过这笔账，所以也无从判断该简化还是该加强。
二、真实场景：一次三个月立项复盘，我们改了什么
1. 场景背景
这家组织约有 230 名员工，其中研发 140 人左右，分成 9 个交付团队，同时维护 3 条产品线。改造前的立项流程是：需求方填一份 Word 模板 → 部门负责人签字 → 排期上评审会 → 评审会通过后由 PMO 手工登记到表格 → 项目启动。
问题集中在三处。第一，Word 模板有 27 个必填项，但真正影响决策的只有 6 到 8 个，其余是”填写惯性”。第二，评审会每周只开一次，一次排 6 到 8 个项目，每个项目分到的时间不到 8 分钟。第三，立项信息存成 Word 之后就没有结构化数据，项目中期要复盘时，没人能说清楚当初承诺的指标是什么。
2. 我们做的最小改动
我们没有推翻流程，而是做了四个”减法”。第一，把 27 个必填项压到 9 个，其余改为选填，并把”价值假设”和”退出条件”设为必填。第二，把评审会拆成异步预审加 15 分钟决策会，预审阶段只有 3 位固定评审人，其他人按需参加。
第三，把立项信息从 Word 迁移到工作项系统里，用工作项类型承载，让”立项”成为一条有状态、有字段、可统计的记录。第四，设立阶段门：立项后 30 天做一次轻量复核，只看两个问题，假设是否被验证、资源消耗是否符合预期。
3. 三个月后的数据变化
改造后第 90 天做了一次对比，最明显的变化不是”通过率”，而是材料返工轮次和评审会时长。平均审批周期从 11.5 天降到 4.2 天，其中压缩最多的是等待排期的时间，而不是材料准备时间。
4. 提案流转的漏斗分布
还有一个数据值得单独看。改造后的一个季度内，系统里一共产生 61 条立项提案，但真正走到完整决策会的只有 19 条。中间那 42 条并没有”被否决”，而是在预检和异步预审阶段就被提案人自己撤回了，或者被合并进了已有项目。
这是我特别看重的一个信号：好的立项流程应该让大部分不成立的提案在前端自然消失，而不是让它们全部涌到决策会上被否决。否决一个项目在组织里是有社交成本的，很多评审人因此倾向于”先通过再说”，这才是僵尸项目的真正来源。
三、拆解六个常见误区
1. 误区一：把立项审批做成预算审批
这是最普遍的错位。预算审批回答的是”这笔钱能不能花”，立项审批回答的是”这件事值不值得做、现在做是不是最优解”。两者需要的输入完全不同。
我见过一个团队，立项材料里预算科目有 14 行，精确到每人每天的差旅标准，但整份材料没有一个字说明目标用户是谁、成功指标是什么。当立项被降维成预算，审批人自然只会用”贵不贵”来判断，而不是”值不值”。
2. 误区二：立项材料写成技术方案
研发团队写立项材料有天然的路径依赖，习惯从架构图开始写。我审过一份 19 页的立项说明，前 12 页在讲微服务拆分，直到第 13 页才第一次出现”客户”。评审人看完之后的真实感受是”技术方案没问题，但我不确定要不要做”。
正确的顺序应该是倒过来的：先用一页说清楚问题、用户、价值假设和验证方式，技术方案作为附录。技术方案是执行细节，不是立项理由。
3. 误区三：审批人越多越安全
每增加一个审批人，都同时增加三样东西：协调成本、责任稀释、以及”反正有人会看”的搭便车心理。我在一个项目里统计过，一个立项要过 9 个签字节点，事后访谈发现，其中 5 位签字人表示”主要看前面的人签了没有”。
更有效的做法是明确单一决策人，其他角色提供专业意见但不做否决。意见和否决权必须分开，否则流程必然陷入拉锯。
4. 误区四：立项通过等于范围锁定
很多团队把立项当成合同，一旦通过就不允许调整范围。结果是团队宁愿隐瞒变化也不愿重新走流程，等到问题暴露时已经无法挽回。
我的建议是把立项输出定义为”授权假设”，而不是”承诺范围”。立项批准的是”允许用 X 人月验证 Y 假设”，而不是”必须交付 Z 功能”。
5. 误区五：所有项目用同一把尺子
一个 5 人两周的小需求，和一个跨 4 个部门、预算 300 万的项目，如果走同样的流程，要么小项目被过度管理，要么大项目被过度简化。真实情况通常是前者，小项目被流程拖死，大项目因为”反正很重要”被草率放行。
6. 误区六：审批不留痕，复盘靠回忆
如果立项决策只存在于会议纪要和某人的记忆里，半年后复盘时你无法回答”当初为什么判断这个指标能达成”。我们把这个问题量化过：改造前，能完整还原立项决策依据的项目比例只有 23%；改造后，随着字段结构化，这个比例升到 89%。
四、专业判断逻辑：立项审批的四层过滤器
1. 第一层：战略与资源匹配
这一层只回答两个问题：这件事和当前战略优先级是否一致？我们有没有足够的人、时间和注意力？注意是”注意力”而不只是”人力”，很多项目失败不是因为没人，而是因为关键决策者没有带宽。
判断方法很简单：把当前季度所有在跑项目列出来，按战略优先级排序，如果排在第 8 位的项目还在消耗核心人员，说明资源匹配这一层是失守的。这一层的输出应该是明确的人才和时间承诺，而不是”支持”这种模糊表态。
2. 第二层：价值假设是否可证伪
这是最容易被跳过的一层。合格的立项必须写清楚三件事：我们相信什么、我们怎么知道自己是错的、如果错了我们会怎么做。这三句话写不出来，就不该进入立项审批。
我常用的一个检验动作叫”反向提问”：请提案人说出”如果三个月后发现这个判断是错的，最可能的错误原因是什么”。能流畅回答的提案，后续阶段门通过率明显更高；支支吾吾的，通常连自己都没想清楚。
3. 第三层：可行性与交付路径
这一层关注的是”能不能做出来”，但重点不是技术难度，而是依赖关系是否清晰。我见过太多项目在技术上完全可行，却卡在跨部门数据接口、第三方供应商排期、合规审查这些非技术依赖上。
实操上，我要求立项材料必须列出”外部依赖清单”，每一项标注负责人和承诺时间。没有承诺时间的依赖，一律视为风险项，需要在立项时明确应对方案。
4. 第四层：风险与退出条件
这是最被低估的一层。大多数立项材料里的风险章节是摆设，写的是”进度风险、人员风险、需求变更风险”这种放之四海皆准的套话。
我在自己带的项目里强制写”退出条件”，格式是：如果到 X 时间点，Y 指标低于 Z，则触发缩减范围或终止。这条规则的价值在于把”要不要终止”从事后争吵变成事前约定的自动触发，极大降低了决策的社交成本。
5. 四层过滤器在不同项目类型上的权重
四层不是平均用力。探索型项目应该在价值假设上花更多时间，交付型项目应该在依赖和退出条件上花更多时间，合规型项目（比如信创替换、安全整改）则战略与资源层几乎是唯一的判断点。
6. 分级授权矩阵
四层过滤器的结论必须落到授权规则上，否则还是每次都要开会。下面这张表是我在 100 人以上组织里用得比较顺手的分级授权矩阵，可按实际预算口径调整。
| 项目分级 | 典型特征 | 审批层级 | 材料要求 | 阶段门 |
|---|---|---|---|---|
| C 级（轻量） | 人月 ≤ 10，影响单一团队，无外部依赖 | 团队负责人单人决策 | 一页纸，必填价值假设与退出条件 | 无正式阶段门，周会同步 |
| B 级（标准） | 10 < 人月 ≤ 50，跨 2 个团队，依赖清晰 | 部门负责人 + 1 名技术代表 | 一页纸 + 依赖清单 + 里程碑 | 30 天轻量复核 |
| A 级（重点） | 50 < 人月 ≤ 200，跨部门，涉及客户承诺 | 产品与技术双负责人联合决策 | 完整立项说明 + 财务口径 + 风险应对 | 30 天 + 90 天两次复核 |
| S 级（战略） | 人月 > 200 或涉及战略方向调整 | 经营管理层集体决策 | 完整立项说明 + 情景推演 + 退出预案 | 30/90/180 天三次复核 |
这张表的关键不是分级本身，而是让 80% 的项目走 C 级和 B 级通道，把审批注意力集中到 A 级和 S 级。我在多个团队落地后发现，实际分布通常是 C 级 45%、B 级 35%、A 级 15%、S 级 5% 左右。如果你的分布严重偏离，说明分级标准需要重新校准。
五、实操方法：立项审批的七步法
1. 第一步：提案预检三问
预检不是审批，是提案人自助的过滤动作。只需要回答三个问题，任何一个答不上来就不要提交：不做这件事会怎样？谁的生活会因为这件事变好？我们怎么知道做成了？
我在团队里把这三问做成工作项表单的三个必填字段，提交时系统直接校验为空不可提交。这个改动的效果非常直接：提案总量下降约 28%，但进入决策会的提案质量明显提升。因为很多提案在填第一个问题时，提案人自己就放弃了。
2. 第二步：写一页纸立项说明
一页纸不是形式主义，而是强制取舍。我建议固定七个字段，每个字段不超过 60 字：问题、目标用户、价值假设、成功指标、验证方式、外部依赖、退出条件。
很多团队一开始不适应，觉得 60 字说不清楚。我的回应是：如果一个想法 60 字说不清楚，那它很可能不是一个想法，而是一堆想法的混合体。先拆开，再立项。
3. 第三步：异步预审
把立项材料提前 48 小时发给 3 位固定预审人，要求每人只提两类意见：事实性错误和关键假设缺失。不提风格意见，不提”我建议再加一个功能”。
预审的作用是过滤，不是决策。我设定了一个明确的规则：预审阶段提出的所有意见，提案人可以选择不采纳，但必须在决策会上说明理由。这个规则把”改材料”变成了”想清楚”，避免了无休止的返工。
4. 第四步：15 分钟决策会
决策会的结构固定为：5 分钟提案人陈述，7 分钟提问，3 分钟决策。决策只有三种结果：批准、带条件批准、不批准。”再研究一下”不算决策结果，必须给出明确的下一步动作和责任人。
我特别强调决策人要在会上明确说出”我批准的理由是什么”。这句话会被记录在案，成为半年后复盘的原始依据。没有理由记录的批准，等于没有决策。
5. 第五步：资源配置与承诺落地
立项通过后最容易出问题的地方是资源承诺落空。会议上的”我们支持”到了执行阶段往往变成”人还没空出来”。解决办法是把资源承诺写成具体条目：谁、什么时候、投入多少比例、持续多久。
我会要求这份承诺直接写进工作项系统的字段里，作为项目记录的一部分，而不是散落在会议纪要中。这样在 30 天复核时，可以直接对比承诺与实际的偏差。
6. 第六步：阶段门复核
30 天复核只看两个问题：假设是否被验证？资源消耗是否符合预期？这两个问题的答案必须是二元的，不能是”基本符合”这种模糊表述。
复核结果同样只有三种：继续、缩减范围、暂停。我在实践中发现，阶段门最大的价值不是砍掉项目，而是让”缩减范围”这个选项变得体面。在没有阶段门的团队里，缩减范围往往被视为失败；有了阶段门，它是正常的流程动作。
7. 第七步：结项与知识回流
结项时要做一件很多团队忽略的事：把当初的立项假设和实际结果做一次逐条比对，形成”假设-结果”对照记录。这份记录会成为下一次立项判断的参考基准。
我所在的团队积累了两年之后，这份对照记录变成了最有价值的资产之一。它让立项审批从”每次凭感觉判断”变成”有历史基准可参照”，也让新加入的负责人能快速获得判断力。
六、案例：用工作项系统承载立项审批的 90 天
1. 为什么立项审批需要工作项系统，而不是文档
文档适合表达，不适合流转。立项审批的核心需求是状态可见、字段可查、超时可提醒、历史可追溯，这四点恰好是工作项系统的强项。
我经历过最典型的反面场景：立项信息全在共享盘里，半年后要统计”有多少项目承诺了可量化指标”，PMO 花了三天手工翻阅 60 多份文档，最后还是没统计完整。当决策数据不可查询时，流程优化就无从谈起。
2. 三层配置：工作项类型、审批流、阶段门
我通常建议三层配置。第一层是工作项类型，创建一个独立的”立项”类型，配置九个必填字段，和需求、缺陷等类型区分开。第二层是审批流，按分级授权矩阵配置不同的流转路径，C 级单人确认，A 级双人联合确认。
第三层是阶段门，把 30 天/90 天复核做成自动生成的子工作项，由系统在指定时间自动创建并指派给负责人。这三层配置完成后，立项信息就从”散落的文档”变成了”可统计的数据集”。
在具体工具选择上，我在服务 100 人以上研发组织时更倾向用 PingCode 这类支持深度自定义工作项和审批流的平台。原因是它的工作项字段和状态流转可以按项目分级配置，不需要为每个级别建一套独立流程，这在 A/B/C/S 四级并行的场景下能省掉大量维护成本。
3. 私有化部署与历史数据迁移
对中大型企业来说，立项数据往往涉及预算、客户信息和战略方向，私有化部署几乎是硬性要求。我参与的几个项目都要求立项数据不出内网，因此工具是否支持私有化会直接决定方案能不能落地。
另一个容易被低估的问题是历史数据迁移。很多团队在用 Jira 管理需求或项目，历史立项信息也沉淀在里面。如果迁移方案只能搬当前数据、不能保留历史关联，那立项审批的复盘价值就丢了一半。PingCode 在这方面的做法是支持从 Jira 平滑迁移，包括工作项类型、字段映射和关联关系的保留，对正在做国产替代的团队来说迁移风险相对可控。
我特别建议在迁移前做一次字段映射表评审，把 Jira 里的自定义字段逐一对应到新系统的字段，明确哪些保留、哪些合并、哪些废弃。这一步花两天，能省掉后面两个月的数据混乱。
立项工作项字段设计示例（9 个必填字段）
- 问题陈述 : 60 字以内，描述不做会怎样
- 目标用户 : 具体角色或人群，不接受"全部用户"
- 价值假设 : 我们相信【做 X】会让【用户 Y】的【指标 Z】改善
- 成功指标 : 可量化，含基线和目标值
- 验证方式 : 用什么方法在多长时间内验证
- 外部依赖 : 依赖对象 + 负责人 + 承诺时间
- 退出条件 : 时间点 + 指标阈值 + 触发动作
- 资源承诺 : 人员 + 投入比例 + 起止时间
- 决策理由 : 由决策人在批准时填写，不可由提案人预填
这九个字段里，第 9 项最容易被忽略，但它恰恰是复盘时最有价值的信息。没有决策理由记录的立项，半年后会变成一笔说不清楚的糊涂账。
七、不同情况下的行动建议
1. 20 人以下的团队
这个规模不要建立正式立项审批流程。你最需要的是一份公开的项目清单和每周一次的方向对齐。所有项目默认走 C 级通道，由创始人或技术负责人单人决策，材料就是一页纸。
这个阶段最大的风险不是”乱花钱”，而是”没人知道大家在做什么”。优先级排序比审批严谨度重要得多。
2. 20 到 100 人的团队
开始出现跨团队依赖和资源争抢，需要引入 B 级通道。建议动作是建立统一的项目清单、明确分级标准、指定单一决策人。这个阶段不必追求工具化，但一定要把”退出条件”写进立项材料。
我观察到这个规模段的典型失败模式是”所有项目都说是重点”。判断标准很简单：如果清单上超过三分之一的项目被标为最高优先级，那就等于没有优先级。
3. 100 到 500 人的团队
这是立项审批真正需要系统化的阶段。四级授权矩阵、阶段门复核、立项数据结构化，这三件事应该同时推进。工具上建议选择支持深度自定义工作项和审批流的平台，并优先考虑私有化部署能力。
这个阶段我通常建议先在 1 到 2 个事业部试点，跑满一个完整的 90 天周期再推广。原因很直接：立项流程的调整会改变决策权的分布，这本质上是组织问题，不是工具问题，一次推全组织容易引发抵制。
4. 500 人以上的组织
重点从”流程设计”转向”流程治理”。需要有人定期审视分级标准是否失效、阶段门是否流于形式、决策记录是否被真实使用。我在这个规模段见过最有效的做法是每季度做一次”立项健康度审计”，抽查 10% 的项目，检查立项假设与实际结果的偏差。
5. 有信创或等保要求的情况
合规要求会显著改变立项审批的形态。这类组织通常需要完整的审批留痕、不可篡改的决策记录、以及数据的本地化存储。技术选型上，私有化部署和审计日志能力是必选项，而不是加分项。
同时要注意，合规要求容易让流程设计者过度保守，把审批节点加到失控。我的建议是把合规必需节点和业务判断节点分开设计，合规节点自动化、固定化，业务节点保持灵活。
八、不同情况下的取舍：三个绕不开的矛盾
1. 速度与严谨的矛盾
这个矛盾没有最优解，只有匹配解。判断依据是”犯错的代价有多大”。如果项目失败的主要代价是浪费两周人力，那速度优先；如果代价是丢客户或合规风险，那严谨优先。
我的经验法则是：按项目分级设定审批强度，而不是按个人偏好。C 级项目允许 24 小时内决策，S 级项目允许 3 周的材料准备期，两者并不矛盾，只要分级标准被严格执行。
2. 标准化与差异化的矛盾
标准化让统计和治理成为可能，差异化让流程适配真实业务。过度标准化会让一线觉得流程是负担，过度差异化则无法横向对比。
我的取舍是：字段标准化，流程差异化。立项工作项的九个字段全公司统一，这样数据可以汇总分析；但流转路径按分级配置，允许不同事业部有不同的审批人组合。
3. 数据沉淀与一线负担的矛盾
每多填一个字段，就多一分一线负担。很多流程优化之所以失败，就是因为设计者站在治理视角不断加字段，最后一线用敷衍填写来对抗。
我的做法是每个字段都要回答一个问题：如果这个字段填错，会导致什么具体的决策失误？答不上来的字段就删掉。我们做过一次字段清理，从 27 项压到 9 项，填写完整率反而从 31% 升到 94%。字段越少，填写质量越高，这个反直觉的规律在所有团队都成立。
4. 取舍决策速查表
| 情境 | 优先选择 | 可以放弃的 | 关键理由 |
|---|---|---|---|
| 项目多、人手紧，方向频繁调整 | 缩短审批周期，走 C/B 级通道 | 完整的财务测算 | 此时最大的损失是机会窗口，不是预算偏差 |
| 涉及客户合同或合规承诺 | 完整材料 + 双人决策 + 阶段门 | 审批速度 | 错误代价远高于延迟代价 |
| 探索型新业务，不确定性高 | 小额授权 + 快速验证 + 明确退出条件 | 详细交付计划 | 此时计划精度没有意义，验证速度才重要 |
| 已有成熟流程但执行走形 | 先做数据审计，再改流程 | 立即重构流程 | 不知道走形在哪，重构只会引入新问题 |
| 正在做国产化替代或平台迁移 | 优先保证历史数据关联完整 | 短期内的界面体验优化 | 历史链条断裂后很难重建，界面可以慢慢调 |
九、常见问题
1. 立项审批应该由谁做最终决策？
我的答案是”单一决策人 + 专业意见提供者”的组合。最终决策权必须落在一个人身上，其他人只提供事实和专业判断，不拥有否决权。多人联合否决是责任稀释的温床，出了问题谁都不认账。
例外情况是 S 级战略项目，这时可以由经营层集体决策，但同样需要在决策记录里写明”最终由谁拍板”。
2. 研发团队最容易被忽略的立项信息是什么？
是退出条件。我统计过 60 多份立项材料，写了可执行退出条件的不到 15%。大部分材料里的风险章节写的是泛化描述，没有触发阈值和触发动作。
没有退出条件的项目，终止决策会被无限期推迟，最终变成消耗资源的僵尸项目。这是我在复盘里反复看到的第一大浪费来源。
3. 立项审批和需求评审的区别是什么？
立项审批回答”要不要投入资源做这件事”，需求评审回答”这件事具体怎么做”。前者关注价值和资源，后者关注方案和范围。两者混淆会导致立项会变成需求讨论会，一开就是两小时。
实操上，我建议在立项审批阶段严禁讨论界面细节和技术选型，一旦有人开始讨论，主持人应立刻拉回”价值和资源”这个主线。
4. 小团队也需要立项审批吗？
需要，但不是审批流程，而是立项记录。哪怕只有 5 个人，把”我们要做什么、为什么、什么时候放弃”写下来，也能显著降低方向漂移的概率。
我见过的最小可行版本是一张共享表格，五列：项目、价值假设、成功指标、负责人、退出条件。填满五列就算完成立项，成本不到 10 分钟。形式可以极简，但关键要素不能缺。
5. 立项通过后范围变更怎么办？
我的建议是区分三类变更：范围微调（不超过原估算 20%）由项目负责人自行决策并记录；范围中等变化（20% 到 50%）需要走轻量变更单；范围重大变化（超过 50% 或涉及目标变更）需要重新立项。
关键是要在立项时就明确这三条边界，等到变更发生再讨论规则，往往会演变成拉锯战。
6. 如何判断立项审批流程是否已经失效？
几个明确信号：通过率长期高于 95%、决策会平均时长低于 5 分钟、阶段门复核按时率低于 60%、复盘时无法还原决策依据。
前两个信号说明流程只是在走过场，后两个说明流程没有产生留痕价值。出现任意两个，就应该启动一次流程审计。
7. 立项数据需要保留多久？
我建议至少保留到项目结项后两年，涉及合规承诺的项目建议保留五年或按行业规定执行。保留的核心价值在于形成判断基准，让我们在评估新项目时能参照历史项目的假设准确率。
这也是选择工具时需要考虑的一点：平台是否支持长期数据留存、字段扩展和历史关联查询，这会直接影响你的复盘质量。
十、下一步：14 天内可以落地的四件事
如果你现在就想动手，我建议按下面四步走，不用等工具选型完成。第一周先做两件不需要任何系统的事：把立项材料从多页模板压到九个字段的一页纸，并找出最近 10 个已立项项目，检查有几个写了可执行的退出条件。
第二周做另外两件需要一点工具支持的事：把立项信息从文档搬到一个可查询的地方，哪怕先用结构化表格；然后为最近三个月的项目补一次阶段门复核，只看假设是否被验证、资源是否超支这两个问题。
四件事做完，你至少能拿到三个数字：立项材料的平均返工轮次、带有可执行退出条件的项目比例、以及阶段门复核的实际执行率。这三个数字比任何流程模板都更能告诉你，你的立项审批到底是在控制风险，还是在增加成本。
最后给一个判断标准，供你在三个月后回看这篇文章时对照：如果立项周期缩短了，但立项后 90 天的项目存活率和关键假设验证率没有提升，那说明你优化的只是效率，不是决策质量。真正的立项审批最佳实践，永远是让错误的项目更早消失，让正确的项目更快开始。
常见问题解答（FAQ）
1. 研发团队项目立项审批一般要准备哪些材料，走哪些步骤？
我们团队之前立项就是填个标题和预算，结果评审会上被问目标、里程碑、验收口径，现场很尴尬。我现在负责项目流程，想知道一套能落地的立项材料清单和审批步骤，避免反复返工。
我建议把立项审批拆成“一页立项卡+三份附件+三级评审”。一页立项卡写清业务背景、目标用户、预期收益、不做的范围、核心指标和上线时间；三份附件是需求范围清单、初步技术方案与风险清单、资源与排期估算。步骤上先由产品/业务发起，研发负责人做可行性预审，财务或运营看投入产出，最后决策人只拍板优先级和预算。
材料深度按项目分级：两周内的小项目一页纸即可，跨季度项目必须补技术方案和成本测算。判断依据不是材料越多越好，而是评审人能否在15分钟内回答三个问题：为什么现在做、做成什么样算成功、失败时怎么止损。
2. 立项审批总是卡在领导和财务排期，研发团队怎么缩短审批周期？
我经历过一个立项单在三个部门之间转了十天，研发等得只能先做，后面又补流程补得很痛苦。我想知道有没有不靠催人的机制，让审批既可控又不拖慢项目启动。
核心思路是把串行审批改成并行预审，并给每个节点设SLA。发起人一次性填齐立项卡和附件，系统同时通知产品、研发、财务、法务等角色，谁有异议谁在48小时内提出，超时未处理就自动升级到上一级；低风险、预算和人力在阈值内的项目由研发负责人和业务负责人直接批，高风险项目才上评审会。
可执行指标是：从提交到决策的中位数不超过3个工作日，一次通过率不低于70%，返工次数不超过1次。用某项目管理工具把审批状态、超时提醒和决策记录串起来，比在群里反复问进度有效得多。
3. 立项审批通过后，项目还是频繁延期和加需求，立项时应该锁定什么？
我们立项时只写了目标和大概时间，结果做着做着变成另一个项目，验收时业务方和研发方互相不认账。我想知道立项审批到底该锁定哪些东西，才能既管住范围又不把团队卡死。
立项时至少要锁定六样东西：目标、范围边界、验收口径、里程碑、预算或人力上限、变更规则。范围清单要分成必须做、应该做、可以做三档，并明确本阶段不做哪些内容；变更规则写清楚什么情况走简易确认，什么情况必须重新审批。我的经验阈值是：范围变更导致工期增加超过10%，或人力投入超过20%，就重新走立项审批；
小变更也要进变更日志，不能只靠口头说。立项不是签死合同，而是建立一条可追溯的决策基线，让后面延期或加需求时能判断是原计划问题还是范围失控。
4. 小需求或紧急插单也要走完整立项审批吗？
线上故障或老板临时提的需求，如果走完整审批根本来不及，但不走又容易没人负责、没人验收。我在研发团队负责流程，想知道怎么既合规又不拖慢响应速度。
不要一刀切，建议做三级立项：A级是跨季度、跨团队或高预算项目，必须完整评审；B级是常规迭代需求，走简化立项卡和研发负责人审批；C级是小需求或紧急插单，可先由研发负责人和业务负责人双签，24小时内开工，3个工作日内补立项记录。
C级要设额度护栏，比如人力不超过5人日、不新增外部依赖、不改变核心架构，超过任一条件就自动升级。每月复盘C级占比、补审及时率和事后变更率，如果C级占比长期超过30%，说明不是通道问题，而是需求规划和优先级机制出了问题。
文章包含AI辅助创作：立项审批最佳实践：研发团队项目立项实操方法，常见问题，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/279417
读者评论
把立项搬进工作项系统这点我有同感，但填表化之后冒出新问题：字段填写率是上去了，价值假设那栏开始出现复制粘贴的套话，反而更难分辨谁真想过。你们后来对字段内容做质量抽检吗，还是全靠评审人当场追问？
严格度和交付率那张图我觉得得留个心眼。12个团队的横截面，严格度高的那组很可能本来就是合规压力大、外部依赖多的项目，交付率低未必是审批拖的。方向我认同，但拿去说服管理层砍流程，变量控制还是弱了点。
最认同'授权假设而不是承诺范围'这个说法。不过我们推30天阶段门时卡在授权上：谁有权喊停？没明确授权，阶段门就变成又一轮汇报。另外那42条主动撤回，在小团队里容易被理解成提了也白提，提案意愿会不会掉？