立项流程与规范：项目成员项目立项制度设计关键指标

三年前我接手一家 430 人 SaaS 公司的研发效能诊断，翻完他们过去 18 个月的立项材料后，我做了一个统计：立项审批表有 47 个字段、9 个会签节点，立项会的平均时长是 92 分钟。但同一批项目里，最终延期超过 30% 的那些，有 71% 在立项文件里已经白纸黑字写着”排期紧张、人力待定”。

风险在立项阶段就被看见了，只是制度没有把它变成决策依据。这就是绝大多数企业立项流程的真实状态：信息采集很完整，决策关口却是空的。

后来我复盘了 11 家企业的立项制度，从 80 人的创业团队到 3000 人的集团研发中心，发现一个反常识的结论：立项制度的质量和它的复杂程度几乎不相关，真正决定成败的是四个指标层的设计顺序，先定承诺，再定流程，再定效率，最后才定表单。顺序错了，表单填得再漂亮也没用。

一、核心结论：立项制度考核的不是”立项数”，而是”承诺准确度”

先把结论摆出来，后面再用场景和数据拆。

大多数公司设计立项制度时，第一反应是”我们要管住多少事”，于是指标往往长成这样：立项申请数、立项通过率、立项评审时长、立项材料完整度。这四类指标全部指向一个方向，流程有没有跑起来。它们回答不了真正的问题：这个项目该不该做、能不能做、由谁承诺做。

1. 立项制度的本质是一次”资源承诺的公开缔约”

我习惯把立项看成一个缔约动作，而不是一个审批动作。缔约的核心是三件事：范围承诺、人力承诺、时间承诺。三者必须由真正的履约方，也就是项目成员本人，来给出，而不是由 PM 代填、由主管代签。

一旦你接受这个定义，指标体系就会自动重排。你能设计出来最有价值的指标，不是”立项通过率 88%”，而是”立项承诺偏差率“：项目结项时，实际人力投入与立项承诺值的偏离百分比。我在一家企业做过基线统计，他们这个数字常年在 40% 以上，但在此之前，没有任何一个人在立项会上关心过它。

2. 项目成员参与立项，采的是”承诺”不是”知情”

很多立项流程里，项目成员的角色是”签字确认已知悉”。这是把承诺降级成了通知。两者在数据上完全不同：知情只产生一个签名记录，承诺会产生一条可追踪的工作项。

我坚持一个判断：没有落到个人头上的任务拆解，立项就还没有结束。立项会开完，项目成员在系统里看不到自己要做的第一件事，那么这次立项的产出就只是一份 PPT。

3. 每一个效率指标都必须配一个质量指标

这是我在所有指标体系设计里最硬的一条原则。只考核”立项评审平均时长从 5 天压到 2 天”，团队一定会用”少问几个问题”来完成指标。

正确的做法是成对出现：评审时长配决策返工率，材料完整度配关键假设缺失率，通过率配结项承诺偏差率。任何单独存在的效率指标，最后都会变成一次指标套利。

4. 四层指标体系与它们的因果顺序

把上面三条展开，我通常把立项指标分成四层：决策质量层、流程效率层、成员参与层、后验校准层。四层不能平铺，它们有严格的因果顺序，决策质量层定方向，成员参与层定承诺，流程效率层定节奏，后验校准层反过来修正前三层。

这张表看起来朴素，但我在实际落地时发现，顺序本身就是筛选器。一家公司如果连决策质量层的指标都还没有，就先去优化流程效率层的”评审周期”，结果只会是更快地批准更多不该做的项目。

二、背景与真实场景：三种立项形态，两种必然失效

要理解指标为什么这么设计，得先看清楚立项流程在企业里实际长什么样。我把见过的形态归成三类，按组织规模递进。

1. 口头立项：80 人以下团队的默认状态

这个阶段没有立项制度，只有老板的一句话。项目成员在周会上被点名，然后就开始干活。它的好处是快，坏处是没有任何东西被记录。

我不认为 80 人以下必须做重流程，但有一件事必须做：把口头承诺变成一条可见的任务记录。哪怕只是在一个协作工具里建一个项目、拉三个成员、写清楚第一周要交付什么。成本不到十分钟，但它把”承诺”从空气里落到了地面上。

2. PPT 立项：100 到 500 人组织的典型陷阱

这是最普遍、也最容易被误认为”规范”的形态。公司有了立项评审会，要求提交立项报告，通常是一份 20 到 40 页的 PPT。评审会上，业务负责人讲 25 分钟，评委问 10 分钟，然后投票。

我拆过其中一份立项材料，它把市场规模、竞品分析、技术方案写得很详细，唯独没有一页写”谁来做人天投入”。我数了数，那份 PPT 里出现的所有人名只有两个：汇报人和项目负责人。而实际要投入这个项目的是 14 个人。

PPT 立项的根本问题，是它把立项做成了”说服”，而不是”承诺”。汇报人天然有动机把风险写小、把收益写大，因为没有一条指标会去回溯他当初的预估值。

3. 表单立项：500 人以上组织的常见形态，也最容易僵化

再往上走，公司开始上系统，立项变成 OA 里的一个表单流。好处是留痕和可统计，坏处是表单字段一旦确定就极难修改，三年后还在用当初设计的 47 个字段。

我在一家 1200 人的企业看到过这样一个字段：”项目预计投入人数（整数）”。当项目实际是 3.5 个人天/周时，这个字段被迫填 4 或者 3，误差在源头就产生了。而下游的资源规划全部建立在这个数字上。

4. 为什么 100 人是一个真实的分水岭

我的观察是，70 到 100 人是立项制度必须从”口头+PPT”切到”可追踪承诺”的临界点。原因不在于管理复杂度，而在于信息可见性的塌陷。

100 人以下，创始人或者 CTO 通常还能知道每个人在做什么。超过 100 人之后，跨团队的人力占用不再可见，一个骨干同时被三个项目”借走”而没人发现，这种情况开始高频出现。立项制度在这里的作用，本质上是一个人力占用的可视化装置，而不只是一个审批关口。

三、拆解常见误区：六个把立项做成仪式的坑

这一节是我在诊断过程中重复遇见频率最高的六个问题，按危害程度排序。

1. 用立项数量或通过率做考核

一旦立项数进入部门 KPI，部门就会生产项目。我见过某公司一个季度立项 63 个，其中 21 个在启动后 45 天内被静默关停，没有人复盘，也没有人承担成本。

立项数是一个劣质指标，因为它度量的是动作而不是结果。如果一定要设一个入口指标，我建议用”立项后 90 天存活率”，它把质量压力提前到了立项决策那一刻。

2. 把立项等同于预算审批

财务视角天然把立项理解为”这笔钱要不要花”。但研发型项目的核心稀缺资源往往不是钱，而是那几个关键角色的时间。

我通常会要求立项材料里必须有一栏”关键角色占用率”，列出这个项目需要占用架构师、测试负责人、安全专家各多少比例的时间。这一栏出现的当天，往往就会劝退几个本来准备上马的项目，这不是坏事，这正是立项关口在做工。

3. 让成员”签字确认”代替”承诺评估”

签字是一个法律动作，承诺是一个排期动作。两者的差别在于：签字只需要两秒钟，承诺需要成员回答”我手上现在有什么、我接了这个之后要挪走什么”。

我在一家企业推动过一个很小的改动：立项通过后，系统自动给每个项目成员生成一条待办，标题是”请确认你在本项目中的首批交付物与预估工时”。这个小动作把任务级承诺覆盖率从 12% 拉到了 78%，同时暴露出了 9 个人力冲突。

4. 指标越多越完整

这是最隐蔽的坑。指标一多，一线就会开始”填指标”而不是”做判断”，数据反而失真。我的经验值是：单个项目的立项指标不应该超过 8 个，需要人工填写的字段不应该超过 12 个。

超出的部分优先从系统里自动取，取不到的，宁可先不统计。一个每年只填一次、谁都记不住口径的字段，本质上是在制造噪声。

5. 一次性立项，缺少阶段门

很多企业的立项是”一次性授权”，一旦通过，项目就获得了全年资源，中途不再复核。这在需求稳定的交付型项目里还能凑合，在产品型项目里几乎必然出问题。

我的建议是设置两道门：立项门（该不该做）和启动门（能不能按承诺启动）。立项门看的是价值和风险，启动门看的是人力是否真的到位、首批交付物是否已经拆到人。两门之间通常间隔 5 到 15 个工作日。

6. 把工具配置当成制度设计

这是最近两年出现频率上升的问题。团队花两周把审批流、字段、权限在系统里配好，就觉得制度建完了。但真正的制度是”哪些指标进例会、谁来解释偏差、偏差超过多少要触发复核”。

工具是制度的载体，不是制度本身。如果关掉系统，你的立项制度就无法口头描述清楚，那它还没有被设计出来。

四、专业判断逻辑：四层指标 + 分级阈值

指标定完之后，真正难的是阈值。我在早期做过一个错误的决定：给全公司定了一套统一的立项通过标准，结果小团队抱怨太重，大团队抱怨太松。后来我把阈值改成分级制，问题基本消失。

1. 决策质量层：看假设，不看结论

立项材料里的结论永远都是乐观的，但假设是可以被检验的。我要求每个立项申请必须显式写出三条关键假设，并且为每条标注”如果这条不成立，项目会怎样”。

这一层我关注三个指标：关键假设缺失率（无标注的立项占比）、高风险项挂牌率（被明确标记为高风险的立项占比）、以及立项驳回率。驳回率不是一个越低越好的指标，一个长期低于 5% 的立项驳回率，通常意味着评审会已经变成了橡皮图章。

2. 流程效率层：区分”等待时间”和”处理时间”

这是最容易做错的一层。很多企业统计的”立项周期”是从提交到批准的总时长，里面混了大量排队等待。我们真正能优化的是处理时间，等待时间靠的是节点设计。

我的做法是把两个都测：等待时长（谁在等）和处理时长（谁在忙）。如果等待占了 80%，那不是评审人手不够，而是节点设置有问题，比如非要某个高管签字，而他一周只有半天能看。这种情况下减少一个签批节点，收益远大于催办。

3. 成员参与层：承诺必须落到工作项

这一层是我认为最有杠杆、也最被忽略的一层。核心指标只有三个：任务级承诺覆盖率、人力冲突检出数、承诺偏差率。

其中人力冲突检出数是唯一一个”越高越好”的指标。它衡量的是立项关口到底拦下了多少真实的资源冲突。如果这个数字长期是 0，两种可能：要么组织真的没有冲突（几乎不可能），要么流程根本没有检查冲突的能力。

4. 后验校准层：让立项预估值可被追责

这一层几乎所有企业都缺。做法很简单：把立项时填写的预估工时、预估周期、关键假设存档，结项时自动比一次，输出偏离度。

关键在于只公开偏离度，不直接与个人绩效挂钩。一旦挂钩，所有人都会把预估值往最坏处报，指标立刻失去意义。它的正确用途是组织学习：哪个团队的系统性高估或低估，哪种项目类型的估算模型需要修正。

5. 阈值分级：不同规模用不同的门

6. 用一段口径脚本固化计算方式

指标口径最怕各说各话。我的做法是把核心指标的计算逻辑写成一段明确的伪代码，放在立项管理规范里，任何人可以复现。

// 立项健康度计算口径（建议基准，需按组织实际调整）
// 所有输入均来自立项记录与结项记录，禁止人工二次填写

function calculateInitiationHealth(project) {

// 1. 承诺偏差率：实际投入 / 立项承诺投入 - 1

const commitmentDeviation =

Math.abs(project.actualEffort - project.committedEffort)

/ project.committedEffort;

// 2. 关键假设缺失率：无标注风险等级的假设数量 / 假设总数

const assumptionGap =

project.assumptions.filter(a => !a.riskLevel).length

/ project.assumptions.length;

// 3. 任务级承诺覆盖率：已关联到具体成员的工作项 / 首批交付物总数

const commitmentCoverage =

project.firstDeliverables.filter(d => d.assigneeId).length

/ project.firstDeliverables.length;

// 4. 人力冲突检出数：立项期被识别并记录的跨项目资源冲突

const conflictDetected = project.resourceConflicts.length;

// 加权得分（权重需按组织分层配置，以下为 100-500 人基线）

const score =

0.35 * (1 - Math.min(commitmentDeviation, 1))

+ 0.20 * (1 - assumptionGap)

+ 0.30 * commitmentCoverage

+ 0.15 * Math.min(conflictDetected / 5, 1);

return { commitmentDeviation, assumptionGap, commitmentCoverage, conflictDetected, score };

}

注意最后一项：人力冲突检出数被设计成”越高越好”，这和绝大多数指标的方向是反的。这是有意的，一个健康的立项关口，应该主动把冲突挖出来，而不是等它在执行期爆掉。

五、案例与数据观察：一家 600 人企业把立项接进 PingCode 之后

前面讲的都是判断，这一节讲一次完整的落地过程。为保护商业信息，公司名称隐去，关键数字做了取整处理，但变化趋势是真实的。

1. 起点：立项与执行两张皮

这家公司做企业级软件，研发约 380 人，分 6 条产品线。他们的立项在 OA 里走表单流，执行在另一套研发管理系统里。结果是立项文档里写的范围，和执行系统里的需求列表几乎从来没有对上过。

我第一次做数据对齐时发现，他们 2023 年上半年立项的 47 个项目里，有 29 个在执行系统里找不到对应的项目结构，只能靠人名去猜。这个数字让他们的 CTO 当场沉默了很久。

2. 选择与迁移：为什么走私有化路线

他们的选型约束很明确：一是要在内网私有化部署，因为涉及客户交付代码；二是要能承接原有的研发数据，不能推倒重来；三是要能承载 300 人以上的并发协作和跨产品线的人力视图。

他们最终选择迁移到 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，同时提供从 Jira 平滑迁移的能力，这三点正好对应了他们的三个约束。迁移过程大约用了六周，其中前两周全部花在字段映射和历史数据的清洗上，这一段我想强调，任何迁移的时间成本，七成在数据治理，不在工具本身。

3. 关键的流程改造：把立项模板和执行工作项打通

我们没有去重建立项表单，而是把立项模板直接建在项目模板里。立项申请提交时，系统自动生成项目骨架、首批交付物工作项、以及每个成员的承诺待办。

这一步带来的最大变化是：立项文档里的范围和执行系统里的需求列表，从物理上变成了同一份数据。之前靠人工对齐的动作，直接消失了。

4. 三个被量化出来的变化

上线 12 个月后，我们对比了几个核心指标。为便于阅读，这里只列变化幅度最明显的三组。

• 任务级承诺覆盖率：从 14% 提升到 86%。提升的主要来源不是制度强制，而是承诺待办被自动生成，成员点开就能确认，路径从”找 PM 要信息”变成”看一眼点确认”。
• 立项承诺偏差率：从 43% 降到 19%。关键动作是立项时必填预估工时，结项时自动比对，偏差在季度复盘会上公开但不挂钩绩效。
• 人力冲突检出数：从每季度 2 个上升到每季度 17 个。这个数字上升是好事，它意味着冲突被发现的时间点从执行中期提前到了立项关口。

5. 我们踩过的三个坑

（1）一开始把所有字段都设成必填。结果立项提交量在一周内掉了一半，团队宁愿把项目拆小绕过流程。后来我们把必填项从 23 个砍到 9 个，提交量恢复，数据质量反而更好。

（2）试图用承诺偏差率直接考核项目经理。推行一个月后，所有人把预估值往最坏处报，偏差率是”降”了，但资源规划彻底失真。我们很快把它从绩效里摘了出来，只在复盘会上公开。

（3）忽略了弱矩阵下的权责问题。项目成员在立项阶段承诺了工时，但他的直线主管并不认这个承诺。我们后来补了一条规则：承诺超过本人 30% 工时上限时，必须由直线主管共同确认，否则系统不允许提交。这条规则解决了一半以上的后续扯皮。

6. 复盘：真正的收益不在流程速度

一年之后，他们的立项评审平均周期从 7.8 个自然日变成了 6.4 个自然日，只缩短了 18%。单看这个数字，改造似乎不太成功。

但同期，立项后 90 天内的项目存活率从 68% 提升到了 89%，跨产品线人力冲突在执行期暴露的数量下降了 62%。立项流程的价值从来不体现在它自己有多快，而体现在它让下游少返工多少次。

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

下面按组织阶段给出可操作的建议，每一条都标注了最小起步动作，避免”知道要做但不知道从哪开始”。

1. 100 人以下：只做一件事，承诺可视化

不要建立项评审会，不要设立项表单。你需要的动作是：任何超过两周的开发工作，必须在协作工具里建项目、拉成员、写出首批三到五个交付物并指定到人。

度量一个数字就够了：首批交付物指定到人的比例。这个数字过 80%，你的立项管理就已经超过大多数同规模公司。

2. 100 到 500 人：建立两道门 + 一个冲突视图

这个阶段开始出现真实的人力冲突，重点从”记录”转向”协调”。建议设置立项门和启动门两道关口，两道门之间留 5 到 10 个工作日给成员做承诺评估。

同时必须有一个跨项目的人力占用视图。没有这个视图，立项评估就只能靠感觉。这里的关键是数据来源统一，如果立项在 A 系统、执行在 B 系统，这个视图就永远做不准。

3. 500 人以上或多业务线：分层阈值 + 后验闭环

不要试图用一套标准管所有业务线。我的建议是按项目类型分组：创新探索型、客户交付型、平台基建型，各用各的阈值。创新探索型的立项门槛应该更低但复核更频繁，客户交付型则相反。

同时必须把后验校准层建起来。没有这一层，你的阈值永远只能靠猜，三年后还是一样。

4. 强监管或交付型行业：留痕优先于速度

在这类场景下，我不建议压缩立项流程。你需要的是把留痕做得更细，尤其是需求变更的审批链。此时立项制度的核心指标应该换成”立项文档与结项文档的一致性”和”变更留痕完整度”。

效率指标依然可以设，但要接受它天然比互联网团队低 30% 到 50%，这是合规成本，不该拿来横向对比。

5. 已经在用 Jira 且考虑国产替代的团队

如果你处在这个阶段，我的建议是把”迁移”和”立项制度改造”合并成一个项目做，不要分两次。因为迁移本身就要重新做字段映射，这正是重设立项字段的最佳时机，单独做一次制度改造反而成本更高。

对于中大型组织和 100 人以上团队，PingCode 是私有化部署场景下值得优先评估的选项之一，它的 Jira 平滑迁移能力可以显著降低这次合并改造的摩擦。但我要提醒一点：迁移工具解决的是数据搬运，制度设计仍然得你自己动手。我见过把工具换了一遍、立项流程一个字没改的团队，半年后问题原样重现。

七、不同情况下的取舍

制度设计到最后都是取舍问题。我把最常见的五组取舍摆出来，给出我的倾向和适用边界。

1. 快速决策 vs 决策质量

我的倾向是：在立项门选择质量，在启动门选择速度。立项门多花三天把关键假设问清楚，比在执行期花三周返工划算得多。但一旦项目获批，启动门就应该尽量快，不要再叠新的审批。

边界在于项目可逆性。如果这个项目的失败成本是可以承受、可以快速回滚的，那就快速决策；如果它涉及到数据迁移、客户承诺或者架构重构，那就必须慢下来。

2. 统一标准 vs 分级阈值

100 人以下统一标准即可，因为组织本身足够同质。超过 300 人之后，统一标准一定会出现”小项目被压死、大项目被放过”的双向失灵。

分级带来的代价是复杂度上升，需要有人维护分类规则。我的建议是分类维度不要超过两个，通常用”项目类型 + 预估规模”就够了。超过两个维度，维护成本会超过收益。

3. 全量指标 vs 最小可用指标

我强烈倾向后者。起步阶段只做三个指标：任务级承诺覆盖率、承诺偏差率、人力冲突检出数。这三个都是可直接计算的，不需要额外人工填报。

等这三个指标稳定运行两个季度，再加入决策质量层的指标。跳过这一步直接上全套，最常见的结局是数据大面积失真，然后所有人都不再相信数据。

4. 自建 vs 采购

这个取舍的拐点通常在 150 到 200 人。低于这个规模，用现有协作工具加一些约定就够；高于这个规模，跨项目人力视图、权限隔离、审计留痕这些需求会迅速超出自建工具的能力边界。

需要强调的是，采购解决的是一致性和可维护性，不解决制度本身。我的判断标准很直接：如果你的立项制度还说不清楚”谁在什么时候必须做什么决定”，那么换任何工具都不会有改善。

5. 指标公开 vs 指标挂钩绩效

这是最容易被做错的一组。我的结论是明确的：承诺偏差率、关键假设缺失率这类指标只公开，不挂钩绩效。一旦挂钩，所有输入数据都会向有利方向失真，指标会变成负担。

可以挂钩的是流程遵守类指标，比如”是否在规定时间内完成承诺确认”。这类指标不易被操纵，而且它约束的是行为，不是判断。

八、总结与下一步

回到最开始那个 47 个字段的立项表。它的问题从来不是字段太多，而是这 47 个字段没有一个是用来承载承诺的。它们全部在描述项目，没有一个在约束人。

我的独特判断可以归结成三句话。第一，立项制度的考核对象不是项目，是承诺；第二，指标必须按”决策质量，成员参与，流程效率，后验校准”的顺序建，顺序错了就白建；第三，效率指标必须成对出现，单独的效率指标一定会被套利。

这三句话看起来很朴素，但它们解释了一个现象：为什么很多公司立项流程越来越规范，项目失败率却没怎么下降，因为规范增长的是流程，没有增长承诺的准确性。

如果你现在就要动手，我建议按这个顺序做四件事。

1. 本周内做一次数据体检：把过去半年立项的项目列出来，检查有多少在执行系统里能找到对应的项目结构和首批交付物。这个比例就是你的起点基线。
2. 下个立项批次开始，只加一个字段：关键假设，要求写 3 条并标注如果假设不成立的后果。不要加别的。
3. 把首批交付物拆到人：立项通过后自动生成成员待办，一周后统计承诺覆盖率。这是投入最小、见效最快的一个动作。
4. 三个月后再加后验校准：把立项预估值和结项实际值做一次比对，只在复盘会上公开，先不碰绩效。

四件事做完，你对立项制度的理解会从”一套审批规则”变成”一套承诺管理机制”。这个转变本身，比任何指标数值都更重要。

最后提醒一句：立项制度不是一次设计完成的，它是被数据反复修正出来的。第一版一定不完美，但只要它记录了承诺、暴露了冲突、并且能被回溯，它就已经在产生价值了。