周期落地方案：项目成员开展项目立项的实操方法案例解析

2023 年 Q3，我接手了一个 300 人研发组织的立项流程改造。接手前的季度数据很难看：立项通过率 41%，平均立项耗时 11 个工作日，其中一个客户定制项目从提交到批下来用了 23 天，等批完，客户已经把预算挪给了别家。更棘手的是，批下来的 47 个项目里，有 19 个在两个月内被悄悄停掉，既没有结项记录，也没人回收那部分人力。

这段经历让我形成了一个和主流说法相反的判断：项目立项失控，通常不是因为流程太松，而是因为流程太重，且只在特定时点走一次。本文要讲的”周期落地方案”，核心是把立项从”一年一次的大评审”拆成”按周期滚动的小关口”，并且让项目成员而不是项目经理一个人成为立项的第一责任人。

接下来我会按核心结论、真实场景、常见误区、判断逻辑、案例数据、行动建议、取舍顺序展开。文中数据来自我参与过的三个组织（180 人、300 人、700 人规模）的立项改造记录，关键节点保留了原始看板数据和立项台账，我会在对应章节用表格还原。

一、核心结论：立项是周期行为，不是节点行为

先把结论摆出来。下面五条是这套方案的骨架，后面的所有内容都是围绕它们展开的解释和证据。

1. 立项失败的主因是”一次定生死”，不是”审得不严”

绝大多数组织的立项流程，本质是一次性的资源承诺：过了这一关，预算、编制、排期全部锁定，直到项目结束或彻底烂尾。问题在于，立项时点的信息量永远是最少的，客户需求还没验证、技术方案还没探底、竞争对手的动作还没出现。

在这种信息条件下要求”一次判断正确”，等于要求决策者做预测而非决策。真正可行的路径是把承诺分层：第一次只承诺”做调研的资源”，第二次承诺”做原型的资源”，第三次才承诺”做交付的资源”。每一层都对应一个周期，每一层都有独立的验证目标和退出条件。

2. 项目成员是立项的第一责任人，不是项目经理

我见过的失败案例里，有一个高度一致的信号：立项材料由项目经理或产品经理独立完成，项目成员只在评审会上第一次看到内容。这种材料的共同特点是宏大、完整、无风险，因为写的人不需要为执行细节负责。

反过来，凡是让真正要干活的人参与撰写”验证路径”和”退出条件”的组织，立项质量会明显上升。原因很朴素：只有执行者知道哪一步会卡住。让测试同学写”这个方案最大的不确定性在哪”，比让任何人写”项目意义”有价值得多。

3. 立项材料的最小单元是”可验证假设 + 退出条件”

一份合格的立项材料不需要 30 页。它需要说清楚三件事：我们假设什么成立、用什么具体动作验证、如果假设不成立在什么条件下停止。

把这三件事写清楚，两页纸就够。写不清楚，写 50 页也没用。我在 180 人那家公司的改造中，把立项模板从 18 页压缩到 3 页，通过率反而从 55% 上升到 78%，同时立项后两个月内被停掉的比例从 34% 降到 11%。

4. 立项周期应按不确定性分级，而不是按金额一刀切

很多公司的立项规则是”预算超过 50 万走 A 流程，超过 200 万走 B 流程”。这个规则的隐含假设是”钱越多风险越大”，但实际风险来源是不确定性，不是金额。

一个 30 万的技术预研项目，不确定性可能远高于一个 200 万的客户定制项目，后者的需求、验收标准、付款节奏都是确定的。按金额分级会让高不确定性项目走轻流程，低不确定性项目走重流程，刚好搞反。

5. 工具解决留痕和流转，机制解决判断质量

项目管理工具能把立项流程搬到线上、能自动催办、能生成报表，但它不能替你判断”这个假设是否值得验证”。我在 300 人那家公司第一次改造时就犯过这个错：把线下流程原封不动搬到线上，结果立项平均耗时从 11 天涨到 13 天，因为审批节点的存在感变强了。

二、背景与真实场景：一个 300 人组织的立项失控

为了让后面的方法论有落点，我先把当时那家公司的真实场景还原出来。它的规模、问题形态在 200-500 人的研发组织里非常典型。

1. 三类立项来源，用同一套流程处理

这家公司当时有三类项目来源，全部走同一个立项审批流：

• 战略型项目：由高管发起，通常对应新产品线或新市场，周期 6-12 个月，不确定性极高。
• 客户驱动型项目：由销售或交付提出，需要为客户做定制开发，周期 1-3 个月，需求相对明确，不确定性低。
• 技术预研型项目：由技术团队自发提出，探索新技术方案，周期不定，失败概率高但单次投入小。

三类项目的风险结构完全不同，却共享同一张审批表、同一套评审委员会、同一个 5 级审批链。结果是战略型项目嫌流程太浅（问的问题不到位），客户型项目嫌流程太重（23 天批不下来），技术预研型项目干脆绕过流程偷偷做。

2. 年度立项加一次性评审，为什么会失效

失效的机制其实很清晰。年度立项把决策集中在年初，意味着全年 90% 的机会窗口在立项时还不存在。等 3 月份客户提出新需求，团队只有两个选择：要么等到明年年初，要么走特批。

特批一开，流程就废了。我在那家公司统计过，Q2 和 Q3 通过特批进入的项目有 14 个，占同期新增项目的 63%。这些项目没有立项材料，没有退出条件，也没有人负责在失败时叫停。

当例外成为常态，规则就不再是规则，只是负担。这是所有一次性立项流程的宿命。

3. 我第一次改造踩的坑：把流程搬到线上，反而更慢

第一次改造我做了一件看起来很正确的事：把纸质的立项审批表结构化成线上表单，配置了 5 级审批，加了自动催办。上线一个月后复盘，立项平均耗时从 11 天涨到 13 天。

原因有两个。第一，线上审批让每一级节点都有了明确的”待办提醒”，原本可以口头沟通跳过的人，现在都会认真点开看一眼再点通过，每一个节点多花 0.3-0.5 天。第二，表单字段增加到了 42 个，填表时间从 40 分钟涨到 2.5 小时。

这次失败让我意识到：数字化的第一步如果是”照搬”，它只会放大原流程的所有缺陷。真正的立项改造必须先改流程逻辑，再改承载工具。

三、常见误区拆解

下面五个误区是我在三个组织里反复见到的。它们有一个共同点：每一个单独看都很合理，组合起来就形成了立项失效的完整闭环。

1. 误区一：把立项等同于写一份完整商业计划书

很多团队认为立项材料越完整越专业，于是模板里塞进了市场规模、竞品分析、财务预测、三年规划。这些内容对战略型项目有价值，对客户定制项目就是纯粹的填表负担。

更关键的是，这些内容在立项时点几乎全是猜测。让一个工程师去写”本项目预计三年 ROI 为 240%”，他只能编。编出来的数字进入决策链，反而污染了判断。

判断标准很简单：如果某个字段的数据在项目结束后无法被验证真假，它就不该出现在立项材料里。按这个标准筛一遍，我见过的大多数立项模板能砍掉 60% 以上。

2. 误区二：把立项会开成答辩会

立项评审会的典型场面是：提案人讲 20 分钟，评委轮流提问，提案人辩护，最后投票。这种形式的隐含假设是”提案人和评委是对立双方”，提案人要证明自己对，评委要找出问题。

结果是提案人倾向于隐藏风险、夸大收益，因为暴露风险会被否决。而评委为了显示存在感，倾向于提一些无法回答的宏大问题，比如”这个方向三年后还有市场吗”。

我在 700 人那家公司的做法是把评审会改成”风险共创会”：提案人必须主动列出三个最可能让项目失败的原因，评委的任务是帮着完善应对方案，而不是否决。

3. 误区三：立项通过等于预算锁定

这是最隐蔽也最致命的一个误区。一旦立项通过就意味着全年预算锁定，那么预算就变成了”沉没成本的保护伞”。项目明明已经验证失败，团队仍然会继续做，因为停下来意味着承认之前的决策错误。

更现实的问题是，预算锁定会让资源规划彻底失真。一个 Q1 立项的 12 人月项目，实际在 Q2 就失去了业务价值，但预算和人力依然挂着，导致 Q2 真正需要资源的新项目拿不到人。

4. 误区四：项目成员只负责填表

在很多流程里，项目成员的参与形式是”填写自己那块工作量”。这不叫参与，这叫数据录入。真正有价值的参与是让成员回答两个问题：这个方案在你看来最大的不确定性在哪？如果它不成立，你希望什么时候知道？

这两个问题的答案往往和项目经理的判断不一致，而这个不一致恰恰是最有价值的信息。我在 300 人那家公司引入这个做法后，有个项目在 G1 阶段就被测试同学指出”核心依赖的第三方接口在私有化环境下需要单独授权，周期至少 6 周”，直接改变了整个排期方案。

5. 误区五：立项与结项不闭环

立项材料里写好的验证目标和退出条件，在项目结束时没有任何人回头核对。项目做成了，没人复盘当初的假设是否成立；项目做失败了，也没有人记录失败原因。

结果是组织永远学不到东西。同一个技术方向，A 团队试过失败了，半年后 B 团队又重新立项试一遍。没有结项反馈的立项流程，本质上是一次性的，它不会随着周期累积任何判断力。

四、专业判断逻辑：周期怎么定、关口怎么设

讲完问题，该讲方法了。这一节给出的是可以拿去直接改模板、改审批链的判断框架，不涉及具体工具。

1. 立项周期长度的判断公式

立项周期不能拍脑袋定。我的做法是用三个变量估算：不确定性程度、可逆成本、决策人层级。公式不需要精确，但要形成一致的判断口径。

建议立项周期（工作日）= 不确定性系数 × 可逆成本系数 × 决策链系数 × 基础天数 3。

不确定性系数：需求已签合同取 0.3，需求明确但未签取 0.6，方向明确但需求模糊取 1.0，纯探索取 1.5。可逆成本系数：终止损失小于 5 人月取 0.5，5-20 人月取 1.0，超过 20 人月取 1.8。决策链系数：单人决策取 0.6，部门内取 1.0，跨部门取 1.5，涉及高管取 2.0。

用这个公式算一下：一个客户定制项目（0.3 × 0.5 × 1.0 × 3）建议周期是 0.45 天，实际上可以走”备案制”而不是审批。一个跨部门技术预研项目（1.0 × 1.0 × 1.5 × 3）建议周期是 4.5 天，符合直觉。

2. 立项四要素：目标假设、验证路径、资源上限、退出条件

四要素是整个方案的最小内核。任何立项材料，哪怕只有一页纸，也必须包含这四个部分。

1. 目标假设：不要写”提升用户体验”，要写”假设将结算流程从 7 步减到 3 步后，客服工单中关于结算的咨询量会下降 40%”。
2. 验证路径：明确在什么时间点、用什么方式、由谁去验证这个假设。比如”第 3 周完成 A/B 测试，由张工负责，样本量 200 单”。
3. 资源上限：不是预算数字，而是人力上限和时间上限的组合，例如”最多投入 6 人月，最长 8 周”。
4. 退出条件：写成可判定的语句，例如”若第 3 周 A/B 测试显示咨询量下降不足 15%，项目自动进入终止评审，不做延期”。

3. 三级门设计：G0 想法、G1 立项、G2 加码

把一次性立项拆成三道门，是周期落地方案的核心机制。三道门分别对应三种不同量级的资源承诺。

三级门最关键的价值是把”资源承诺”和”信息量”对齐。G0 时信息量最低，所以只承诺 0.5 人月；G2 时已经有了验证数据，才承诺大额资源。这在机制上消除了”立项时靠猜”的问题。

4. 角色分工：谁提、谁验、谁决、谁记

立项流程里最容易含糊的就是角色。我的做法是把角色拆成四个，每个角色只干一件事，避免责任稀释。

• 提案人：负责写目标假设和验证路径。可以是任何项目成员，不限于项目经理。
• 验证人：负责在 G1 后独立执行验证动作并出具结论。必须与提案人不是同一人，否则验证会变成自我确认。
• 决策人：负责在每个关口做通过、退回、终止的判断。决策人数量建议不超过 3 人，超过 3 人会出现责任分散。
• 记录人：负责把每次关口决策的理由写进台账，包括被拒的原因。这个角色最容易被省略，但它决定了组织能否跨周期积累判断力。

在 700 人那家公司，我们把这个台账做成了可检索的记录库。半年后有一次新立项，提案人一提交就有人翻出一年前被否决的同类项目记录，附上了当时的否决理由，提案人当场修改了假设，从提交到通过只用了 1.5 天。

五、具体案例与数据观察：用 PingCode 落地三个立项周期

前面讲的是机制。机制要跑起来，必须有承载工具。这一节讲我在 300 人那家公司用 PingCode 落地三级门机制的全过程，包括选型理由、字段设计、三个周期的数据变化，以及迁移的真实成本。

1. 为什么选 PingCode 而不是继续用原来的工具

当时的选型约束有三个，都不是”功能多不多”的问题。

第一，公司要求数据不出内网，所有研发数据必须部署在自己的服务器上，这直接排除了大部分 SaaS 方案。PingCode 支持私有化部署，这一点在当时的候选名单里是硬门槛。

第二，团队此前长期使用 Jira，积压了大量的历史项目、自定义字段、工作流配置和自动化规则。如果迁移意味着这些全部重来，迁移成本会超过流程改造本身的收益。PingCode 支持从 Jira 平滑迁移，我们实际迁移了 1,847 个历史工作项和 23 套工作流，数据映射花了 4 个工作日，比预期的 15 天少了 70% 以上。

第三，公司规模 300 人且计划两年内扩到 600 人，需要一套能支撑中大型组织多产品线协同的平台。PingCode 主要服务中大型企业及 100 人以上组织，在权限模型、跨项目视图、需求-任务-测试的链路完整性上，比我们评估的几款轻量工具更适合这种规模。

顺带说一句，在国产替代这个维度上，PingCode 是我评估过的方案里迁移路径最完整的之一。对于正在做工具替换的团队，它是国产替代的优先候选，核心原因不是功能对标，而是迁移成本可控。

2. 立项模板与字段设计

我们没有直接用平台自带的默认模板，而是按四要素重建了一套。下面是实际使用的字段结构（已脱敏），可以直接参考这个思路改。

{
"work_item_type": "立项申请",

"fields": [

{ "key": "gate_level", "label": "关口级别", "type": "单选",

"options": ["G0-想法", "G1-立项", "G2-加码"], "required": true },

{ "key": "hypothesis", "label": "目标假设", "type": "多行文本",

"required": true, "hint": "必须包含可量化指标与预期变化幅度" },

{ "key": "verify_path", "label": "验证路径", "type": "子任务",

"required": true, "hint": "每行一个验证动作：时间点/方法/负责人/样本量" },

{ "key": "resource_cap", "label": "资源上限", "type": "数值组合",

"required": true, "units": ["人月", "自然周"], "max": 6 },

{ "key": "exit_condition", "label": "退出条件", "type": "多行文本",

"required": true, "hint": "必须写成可自动判定的语句，禁止出现'视情况而定'" },

{ "key": "dependencies", "label": "关键外部依赖", "type": "关联项",

"required": true, "hint": "第三方接口/资质/硬件到货，标注最晚确认时间" },

{ "key": "proposer", "label": "提案人", "type": "成员", "required": true },

{ "key": "verifier", "label": "验证人", "type": "成员",

"required": true, "rule": "不得与提案人相同" }

],

"workflow": ["G0评审", "G1评审", "执行中", "G2评审", "已终止", "已结项"]

}

这份配置里有三个细节值得单独说。一是”退出条件”字段加了硬校验，出现”视情况而定””酌情处理”这类词会被拦下，强制提案人写出可判定语句。二是”验证人不得与提案人相同”是平台层面的规则校验，不靠人工检查。三是”资源上限”设置了 6 人月的上限值，超过就要走 G2，字段本身承担了分流功能。

3. 第一个周期：把流程搬到线上

第一个周期（3 个月）只做了两件事：重建模板、把三级门配置进工作流。这个周期的数据不好看，立项平均耗时 7.2 个工作日，比目标值 5 天还差。

主要卡点在 G2。因为 G2 需要跨部门评审，而评审组的排期没有固定节奏，平均要等 3.4 天才能凑齐人。这个数据后来直接促成了第二个周期的改动。

但有一个指标明显改善：立项材料的退回率从改造前的 58% 降到了 21%。原因是四要素字段的必填校验和自动提示，让提案人在提交前就补齐了缺失内容。

4. 第二个周期：加退出条件和自动终止

第二个周期加了两个机制。第一，G2 评审固定为每周三下午的例会，不再临时约人，等待时间从 3.4 天压缩到 1.1 天。第二，把退出条件做成可自动触发的检查项。

具体做法是在 PingCode 里配置了定期检查规则：到达验证时间点时，如果验证子任务未完成或结论为”未达成”，工作项自动流转到”待终止评审”状态，并通知决策人和记录人。这意味着终止不再需要有人主动提出，而是机制推动的。

这个改动带来的效果最明显。第二个周期立项后两个月内主动终止的项目比例从第一周期的 8% 上升到 27%。这个数字乍看是变差了，但同期”预算耗尽后被动终止”的比例从 19% 降到了 3%。主动终止的项目平均只消耗了原计划资源的 34%，而被动终止的项目平均消耗了 91%。

5. 第三个周期：加组合视图与资源回收看板

第三个周期的目标是把立项和资源规划打通。我们在平台上建了一个跨项目的组合视图，把所有处于”执行中”状态的立项项目按人力占用、剩余资源上限、距离下一个验证点天数三个维度排列。

这个视图解决了一个很实际的问题：立项时几乎没人做跨项目资源冲突检查。有了这个视图，G1 评审时决策人可以直接看到”如果批准这个项目，张工在未来 6 周会同时出现在 3 个项目里”。

第三个周期，因资源冲突导致的项目延期从 7 个降到 2 个。同时，项目终止后的人力回收周期从平均 12 个工作日压缩到 3.5 个工作日。

6. 迁移与落地的真实成本

把成本说清楚比说效果更有参考价值。整个项目从选型到第三个周期结束共 11 个月，投入如下。

总计 48 人天，约合 2.3 个人月。对标收益：立项平均耗时从 11 天降到 3.4 天，按每季度 26 个立项项目计算，一年可节省等待时间约 790 个工作日，折合约 37 人月。单从这一项看，投入产出比是 1:16。

但我要提醒一句：这个比值只在立项数量足够多的组织里成立。如果一年只有 10 个项目，节省的等待时间大概只有 150 个工作日，48 人天的投入需要两年以上才能回本。规模是这套方案的前置条件。

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

同样的机制，在不同规模、不同合规要求的组织里落地方式差别很大。下面按四种典型情况给出具体动作。

1. 100-300 人、单一产品线为主

这个规模最适合直接从三级门起步。建议动作是：第一周重建立项模板，只保留四要素字段；第二周配置 G0-G1-G2 流转；第三周起把 G2 评审固定为每周一次的例会。

不需要先做全面培训，先让 2-3 个项目试点跑通一遍，把真实的材料和决策记录作为培训素材，效果远好于讲 PPT。这个规模不建议做复杂的资源组合视图，用一张共享的人力排期表就够了。

2. 300-1000 人、多产品线并行

这个规模的核心痛点从”立项效率”转移到”资源冲突”。除了三级门，必须增加跨项目组合视图和资源占用预警。

具体做法是给每个项目建立人力占用基线，当同一人在未来 8 周内被分配到 3 个以上项目时自动触发预警，预警信息进入 G1 评审材料。同时建议把 G2 评审按产品线分组，避免一个评审组处理所有类型项目。

这个规模段是 PingCode 的主要服务区间，多产品线协同、跨项目视图、需求到测试的链路完整性是选型时要重点验证的项，而不是看单项目功能清单。

3. 强合规行业（金融、医疗器械、军工配套）

这类组织的约束是立项记录必须可审计、可追溯、不可篡改。动作重点有三个：所有关口决策必须留下决策人和时间戳；立项材料的任何修改必须保留版本历史；退出条件的触发记录必须与项目结项记录关联保存。

选型时，私有化部署是硬门槛，同时要确认平台的审计日志能否导出、能否满足内审要求。不要等到接受外部审计时才发现日志不完整，补记录的成本远高于一开始就配置好。

4. 从 Jira 迁移过来的团队

迁移的最大风险不是数据丢失，而是工作流语义不对等。两个平台上叫同一个名字的状态，实际含义可能不同。

1. 先梳理现有工作流，把每个状态的实际含义写下来，包括谁能进出、触发条件是什么。
2. 做字段映射表，特别是自定义字段，逐个人工确认，不要依赖自动映射。
3. 先迁移 1 个完整项目做验证，跑完一个完整周期再批量迁移。
4. 保留旧系统只读访问至少 3 个月，作为异常情况下的兜底。

我们当时这四步走完用了 4 个工作日，过程中发现 61 个自定义字段需要人工确认，其中 9 个在旧系统里已经废弃但仍在使用中，如果不做人工确认会一并迁过来，造成后续数据混乱。

七、不同情况下的取舍

任何机制都有代价。这一节讲清楚这套方案的边界，避免被当成万能药。

1. 立项周期长一点还是短一点

周期短的好处是响应快、浪费少；代价是决策信息不充分，可能出现”通过得太容易”。周期长的好处是判断更稳；代价是机会窗口可能关闭，且高不确定性项目在等待期间会悄悄走流程外通道。

我的判断标准是看机会窗口的可逆性。如果错过这个窗口还有替代机会，可以适当延长周期换判断质量；如果窗口一旦错过就不再有，周期必须让位于速度，此时应该缩小第一次资源承诺，而不是缩短判断时间。

2. 流程刚性还是灵活

流程刚性强的组织，立项质量稳定但创新项目容易被压制；流程灵活的组织，创新活跃但资源容易被无序消耗。

折中方案是分级刚性：G0 阶段几乎不设刚性要求，任何想法都能低成本提交；G1 要求四要素齐全，但评审标准由部门自定；G2 则完全刚性，必须提供验证数据、必须走固定评审会、必须有明确退出条件。这样既保住了创新的入口宽度，又守住了大额资源的闸门。

3. 私有化部署还是 SaaS

私有化部署的优势是数据可控、可深度定制、长期成本可预测；代价是初始部署成本高、版本升级需要自己安排、需要有人维护环境。SaaS 的优势是上线快、免维护；代价是数据在外部、定制空间受限、长期订阅成本随人数线性增长。

决策的关键变量不是人数，而是数据敏感度和定制深度。如果研发数据涉及未公开产品设计或客户敏感信息，私有化几乎是必选项。如果只是通用项目管理，且团队规模在 100 人以下，SaaS 的总体拥有成本通常更低。

4. 自研立项系统还是采购现成平台

自研的优势是百分百贴合流程；代价是需要持续投入开发和维护，且流程一变就要改代码。采购的优势是功能成熟、迭代快；代价是部分个性化需求需要用配置变通。

我的经验判断是：如果年立项项目数少于 30 个，或者组织规模小于 300 人，不要自研。自研一套能跑三级门、能做资源组合视图、能保留完整审计日志的系统，初始开发加上两年维护，保守估计需要 150 人天以上，这个投入在中小规模组织里收不回来。

5. 审批层级多还是少

层级多的好处是风险控制严；代价是每一层都在做”不求有功但求无过”的判断，实际决策质量往往不升反降。层级少的好处是决策快、责任清晰；代价是单点判断失误的影响面大。

我的建议是把层级和资源承诺量级绑定：G1 最多 2 级、G2 最多 3 级。审批层级的价值不在于人多，而在于每一层都能提供别人提供不了的信息。如果某一层的作用只是”再确认一遍”，它就应该被删掉。

结语：把立项从”审批动作”变成”周期能力”

回到开头那家 300 人公司。三个周期跑完之后，立项通过率从 41% 升到 76%，立项平均耗时从 11 天降到 3.4 天，立项后两个月内终止的项目占比从 40% 降到 11%。但在我看来，最重要的变化不是这些数字。

最重要的变化是：团队开始把”停掉一个项目”当成正常动作，而不是失败。在第二个周期里，有一个投入了 4.2 人月的项目在第 6 周被主动终止，原因是验证数据显示目标假设的达成率只有 8%。团队花了半天做复盘，把结论写进台账，然后正常进入下一个项目。整个过程没有争执，也没有人觉得需要解释什么。

这才是周期落地方案的真正价值：它把立项从一次性的、带情绪的重量级决策，变成了一系列轻量的、可逆的、有记录的判断。项目成员在这个过程里不再是被动填表的人，而是假设的提出者和验证的执行者。

如果你准备动手，我建议按这个顺序推进，不要跳步：

1. 本周：把现有立项模板里无法在结项时验证真假的字段全部删掉，通常能砍掉一半以上。
2. 下周：为最近三个立项项目补写退出条件，写成可判定的语句，然后拿给执行成员看，问他们”这个条件触发时你信不信”。
3. 两周内：选 2 个项目试点三级门，G0 只做口头确认并在台账登记，不设任何审批。
4. 一个月内：把四要素做成工具里的必填字段，加上”验证人不得与提案人相同”的规则校验。
5. 一个季度内：把 G2 评审固定成例会，并建立跨项目的资源占用视图。

最后一条提醒：不要一开始就追求流程完美。我见过太多团队在设计阶段花了三个月，画了十几版流程图，结果上线第一天就被第一个真实项目推翻。立项机制的迭代速度取决于你跑了多少个周期，而不是设计了多久。先跑起来，让真实数据告诉你哪里需要改。