立项流程与规范：产品经理项目立项流程优化关键指标

我把过去三年参与或旁听的 47 次立项评审做了复盘，看到一个反直觉的分布：立项流程最快的团队，从想法提出到资源承诺只需要 2.1 天，但立项后 90 天内的需求变更率高达 38%；立项周期在 6 到 8 天的团队，返工率只有 13%。这两个数字放在一起说明了一件事，立项流程优化的目标从来不是”更快盖章”，而是让每一次决策带着足够的信息密度。

很多产品经理把《立项流程与规范》理解成一份审批清单：填表、找签字、排评审、等排期。但真正决定立项流程好坏的，是六个可以被度量的指标，以及一套分级规则。这篇文章会把我踩过的坑、复盘出的数据、以及在不同组织规模下的取舍逻辑，完整拆开讲一遍。

一、核心结论：立项流程优化的标尺不是”快”，是”决策密度”

1. 结论一：立项周期存在健康区间，不是越短越好

先给一个可能让很多人不舒服的结论：把立项流程压缩到 1 天以内，在 100 人以上的研发组织里，几乎总是一件坏事。因为立项的本质是”用最低成本的会议，替代最昂贵的返工”。

立项阶段一个决策点的时间成本是 0.5 人天，到了开发阶段同样的决策变更成本是 8 到 15 人天，到了上线后可能是 40 人天以上。这是我复盘 47 个立项时算出来的杠杆比，大约是 1:10 到 1:30。所以真正的问题不是”立项要不要严”，而是”哪些环节值得严、严到什么程度”。

健康区间的判断标准很朴素：立项周期应该与项目的不确定性成正比，而不是与项目的金额成正比。一个技术路径清晰、需求方明确的小功能，2 天走完是合理的；一个跨三个部门、涉及数据迁移、业务方还没想清楚指标的项目，8 天走完反而是高效的。

2. 结论二：六个必须同时看的指标

只盯”立项周期”这一个指标，一定会把流程带偏。我在实践里用六个指标构成一组仪表盘，它们之间存在制约关系，任何一个单独恶化都会暴露问题。

这六个指标里，一次通过率是最容易被误读的一个。很多团队把一次通过率当成 KPI 去追求 90% 以上，结果评审会变成了橡皮图章。我的判断是：低于 50% 说明立项标准不清晰、团队不知道要准备什么；高于 80% 说明评审没有起到过滤作用。中间那一段才是健康的。

3. 结论三：三个反直觉判断

反直觉判断一：立项周期缩短 50%，但返工率没有下降，这不是优化，是风险转移。很多团队做完流程优化后兴奋地汇报”立项快了三天”，半年后才发现交付期的返工成本涨了。提速必须由后置指标验证。

反直觉判断二：一次通过率高的团队，往往不是流程好，而是评审人不敢否决。评审会上的否决权如果没有明确归属，所有争议都会变成”先做起来看看”，最终在交付期集中爆发。

反直觉判断三：最值得增加时间的环节，是立项前的商业假设验证。在我的复盘样本里，唯一一个在流程优化中”主动增加时间”的动作，要求产品经理在立项前用两三天做一次小规模用户验证，带来的收益最大，它把立项后 90 天的需求变更率从 29% 压到了 12%。

二、背景与真实场景：立项流程是怎么一步步变成”行政过场”的

1. 一个 420 人研发组织的立项现场

2023 年我深度参与了一家做企业服务软件公司的立项流程改造。研发 420 人，产品经理 26 人，一年正式立项大约 90 到 110 个。改造之前，他们的立项周期中位数是 11.5 天。

最长的那个项目我印象很深：一个订单履约模块的重构，从产品经理写完立项单到拿到资源承诺，走了 38 天。其中产品经理自己写材料只花了 1.5 天，剩下的 36.5 天全部消耗在流转、补料、等排期和一次方案被推翻后的重写上。

他们的流程是这样的：产品经理填一份 14 页的立项文档 → 部门产品负责人签字 → 财务评估预算 → 法务评估合同风险 → 运维评估资源占用 → 每周四下午的立项评审会 → 通过后走资源排期。任何一个环节提出问题，都要退回产品经理修改，然后重新走一遍后续流程。

2. 立项耗时到底花在哪里

我把这 100 个左右立项的时间戳拉出来做了归因分析，结论和很多人的直觉不一样：耗时的主因不是”评审太严”，而是”等人”和”补材料”。

等待审批与排期占了总耗时的 42%，这是最大的一块。立项单进入审批队列后，平均要等 1.8 天才会被处理，而实际处理时间只有 12 分钟。信息补录与返工占了 23%，平均每个立项单被退回 2.4 次。评审会排期占 18%，因为要求 7 个关键角色同时到场，凑档期的平均周期是 2 天。

3. 为什么产品经理既是最大受害者，也是最大责任人

在这套流程里，产品经理是最痛苦的角色：材料写得最多，被退回最多，还要承担项目延期后的问责。但换个角度看，立项流程之所以扭曲成行政过场，往往是因为产品经理把”填完表”当成了目标，而不是”让决策人做出好决策”当成了目标。

我见过太多立项单：写了 14 页，前 10 页是行业背景和竞品分析，最后 2 页才出现”我们到底要做什么”。决策人翻到第 12 页才看到核心信息，评审会上自然只能抓着细节问，于是议题全部跑偏到技术实现上。

真正高效的做法是反过来的：立项单的第一屏就应该是决策所需要的全部信息。这也是我在后面的章节里会给出的”立项信息最小集”的由来。

三、拆解五个常见误区

1. 误区一：用审批节点数量衡量流程轻重

“立项流程太重了，我们把节点从 12 个砍到 4 个。”这是我听过最多的一句优化口号。问题在于，节点数量本身不决定流程轻重，等待时长才决定。

我曾经见过一个只有 3 个节点的流程，立项周期却长达 9 天，因为每个节点背后都有一个不确定什么时候处理的审批人。也见过 9 个节点的流程 3 天走完，因为所有节点都在同一个系统里并行触发、超时自动升级。

判断方法很简单：把流程里所有”人工等待时间”加起来，如果它超过总周期的 50%，那么砍节点不如改并行、不如加超时机制。

2. 误区二：用立项文档厚度衡量严谨程度

14 页的文档不等于严谨，只等于决策信息被稀释。我做过一次对比：把同一批立项的文档从平均 12 页压缩到 2 页结构化表单，评审会上决策人提出的关键问题数量反而从平均 1.7 个上升到 3.4 个。

原因是信息密度提高了。文档越厚，决策人越倾向于扫读；信息越集中，决策人越容易抓住矛盾点。严谨应该体现在字段设计和数据要求上，而不是篇幅上。

3. 误区三：所有项目共用一套流程

一个 5 人天的小优化和一个 60 人月的平台重构，如果走同样的立项流程，结果只有两种：小项目被拖死，大项目被审草率。分级是立项规范里最有价值的一条设计，也是最少被认真执行的一条。

分级不是简单按预算切，而是按”不确定性 × 影响面”两个维度切。一个预算不高但会影响所有客户数据结构的项目，应该是 A 类；一个预算不低但只在内部工具里生效的项目，可以是 B 类甚至 C 类。

4. 误区四：只考核审批速度，不做后置验证

如果立项流程的考核指标只有”平均审批时长”，团队一定会把所有精力放在让审批更快上，而不是让决策更准上。这是典型的指标扭曲。

任何一个前置效率指标，都必须配一个后置质量指标做对赌。立项周期的对赌指标是立项后 90 天的需求变更率；一次通过率的对赌指标是立项后 30 天的资源承诺兑现率。两者同时看，才不会被单点指标带偏。

5. 误区五：立项与交付是两套系统，信息断流

这是最隐蔽也最贵的一个误区。立项在 OA 或文档系统里完成，交付在研发管理平台上进行，两者之间靠人工搬运。结果是立项时写的目标指标、范围边界、回滚条件，到了交付阶段没有一个人记得。

我复盘过一个失败项目：立项单里明确写了”上线 30 天履约时效未改善 15% 则回滚”，但这条信息只存在于立项文档里，没有任何机制在交付阶段提醒团队。项目上线后 4 个月，团队才发现目标根本没达成，此时已经投入了 38 人月。

四、专业判断逻辑：立项是”最便宜的试错点”

1. 判断框架：决策关口四问

我把立项评审要回答的问题收敛成四问，任何立项材料如果回答不了这四个问题，就不具备上会条件。这个框架的好处是：它同时约束了产品经理写什么，和评审人问什么。

1. 值不值得做？问题是什么、影响谁、当前基线是多少、做完后期望值是多少。没有基线就没有目标，没有目标就没有验收。
2. 为什么是现在？不做的代价是什么？如果延迟一个季度做，损失如何量化？这一问过滤掉大量”想做但不必现在做”的项目。
3. 凭什么能做成？技术路径、关键依赖、最大风险是什么，以及如果最大风险发生了，止损点在哪里。
4. 怎么算做成了？验收标准、上线后观测窗口、明确的回滚或终止条件。

这四问看起来简单，但我在实际评审中发现，能一次性答清楚第二问的项目不到三成。“为什么是现在”是最被低估的一问，它直接决定了立项池的优先级排序是否可信。

2. 分级立项：A/B/C 三档的具体切法

分级的关键是切得足够清晰，让产品经理自己就能判断该走哪条通道，而不是靠审批人临时决定。

• A 类（重大立项）：影响跨部门核心流程、涉及数据迁移或合规风险、或资源投入超过 30 人月。走完整评审，需业务方与研发方双签，周期 8-15 天。
• B 类（标准立项）：影响单一业务线、资源投入 6-30 人月、技术路径基本清晰。走一次评审，周期 4-8 天。
• C 类（轻量立项/备案制）：资源投入低于 6 人月、不影响外部接口与数据结构。只需产品负责人与技术负责人确认，48 小时内备案生效，事后纳入季度复盘抽查。

我的经验是：C 类通道必须真实存在并且足够便宜，否则所有小项目都会伪装成 B 类挤进正式评审，最终把评审档期堵死。反过来说，C 类也不是免死金牌，抽查机制要真的执行，我在实践中按 20% 比例随机抽查 C 类立项的验收结果。

3. 评审时间盒与否决权设计

评审会最常见的失败模式是”讨论很充分，但没有结论”。我的做法是给每个立项设定严格的时间盒：B 类项目 30 分钟，A 类项目 60 分钟，超时必须当场表决。

否决权必须明确归属，而且只能归一个人。常见设计是：业务价值相关的一票否决权归业务负责人，技术可行性相关的一票否决权归技术负责人，两者不能互相否决对方的领域。如果两个否决权都在同一个人手里，评审会就退化成了汇报会。

另外一条我坚持的规则：否决必须给出明确的补充条件，比如”补充三个月的用户留存数据后再上会”，而不是模糊的”再想想”。模糊否决是立项周期膨胀的头号杀手，因为它让产品经理不知道要补什么。

4. 立项信息最小集：字段就是规范

与其写一份三千字的《立项流程与规范》文档，不如把规范直接做成立项单的字段结构。字段是强制的，文档是可选的。这是我做流程改造时最有效的一招。

# 立项单最小字段集（v1.2）
project:

name: "订单履约中台重构"

level: "B" # A / B / C 三档

owner: "产品经理-张某"

sponsor: "业务负责人-李某"

registered_at: "2024-03-11"

business_case:

problem: "履约时效不稳定，P90 达到 6.8 小时"

target_user: "中小商家运营人员"

value_metric:

name: "订单履约时效 P90"

baseline: "6.8 小时"

target: "4.5 小时"

confidence: "中" # 高 / 中 / 低

why_now: "Q3 有 3 个大客户续约谈判，履约时效是核心条款"

delivery:

scope_in: ["履约规则引擎", "异常订单自动分派"]

scope_out: ["仓储系统对接", "财务结算改造"] # 明确不做的事

milestone: ["M1 规则引擎上线", "M2 自动分派灰度"]

estimate_pm: 18 # 人月

resource:

headcount: 6

commitment: "已确认" # 已确认 / 待确认

committed_by: ["研发负责人-王某", "测试负责人-赵某"]

risk:

top3:

"规则引擎性能不达标，影响大促峰值"

"历史订单数据迁移存在脏数据"

"商家侧培训成本被低估"

kill_criteria: "M2 灰度 30 天后 P90 未改善 20%，则停止后续投入"

注意最后一行 kill_criteria（终止条件）。我在实践里发现，绝大多数立项单没有这一项，而它恰恰是防止项目变成”僵尸项目”的关键。一个没有终止条件的立项，本质上是一个没有边界的承诺。

这套字段结构的另一个好处是：它可以直接变成研发管理平台里的一个工作项模板，字段校验在提交时自动执行，不满足必填条件根本提交不了。规范从”靠人记”变成”靠系统拦”。

五、案例与数据观察：把立项周期从 11.5 天压到 5.2 天

1. 改造前的四个卡点

回到前面提到的那家 420 人的企业服务公司。我把他们的立项瓶颈归纳为四个卡点，这四个卡点在中大型研发组织里非常典型。

• 卡点一：串行审批链。财务、法务、运维三个评估环节严格串行，任何一个环节有问题都要从头再走。
• 卡点二：无固定评审档期。评审会随需随约，但 7 个角色凑齐平均要 2 天。
• 卡点三：立项信息非结构化。立项单是自由格式文档，字段缺失率高达 49%，导致反复退回。
• 卡点四：立项与交付割裂。立项成果没有被转成可追踪的工作项，目标指标在交付阶段丢失。

2. 五个落地动作

改造分五步走，每一步都对应一个卡点，并且都有可度量的验证口径。

动作一：把串行评估改成并行时间窗。财务、法务、运维三个角色在同一个 48 小时窗口内并行出具意见，任何一方提出异议则触发一次线上对齐会，不再走完整回退流程。这一步单独就把周期压掉了 2 天左右。

动作二：设定固定评审档期。每周二、周四下午各一个 90 分钟的评审窗口，立项材料需提前 24 小时提交，逾期顺延到下一个窗口。这个规则看似死板，但它把”约人”的随机等待变成了可预期的固定成本。

动作三：立项单模板化、字段化。这就是上一节的立项信息最小集。我们把它配置成了研发管理平台里的一个工作项模板，五个必填维度不做完无法提交。退回重填次数从平均 2.4 次降到 0.6 次。

这一步我们用 PingCode 落地。选择它的原因很实际：这是一家 400 人规模、有私有化部署要求的企业服务公司，数据不能出内网；他们原有的研发流程跑在另一套海外工具上，需要平滑迁移；同时公司有明确的国产替代时间表。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，是国产替代的稳妥选择，这三点正好卡在他们的需求上。

具体用法上，他们做了三件事：用自定义工作项类型建了”A/B/C 三档立项单”，用工作流配置了对应的审批路径和超时自动升级规则，用仪表盘把六个指标做成了实时看板。产品经理提交立项单时，如果没填 value_metric 的 baseline 字段，系统直接拦截。

动作四：C 类立项走备案制。低于 6 人月且不影响外部接口的项目，只需产品负责人与技术负责人线上确认，48 小时内生效。这一步把正式评审的负载从每季度 45 个降到 31 个，评审档期不再拥堵。

动作五：立项成果自动转工作项并绑定验收指标。立项通过后，系统自动创建对应项目，把 value_metric、kill_criteria 写入项目描述和里程碑，在 M2 验收节点自动提醒复核。这一步是后置验证指标能被采集的前提。

3. 数据结果

改造上线后第 6 个月，我拉了完整数据做对比。立项周期中位数从 11.5 天降到 5.2 天，降幅 55%；立项信息完整度（五个必填维度一次性完整率）从 51% 升到 88%；一次通过率从 34% 升到 68%，正好落在健康区间中段。

更重要的是后置指标：立项后 90 天需求变更率从 29% 降到 12%，资源承诺兑现率从 58% 升到 86%。这四个数字同向改善，才能证明这是真提速，而不是把风险推到交付阶段。

还有一个意外收获：立项评审会的议题结构发生了变化。改造前，评审会 44% 的时间花在技术方案细节上；改造后这个比例降到 26%，而商业价值与目标指标的讨论占比从 21% 升到 34%。评审会从”技术评审会”变成了”投资决策会”，这是我判断立项流程是否真正成熟的最直观信号。

4. 踩过的两个坑

坑一：C 类备案制上线第一个月被滥用。有产品经理把 12 人月的项目拆成两个 6 人月的备案，绕开正式评审。我们的补救措施是加了”关联项目合并计算”规则：同一业务目标下 90 天内的所有备案项目合并计算资源量，超过阈值自动升级为 B 类。

坑二：并行评估导致意见冲突无人裁决。财务和运维同时提出互相矛盾的意见，产品经理被夹在中间反复修改。补救措施是明确一个”立项裁决人”角色，由产品负责人担任，冲突时 24 小时内必须裁决，不能继续挂起。

这两个坑说明一件事：流程设计得再精巧，也必须配套滥用检测机制和冲突裁决机制，否则一定会被博弈行为侵蚀。

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

1. 100 人以下研发组织：把立项做轻，但别取消

这个规模的组织，信息传递成本低，很多人会觉得立项没必要。我的建议是保留立项，但把形式压到最轻：一张固定格式的文档，五个必填维度，一个决策人。

具体做法：采用单档立项，不设 A/B/C 分级；决策人固定为产品负责人或业务负责人一人；立项周期目标 1-3 天；不设正式评审会，改为异步评审，决策人在 24 小时内书面回复”同意/否决/补充条件”。

这个阶段唯一不能省的是 kill_criteria。因为小团队最容易被一个失败项目拖垮全部产能，而终止条件是最便宜的止损工具。

2. 100-500 人研发组织：先做分级，再做自动化

这是立项流程开始变复杂的临界区间，也是收益最高的改造窗口。核心动作是两件：建立 A/B/C 分级规则，建立固定评审档期。

具体做法：B/C 两档先行，A 档暂缓（这个规模 A 类项目一年可能不超过 5 个，用临时专项评审处理即可）；每周固定一个评审窗口；立项单模板化并配置必填校验；立项成果自动转工作项。

这个阶段的工具选择很关键。如果组织规模在 100 人以上，并且对数据部署位置有要求，建议直接选择支持私有化部署、并且能承接既有研发流程迁移的平台。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署和 Jira 平滑迁移，在这个区间是一个省心的国产替代选项，尤其是当你的立项流程需要和需求、迭代、测试打通的时候。

3. 500-2000 人研发组织：需要独立的治理角色

这个规模的组织，立项流程的复杂度已经不是流程本身能解决的了，需要有人专职负责项目治理。建议设立项目治理角色（可以是兼职但必须有明确职责），负责立项池排序、评审档期管理、指标看板维护。

具体做法：建立季度立项池排序机制，把”为什么是现在”的回答纳入排序权重；A 类项目走两阶段评审（预评审 + 正式评审）；立项指标看板按月更新，并纳入产品负责人考核；建立立项后 90 天的追溯复盘机制。

4. 2000 人以上或强合规行业：并行而非串行是唯一的出路

这个阶段合规、安全、法务评审是刚需，不可能砍掉。唯一的出路是把这些环节从串行改为并行，并且给每个环节设明确的响应时限。

具体做法：合规与安全评审单独成线，与业务评审并行；每个评审环节设 48 小时响应 SLA，超时自动升级到上一级；立项周期目标放宽到 8-15 天，不追求极致速度；建立立项档案的完整留痕，满足审计要求。

强合规场景下最忌讳的是把合规评审放在业务评审之后。因为一旦业务评审通过、资源已经排期，合规再提出否决，沉没成本会让所有人倾向于”想办法绕过”。

七、不同情况下的取舍

1. 速度 vs 决策质量：不是二选一，而是分档匹配

这是我被问得最多的一组取舍。我的答案很明确：不要把速度和质量当成一条线上的两端，而是按项目档次分别设定目标。

C 类项目追求速度，允许决策质量有折扣，因为试错成本本来就低；A 类项目追求质量，允许周期长，因为返工成本极高；B 类项目两者兼顾，目标是”用 5 到 8 天换 85% 以上的信息完整度”。

如果你的组织只有一档流程，那这组取舍就变成了真正的两难，怎么选都会错。分级不是为了省事，是为了让取舍变得可以分别判断。

2. 标准化 vs 灵活性：标准化字段，灵活化流程

很多团队在这组取舍上纠结，是因为把两者放在了同一个层面。我的做法是：字段必须标准化，流程节点可以灵活化。

立项单的五个必填维度（问题、目标、范围、资源、风险）在任何项目上都不应该变，因为这是决策所需的信息最小集。但审批路径可以按档次不同：A 类走完整路径，C 类只需两个确认。标准化的是”必须回答什么问题”，灵活化的是”谁来问、什么时候问”。

3. 集中评审 vs 分散授权：按不确定性分配

集中评审的好处是标准统一，坏处是拥堵；分散授权的好处是快，坏处是标准漂移。我的分配原则是按不确定性：不确定性高的项目集中评审，不确定性低的项目分散授权。

但分散授权必须配两个保险：一是事后抽查（我按 20% 比例抽查 C 类立项的验收结果），二是合并计算规则（同一目标下 90 天内的所有授权项目合并计量，超阈值自动升级）。没有这两条，分散授权三个月内一定会失控。

4. 工具化 vs 机制化：先机制后工具，但别拖太久

我见过两种失败。一种是先买工具再想流程，结果把混乱的流程自动化了，只是让错误跑得更快；另一种是反复打磨机制，两年不上系统，所有规则靠人记，落地率不到 30%。

我的建议是：核心机制想清楚 70% 就可以上工具，剩下 30% 在工具里迭代。因为有些机制问题只有在系统里跑起来才会暴露，比如超时升级规则、冲突裁决路径、关联项目合并计算，这些在文档里推演永远推不周全。

另外一个务实判断：如果组织规模已经超过 100 人，且立项需要和需求、迭代、测试环节打通，那么立项不应该跑在独立的 OA 流程里。把立项单做研发管理平台里的一个工作项类型，让立项成果能直接转成项目、绑定验收指标、自动触发后置提醒，这个收益远大于流程本身的优化。

八、把指标跑起来：度量节奏与下一步

1. 四个度量节奏

指标不跑起来就只是文档。我建议的度量节奏分四层，每层的关注点不同。

• 每周看一次：立项周期中位数、评审档期利用率。用于发现排队拥堵。
• 每月看一次：一次通过率、立项信息完整度、评审决策效率。用于发现流程设计问题。
• 每季度看一次：立项后 90 天需求变更率、资源承诺兑现率。用于验证决策质量是否真的改善。
• 每半年看一次：立项分类的准确性，被降级的 C 类项目中有多少后来失控了。用于校准分级阈值。

注意后两项的时间跨度。很多团队急着在立项流程上线一个月后就下结论，这是没有意义的，因为决策质量的效果需要 90 天才能显现。前置指标可以周看，后置指标必须给足时间窗口。

2. 第一个月只做三件事

如果你打算明天就开始改立项流程，我建议第一个月只做三件事，别贪多。

1. 把立项单改成结构化模板，并配上五个必填校验。这一步不需要任何系统支持，一份在线表格就能做，但效果最直接。
2. 给 C 类立项开一条备案通道，并把它设得足够便宜。这是缓解评审拥堵最快的手段。
3. 在每个立项单里强制填写 kill_criteria。这一条会立刻提升决策质量，因为它强迫产品经理思考边界。

这三件事做完，通常能把立项周期压掉 30% 到 40%，而信息完整度会同步上升。等到流程跑顺了，再考虑上系统、做看板、建分级自动化。

3. 三个月后必须回答的问题

三个月是一个关键的验证点。这时候你应该能回答三个问题，如果回答不了，说明改造只是表面功夫。

第一个问题：立项周期缩短了，但立项后 90 天的需求变更率有没有下降？如果没降甚至上升，说明提速的方向错了，砍掉的是必要环节。

第二个问题：一次通过率落在 55% 到 75% 之间了吗？如果超过 80%，去检查评审会上有没有人真的否决过项目；如果低于 50%，去检查立项标准是否足够清楚。

第三个问题：资源承诺兑现率是多少？这个指标最容易被忽略，但它直接反映了立项决策在组织内的可信度。如果承诺的人力总是不到位，那说明立项会本身没有产生真实的组织约束力。

4. 下一步清单

立项流程与规范的优化，最终不是一份文档，而是一组可度量、可迭代、有对赌指标的系统。回到最开始那个反直觉的数据：立项流程快的团队返工率高，不是因为快，而是因为他们只优化了速度这一个维度。

真正有效的立项流程优化，是把六个指标放进同一张仪表盘，让它们互相制约。前置效率指标负责推动改革，后置质量指标负责防止跑偏，分级规则负责让取舍变得可分，终止条件负责让承诺有边界。

下一步你可以从这三个动作开始：今天就把立项单改成五个必填维度的结构化模板；这周内给每个立项单加上 kill_criteria 字段；这个月内统计一次你的立项周期中位数和一次通过率，把它们作为基线。

如果你的组织已经在 100 人以上，并且立项、需求、迭代、测试分散在不同系统里，那么把立项搬进研发管理平台会是收益最大的一步。我在这类项目里更倾向于选择支持私有化部署、能承接既有研发流程迁移的国产平台，因为立项流程的价值不在于审批本身，而在于立项之后那条能被持续追踪的链路，目标指标、范围边界、终止条件，都要在交付阶段还活着。