立项流程与规范：产品经理项目立项落地方案关键指标

去年我帮一家约 300 人的研发组织复盘全年立项数据，结果有点刺眼：全年立项 47 个，评审通过 46 个，通过率 97.9%；一年后还在正常推进的只有 21 个，而主动关停的只有 2 个，剩下的 23 个全部属于”还在做，但没人说得清现在到哪一步了”。也就是说，这套立项流程的筛选力接近于零，它拦不住任何一个项目，也没有任何一个项目被体面地结束。

我把这种现象叫做立项空转：流程在跑，表单在填，评审会在开，但决策质量没有任何提升。问题不在产品经理写得不够认真，而在于大多数组织衡量立项流程的那几个指标，本身就选错了。下面这份内容，是我过去几年在几十个中大型研发组织里反复验证过的一套立项落地方案，包括指标口径、阈值、分层标准和我自己踩过的坑。

一、结论先行：立项流程的 KPI 不该是”通过率”，而是”筛选力和退出力”

1. 立项的本质是一次可撤销的资源承诺

很多团队把立项理解成”申请资源的手续”，这是错的。立项真正完成的是三件事的绑定：投资决策、资源承诺、风险定价。投资决策回答”这件事值不值得占用公司的钱和人”；资源承诺回答”谁在什么时间投入多少”；风险定价回答”如果判断错了，我们损失多少、什么时候能发现”。

这三件事里最容易被忽略的是第三件。一个立项流程如果只教人怎么”论证值得做”，却从不定义”什么情况下必须停”，那它本质上是一个放大器，会把错误的判断放大成不可逆的投入。所以我在设计任何立项规范时，第一句写的都不是”通过标准”，而是”退出条件”。

2. 真正需要盯的六个关键指标

立项流程的指标体系应该分成四层，但真正需要每周看、每月复盘的只有六个。它们的共同特点是：都能被决策改变，而不是只用来描述现状。下面这张表是我在多个组织里调过的口径和阈值。

注意最后两项，它们经常被忽略，但恰恰是流程效率的隐形黑洞。我见过一个组织，每个立项平均消耗 4.2 个评审人天，一年 60 个项目，光立项环节就烧掉 250 多人天，而立项后范围变更率仍然高达 43%。

3. 指标分层：别把过程指标当成结果指标用

立项指标最容易犯的错误，是把不同层的指标混在一个看板里对比。我把它们分成四层：过程指标（周期、人天、评审次数）、质量指标（一次通过率、论证完整度）、结果指标（立项后 30/90 天变更率、上线达成率）、反指标（通过率、关停率）。

反指标的用法很特别：通过率越高，越可能是流程失效的信号。当通过率长期高于 95%，你基本可以确定这个评审会只是形式，真正的筛选发生在别处，或者根本没发生。同理，关停率接近零，不是执行坚定的证明，而是纠错机制缺席的证据。

4. 一句话记法：立项流程只管三件事，敢问、敢否、敢停

敢问，是指立项材料必须回答”如果不做会怎样”；敢否，是指评审会必须有一定比例的否决，而不是全部通过；敢停，是指立项后存在明确的终止触发条件。这三件事对应三个可观测指标：论证完整度、否决率、主动关停率。任何一个长期为零，流程就是装饰。

二、真实场景：我见过的三种立项现场

1. 场景 A：三天评审 40 个项目，通过率 98%

这是一家约 1200 人的企业，年度立项评审会开了三天，每天从早到晚排满，平均每个项目 22 分钟。我作为外部顾问旁听了全程，记录下来的实际内容分布是：项目陈述 12 分钟，提问 5 分钟，讨论 3 分钟，结论 2 分钟。

三天的结果是 40 个项目通过 39 个。唯一被否掉的那个，是因为预算表里的小数点写错了。这个场景的荒诞之处不在于通过率高，而在于没有任何一个项目因为”不值得做”被否掉。评审会真正做的事情是资源分配顺序，而不是价值筛选。

2. 场景 B：28 页立项书，决策人只看了前 3 页

我做过一个小样本观测：收集 12 份被实际评审的立项文档，让评审人在阅读时做标记，记录停留时长分布。结果非常一致，决策人的注意力高度集中在前 3 页，也就是问题定义、目标指标、资源需求这三块。后面的竞品分析、技术方案、里程碑排期，平均停留时长不到总阅读时间的 25%，而它们占用了约 70% 的篇幅。

这个观察改变了我对模板的理解：立项文档不是写得越全越好，而是把决策必需的信息压进前 3 页，后面作为附录按需展开。模板的价值在于信息前置，不在于信息堆砌。

3. 场景 C：立项之后，没人敢停

第三家组织的情况更典型。他们的立项流程其实做得不错，评审严格、材料规范，但立项后没有任何复盘机制。我抽查了 18 个立项超过 9 个月的项目，其中 7 个已经明显不具备继续投入的价值，但仍在正常占用人力。

问负责人为什么不叫停，回答几乎一样：“当初是领导批的，现在停，等于承认当初批错了。”这说明问题不在流程设计，而在流程缺少一个能让人体面退出的机制。立项规范里如果没有”退出条件”和”复盘节点”，所有的严格评审最终都会变成沉没成本的保护伞。

三、七个常见误区，我几乎在每个组织都见过

1. 误区一：用通过率证明流程有效

这是最根深蒂固的一个。很多流程负责人会汇报”今年立项通过率 96%，说明流程运行顺畅”。这个逻辑是反的。通过率是筛选力的反向指标：一个能筛选的流程，一定会有一定比例的否决。合理的否决率区间我通常建议在 15%-30%，低于 5% 就要警惕形式化。

更深一层的问题是：被否掉的项目去哪了？如果否决即终结，那它其实不是真正的筛选，而是消耗了提出者的积极性。健康的做法是给出”重做路径”，补充哪三个证据后可以再提。

2. 误区二：把文档厚度当严谨度

我见过最夸张的一份立项书有 68 页，包含完整的市场调研、技术选型对比和三年财务模型。结果是它顺利通过，三个月后无人再提。厚文档的真正作用，往往是提高写作门槛，从而减少立项数量，这是一种低效的过滤方式，因为它过滤掉的是”没时间写”的项目，而不是”不值得做”的项目。

我的判断是：立项文档控制在 L1 层级 6-10 页、L2 层级 12-15 页比较合理。超过 20 页的部分，应该拆成按需查看的附件，而不是塞进主文档。

3. 误区三：只定义入口，不定义出口

几乎所有立项规范都在写”需要提交什么材料、经过几级审批”，极少有规范写”什么条件下必须停止投入”。这是结构性缺失。没有退出条件的立项流程，等于没有风险定价，因为所有风险都被默认转化成”继续投入”。

我在规范里会强制要求每一项立项填写三个字段：终止触发条件、复盘节点日期、复盘责任人。这三个字段如果填不出来，立项本身就不成立。

4. 误区四：所有项目走同一套流程

一个 3 人两周能验证的小需求，和一个预计投入 30 人月、跨三个部门的大项目，走同一套评审流程，结果是前者被流程拖死，后者被流程放水。分层立项不是官僚主义的对立面，恰恰是反对一刀切官僚主义的手段。

我建议按投入规模、不可逆程度、跨部门复杂度三个维度打分，落入 L0、L1、L2 三个层级，各层级对应不同的材料深度、评审层级和审批权限。这一点在第四章会展开。

5. 误区五：业务方和研发方对”成功”的定义不一致

我见过一个项目，业务方认为成功是”三个月内上线并覆盖 5000 名用户”，研发方理解的成功是”核心功能按需求文档交付”。项目上线后覆盖了 3200 名用户，双方都觉得自己完成了任务，但都认为项目失败。

根源在于立项文档里只有一个模糊的”项目目标”，没有把成功指标拆成业务指标、交付指标和过程指标三份，并明确各自的责任人。立项评审时，这三份指标必须分开签署确认，否则后续扯皮是必然的。

6. 误区六：把立项会开成资源分配会

立项评审会一旦变成抢人力的战场，讨论就会从”这件事值不值得做”滑向”凭什么先给你资源”。我观察到的规律是：当评审名单里超过一半是资源提供方时，会议一定会转向资源博弈。合理的评审名单里，业务决策人和价值判断者应该占多数，资源方占少数但拥有明确的追问权。

7. 误区七：指标只统计，不进入决策

最后一个误区最隐蔽。很多组织其实收集了立项周期、通过率这些数据，但从不把它们和决策挂钩。数据只在季度汇报里出现一次，看完就归档。

我的做法是把指标直接写进流程规则：立项周期中位数连续两个月超过 10 天，就触发流程简化；某个负责人名下项目范围变更率连续两个季度超过 40%，就要求其立项材料增加论证强度。指标一旦和规则绑定，它才会被真正当成决策依据。

四、专业判断逻辑：三关、五问、分层与评分卡

1. 第一关：问题真实性，这件事真的存在吗

立项最容易注水的地方是问题描述。我要求所有立项材料里的问题陈述必须包含三类证据中的至少两类：行为数据（用户实际的行为记录，不是问卷意愿）、成本数据（当前问题造成的可量化损失）、外部证据（客户明确承诺、合同条款、监管要求）。

三类都不具备的立项，我倾向于直接压到 L0 层级，允许用两周时间做小规模验证，验证通过再升级立项。这样做的好处是，把”证明问题存在”的成本从评审环节转移到了验证环节，而后者成本低得多。

2. 第二关：方案必要性，为什么是现在、为什么是这个方案

这一关的核心是反对”唯一方案谬误”。很多立项材料直接给出一个方案，然后论证它的可行性，却从不说明为什么不做别的方案。我会要求至少列出两个备选方案，并说明不选它们的具体理由以及”什么都不做”的后果。

特别是”什么都不做”这一项，最常被跳过，但它恰恰是判断紧迫性的关键。如果什么都不做的后果可以接受，那这个项目很可能应该延后，而不是现在抢资源。

3. 第三关：资源可行性，不是有没有，而是愿不愿意给

资源可行性的常见问法是”需要多少人、多少时间”。但真正决定成败的问题是：这些人在这个时间段里，是不是真的能被释放出来。我见过太多立项书里写着”投入 3 名后端，6 个月”，而这 3 个人手上有 4 个在跑的项目。

我的判断方法是要求填写”资源来源”字段：这名人力来自哪个现有项目、该项目是否因此延期、延期是否已被相关方确认。这个字段一填，大部分虚假的资源可行性立刻暴露。

4. 分层立项：L0 / L1 / L2 的划分标准

分层的意义在于让流程成本和风险等级匹配。我用的划分维度有三个，每个 1-3 分，总分决定层级。

• 投入规模：1 分 = 10 人月以内；2 分 = 10-30 人月；3 分 = 30 人月以上
• 不可逆程度：1 分 = 可灰度、可回滚；2 分 = 部分不可逆（数据迁移、对外承诺）；3 分 = 高度不可逆（合同、合规、硬件采购）
• 跨部门复杂度：1 分 = 单一团队；2 分 = 2-3 个团队；3 分 = 4 个以上团队或涉及外部方

总分为 3-4 分进入 L0，5-7 分进入 L1，8-9 分进入 L2。层级一旦确定，材料深度、评审范围、审批权限就随之确定，不再逐个讨论。这套规则的最大价值不是分类准确，而是消除每次立项都要争”该走什么流程”的沟通成本。

5. 评分卡：8 个维度、权重与阈值

评分卡不是为了算出一个精确分数，而是为了把争论从”我觉得”拉回到”哪一项证据不足”。下面是我实际在用的配置，可以直接作为模板调整。

charter_scorecard:
problem_evidence: 20 # 问题证据强度：行为数据/成本数据/外部证据

goal_measurable: 12 # 目标可衡量性：是否有基线值和目标值

alternative_analysis: 10 # 备选方案对比：至少两个备选加"不做"

resource_commitment: 15 # 资源承诺：来源明确、相关方确认

risk_and_exit: 15 # 风险与退出条件：触发条件可观测

cross_team_impact: 8 # 跨部门影响：依赖是否已对齐

reversibility: 10 # 可逆性：灰度与回滚方案

strategic_fit: 10 # 战略契合：与年度重点的对应关系

thresholds:

L0: 60 # 达到 60 分即可由团队负责人决策

L1: 72 # 达到 72 分进入部门评审

L2: 82 # 达到 82 分进入跨部门评审

reject_below: 55 # 低于 55 分直接退回补充证据，不进入评审排期

使用这套评分卡之后，一个明显变化是：被退回的项目主要不是因为分数低，而是因为某几项证据缺失。这让产品经理知道该补什么，而不是被一句”感觉不成熟”打发掉。我在一个 400 人组织里推行后，立项文档二次提交的通过率从 38% 提升到 76%。

6. 决策规则：什么情况下必须否、必须停

把规则写成”必须”，比写成”建议”有效得多。我的规范里有三条硬性否决和三条硬性停止条件。

硬性否决包括：无法给出任何一类问题证据；目标没有基线值（说”提升效率”但说不出当前是多少）；资源来源未获得相关方确认。这三条任意一条不满足，项目直接退回，不进评审排期。

硬性停止条件包括：连续两个复盘节点未达成阶段性目标；核心依赖方撤出且两周内无法补位；外部前提发生变化导致原目标失去意义。触发任意一条，项目自动进入终止评估流程，由指定的复盘责任人发起，而不是等某个领导想起来。

五、案例与数据观察：一个 300 人研发组织的立项改造

1. 改造前的基线：一个完整的失败样本

这家组织的研发团队约 300 人，分 6 个产品线，年立项量 47 个。改造前的关键数据是：立项周期中位数 14.5 天，文档平均 28 页，一次通过率 34%，立项后 30 天范围变更率 41%，主动关停率 4.3%，决策到启动间隔 11 个工作日。

更有意思的是定性观察：60% 的立项申请在提交后一周内没有任何状态变化，产品经理完全不知道卡在谁那里。这是典型的”流程黑箱”，不是流程太严，而是流程不可见。

2. 四步改造法：从流程设计到系统落地

我们没有推翻原有流程，而是做了四件事，每件事都对应一个可观测指标。

1. 数据前置：把立项必需的行为数据和基线数据做成常备看板，产品经理不需要临时找数，直接引用。
2. 模板瘦身与信息前置：主文档从 28 页压到 9 页，问题定义、目标指标、资源需求、退出条件这四块必须在前 3 页，技术细节移入附件。
3. 分级评审与固定窗口：L0 由团队负责人 48 小时内决策；L1 每周三固定评审窗口，一小时处理 4 个项目；L2 双周一次跨部门评审。
4. 退出机制落地：每个项目强制填写终止触发条件和复盘节点，复盘由系统在节点自动提醒责任人发起。

第三件事的效果超出了我的预期。固定评审窗口的做法，把”等档期”这个最大的不确定性变量直接消除了。产品经理知道材料要在周二下班前提交，评审人在周三上午固定空出这一小时，双方的协调成本降到了接近零。

3. 十二个月后的数据结果

主动关停率从 4.3% 上升到 19.1%，这是整个改造里我最看重的一项。它意味着组织终于允许项目被体面地结束。关停率上升不是失败率上升，而是纠错速度上升，被关停的 9 个项目平均在立项后 4.2 个月终止，而改造前积压的僵尸项目平均已经持续 11 个月以上。

4. 工具在其中的作用与边界

流程设计完之后，落地环节必须靠系统承载，否则规范会在三个月内退化成文档。这家组织在选型阶段有三条硬门槛：能不能私有化部署、能不能从既有研发工具平滑迁移、数据留在谁手里。作为服务中大型企业的研发管理平台，PingCode 在这三点上都比较匹配：支持私有化部署，对数据敏感的中大型组织可以直接把立项数据留在自己的机房；支持从 Jira 平滑迁移，存量工作项、字段和流程配置可以按映射关系平移，减少切换期的一次性成本。

对于以国产替代为目标的组织，这类平滑迁移能力往往比功能列表本身更关键。

PingCode 主要服务中大型企业及 100 人以上组织，这一点在实际使用中能明显感觉到，权限模型、项目集管理、跨团队依赖这些能力比较完整，但对二三十人的小团队来说会显得偏重。这是我给出的选型判断里很重要的一条：工具和流程都要和组织规模匹配，能力过剩和流程过重一样是负担。

同时必须说清楚边界：平台解决的是流程可见性、状态一致性和数据沉淀，它解决不了”该不该做这个项目”的判断问题。工具能让你看见僵尸项目，但叫停它仍然需要制度授权。我在复盘时反复强调，改造成功的 70% 来自评分卡和退出机制，30% 来自系统承载。

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

1. 30 人以下：只留两页纸和一条退出规则

这个规模的团队不需要立项委员会。我建议只保留一份两页文档：一页写问题、目标、指标、资源，另一页写两周一次的目标复盘。审批由创始人和技术负责人共同完成，原则上 24 小时内给结论。

唯一需要坚持的是退出规则：每个项目立项时必须写清”什么情况下我们会放弃”。这条规则在小团队里成本几乎为零，但能避免最常见的”小项目慢慢拖成大包袱”。

2. 30-100 人：建立 L0/L1 两层和固定评审窗口

这个阶段的关键动作是把流程从”随时评审”改为”固定窗口评审”。每周固定一小时，只处理 L1 项目，L0 项目由团队自行决策并备案。同时开始记录立项周期和变更率两项数据，先跑三个月再调阈值。

我在这个规模的组织里最常看到的问题是”每个人都是评审人”，结果是没人真正负责。建议明确一个项目价值判断人，他的意见占决策权重的 50% 以上。

3. 100-500 人：引入完整评分卡和分层立项

进入这个规模后，立项的主要矛盾从”效率”转向”一致性”。不同产品线对”合格立项”的理解开始分化，需要用评分卡把标准固化下来。L0/L1/L2 三层同时启用，L2 设跨部门评审。

这个阶段也是把流程放进系统的合适时机。流程靠人维护的极限大约是 50 个并发项目，超过之后必然出现状态不同步。需要私有化部署或对数据归属有要求的组织，可以优先评估支持本地部署的平台；有存量研发工具的组织，则要把迁移成本算进选型决策里。

4. 500 人以上、多 BU：把立项权下放，把指标统一

这个规模下，公司级立项流程不可能管住所有项目。我的建议是权力下放、标准统一、数据集中：L0 和 L1 由各 BU 自行决策，公司只保留 L2 的评审权和全量数据看板。

公司级要盯的不再是单个项目，而是分布特征：各 BU 的立项周期中位数、关停率分布、变更率异常值。某个 BU 的关停率长期为零，比某个项目被否决更值得关注。

5. 强监管、大客户定制型：把不可逆性作为第一维度

如果你的立项经常涉及合同承诺、数据合规或硬件采购，那么”不可逆程度”应该成为分层的第一维度，权重高于投入规模。我在这类组织里的做法是：所有不可逆项目强制进入 L2，并且必须由法务和合规会签。

另外这类组织要特别注意立项到启动的间隔。合同类项目的窗口期很短，决策到启动间隔超过 5 个工作日，业务侧就可能错失机会。建议把 L2 的评审频率提高到每周一次。

七、不同情况下的取舍：没有最优解，只有匹配

1. 速度 vs 严谨：最优区间不是越快越好

我做过一个跨 9 个组织的对照观察，把立项周期和立项后 30 天变更率做了相关性分析，结果不是线性的。立项周期在 5-7 天区间时，变更率最低，约在 18%-21%；周期压缩到 3 天以内的项目，变更率反而回升到 32% 以上；周期超过 15 天的，变更率是 38%。

我的解释是：3 天以内完成立项，通常意味着跳过了必要的证据收集和对齐，决策建立在直觉上；而 15 天以上则意味着流程损耗过大，等到决策时业务前提已经变了。立项周期存在一个效率最优区间，追求极致的快会以质量为代价。

2. 集中 vs 分散：决策权该放多深

集中决策的优势是标准统一、避免重复投入；劣势是决策层离业务远，周期长。分散决策的优势是快、贴近业务；劣势是标准漂移、资源重复。

我的取舍原则是按不可逆程度分配：可逆的决定尽量分散，不可逆的决定必须集中。一个可以灰度回滚的功能优化，让产品线和研发负责人自己决定就够了；一个涉及数据迁移或对外承诺的项目，必须收到公司级评审。

3. 标准化 vs 灵活性：标准化的是字段，不是判断

很多组织在推立项规范时把两者搞反了，字段随意填，判断标准却卡得很死。我的做法是反过来：字段必须标准化（问题、目标、基线、资源来源、退出条件这五项缺一不可），但判断可以灵活，允许评审人根据自己的经验做取舍，只要在记录里写清理由。

标准化字段带来的最大收益是可比较性。当所有立项都填了基线值，你才能横向对比哪个项目的目标设定合理，哪个明显注水。

4. 自研 vs 采购：把迁移成本算进去

立项流程的承载工具，自研的优势是贴合流程，劣势是维护成本被严重低估。我见过一个 500 人组织自研的立项系统，三年维护成本超过 200 人天，而且每次流程调整都要排开发排期。

采购的优势是成熟度和维护成本，劣势是流程可能被工具反向约束。我的建议是：把”迁移成本”作为选型的第一硬指标。有存量研发工具的组织，如果迁移需要重新配置全部工作项和权限，这个成本往往超过工具本身的三年费用。这也是为什么支持从既有工具平滑迁移的平台，在国产替代场景里更值得优先评估。

5. 我的取舍顺序与判断依据

如果只能保留三条规则，我会按这个顺序取舍：第一，退出条件必须有，因为它决定了下行风险；第二，资源来源必须明确，因为它决定了项目能不能真正启动；第三，分层必须做，因为它决定了流程成本是否匹配风险。

反过来，我最先砍掉的是复杂的技术评审环节和长达数页的竞品分析。这两项看起来专业，但对决策的实际贡献很小，反而拉长了立项周期，降低了产品经理提交高质量材料的意愿。

八、结语：立项流程的价值在于让组织敢于开始，也敢于结束

回到开头那组数据，通过率 97.9%、主动关停率 4.3%、僵尸项目占比 49%。这三个数字放在一起，说明的不是团队执行力问题，而是流程设计里缺少了”结束”这个动作。立项流程如果只教会组织如何开始，它就只是一个加速器，而不是一个决策系统。

我这些年最确定的一个判断是：立项规范的质量，不取决于模板有多完整、评审有多隆重，而取决于两件事，它能不能让一个证据不足的项目被退回，以及它能不能让一个已经失去价值的项目被结束。前者对应评分卡的阈值，后者对应退出条件和复盘节点。

如果你准备在接下来一个季度动手改造立项流程，我的建议是按这个顺序推进：第一周，先把过去一年所有立项的周期、变更率、关停情况统计出来，看清基线；第二周，确定 L0/L1/L2 的分层标准和评分卡阈值；第三周，把评审改成固定窗口，并把立项文档压到 10 页以内；第四周，强制每个项目填写终止触发条件，并在系统里设置复盘提醒节点。

四件事做完，三个月后再看数据。你会发现立项数量可能减少了，但立项后 30 天变更率明显下降，主动关停率上升，而团队对流程的抵触情绪反而更低了，因为流程不再是一个只会说”再补充一下材料”的黑箱，而是一个能给出明确结论、也允许体面退出的决策机制。