立项审批最佳实践：项目成员项目立项制度设计，常见问题

我见过最贵的一次立项审批，是一张填了 6 个项目成员、走了 5 级审批、盖了 4 个部门章的立项单。通过后的第 11 天，项目经理在群里说了一句：“这个项目实际是我和另外一个人在干。”那张单子上另外 4 个人的名字，从立项那天起就没有在任务看板上出现过一次。

复盘这件事时我发现，问题既不在审批层级不够，也不在审批人不认真，而在于“项目成员”这一栏从设计之初就被当成了填名字的礼貌性字段，而不是一份资源承诺。项目立项制度真正失效的地方，几乎都藏在这一栏里。

这篇文章不讲立项审批的标准定义，也不给你一套万能模板。我把它拆成三件事：立项制度到底该解决什么问题、项目成员字段该怎么设计、以及不同规模的组织在效率和管控之间该怎么做取舍。文中的数据来自我在几家 100 人以上企业做研发效能和 PMO 流程重构时的观察与样本推演，标注为示意数据的地方请按情景模拟理解，不要当成行业统计。

一、核心结论：立项审批的本质是资源承诺，不是流程仪式

先把结论放在最前面。绝大多数立项制度做废，不是因为审批流画错了，而是因为设计的锚点选错了。审批锚点一旦选错，后面所有的表单、节点、权限都是在给一个错误的问题做精细化。

1. 立项审批真正只解决三个问题

我在设计或重构立项制度时，会先把所有需求压缩成三个必答题。任何不能回答这三题的字段和审批节点，都应该被删掉。

• 值不值得做：这个问题决定了立项的“价值判断”，对应的是业务目标、预期收益、不做会怎样。
• 用什么资源做：这个问题决定了立项的“资源承诺”，对应的是项目成员、投入比例、起止时间、来源部门。
• 什么条件下停：这个问题决定了立项的“退出机制”，对应的是阶段门、验收标准、再审批触发条件。

现实中大量立项单，第一题回答得很热闹，第二题填得很潦草，第三题根本没有。于是立项审批变成了一场关于“要不要做”的表态会议，而没有人对“谁来做、做到什么时候、中途怎么停”负责。

2. 项目成员是立项单上唯一的“资源凭证”

预算金额代表钱，项目成员代表时间。但钱花出去是可以报销、可以审计、可以进成本中心的，而时间花出去之后什么都不会留下。这就是为什么项目成员这一栏在立项单上最容易被敷衍。

一个可用的项目成员字段，至少要能推出人天：成员 × 投入比例 × 周期 = 人力预算。如果这三个变量缺任何一个，立项单上的人力承诺就是不可验证的，审批人也没有任何依据判断这个项目到底占用了多少稀缺资源。

我通常会把项目成员字段设计成四个子字段：成员姓名、在项目中的角色、投入比例（百分比区间）、承诺起止日期。少了“起止日期”，你就无法判断一个被 4 个项目同时占用的骨干，到底是忙三个月还是忙一年。

3. 审批层级应该跟“资源冲突度”挂钩，而不是跟金额挂钩

这是我最想强调的一条反常识判断：一个 20 万元但不动用任何跨部门稀缺资源的项目，风险远低于一个 5 万元但要从核心平台组抽走 3 个人的项目。金额是财务口径，资源冲突才是交付口径。

按金额分级的审批流，会把大量注意力消耗在“钱多钱少”上，而对真正会拖垮交付的资源抢占视而不见。按资源冲突度分级，则要求立项单必须回答：这个项目要抽走的人，现在是不是已经有别的承诺？他所在的部门负责人是否知情并同意？

二、背景与真实场景：立项审批是怎么一步步退化成盖章的

没有哪家公司是故意把立项制度做成盖章机器的。它是在一次次“这个项目比较急、先过去吧”的妥协中逐步退化的。我想用一个具体的现场还原这个过程。

1. 一个 340 人研发团队的立项现场

这家企业做工业设备，研发加产品大约 340 人，2023 年第二季度一共提交了 47 个立项申请。我拿到数据后做了几个统计：立项单平均填写耗时 22 分钟，审批平均耗时 5.8 天，47 个申请里只有 3 个被驳回或要求修改，通过率 93.6%。

更值得关注的是另一组数字：47 个项目里，有 29 个在立项通过后的 30 天内发生过成员变更，其中 17 个变更幅度超过 30%。换句话说，审批时承诺的资源，和实际执行的资源，是两套东西。

我把这 47 张立项单的“项目成员”字段单独抽出来看，发现 41 张只填了姓名，其中 26 张连部门都没写；只有 6 张填了投入比例，而且其中 5 张的比例合计超过了 100%。这张表实际上不具备任何资源承诺功能。

2. 项目成员的三种填写方式，对应三种结局

我把见过的立项单归类，项目成员字段基本只有三种写法，而它们几乎决定了项目的三种命运。

1. 只填名字，不填比例和时间：审批人无法判断资源占用，成员本人也不知道自己被立项了。结局是立项后成员不到场，项目经理临时抓人。
2. 填了比例，但所有人都是 100%：看起来严谨，实际上是把填报责任转移给了填表人。一个成员同时出现在 3 个 100% 的项目里，这在数学上就不成立。
3. 填角色、比例、起止日期，并且需要成员所在部门确认：这是唯一能在审批阶段暴露资源冲突的写法，代价是立项单填写时间会从 22 分钟增加到 40 分钟左右。

3. 立项审批退化的四个推力

理解了现场，就能看清退化的动力来自哪里。我把它们总结为四个推力，它们往往同时作用。

• 考核导向：当立项通过率被当成 PMO 或部门的效率指标时，审批人会本能地少驳回。
• 审批人不懂资源：财务看金额、法务看合同，没有人对“这个人这三个月还能不能干别的”负责。
• 系统不支持：立项单是孤立表单，和工时、排期、成员档案都不连通，想核对冲突也没有数据。
• 没有回流数据：立项时的承诺和结项时的实际从不对比，制度自然没有改进压力。

信息在这条链路上是一路衰减的。我在一家 600 人企业做过一次抽查，追踪了 100 张立项单从提交到成员真正投入的全过程，衰减程度相当惊人。

三、常见误区拆解：八个把立项制度做废的设计

下面这八个误区，是我在复盘立项制度时出现频率最高的。它们单独看都不致命，但组合在一起，就构成了一套“看起来很严谨、实际上不产生任何约束”的制度。

1. 误区一：把项目成员当成通讯录字段

最典型的症状是：立项单上有“项目成员”一栏，可以填多个人，但系统只校验“不能为空”，不校验比例、不校验时间、不校验是否冲突。填表人自然会用最省事的方式通过校验。

判断标准很简单：如果这张立项单无法算出这个项目占用了多少人天，那这一栏就是装饰。装饰性字段会让审批人产生“我已经看过资源了”的错觉，比没有这一栏更危险。

2. 误区二：审批流按金额分级，不按资源冲突分级

金额分级的好处是客观、好量化、财务系统天然支持。但它的致命缺陷是：金额和交付风险不是同一条曲线。我见过一个 3 万元的内部工具项目，因为要占用唯一的数据库专家两个月，直接导致另一个百万级项目延期六周。

更合理的做法是同时使用两个维度：金额决定是否需要财务介入，资源冲突度决定审批层级。两者取较高者，而不是只用其中一个。

3. 误区三：立项即永久立项，没有阶段门

很多公司的立项审批只有“通过”和“不通过”，一旦通过，项目就拥有了永久身份证。没有阶段门，意味着没有人需要在项目跑偏时重新做一次判断。

我通常会设置两类再审批触发条件。事件型触发：成员变更超过 30%、周期延长超过 50%、目标发生实质变化。时间型触发：跨季度项目在每季度末做一次轻量复核，只回答“还做不做、还要不要这么多人”。

4. 误区四：投入比例缺失，或者全员填 100%

投入比例是立项单上信息密度最高的一个字段，也是最容易被滥用的。全员 100% 的本质是填表人不敢做承诺，于是把所有不确定性推给了执行阶段。

我的建议是允许填写区间，比如“40%-60%”，但要求区间上下限之差不超过 20 个百分点。区间制比精确值更贴近现实，也比不填更有约束力。同时，系统应该对同一成员在同一时间段的投入比例做合计校验，超过 100% 直接标红。

5. 误区五：审批人越多越严谨

这是最普遍也最昂贵的误区。每增加一个审批节点，增加的不是判断质量，而是责任分散。当五个人都可以签字时，没有一个人真正对结果负责。

我在重构时会把审批节点压到三级以内，并且明确每个节点的唯一判断职责：业务负责人判断值不值得做，资源负责人判断人从哪来，财务或合规判断红线是否触碰。职责重叠的节点一律合并。

6. 误区六：把立项通过率当成 PMO 的绩效指标

只要立项通过率进入考核，审批人的理性选择就是少驳回。这个指标看起来在衡量效率，实际上在鼓励放水。

更健康的度量是“立项后 30 天成员变更率”和“阶段门复核后的终止率”。前者衡量承诺质量，后者衡量退出机制是否真的在工作。一个健康的立项制度，应该允许一定比例的项目在阶段门被合理地终止，而不是全部跑到最后。

7. 误区七：立项系统与工时、排班、绩效系统不通

这是技术层面的误区，但对制度有效性的杀伤力最大。立项时承诺了 60% 的投入，工时系统里实际只有 15%，如果这两个数字从未被放在一起看过，那立项承诺就永远不会被验证。

打通不需要一步到位。最低成本的起步方式，是在项目结束后自动生成一份“承诺 vs 实际”的对比，推送给项目经理和资源负责人。仅仅是把这份对比做出来并推出去，就能显著改变填报行为。

8. 误区八：成员变更走口头，不走流程

立项审批再严格，如果成员变更只需要在群里说一声，整个制度的约束力会在第一次变更时归零。我见过太多项目，立项单上写着 6 个人，执行到第二个月变成 3 个人，没有任何记录。

正确的做法不是禁止变更，而是让变更留下痕迹并触发一次轻量再确认。变更超过一定幅度时，自动回到资源负责人那里确认一次，这比重新走一遍完整立项流程要轻得多。

四、专业判断逻辑：立项制度的五层结构

拆完误区，接下来讲怎么建。我习惯把立项制度拆成五层，从下往上依次是对象定义、承诺模型、审批矩阵、阶段门、数据回流。这五层有严格的依赖关系，跳过任何一层都会导致上层失效。

1. 第一层：定义立项对象，项目、需求、任务的分界线

很多公司的立项制度之所以臃肿，是因为所有东西都要立项。一个两天的配置修改走完整立项流程，结果就是大家开始批量伪造立项单，或者把大项目拆成一堆小需求绕开审批。

我会用三条硬线来切分：涉及跨部门资源、周期超过一个迭代或一个月、需要独立预算或对外承诺。三条命中任意两条才需要正式立项，其余走轻量登记即可。这条线画清楚了，立项单的数量通常会下降 40% 以上，而真正重要的项目反而更容易被看见。

2. 第二层：成员承诺模型，角色、比例、起止、来源部门

这是整篇文章的核心。我给项目成员字段设计过一个四要素模型，四要素缺一不可。

• 角色：不是职位名称，而是项目内的职责，比如“后端负责人”“数据接口对接人”。角色决定这个人在这件事上是否不可替代。
• 投入比例：建议用区间，如 30%-50%，并强制同一成员在同一时间段的合计不超过 100%。
• 承诺起止日期：没有日期就没有冲突判断的依据，这一条最常被忽略。
• 来源部门与确认人：成员所在部门的负责人必须知情，否则这就是一次未经授权的资源借用。

下面是我在配置立项表单时常用的一段字段定义，可以直接作为配置参考。

project_member:

field: member_name # 成员姓名

required: true

field: project_role # 项目内角色

required: true

type: enum

options: [负责人, 核心成员, 支持角色]

field: allocation_ratio # 投入比例区间

required: true

type: range

rule: "max – min <= 20"

conflict_check: "同一成员同期合计 <= 100%"

field: commitment_period # 承诺起止日期

required: true

type: date_range

field: source_department # 来源部门

required: true

field: department_approver # 部门确认人

required: true

trigger: "自动通知并需确认"

这段配置里最关键的两条规则是 conflict_check 和 department_approver。前者让系统自动发现资源冲突，后者让资源借用在发生前就被知情。这两条一旦落地，立项单的填写时长会增加十几分钟，但立项后 30 天的成员变更率通常会腰斩。

3. 第三层：分级审批矩阵，按资源冲突度而非金额

有了四要素模型，分级就有了依据。我用一张矩阵来表达这个逻辑，纵轴是资源冲突度，横轴是金额或对外承诺等级。

这张矩阵的实际价值在于，它让大部分项目落在了一级或两级审批上，只有真正抢占稀缺资源的项目才需要走到更高层级。审批层级不是用来体现项目重要性的，而是用来匹配资源决策权限的。

4. 第四层：阶段门与再审批触发条件

阶段门不是每个项目都要设。我给的经验值是：周期超过 3 个月或跨季度的项目设阶段门，其余项目只在成员变更超过 30% 时触发再确认。

阶段门的复核内容应该极简，只回答三个问题：原定目标是否仍然成立、原定成员是否仍然可用、继续投入的资源是否仍然值得。每个问题只允许选是或否，选否就进入终止或调整流程。复杂的复核表只会让人敷衍了事。

5. 第五层：数据回流与度量指标

制度能不能自我改进，取决于有没有回流数据。我建议只盯四个指标，不要贪多。

1. 立项单成员字段完整率：反映填报质量的下限。
2. 立项后 30 天成员变更率：反映承诺质量，这是最灵敏的指标。
3. 同一成员同期投入合计超过 100% 的人次数：反映资源冲突的真实规模。
4. 阶段门复核后的调整率：反映退出机制是否真的在运转。

审批层级并不是越多越好，这一点可以用数据直接说明。我把不同层级数量下的拦截效果和成本放在一起对比，结论非常清楚。

五、具体案例与数据观察：一家 400 人企业的立项制度重构

接下来是一个完整案例。这家企业是做企业级软件的，研发加产品约 400 人，2023 年初找我做立项流程重构。选择它是因为它的数据相对干净：立项单、工时、项目结项记录都在，只是从来没有放在一起看过。

1. 重构前的基线

重构前的状态很有代表性。立项审批平均耗时 6.5 天，跨部门资源冲突导致的返工平均每季度 23 次，成员承诺到位率只有 54%，项目按期交付率 59%，立项单填写完整率 41%。

最麻烦的不是这些数字本身，而是它们彼此之间没有因果关系被识别出来。当时的共识是“交付差是因为执行不力”，而没有人把交付问题和立项时的资源承诺质量联系起来。

2. 关键改动：六条，三个月内全部落地

我们没有推翻原有制度，只做了六处改动。每一条都对应前面讲过的某层结构。

1. 项目成员四要素化：角色、投入比例区间、承诺起止日期、来源部门确认人，四项全部必填。
2. 加入同期投入合计校验：同一成员在同一时间段的投入比例合计超过 100% 时，系统直接阻止提交。
3. 审批锚点从金额改为资源冲突度：金额只决定是否需要财务介入，不决定审批层级。
4. 审批层级压到三级以内：取消了原来两个职责重叠的会签节点。
5. 成员变更流程化：变更超过 30% 时自动通知资源负责人确认，不需要重走完整立项。
6. 结项自动生成承诺 vs 实际对比：推送给项目经理和资源负责人，不进考核，只做反馈。

第三条和第四条在推行时阻力最大，因为涉及审批权限的重新分配。我们用了两个迭代做试点，先在一个事业部跑，用数据说服了其余部门。

3. 12 个月后的数据变化

重构后满 12 个月，我们做了一次完整对比。变化幅度超出了我最初的预期，尤其是成员承诺到位率这一项。

4. 平台能力如何支撑这套制度：以 PingCode 为例

（1）为什么最终选择私有化部署

这家企业的客户里有几家对数据驻留有硬性要求，项目信息不能出内网。所以选型时第一个过滤条件就是支持私有化部署。PingCode 主要服务中大型企业及 100 人以上组织，私有化部署是其标准能力之一，这让它在第一轮筛选里就留了下来。

（2）历史数据迁移是最大的隐性成本

他们原来的研发管理平台积累了 1,180 个历史项目和约 4.6 万条工作项，研发团队对既有数据的依赖很强，迁移失败就意味着整个方案不可行。PingCode 支持 Jira 平滑迁移，这是我们能在一个季度内完成切换的关键前提。

我把实际的迁移阶段耗时整理出来，这类数据在选型阶段几乎没人给你，但恰恰是决策最需要的信息。

（3）审批规则与校验必须能配置，而不是靠人盯

四要素模型里最有效的规则是“同一成员同期投入合计不超过 100%”。这条规则如果靠人核对，一定会在第三个月失效。它必须落在系统里，提交时就拦住。

这也是我选型时最看重的一点：立项单的字段、校验规则、审批分支能不能由业务方自己配置。如果一个流程改动需要提研发需求排期两周，那这套制度实际上是不可迭代的。

（4）对有国产替代诉求的组织的适用性

这家企业的诉求很典型：既想要国际化平台的产品成熟度，又需要数据可控和本地化支持。在这类场景下，支持私有化部署、支持从既有平台平滑迁移的国产平台是一个务实选项，PingCode 在这条路径上的工程化程度相对完整，可以纳入国产替代的候选清单。

5. 我们踩过的三个坑

上面讲的是结果，这里讲代价。这三件事如果重来一次，我会处理得不一样。

第一个坑是校验规则上线太猛。第一周就有项目经理反馈“填不进去”，因为历史并行的项目本身就超配。我们的解决办法是给存量项目一个 60 天的宽限期，只警告不阻断，新立项才强校验。

第二个坑是部门确认人机制被滥用。部分部门负责人设置了自动确认规则，等于绕过了确认环节。后来我们改成确认时必须填写一句资源安排说明，敷衍率立刻下降。

第三个坑是阶段门一开始设得太重。第一版阶段门有 18 个字段，结果没有一个项目认真填。压缩到 3 个是否题之后，反而真正开始起作用了。

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

同一套制度不能套在所有组织上。下面按组织规模给出我的建议，每一条都包含“做什么”和“不要做什么”。

1. 50 人以下的组织：只做登记，不做审批

这个规模下，创始人或技术负责人对每个人的工作状态一清二楚，任何正式审批都是纯成本。你需要的是可回溯的记录，不是审批节点。

• 要做：保留一份轻量项目登记表，记录项目目标、负责人、大致投入的成员。
• 不要做：不要设审批流，不要设阶段门，不要做投入比例校验。
• 唯一例外：当同一个骨干同时出现在三个以上项目时，才需要一次人工介入。

2. 100 至 500 人：两级审批 + 成员承诺表

这个区间是制度收益最高的阶段。人已经多到靠印象管不住，但还没有多到需要复杂的资源池。核心动作是把项目成员四要素做实。

• 要做：业务负责人 + 资源负责人两级审批，成员四要素必填，同期投入合计校验。
• 要做：立项后 30 天成员变更率进入月度回顾，但不进个人考核。
• 不要做：不要按金额分级，不要超过三级审批，不要给每个项目都设阶段门。

3. 500 至 2000 人：三级审批 + 资源池 + 阶段门

这个规模下，资源冲突开始变成常态，靠单点确认已经不够，需要有一个能看到全局资源占用的视图。

• 要做：建立共享资源池视图，按角色和技能维度展示未来 3 个月的占用率。
• 要做：跨季度项目一律设阶段门，复核只回答三个是否题。
• 要做：立项系统和工时、排期系统打通，至少做到结项自动生成承诺 vs 实际对比。
• 不要做：不要为了资源池再建一套独立的表格体系，一定会在两个月内和主系统脱节。

4. 2000 人以上或多事业部：矩阵管控 + 资源委员会

到这个规模，问题不再是“要不要审批”，而是“谁有权跨事业部调资源”。单纯加审批层级已经无效，需要的是治理结构。

• 要做：建立资源委员会，只处理重度资源冲突（占比约 10%-15% 的立项申请），其余全部下放。
• 要做：每季度做一次跨事业部的资源再平衡，把已立项但进展停滞的项目资源回收。
• 不要做：不要让资源委员会审批所有项目，那会变成最大的瓶颈。

5. 强监管或交付型组织：合规门与合同门前置

如果你的组织受行业监管，或者以对外交付为主，立项审批里必须增加合规判断和合同判断。这两项不应该混进资源审批，而应该作为独立的前置门。

• 要做：合规门回答“这个项目的业务模式是否需要备案或评审”，合同门回答“是否已有明确的交付边界和验收标准”。
• 要做：人力测算以合同工期倒推，先算清楚需要多少人力，再看人从哪里来。
• 不要做：不要让合规判断和资源判断在同一个节点由同一个人做，两者的判断依据完全不同。

七、不同情况下的取舍

制度设计到最后，几乎都是取舍问题。没有哪一套方案是全面占优的，你只能选择承担哪一类成本。下面是我最常被问到的四组取舍，以及我的判断依据。

1. 效率与控制：把审批花在 15% 的项目上

严格审批一定会拖慢项目启动，这是无法消除的。你能做的是让这份延迟只发生在真正需要它的项目上。我的经验值是：大约 10%-15% 的项目属于重度资源冲突，值得走完整流程，其余项目应该走轻量通道。

具体做法是用投入比例合计作为分流器：成员同期投入合计低于 30% 的项目走简易登记，30%-60% 走两级审批，超过 60% 或涉及唯一技能才走完整流程。这样既保住了控制力，又不会让所有项目一起排队。

2. 立项颗粒度：越细管得越准，也越容易造假

立项颗粒度是个典型的双向陷阱。颗粒度太粗，资源冲突看不见；太细，团队会通过拆单来规避审批。我见过一个团队把一个 200 人天的项目拆成 9 个小需求，全部绕过立项。

我的判断标准是：立项颗粒度应该对齐“资源决策的最小单元”，而不是对齐交付物拆分。如果两个子任务由同一批人在同一时间段完成，它们就应该在同一个立项单里。

3. 集中管控与事业部自治：分层而不是二选一

完全集中会导致审批排队，完全自治会导致资源被事业部锁死。可行的做法是分层：事业部内部资源调配完全自治，跨事业部资源借调必须走集中审批。

这条规则看上去简单，但它把 80% 以上的审批量留在了事业部内部，只有真正的跨部门冲突才上升。这也是我前面说“资源委员会只处理 10%-15% 立项申请”的实现方式。

4. 自研与采购：算清三年总成本再决定

立项审批涉及表单配置、审批流、资源冲突校验、工时回流，这些功能自研的成本常被严重低估。我在评估时习惯算一笔三年账。

我的判断是：如果你的组织年立项量低于 200 个，自研几乎没有经济性；超过 500 个且有强定制需求，才值得考虑自研核心校验逻辑。而无论哪种选择，优先确认平台是否支持私有化部署和从既有系统的平滑迁移，这两项会在切换阶段决定项目成败。

八、总结与下一步：三个反直觉判断和 90 天落地路线

写到这里，我把整篇文章的判断压缩成三条，它们都跟直觉相反，但在我经手的项目里反复被验证。

• 立项审批的质量，取决于项目成员这一栏，而不是审批层级。成员四要素做实，一级审批也可能有效；成员栏空着，五级审批也只是盖章。
• 审批应该按资源冲突度分级，而不是按金额分级。金额是财务语言，资源冲突才是交付语言，用错了语言，审批就永远抓不到真正的风险。
• 严格度存在最优区间，过了就会反弹。三层审批、十来个必填字段、三个是否题的阶段门，在我见过的组织里是最稳的配置，再往上加只会催生规避行为。

1. 90 天落地路线

如果你准备动手，我建议按下面的节奏推进，不要一次性全上。

1. 第 1-2 周：摸基线。抽取过去一个季度的立项单，统计成员字段完整率、立项后 30 天成员变更率、同期投入超 100% 的人次数。没有基线，后面无法证明改进。
2. 第 3-6 周：改字段和校验。把成员四要素做成必填，加上同期投入合计校验，先只警告不阻断，给存量项目 60 天宽限期。
3. 第 7-9 周：调审批矩阵。把审批锚点从金额改为资源冲突度，合并职责重叠的节点，目标是把审批层级压到三级以内。
4. 第 10-12 周：加反馈回路。结项时自动生成承诺 vs 实际对比，推送给项目经理和资源负责人，先不进考核。

2. 下一步你可以立刻做的一件事

如果你现在只做一件事，我建议是：把最近 20 个已立项项目的成员字段导出来，看有多少张单子能算出人天，再看这些人的实际投入和承诺差了多少。这个对比出来的那一刻，你就不需要再向任何人解释为什么要改立项制度了。

制度的价值不在于它有多完备，而在于它是否让资源承诺变得可见、可核对、可追溯。项目成员这一栏，恰恰是这一切的起点。