项目立项优先级教程：企业管理者流程优化，避坑指南

去年 Q1，我帮一家 460 人的智能硬件公司做研发体系诊断。他们的 PMO 拿出一份”一季度立项清单”：47 个项目请求，正式评审通过 12 个，但研发中心同时在跑 21 个项目。多出来的 9 个，没有一个是偷偷做的，全部来自高管在走廊、饭局、周会上的一句”这个先做起来，立项流程后面补”。三个月后，两个被”补流程”的项目吃掉了整整 8 个核心工程师，导致原本排在最高优先级的平台重构延期 11 周。

这件事让我彻底改变了对”项目立项优先级”的看法：绝大多数企业缺的不是一张更精密的打分表，而是一套能让取舍真正发生的机制。这篇文章不讲教科书里的加权评分法，讲我在真实企业里踩过的坑、用过的漏斗、以及那些看上去合理但会系统性带偏决策的做法。

一、先给结论：立项优先级不是排序问题，而是取舍机制

很多人把”立项优先级”理解成一道排序题：把所有项目请求收集起来，按某个维度打分，从高到低排。这个理解在项目数量少于组织消化能力的时候没问题，一旦请求数超过容量的 2 倍以上，排序题就变成了取舍题，你必须明确地、有记录地、可追溯地拒绝掉一部分项目，并且让被拒绝的人接受这个结果。

排序题的目标是”选出最好的”，取舍题的目标是”让组织在容量红线内运行，同时让被牺牲的项目输得心服口服”。这两件事需要的工具完全不同。

1. 三个我认为最该记住的判断

第一，没有容量红线的立项流程，等于没有流程。我见过太多企业把立项评审做得极其严谨：五级评审、九维度打分、三轮答辩。但从来没有一份文件写清楚”研发中心在同一个季度最多能并行几个项目”。结果就是评审会上一片和谐，所有人都同意”这个项目很重要”，会后资源开始互抢。

第二，打分表的作用是制造共识，不是产生决策。这话听起来反常识。我的观察是：打分表最大的价值在于让不同部门把各自的判断显性化、可比较，从而在会议上吵得更有质量。但最终决断往往需要一个人或一个小组合议来拍。指望分数自己排出名次，通常会导致权重被反复调整、指标被反复解释，流程空转。

第三，立项的最高成本不是做错项目，而是做太多项目。做错一个项目，损失是可计算的；同时做太多项目，损失是弥散的，每个项目都慢一点、质量都差一点、团队都累一点，没人能说清到底是哪个项目出了问题。这种弥散损失，才是企业研发效率最大的黑洞。

2. 为什么我把”打分表”从核心位置拿掉了

我不反对打分表，我反对把打分表放在流程的中心位置。原因是我做过一次回溯：把某企业过去两年 63 个已立项项目的立项评分，和它们 12 个月后的实际投入产出做了一次对照。结果很不客气，评分前 20% 的项目里，只有 7 个真正跑出来了；评分后 20% 的项目里，反而有 3 个成了当年的明星项目。

这不是打分表本身的错，而是三个结构性偏差在起作用：评分发生在信息最少的时点、评分者对不同项目的熟悉程度差异巨大、以及评分维度天然偏向”容易说清楚的收益”，而不是”真正重要的收益”。

3. 立项流程优化的真正目标

我把立项流程优化的目标重新定义为三句话：让该拒的拒得掉、让该等的等得起、让该变的变得了。

“拒得掉”意味着拒绝必须有制度依据，不能靠某个领导挡；”等得起”意味着优先级不是二元的是非题，而是可以排队、可以分批启动的时序安排；”变得了”意味着立项不是一次性决定，而是在关键节点上可以被重新审视、甚至被终止。

这三句话对应的，其实就是进入机制、排序机制和退出机制。大多数企业只做了第一件事。

二、真实场景：立项失控通常不是从决策开始的

我想把上面那家智能硬件公司的场景展开讲清楚，因为它太典型了。这不是一家管理混乱的公司，他们有 ISO 体系、有 PMO、有完整的立项模板、有项目管理系统。失控发生的原因，恰恰藏在他们自认为最规范的地方。

1. 一个 47 个项目请求的季度评审会

他们的立项节奏是季度集中评审。Q1 收到 47 份立项申请，PMO 提前一周把材料发给评审委员会，委员会由 CTO、三位产品线负责人、一位财务总监、一位供应链总监组成。

评审会开了整整两天，每天 8 小时。47 个项目，平均每个项目讨论 20 分钟。前 10 个项目讨论得很细，中间 20 个开始加速，最后 17 个项目基本是”材料看着还行，先过，后面细化”。

会后统计：通过 12 个，暂缓 30 个，否决 5 个。但暂缓的 30 个里，有 9 个在接下来的六周内被陆续”激活”，激活方式是高管口头指示或客户合同倒逼。这就是那 21 个在跑项目的来源。

2. 立项失控的四个阶段

我把这类失控的演化过程总结成四个阶段，你可以对照看看自己在哪一阶段。

1. 通道分叉期：正式评审通道之外，出现了”先做后补”的潜规则。此时没人觉得有问题，因为业务确实要响应。
2. 容量透支期：在跑项目数超过研发容量的 1.3 倍，开始出现关键岗位被多个项目同时占用。项目经理开始靠私人关系抢人。
3. 进度塌陷期：在跑项目数超过容量 1.8 倍，所有项目都在延期，但每个项目都有”合理理由”。此时组织已经失去区分”真延期”和”假延期”的能力。
4. 信任崩塌期：业务方不再相信研发的排期，开始绕开研发找外部供应商或自建影子团队，治理成本进一步上升。

绝大多数企业是在第三阶段才意识到要治理的，而这时候治理难度已经翻了几倍，因为你要同时做两件事：建立新规则，以及清理已经积压的超载项目。

3. 谁在为失控买单

我特别想指出一个容易被忽略的事实：立项失控的直接承受者通常不是决策者，而是一线技术骨干。决策者看到的是”项目都在推进”，一线看到的是”我同时在四个项目里，每个都只能给 25% 的注意力”。

这种错位会导致一个长期的、很难逆转的后果：组织里最能干的那批人，会最先感到疲惫和失望，然后离开。而当他们离开时，管理层看到的解释往往是”薪酬没竞争力”，而不是”立项机制把人耗干了”。

所以我在做立项治理诊断时，一定会加一个指标：核心岗位的人均并行项目数。这个数字长期高于 2.5 的组织，基本都存在立项治理问题，无论它的流程文档写得多漂亮。

三、拆解六个高频误区

下面六个误区，是我在不同企业里反复见到的，有的甚至是行业里被当作最佳实践在传播的做法。我逐条说明为什么它们会带偏决策。

1. 误区一：把”战略重要性”当成最高权重

几乎所有打分表都把”战略契合度”放在 30% 以上的权重。问题在于，战略契合度是最容易被”论证”的维度，任何一个项目负责人，都能用三页 PPT 论证自己的项目和公司战略高度相关。当所有项目的战略契合度得分都在 8 分以上时，这个维度就失去了区分度。

我的做法是把战略维度从”打分”改成”闸门”：战略一致性是 0 或 1 的问题，要么符合，要么不符合，符合的进入下一层。这样既保留了战略对齐的要求，又避免它变成一个人人满分的无效维度。

2. 误区二：用打分表制造”伪量化”

打分表最迷人的地方是它看起来客观。但在我做过的回溯分析里，打分表对项目实际成败的预测能力相当有限。原因很简单：大部分项目的收益预测是在信息最少的时点做出的，而此时给出的”预计年化收益 1200 万”，本质上是一个愿望，不是一个估计。

更麻烦的是，一旦引入了打分，组织就会开始优化分数而不是优化决策。项目负责人会学习”怎么写材料能拿高分”，PMO 会学习”怎么调权重能让结果看起来合理”。最终分数依然存在，但和真实价值的关系越来越远。

3. 误区三：只算收益，不算容量与机会成本

这是我见过最普遍、也最致命的一个问题。立项材料里通常有：预期收益、投入人力、预计周期、风险等级。但极少有材料写：如果做这个项目，我们必须放弃哪个项目？

机会成本不写进材料的后果是，每个项目都可以独立论证为”值得做”。因为单看它自己的投入产出比，确实可能是正的。但当 20 个”单独看都值得做”的项目同时上马，总的机会成本就体现在那些被挤压的高价值项目上，而它们从来不会出现在任何一份立项材料里。

我的改进做法很简单：在立项材料里强制增加一栏”占用容量的具体来源”，要求申请人写明这个项目的人力从哪里出。是从哪个项目抽、还是新招、还是延后哪个交付。这一栏填不出来的项目，直接退回。

4. 误区四：没有退出机制，只有进入机制

我见过企业设计出了七道立项关卡，但没有一道是”退出关卡”。项目一旦立项，就获得了永久的合法身份，直到它自己烂掉、或者在某个季度被高层一句话砍掉。

健康的立项机制必须有对称的退出机制。我的建议是在立项时就约定三个终止触发条件，写进立项决议：连续两个里程碑延期超过 30%、连续两个评审周期无法验证核心假设、或者关键假设被证伪。触发任意一条，项目自动回到评审池，而不是继续消耗资源。

关键是”自动”。一旦终止需要重新开会讨论，它就会变成人情博弈。

5. 误区五：优先级被当成永久标签

“这个是 P0，那个是 P1″，这种标签一旦贴上，通常不会再变。但现实是，项目的价值会随着市场、竞争、技术条件的变化而快速变化。

我的做法是给优先级加上有效期。任何 P0 或 P1 的标记，有效期不超过一个评审周期（比如 6 周）。到期后如果没有人主动重新论证，它自动降一级。这个规则的作用是制造”重新论证”的摩擦，让资源自动流向那些有人持续为它站台的项目。

6. 误区六：忽略”可交付性”这个前置条件

这是最技术性的一个误区。一个项目的价值再高，如果组织当前没有能力交付它，那它的现实优先级就应该降低。可交付性至少包括四个方面。

• 关键角色可用性：这个项目需要的架构师、领域专家、测试专家，当前是否真的有档期，而不是”理论上可以协调”。
• 依赖就绪度：上游系统、数据接口、第三方供应商、合规审批是否已经就位。
• 技术可行性验证程度：核心技术假设是否做过 PoC，还是停留在方案阶段。
• 团队经验匹配度：团队是否做过同类项目，还是需要边学边做。

把这四项做成一个 0 到 3 分的快速评估，总分低于 8 分的项目，无论价值多高，都应该先安排”备料”动作，而不是立即启动。

四、我用的四层漏斗判断逻辑

讲完误区，我把实际在用的判断逻辑完整说一遍。它的结构是四层漏斗，每一层的目标和手段都不同。核心思想是：把可判定的问题前移，把需要判断的问题后置，把不可比的比较变成可比的分层比较。

1. 第一层：战略一致性闸门（Gate 0）

这一层只问一个问题：这个项目是否直接支撑本年度三到五个战略重点中的某一个？是就通过，不是就进入”资源池候补”，不参与本轮排序。

这里有个关键细节：战略重点必须是有限的、事先确定的、并且是经过高管团队正式确认的。如果战略重点有 12 条，那这个闸门就是摆设。我的经验是战略重点控制在 3 到 5 条效果最好，超过 7 条，闸门失效。

这一层的通过率通常在 50% 到 65% 之间。如果通过率超过 80%，说明闸门太松，战略重点写得太宽泛。

2. 第二层：容量可行性与红线

这一层是我认为最被低估的一层。具体做法是：先算出研发组织在下一个评审周期内的真实可用容量，再扣掉已承诺项目和运维类工作的刚性占用，剩下的才是可分配容量。然后对通过第一层的项目做容量合计，如果超出可分配容量的 1.1 倍，就必须在这一层砍掉一部分。

砍的标准是什么？很简单也很残酷：先砍那些无法明确说明容量来源的项目。这也是我前面提到的”占用容量来源”栏的目的。

3. 第三层：风险调整后的价值密度

到了这一层，剩下的项目数量已经可控，我才会引入相对复杂的价值评估。这里我用的是”价值密度”而不是”总价值”，公式大致是这样：

价值密度 = （三年预期净收益 × 成功概率）÷ 峰值容量占用（人月）

这个公式有三个刻意的设计。第一，用净收益而不是收入，避免把高成本项目看成高价值项目。第二，乘上成功概率，也就是做风险调整，让高确定性项目在同等收益下胜出。第三，除以峰值容量占用而不是总投入，因为真正稀缺的是”同时占用多少人”，而不是”总共花多少人月”。

我用峰值而不是均值，是因为绝大多数项目失败不是因为总投入不够，而是因为某个阶段挤不出足够的人。

4. 第四层：时序、依赖与批次节奏

最后一层不判断”做不做”，只判断”什么时候做、和谁一起做”。这一层要处理三件事：依赖关系（A 必须在 B 之前）、共享资源冲突（两个项目都需要同一位专家）、以及批次节奏（一次启动多少个项目）。

关于批次节奏，我的经验是：宁可小批次高频启动，也不要大批次集中启动。一次启动 10 个项目，前两个月所有项目都在做前期调研和方案设计，人看起来很忙，但没有一个项目进入产出阶段；而且当第一批项目开始暴露问题时，你已经没有余量调整了。

5. 权重怎么定：一张可以直接抄的表

如果你确实需要一个可计算的排序，下面这张表是我在多个项目里调过之后的版本。注意它只用于第三层的排序，不用于”做不做”的判断。

这张表里我最想强调的是”可交付性”给了 20%，和”价值密度”持平。传统打分表通常把可交付性放在 5% 到 10%。我认为这是很多立项决策失误的根源之一，价值再高但交不出来的项目，不应该占据稀缺容量。

6. 让规则可执行：一个最小可用的打分脚本

规则如果只能靠 Excel 手工算，很难坚持下去。我通常会给团队一个几十行的脚本，把容量红线检查和价值密度排序自动化，让评审会上能实时看到”再多批一个项目会越过红线”的后果。

# 立项排序最小可用脚本（伪代码，可直接改写为 Python）
CAPACITY_LIMIT = 42          # 本周期研发可用峰值容量（人月）

RED_LINE_RATIO = 1.10        # 超过可用容量的 110% 即触发红线

def value_density(p):

p: dict，字段见下方 candidates 示例

return (p["npv_3y"] * p["success_prob"]) / max(p["peak_months"], 0.5)

def feasible(p):

可交付性四项快速评估，每项 0-3 分

steps = ["key_role_ready", "deps_ready", "tech_validated", "team_experience"]

return sum(p[s] for s in steps) >= 8

def prioritize(candidates):

pool = [p for p in candidates if p["strategic_fit"] and feasible(p)]

pool.sort(key=value_density, reverse=True)

approved, used = [], 0.0

for p in pool:

if used + p["peak_months"] > CAPACITY_LIMIT * RED_LINE_RATIO:

p["decision"] = "next_batch"   # 不是否决，而是延后到下一批次

continue

used += p["peak_months"]

p["decision"] = "approved"

approved.append(p)

return approved, used

candidates = [

{"name": "平台架构重构", "strategic_fit": True, "npv_3y": 1500,

"success_prob": 0.72, "peak_months": 14, "key_role_ready": 3,

"deps_ready": 2, "tech_validated": 3, "team_experience": 3},

{"name": "客户A深度定制", "strategic_fit": False, "npv_3y": 320,

"success_prob": 0.55, "peak_months": 9, "key_role_ready": 2,

"deps_ready": 1, "tech_validated": 2, "team_experience": 2},

]

注意脚本里那个 next_batch 状态。这是我在实践里最重要的一个设计：不要把项目的结果设计成”通过 / 否决”两种，而要设计成”本批通过 / 下批启动 / 待备料 / 否决”四种。多种状态的存在，让拒绝变得不那么对抗，也让资源池始终保持活力。

五、案例与数据观察：一家 460 人制造企业的 12 个月

下面这家企业的数据，来自我参与过的一次完整改造。为了保护商业信息，公司名称和部分业务细节做了模糊处理，但流程结构和数据口径是真实的。它的规模、行业复杂度、以及治理起点，都很有代表性。

1. 改造前：三条并行的立项通道

这家公司的研发中心约 460 人，横跨硬件、嵌入式、上位机软件、算法四个方向。改造前，他们实际上有三条并行的立项通道：

• 正式通道：季度集中评审，走完整的六页立项模板和评审委员会。
• 快速通道：针对销售额 500 万以上的客户定制需求，由销售总监和一位产品副总双签即可立项。
• 影子通道：高管口头指示、客户合同倒逼、或者”反正是小改动”的技术债修补，没有正式记录。

问题不在于有三条通道，而在于三条通道共享同一批人，但没有任何一个地方能看到这批人的总占用。研发中心负责人跟我说过一句话，我印象很深：”我每个月都在做资源分配，但我从来不知道我们一共有多少资源。”

2. 改造动作：只做了四件事

我们在 10 周内只做了四件事，没有推翻原有流程，也没有引入复杂的组合管理软件。

1. 把三条通道合并成一条：快速通道和正式通道合并，区别只在于评审的深度和所需的材料量，但所有项目都必须进入同一个待评估池。
2. 建立容量台账：按方向统计每个季度的可用峰值容量，扣除运维和已承诺交付，得到可分配容量。这个数字公开到所有产品线和销售负责人。
3. 引入四种决策状态：本批通过、下批启动、待备料、否决，并为每种状态定义明确的触发条件。
4. 把规则固化到项目管理平台：立项申请、容量校验、状态流转、终止触发条件全部在系统里执行，Excel 不再是决策依据。

3. 改造后的数据对比

改造后跑了完整四个季度，主要指标变化如下。需要说明的是，这套数据是单一企业样本的纵向对比，不能直接推广为行业基准，但变化的方向和幅度，和我在其他几家企业观察到的趋势是一致的。

4. 工具层的选择：为什么私有化部署是硬约束

到第四件事的时候，问题就变成了选工具。这家公司的约束条件很具体：研发数据不出内网、与现有 LDAP 和工时系统打通、需要支持他们原有的项目层级结构、并且要能承载四个方向近 500 人的并发使用。

对我们来说，私有化部署不是加分项，而是准入条件。他们的上位机软件涉及设备控制的底层协议，算法团队的数据来自客户现场的质检图像，这两类信息都不允许走公有云。同时他们已经在用一套海外项目管理工具管了六年，积累了大量的自定义工作流、字段映射和历史数据，迁移不能是”重新录入”。

最终他们选了 PingCode。原因很直接：PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，支持从 Jira 平滑迁移，在国产替代的选项里属于可以直接对位替换的那一类。他们那次迁移涉及 6 年历史数据、约 3400 个 Issue、27 个自定义字段和 11 条工作流，实际迁移窗口用了两个周末，业务侧基本无感。

我想强调的是，工具选型在立项治理里的作用常被高估也常被低估。高估在于，很多人以为买个系统就能管住立项；低估在于，规则一旦不能自动执行，就一定会退化成人情博弈。

5. 我们在 PingCode 上固化了什么

具体到配置层面，我们把四件事做成了不可绕过的机制，这也是我建议任何做立项治理的团队优先解决的部分。

• 立项申请强制字段：容量来源、峰值人力、终止触发条件三项设为必填，不填无法提交。
• 容量看板：按方向实时显示当前已占用容量与红线比例，超过 90% 时看板变黄，超过 100% 变红，并阻止新的”本批通过”操作。
• 状态机：立项申请只能在本批通过、下批启动、待备料、否决四个状态间流转，每次流转记录操作人和理由。
• 自动回池：项目连续两个里程碑延期超过 30% 时，系统自动把项目状态改为”待重新评估”，并通知评审委员会，不依赖任何人主动发起。

这四条里，我认为第四条价值最大。因为它把”终止项目”从一个需要勇气的管理动作，变成了一个自动发生的系统事件。管理者的角色从”决定要不要砍”变成了”决定要不要救”，心理负担小得多，决策质量反而更高。

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

前面讲的是通用逻辑。但不同规模、不同行业、不同治理成熟度的企业，能承受的治理复杂度完全不同。硬套一套方法，结果往往是流程被架空。下面按三个维度给建议。

1. 按企业规模

100 人以下、单一产品线：不要建立评审委员会，不要做打分表。只需要做一件事：明确列出本季度最多并行几个项目，写在墙上，超过就不批。这个规模下，创始人对业务的判断力远强于任何评分模型。

100 到 500 人、多产品线：这是治理收益最大的区间，也是我建议重点投入的区间。需要建立容量台账、四种决策状态、以及一个可执行的排序规则。工具层面建议直接用支持私有化部署的平台，因为这个规模下数据敏感性和并发量都已经成为实际问题。

500 到 2000 人、多事业部：核心矛盾从”容量不够”变成”标准不统一”。建议在集团层面只统一三件事：决策状态定义、容量口径、终止触发条件。其他细节下放到事业部，避免集团流程和业务实际脱节。

2000 人以上：需要引入组合管理视角，把立项优先级和年度预算、人力规划、技术战略挂在一起。这个阶段最关键的不是流程设计，而是数据一致性，不同事业部的”人月”必须是同一个口径，否则容量台账毫无意义。

2. 按行业与合规强度

制造业与硬件：立项优先级必须把供应链就绪度和量产节奏作为独立维度。一个软件项目晚上线两周，影响有限；一个硬件项目错过模具窗口，可能影响整个产品季。这类企业我建议把”时间窗口紧迫度”的权重从 15% 提到 25%。

金融、医药、能源：合规类项目不能和价值类项目放在同一个池子里排序。因为合规项目的收益是”规避损失”，在净现值模型里天然打不过价值类项目，但它们是不可或缺的。正确做法是单独设一个”必做池”，先扣掉这部分容量，剩下的再排序。

互联网与软件：最大的风险是立项太轻、迭代太碎。建议把立项门槛设在”是否需要跨团队协作”上，单一小组内部的小改动不进立项池，走需求池即可。这样能把立项流程的注意力集中在真正需要协调资源的项目上。

项目型服务业：立项优先级本质上等于客户选择。建议在立项阶段就引入客户毛利、回款条件、战略客户价值三个字段，把立项决策和商务决策绑定，避免销售承诺与研发能力长期脱节。

3. 按治理成熟度

阶段一，完全人治：不要急着上流程，先做一件事，把过去 12 个月实际在跑的项目全部列出来，标注每个项目的来源和当前状态。这一步通常会让人震惊，因为很多企业会发现影子项目占了总量的三分之一。有了这个清单，才谈得上治理。

阶段二，有流程但被绕过：重点不是加流程，而是加约束。把容量红线做成硬性拦截，把绕过流程的项目在系统里显式标记。让”绕过”这件事变得可见，比让”绕过”这件事变得困难更有效。

阶段三，流程稳定但僵化：这时候要防止的是流程本身变成负担。建议简化评审材料，把六页模板压到两页，把评审会从两天压到半天。判断标准很简单：如果立项评审周期超过 15 个工作日，流程就在拖累业务。

阶段四，数据驱动：开始做回溯校准。每半年把已立项项目的实际表现和当初的评估做一次对照，用真实数据修正你的权重和阈值。这一步做完，你的立项机制才真正属于你自己的组织，而不是从书上抄来的。

4. 一个 30 天可以落地的动作清单

如果你看完想马上动手，下面是我建议的 30 天节奏。它的设计原则是：每一步都能独立产出价值，不需要等全部做完才见效。

1. 第 1 到 5 天：盘点过去 12 个月所有实际在跑的项目，列出名称、来源、启动日期、当前状态、占用人力。不要做任何判断，只做记录。
2. 第 6 到 10 天：算出可分配容量。用”研发总人数 × 有效投入系数（建议 0.7）× 周期长度”得到理论容量，再扣掉运维和已承诺交付。把这个数字公开。
3. 第 11 到 15 天：定义四种决策状态和各自的触发条件，形成一页纸的规则文件。不要超过一页。
4. 第 16 到 20 天：在项目管理平台里把立项申请表单改成必填容量来源和终止条件，配置容量看板和状态机。
5. 第 21 到 25 天：用新规则完整跑一次评审，重点不是选出哪些项目，而是验证规则本身是否可执行、拒绝理由是否站得住。
6. 第 26 到 30 天：复盘这次评审，修正一到两个明显不合理的参数，然后宣布规则正式生效并设定下一次校准时间。

七、不同情况下的取舍

治理这件事没有最优解，只有取舍。我把最常遇到的四组取舍讲清楚，帮你在具体情境下做判断。

1. 速度 vs 严谨

选速度的场景：市场窗口极短、竞争格局未定、试错成本低。这时候立项应该轻量化，甚至允许”先做后补”，但必须有一个前提，占用容量是明确的、可回收的。

选严谨的场景：项目涉及跨部门大额投入、存在不可逆的架构决策、或者交付承诺已经对外做出。这时候立项阶段多花两周，通常能省下后面两个月的返工。

我的判断经验是：看这个项目的错误决策成本是否可逆。可逆的，选速度；不可逆的，选严谨。绝大多数立项争议，本质上是双方对可逆性的判断不同，而不是对流程的偏好不同。

2. 集中管控 vs 业务自治

集中管控的优点是全局视野，能看到资源的真实总占用；缺点是响应慢、容易和业务实际脱节。业务自治的优缺点正好相反。

我的建议是分层：容量层集中，优先级层自治。也就是说，集团或研发中心统一控制每个方向每个季度的容量红线，但红线以内的具体项目排序，交给方向和业务负责人决定。这样既防止了总量透支，又保留了业务判断的灵活性。

3. 自研门禁系统 vs 采购平台

我见过一些企业为了立项治理专门自研了一套系统，投入了十几个工程师半年时间。结果是系统上线了，但没人用，因为立项只是研发管理的一个环节，自研系统无法和需求、缺陷、测试、发布打通。

我的判断标准很简单：除非你的立项规则已经稳定运行两年以上且极其特殊，否则不要自研。采购一个支持私有化部署、支持从既有工具平滑迁移的商业平台，用配置实现你的规则，成本通常是自研的十分之一，而且能立刻和后续环节打通。

4. 短期止血 vs 长期治理

如果组织已经处在进度塌陷期，我建议先做短期止血：砍掉或暂停所有无法明确说明容量来源的项目，把在跑项目数压回容量红线的 1.1 倍以内。这个过程会很痛，短期交付也会受影响，但不做这一步，任何新规则都会被存量超载淹没。

止血完成后，再进入长期治理：建立容量台账、四种决策状态、自动回池机制、半年一次的回溯校准。顺序不能颠倒，先治本再止血的结果通常是新规则被旧问题压垮。

八、我的核心观点和你的下一步

写到这里，我把整篇文章最想表达的一个观点再明确一遍：立项优先级管理的本质，不是找到一套能算出正确答案的公式，而是设计一套能让组织在容量约束下持续做出取舍、并且让取舍结果被接受和执行的机制。

公式追求的是精准，机制追求的是可持续。我见过太多企业在公式上花了几个月，在机制上花了几小时，最后流程被架空，回归到”谁声音大谁的项目先做”。

三个我认为最容易被忽视、但价值最高的具体设计，值得你再回头看一遍。

• 把战略一致性从打分改成闸门。0 或 1 的判断，比 1 到 10 的打分有效得多，也吵得少得多。
• 把决策结果从两种状态扩展成四种。“下批启动”和”待备料”这两个状态的存在，让拒绝这件事不再是对抗性的，也让资源池始终保持流动。
• 把终止项目做成系统自动事件，而不是管理者的勇气考验。规则只有不依赖人的意志才能长期存活。

至于下一步，我的建议是按顺序做三件事，不要跳步。

第一步，本周内完成过去 12 个月实际在跑项目的盘点。这一步不需要任何工具，一个表格就够，但几乎每次都能让管理层看到此前完全没有意识到的事实。

第二步，在两周内算出并公开可分配容量。这个数字一旦公开，很多原本需要开的会就不用开了，因为大家看到的是同一本账。

第三步，在一个季度内把规则固化到项目管理平台里。规则写在文档里会退化，写在系统里才会稳定。如果你所在的组织规模在 100 人以上、对数据不出域有要求、或者正在从海外工具迁移，那么在选型阶段就把”私有化部署”和”平滑迁移能力”作为准入条件来筛，会比事后补救省很多力气，像 PingCode 这类面向中大型企业、支持私有化部署和 Jira 平滑迁移的国产平台，在这个环节是可以直接纳入候选的。

最后提醒一句：立项治理的目标从来不是让立项变难，而是让资源流向真正重要的地方。如果你的新流程让所有项目都变慢了、但没有让重要的项目变快，那说明你优化的是审批，不是优先级。这两件事的区别，值得在每个季度回头确认一次。