项目立项优先级教程：项目经理落地方案，避坑指南

去年 11 月，我帮一家 1400 人的制造企业做研发效能复盘，翻出他们当年的立项台账：全年立项 63 个，走完评审流程的有 58 个，到 12 月真正交付上线的只有 21 个。剩下那 37 个里，14 个卡在需求反复，11 个卡在人力被抽调，还有 12 个，其实早就没人记得当初为什么要立。

更扎心的数字在后面：这 37 个未交付项目，吃掉了当年研发总工时的 41%。也就是说，公司将近一半的研发产能，投在了年底盘点时没人愿意认领的事情上。项目经理在立项会上说的每一句”先都立着，后面再排”，最后都会变成某个具体的人夜里加班还债。

这篇内容不打算复述”优先级矩阵”那套教科书。我想讲的是：我在十几家 100 到 3000 人规模的组织里，实际跑过、改过、也翻过车的立项优先级方法，包括它什么时候有效、什么时候纯粹是给自己找麻烦。

一、先说结论：立项优先级的本质是”弃项”，不是”排序”

大部分团队把立项优先级理解成一道排序题：把候选项目按分数从高到低排好，从最高的开始做，做完了再做下一个。这个理解在项目数量少于团队产能的时候成立，一旦候选项目超过产能水位，排序就失效了，因为你排在第 8 位的项目照样会被立项，照样会有人开工。

我的核心结论只有一句：立项优先级的产出不是”顺序表”，而是”弃项清单”和”资源锁定表”。顺序表让所有人舒服，弃项清单让公司活下来。

1. 三个我反复验证过的判断

第一个判断：立项阶段的错误，是后续所有敏捷实践都救不回来的。我和不少团队做过对照，同一个组织里，需求评审、迭代复盘、看板可视化都做得很扎实的项目，如果立项时的价值假设本身是错的，最终交付出来照样没人用。流程只能提高”把事做对”的概率，救不了”做了错的事”。

第二个判断：优先级不需要算得很准，但必须算得一致。我见过太多团队纠结权重是 0.25 还是 0.3，结果连”什么叫高价值”都没统一。真正有效的做法是先把口径统一到能让两个部门的人吵起来，再谈精度。

第三个判断：没有资源锁定周期概念的优先级，都是纸面优先级。一个项目立了项，就意味着未来三到六个月里，某几个关键角色不能全力做别的事。不算这笔账，优先级就只是愿望清单。

2. 我的主干模型：三层漏斗 + 五维打分 + 一道硬约束

这套模型是我从 2021 年开始逐步收敛出来的，现在用在大多数中大型组织里都比较顺手。它的结构其实很简单：

1. 第一层，红线层：合规、安全、战略指令类项目先过筛，一票否决或一票通过，不参与打分。
2. 第二层，分层层：把剩下的项目按收益类型分成四类，不同类别用不同标尺，不混在一张表里排。
3. 第三层，打分层：同类项目内做五维加权打分，得出组内相对优先级。
4. 硬约束层：把打分结果放到真实产能水位里做裁剪，超出水位的高分项目也要延后，而不是硬塞。
5. 校准层：季度回看，记录预测值和实际值的偏差，用来修正下一周期的权重。

这五步里，最容易做错、也最值钱的是第三层和硬约束层之间的那个动作：先打分再裁剪，而不是先裁剪再打分。因为如果一开始就按”我们只有 5 个人”来评，评审会立刻变成资源争夺战，价值讨论会被挤出去。

3. 立项会开完，必须产出四样东西

我要求所有我参与设计的立项评审，散会时必须有四份东西存档，少一份这场会就算白开：

• 立项结论表：通过、有条件通过、暂缓、否决，四选一，不允许”再研究研究”。
• 弃项清单及理由：写清被砍掉的项目和砍掉的原因，下次有人再提同样的项目，先看这份清单。
• 资源锁定表：每个通过的项目锁定哪些角色、锁定多少人天、锁定多长时间。
• 假设台账：这个项目成立依赖哪三个前提，什么时间点用什么信号来验证。

第四份最容易被忽略，但它是我见过最有价值的一份。立项不是承诺结果，是承诺一组假设。把假设写下来，三个月后验证的时候才有依据说”这个项目该停了”，而不是靠谁的嗓门大。

二、为什么大多数公司的立项排序会失效

讲完结论，我想先讲失效的机制。不理解失效机制，再好的打分表都会被组织惯性碾平。

1. 立项会开成了分蛋糕大会

我参加过的最典型的一场立项会，坐了 18 个人，议程是”各部门汇报本季度拟立项目”。结果是每个部门都立了 2 到 4 个，总量 31 个，评审委员全程没问过一个”如果这个不做会怎样”。散会时大家的评价是”会开得很顺利”。

顺利的原因是：这本质不是评审会，是配额分配会。每个人的目标不是找出最该做的三件事，而是确保自己部门的项目不被砍。在这种结构里，打分表只是一层装饰。

我的应对办法很直接：把评审委员的构成改掉。让 60% 的评委来自与提案无关的业务线，并且给每个人一份”否决额度”，每位评委必须至少否决一个项目，否则不能投票通过任何一个。这个规则听起来粗暴，但它能在两轮之内把立项会从分蛋糕变回真评审。

2. 价值标尺不统一：财务口径和战略口径互相打架

财务看项目的口径是投资回报周期和现金流影响，战略看的是能力沉淀和市场卡位。这两套口径本身都没错，问题在于如果放在同一张评分表里，一定会出现”财务给 2 分、战略给 9 分”的项目。

我处理这件事的方式是：不让它们在同一张表里打分。先按收益类型分层，财务型项目用财务标尺排，战略型项目用战略标尺排，最后在硬约束层用”资源包”的方式做配额分配，比如 60% 产能给财务型，25% 给战略型，15% 留给合规和应急。

配额比例比打分权重更好用，因为它把抽象的价值争论，转换成了可协商的数字。业务负责人更容易接受”战略项目今年最多占 25% 产能”，而不是接受”你们项目的战略匹配度只有 0.3″。

3. 信息不对称：提案人掌握的信息是评委的五倍

这是最隐蔽的一条。我做过一个小统计：在一次典型立项评审上，提案人平均掌握的业务细节量，大约是评委的 4 到 6 倍。评委只有在 15 分钟汇报里听到的部分，而汇报内容通常是经过筛选的。

结果就是：谁更会讲，谁的项目优先。这不是道德问题，是结构问题。解决方式只有一个，把信息压缩到固定模板里，让不同项目的可比性从”表达能力”转到”内容本身”。

我用的模板要求提案人必须回答四个量化问题：预期收益的量级和计算方式、不做的后果、需要锁定的人天、三个月后的验证信号。答不上来的项目，直接进入下一轮，不占用评审时间。

4. KPI 错位：立项数量本身成了部门业绩

我遇到过一家公司，研发部门的季度考核里有一条”立项数量不少于 8 个”。这条指标存在了两年，直接导致立项变成凑数游戏。后来我们把这条改成”通过立项评审且三个月后仍在正常推进的项目数”，立项数量当季就从 8 个掉到 4 个，但交付率涨了。

指标改一个词，行为变一大截。做立项优先级治理时，如果不动考核指标，流程改十遍也没用。

三、六个我踩过或见过别人踩的坑

下面这六个误区，我按自己踩坑的次数排序，第一个是我自己犯过的。

1. 用紧急度代替价值度

我早期做项目经理时，最常用的判断是”老板提的、客户催的、竞品上了的”先做。这个规则短期很有效，长期很致命，因为它会让团队永远在还债，永远没时间做能降低未来还债量的事。

判断信号很简单：如果你的立项清单里超过 70% 的项目都是”应对型”，说明优先级机制其实不存在，只是被动响应。我的经验值是应对型不超过 50%，并且每个季度至少留 20% 产能给主动型项目。

2. 把所有项目放进同一张表排序

一个 30 人天的小工具优化和一个 600 人天的系统重构，放进同一张加权表打分，结果一定是小项目全部胜出，因为它们的确定性高、风险低、见效快。这不是打分错了，是量级不可比。

我的做法是按体量分档：小于 50 人天、50 到 200 人天、200 人天以上，各成一档，档内排序，档间用配额分配。这样既保证了大项目不被小项目挤死，也避免大项目独占产能。

3. 只看收益，不算机会成本和资源锁定周期

这一条是我在 2022 年一个项目上真正吃亏的地方。当时我们立了一个数据平台重构项目，预估 300 人天，结果实际投入 520 人天，锁定了两名核心后端将近七个月。那七个月里，我们推掉了三个原本可以带来直接收入的需求。

事后核算，如果那七个月只投入 250 人天做平台的最小可用版本，剩下的产能去做其中一个需求，整体收益大概会高出 40%。机会成本从来不写进立项表，但它是真实发生的成本。

4. 打完分就结束，没有校准机制

我见过评分表做得最精致的团队，五级评分、十二个维度、权重精确到小数点后两位，但三年来从来没记录过一次”预测值和实际值的偏差”。这意味着这张表从来没被验证过，它只是在提供一种精确的错觉。

我的做法很笨但很有效：每个立项项目在季度末填一张偏差卡，记录预估收益、实际收益、预估人天、实际人天四项。积累四到六个季度后，你会得到自己组织的”估算偏差系数”，比如实际人天普遍是预估的 1.6 倍，实际收益普遍是预估的 0.5 倍。把这个系数带回打分表，预测质量会跳一个台阶。

5. 忽略依赖关系和”入场券型项目”

有些项目本身收益很低，但它是另外三个高收益项目的前置条件。这类项目我叫它”入场券型项目”。如果只按打分排序，它们会被永远排在后面，导致真正赚钱的项目也做不了。

识别方法是在立项材料里强制填一栏：本项目是哪些其他项目的前置条件。任何被引用两次以上的项目，自动升档处理，不参与常规排序。

6. 一套权重打天下

同样是五维打分，成熟业务线的权重应该偏向收益确定性，创新业务线的权重应该偏向战略匹配度和学习价值。用同一套权重评这两类项目，结果就是创新项目永远排在最后，公司慢慢失去第二曲线。

我的建议是按业务线准备 2 到 3 套权重模板，并在评审前明确公告本季度用哪一套。不要在同一场会上临时切换，那会引发无休止的争论。

四、我实际在用的判断逻辑

这一节把前三层的细节讲透，包括权重的取值和我为什么这么取。需要说明的是，下面的数值是我在多个组织里校准后的经验基准，不是行业标准，你可以用它作为起点再本地化。

1. 第一层：红线层，一票否决和一票通过

红线层的作用不是筛选价值，而是处理掉那些”不该用打分来决定”的项目。我把它分成两类：

• 一票通过：法规强制的合规项目、已签约的客户承诺交付、董事会级别的战略指令。这三类不参与打分，直接进入资源配额。
• 一票否决：明确违反数据安全与隐私政策的、前置依赖不成立的、关键角色在未来六个月内无法到位的、无法定义验证信号且投入超过 100 人天的。

最后那条否决理由是我自己加进去的，很多团队会觉得过于苛刻。我的判断是：一个无法定义”三个月后用什么信号验证它是对的”的项目，本质上不是项目，是一个愿望。愿望可以留在待办清单里，但不应该占用立项名额。

2. 第二层：收益类型分层，四类四套标尺

我把项目按收益类型分成四类，每一类用完全不同的评价语言：

1. 财务型：能直接算钱，用投入产出比、回收周期、现金流影响来评。
2. 战略型：能力沉淀、市场卡位、生态占位，用不可替代性和时间窗口来评。
3. 合规型：用风险敞口和处罚概率来评，基本不参与收益排序。
4. 效率型：内部提效，用节省人天和影响人数来评。

分层的最大价值是让不同类型的项目不互相抢分。财务型和效率型放在一起评，效率型永远输，但效率型项目累积起来的效果往往比单个财务型项目更大。

3. 第三层：五维加权打分，以及我为什么用这五个维度

五维是我反复删减后的结果。我试过十二维，也试过三维，最终稳定在五个：

• 战略匹配度（权重 0.25）：与年度重点方向的关联程度，1 到 5 分。
• 收益确定性（权重 0.25）：收益可测算且有历史依据的程度，1 到 5 分。
• 实施风险（权重 0.20，反向计分）：技术、供应商、合规、组织协同四类风险的叠加。
• 资源可用性（权重 0.15）：关键角色在未来一个季度能否真正腾出时间。
• 依赖成熟度（权重 0.15）：前置条件是否已经具备，还是需要同步建设。

为什么把”资源可用性”和”依赖成熟度”单独列出来？因为这两项是立项会上最常被口头承诺、最容易被现实打脸的东西。把它们变成可打分的项，就等于给口头承诺装了一个可见的刻度。

下面是我在飞书表格和内部工具里用的打分配置，直接贴出来给你参考：

scoring_config:
version: 2024Q3

dimensions:

key: strategy_fit

name: 战略匹配度

weight: 0.25

scale: [1, 2, 3, 4, 5]

reverse: false

key: benefit_certainty

name: 收益确定性

weight: 0.25

scale: [1, 2, 3, 4, 5]

reverse: false

key: risk_level

name: 实施风险

weight: 0.20

scale: [1, 2, 3, 4, 5]

reverse: true # 5 分代表风险最低

key: resource_availability

name: 资源可用性

weight: 0.15

scale: [1, 2, 3, 4, 5]

reverse: false

key: dependency_maturity

name: 依赖成熟度

weight: 0.15

scale: [1, 2, 3, 4, 5]

reverse: false

tier_quota:

tier: financial

capacity_share: 0.60

tier: strategic

capacity_share: 0.25

tier: compliance

capacity_share: 0.10

tier: emergency

capacity_share: 0.05

calibration:

actual_person_day_factor: 1.6 # 实际人天 / 预估人天

actual_benefit_factor: 0.5 # 实际收益 / 预估收益

最后两行校准系数是整个配置里最值钱的部分。它把你组织的乐观偏差固化成了一个可以参与计算的数字，而不是每次靠某个老员工的经验来拍。

4. 硬约束层：产能水位与资源锁定

打分完成后，我会做一张产能水位表。做法是把通过打分前 42 名的项目，按需要锁定的角色和时长铺到未来两个季度的日历上，看哪些时段会出现同一个人被两个项目同时锁定。

我用的经验标准是：任何关键角色，同一时期被超过 1.3 个项目锁定，就视为超配。1.3 而不是 1，是因为现实里总要留出 30% 的缓冲用于支持、答疑和突发。

超配的时段里，直接砍掉分数最低的项目，而不是延长所有项目的周期。这一点我踩过坑：早期我倾向于”都保留，只是拉长”，结果是所有项目的周期都变长，团队同时面对五个半成品，反馈周期被拉得极长，信心比砍掉几个项目时更差。

5. 校准层：季度偏差卡和估算系数

偏差卡我要求填四项：预估收益、实际收益、预估人天、实际人天。项目负责人填，PMO 汇总，每季度出一次组织级的两个系数。

我服务过的组织里，这两个系数的典型区间是：实际人天是预估的 1.4 到 1.9 倍，实际收益是预估的 0.4 到 0.7 倍。把这两条写进打分表，你的立项判断立刻会比竞争对手准一档，因为这等于把人性里的乐观偏差提前扣掉了。

五、一个真实案例：从 63 个项目收敛到 28 个

下面这个案例是我 2023 年到 2024 年深度参与的，数据来自客户的内部台账，我做了脱敏处理。

1. 案例背景

客户是一家制造企业，总部加两个基地共约 1400 人，研发与信息化相关的人员约 260 人。业务特点是：订单驱动的项目多、跨系统集成多、合规审计要求高。改造前的主要问题是立项数量失控、资源锁死、年底盘点大面积烂尾。

我当时接手的第一个动作不是改流程，而是把过去两年的立项台账、实际交付记录、人力投入记录三张表对齐，做了一次彻底的数据考古。这一步花了大概两周，但它决定了后面所有判断的可信度。

2. 改造前后的关键数据

经过两个完整季度的运行，几个核心指标的变化比较明确：

• 立项通过率从 92% 降到 47%，入口收窄了一半以上。
• 按计划启动率从 61% 提升到 88%，说明立项时的资源承诺开始变得可信。
• 按期交付率从 33% 提升到 69%。
• 需求返工率从 34% 降到 17%。
• 关键角色平均被锁定项目数从 1.9 降到 1.2。

需要诚实说明的是，同期他们还做了一次组织架构微调，所以这些数字不能全部归因于立项机制。我个人的判断是，其中大概 60% 来自立项优先级的治理，40% 来自组织调整和工具落地。

3. 工具侧怎么承接：以 PingCode 为例

流程设计得再好，如果落到工具上要填五张表、走三个系统，团队两周就会放弃。这个客户的情况是：240 多名研发和业务人员，需要私有化部署，原有工具是 Jira，历史数据不能丢。

综合评估之后他们选择了 PingCode。我参与了这个选型过程，把真实原因写出来：

• 私有化部署：他们有内网合规要求，项目数据和客户信息不能出内网，这一条直接筛掉了大部分 SaaS 方案。
• Jira 平滑迁移：历史项目、工作项、字段映射、附件都能批量迁移，迁移窗口只花了一个周末，没有出现数据丢失。
• 项目集与需求池的层级：立项台账、项目集、需求池、迭代四层结构能直接对应我们设计的三层漏斗，不需要自己在外面再维护一张 Excel。
• 中大型组织的权限模型：多基地、多事业部的数据隔离和跨部门可见性需求都能满足，这是 100 人以下团队不太会遇到但对 1400 人组织非常关键的一点。

我想强调的是，工具在这里承担的是”让规则可执行”的角色，而不是”提供方法论”。如果你的立项规则本身不清楚，换任何工具都只是把混乱搬到更贵的地方。这个客户是先花了两周对齐规则，再花一周配置工具，顺序没有反。

他们在工具里落地的具体动作有三个，我觉得值得抄：

1. 把”立项状态”做成一个独立字段，取值只有待评估、已通过、有条件通过、暂缓、否决五种，任何人不能自建新状态。
2. 把”资源锁定人天”做成必填字段，未填写无法提交评审。
3. 把”验证信号”做成一个独立的检查项，立项后第 90 天自动推送给项目负责人和 PMO，要求回复信号是否出现。

第三条是整套机制里我最满意的一处设计。它把”什么时候该停”这件事从人的主动性，变成了系统的自动提醒。上线半年，他们因此主动终止了 6 个项目，释放出约 420 人天的产能。

4. 半年后的结果与代价

好的部分是产能释放和交付改善。代价也必须说清楚：立项评审占用了我每周约 4 小时的时间，PMO 增加了一个半人的工作量。前两个月，业务部门的抱怨明显上升，主要集中在”立项变慢了”。

我的处理方式是给紧急通道留了出口：一定金额以下、且不涉及跨系统集成的项目，走简化的单人审批，24 小时内出结论。这个通道消化了大约 30% 的小项目，把主评审会的压力降了下来，抱怨也随之缓解。

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

下面按组织规模分场景给建议。我的基本判断是：规模越小，机制越要轻；规模越大，口径越要硬。用错方向比不做更糟。

1. 50 人以下的团队：不要做打分表

这个规模的公司做五维加权打分是自欺欺人，因为样本量太小，权重根本不收敛。我的建议是只做三件事：

1. 列出当前所有在推进的事，包括没立项但有人在做的。
2. 强制排一次”如果只能做三件”的序，由一号位拍板。
3. 把排在第 4 位之后的事情明确写进”暂缓清单”，并且真的不分配人。

对 50 人以下的团队，最有效的手段是”暂缓清单”这三个字被真实执行，而不是流程本身有多精细。

2. 100 到 500 人的组织：分层加配额

这是收益最明显的区间。建议做完整的收益分层和配额分配，打分维度可以砍到四维（战略匹配、收益确定性、实施风险、资源可用性），暂时不用管依赖成熟度，因为这个规模的项目依赖通常还在可控范围内。

重点是把配额比例定下来并写进制度。我常用的初始比例是财务型 55%、战略型 25%、合规型 12%、应急 8%，运行两个季度后按实际偏差调整。

3. 500 人以上或多事业部组织：口径统一优先于精度

这个规模最大的问题不是算不准，而是”同一个词在不同事业部含义不同”。我建议先做一次术语对齐，把”高价值””紧急””战略项目”这些词写成有明确判据的定义，再谈打分表。

这个规模还应该配一个固定的立项评审节奏，比如双周一次、每次不超过 8 个项目。频次太低的评审会累积出一次超长会议，而超长会议的决策质量一定下降。

4. 强合规行业：合规项目单独走通道

金融、医疗、汽车电子这类行业，合规项目占比可能达到 20% 到 30%。我的建议是把合规项目完全独立出评分体系，单独设配额、单独设通道，避免它们在其他维度（比如收益率）上被打低分之后被反复争论。

同时要注意，合规项目的验收标准通常由外部审计决定，内部打分对它没有约束力，硬塞进加权模型只会制造噪音。

5. 从通用工具迁移的场景：先迁移字段语义，再迁移数据

我参与过的迁移项目里，最常见的坑是直接照搬原系统的字段和状态机。结果是新系统里保留了一堆没人理解的历史状态，新规则根本装不进去。

正确顺序是：先定义新系统里的字段语义和状态集合，再设计映射关系，最后做数据迁移。以 PingCode 承接 Jira 迁移的场景为例，他们先花三天对齐了工作项类型和状态映射，再执行批量迁移，迁移后只做了不到 40 处人工修正。如果顺序反过来，修正量通常是几百处起步。

七、不同情况下的取舍

立项优先级做到最后，本质上是一连串取舍。我把最常遇到的五组写在下面，每组给出我的倾向和判断信号。

1. 战略项目和现金牛项目的取舍

我在这件事上的倾向很明确：战略投入的比例应该由现金流决定，而不是由野心决定。如果现金牛业务的毛利无法覆盖 12 个月以上的战略投入，那战略项目的优先级就必须下调，否则你会在半途因为资金压力被迫砍掉，前期投入全部沉没。

我见过最惨的情况是，一家公司连续三年同时启动四条战略线，每条线都在第二年因为现金流紧张被砍，三年下来没有一条形成能力。这比一开始只选一条线要糟糕得多。

2. 快速见效和长期基建的取舍

我的判断信号是团队的持续加班率。如果过去两个季度加班率一直高于 15%，说明基建欠账已经在吃人，这时候应该优先做能降低未来成本的基建项目，哪怕它当期看不到收益。加班率是最诚实的基建体检指标，因为它是人力透支的直接体现。

3. 自研和采购的取舍

我用的判断标准只有两条：这个能力是否构成公司的核心差异化，以及公司是否有人能长期维护它。两条都满足才自研，否则采购。这里最容易犯的错是”因为我们是研发公司，所以应该自研”，但内部工具类能力和产品类能力是两回事，后者才是差异化所在。

4. 打分精细度和决策速度的取舍

当候选项目数量超过产能水位 3 倍以上时，我倾向于放弃精细化打分。因为在这个倍数下，你不需要精确区分第 5 名和第 6 名，你只需要快速把前 30% 选出来，剩下的全部延后。把精力花在精细区分第 20 名和第 21 名，是立项治理中最常见的浪费。

5. 流程治理和工具治理的取舍

我的顺序永远是先定规则再配工具，但有一个例外：如果组织里连”应该按什么标准排优先级”的共识都不存在，那么先上一个有结构的工具反而能加速讨论，因为工具会逼迫你对字段做出选择。

判断信号是：过去半年里，是否有人正式提出过立项标准的问题。如果连提出都没有，说明意识还没到，工具可以先上；如果已经争论过但没结论，那就先关起门来把规则定死。

八、可以直接拿去用的落地清单

最后我把前面所有内容压缩成两份清单，你可以在下一次立项评审前后直接对照执行。

1. 会前 48 小时检查清单

1. 所有提案材料的收益测算是否包含计算方式，而不只是结论数字。
2. 每个提案是否写明”不做的后果”。
3. 资源锁定人天是否填到角色级别，而不是只有一个总数。
4. 是否标注了前置依赖，以及是否被其他项目引用过。
5. 是否定义了 90 天后的验证信号。
6. 材料是否在会前 48 小时发到所有评委手中，且简单问题已在会前澄清。

2. 会后 5 天检查清单

1. 是否产出了明确的四选一结论，没有任何一项停留在”再研究”。
2. 弃项清单是否公示，并且写明了具体理由。
3. 资源锁定表是否已同步给所有相关角色的直线经理。
4. 假设台账是否录入系统，并设置了到期提醒。
5. 本季度的产能水位是否重新核算过，关键角色锁定数是否都在 1.3 以下。

3. 常见问题

问题一：立项评审要不要总经理参加？

我的经验是 100 人以下必须有，100 到 500 人可以参加但不必主持，500 人以上建议只参加季度级的立项战略会，不做日常评审。日常评审由 PMO 加业务负责人组成即可，否则决策链条太长。

问题二：打分权重多久调整一次？

建议每两个季度调一次，且每次只调一到两个维度的权重，幅度不超过 0.05。频繁大幅调整权重会让团队觉得机制不可靠，进而转向靠关系推动项目。

问题三：已经开工但没立项的项目怎么处理？

我主张全部纳入一次专项评审，不做追溯惩罚，只做现状判定。原则是”存量认账，增量控住”。对已经投入超过 30% 的项目，优先判断是否继续，而不是一律补流程。

问题四：小团队要不要专门配 PMO？

500 人以下不建议设专职 PMO，可以由一位资深项目经理兼任，每周投入 4 到 6 小时即可。这个阶段机制越轻越好，重流程会直接压制交付速度。

问题五：立项优先级和年度规划是什么关系？

年度规划定配额和方向，立项优先级定具体做什么和什么时候做。规划如果细到项目级别，立项评审就失去了意义；规划如果只到方向级，立项评审才有真实的决策空间。我见过的最健康的状态是：年度规划只定四个方向加配额比例，具体项目全部在季度立项评审上定。

回到开头那家公司。他们今年上半年的立项数量是 26 个，交付了 19 个，产能利用率反而比去年高。立项优先级做对之后，最重要的变化不是变得更能干，而是变得更能拒绝。

如果你现在就想动手，我建议你不要一上来改流程，而是先做一件小事：把过去 12 个月所有立项项目列出来，逐个标注”是否交付””实际投入人天””预估投入人天”三列，然后算出你们的组织估算系数。这一张表做完，你后面所有的优先级讨论都会变得具体得多。