项目立项优先级教程：管理层数据分析，避坑指南

很多团队把项目立项优先级做成了一张 Excel 打分表：战略贴合度 20 分、财务回报 30 分、技术风险 15 分……加权求和，按分数从高到低排一遍，就算完成了立项决策。我在三家超过 500 人的公司参与过这套流程的重建，也见过它彻底失效的样子：分数排名第一的项目做了七个月被叫停，排名第七的项目反而成了当年最大的收入来源。

问题不在打分表本身，而在定位。立项优先级的本质不是”给项目排队”，而是”给管理层有限的注意力、现金和人天排队”。这两件事的解法完全不同：前者是数学问题，后者是约束优化问题。当你把它当数学问题时，你会追求模型精确；当你把它当约束问题时，你首先要问的是”我们这季度到底能同时开几条线”。

这篇文章我会拆开讲三件事：管理层数据分析在立项环节到底该看什么数据、八个我亲眼见过的坑、以及一个我用了五年、在 100 人到 3000 人规模组织里都跑得通的四层漏斗判断逻辑。所有数据观察都来自我在企业内部的立项评审记录和研发管理平台里的执行数据回看，涉及具体企业时会做脱敏。

一、核心结论：立项优先级是注意力分配问题，不是打分问题

1. 先说三个我反复验证过的结论

结论一：维度超过 6 个的立项打分表，基本都会退化成拍脑袋。我统计过自己经手的 11 次立项评审，维度数在 5 到 6 个时，评审会的争论集中在”某个项目的某项得分依据是否成立”；维度数超过 9 个时，争论会转移到”我们是不是该加一个维度”，而最终排序往往被最后一个发言的高管意见覆盖。维度越多，越没人真正算得过来。

结论二：管理层在立项环节真正缺的不是”排名”，而是”取舍依据”。排名告诉你第 1 名比第 2 名高 3.2 分，但管理层需要回答的是”如果我砍掉第 3 名，省下的 6 个人能不能让第 1 名提前一个季度上线”。这是机会成本问题，不是排序问题。

结论三：立项数据如果不接执行数据，就是一次性消耗品。我只见过一种立项评审是长期有效的：立项时写下的假设（预计工期、预计收益、关键依赖）能在三个月、六个月后被自动拉出来对照。没有这条回流链路，立项文档的寿命通常不超过 45 天。

2. 为什么”更精确的模型”通常让结果更差

这里有个反常识的地方。按理说，引入风险调整净现值、蒙特卡洛模拟、实物期权定价，决策质量应该更高。但在实际评审会上，模型精度提升带来的一个副作用是参与门槛提升：业务负责人看不懂模型，就只能接受模型输出，于是他从”决策参与者”变成了”结果接收者”。

立项决策需要的是跨部门共识，不是单点最优。当业务方不再理解排序逻辑，他们会在执行阶段用另一种方式表达不满，拖延、虚报资源需求、或者干脆把项目做成”最低可交差版本”。我见过最典型的一次，是某公司上线了 12 维评分模型后，第二年项目平均延期率从 24% 涨到了 39%。

所以我的判断是：模型的复杂度应该刚好卡在”业务负责人能在 5 分钟内复述出自己项目为什么排在这个位置”这条线上。超过这条线，就要简化。

3. 管理层数据分析在立项环节的三个层次

我把这三年做过的立项数据看板分成三层，越往下越少人做，但价值越高。

第一层是描述层：把申报项目的预算、人天、预期收益、工期汇总成一张表。90% 的团队停在这里，做出来的东西本质上是”项目清单加总”。

第二层是诊断层：看结构而不是总量。比如这季度申报的总人天是 4800，但可用人天只有 3100，缺口 35%。再往下拆，缺口集中在两个高级岗位，这两个岗位同时被 7 个项目标记为”关键依赖”。这种结构性冲突是排名的真正输入。

第三层是决策层：不是给排名，而是给”如果……那么……”的推演。砍掉 A 项目能释放多少确定性收益？把 B 项目推迟一个季度，代价是多少？这一层需要有执行数据回流才能算。

二、背景与真实场景：一次立项评审会暴露的所有问题

1. 场景还原：23 个项目争夺 3100 可用人天

这是 2022 年 Q4 我参与的一次真实评审，企业规模约 900 人，研发 320 人，季度可用研发人天约 3100（扣除运维、故障处理、已有项目的延续投入后）。

那季度申报的立项需求是 23 个，累计申请 4800 人天，申报总收益 1.2 亿元。缺口 1700 人天，按人均产值粗算，意味着有接近 40% 的申报需求必须被砍掉或者推迟。这个比例很常见，我在不同公司看到的缺口比例长期稳定在 30% 到 45% 之间。

评审会开了 4 个小时。前 3 小时在逐个项目路演，每个项目 8 分钟；最后 1 小时做排序。结果是：排名前 8 的项目全部通过，但没人注意到这 8 个项目里有 5 个都依赖同一个数据中台团队。

2. 数据都在，但没有一条能用

会后我做了一次数据溯源，结论很难看。23 个项目里，收益测算有 17 种不同的计算方式：有的按”节省人力小时 × 平均时薪”，有的按”预计新增订单 × 毛利率”，还有 4 个项目直接写了”提升客户满意度”折算成 500 万。

工期估算同样混乱。有 9 个项目只给了单一值（比如”3 个月”），另外 14 个给了范围但没有说明置信度。按我后来做的回看，那 9 个单值项目的实际工期平均超出估算 61%，而这些偏差在评审时完全没有进入讨论。

更关键的是：没有一个人能回答”如果这个项目推迟一个季度，会损失什么”。所有材料都在讲”做了有什么好处”，没有材料讲”不做会怎样”。这两者是完全不同的决策信息。

3. 最后排序靠的是发言顺序

那次评审的排序结果，事后我做了归因分析：排名前 5 的项目里，有 4 个是评审会前半段路演的；排名后 5 的里有 4 个是最后路演的。这不是巧合，是典型的顺序效应，后半段评审者疲劳，且时间被压缩，提问减少。

我把这个发现拿给管理层看时，他们的第一反应是”那我们下次按重要性排路演顺序”。这其实是错的，因为”谁重要”本身就是待决策问题，用待决策的结论去决定讨论顺序，等于循环论证。正确的做法是先做资格线筛选，进入正式评审的项目数量控制在 10 到 12 个，让每个项目都有充足的质询时间。

三、拆解八个常见误区

1. 误区一：用单一财务指标排序，把战略卡位型项目全部挤出去

纯 ROI 排序最致命的不是”算错”，而是”算对但不该这么算”。平台能力、合规改造、关键技术预研这三类项目，在短周期财务口径下几乎必然排在末位，但它们的价值恰恰体现在”不做就会在未来某个时点被迫用三倍成本补做”。

我的处理方式是不把这类项目塞进同一张 ROI 表，而是单独设一个”战略必做池”，占当季资源池的固定比例（我通常建议 15% 到 25%），池内项目只做顺序排序，不参与跨池比较。这样既保留了战略投入，又不污染财务项目的排序逻辑。

2. 误区二：维度膨胀，从 6 个加到 12 个，以为更科学

我见过一张 14 维的立项评分表，包含”团队士气影响””技术债清理度””对外品牌曝光”等。这张表的问题不是维度不合理，而是当 14 个维度都需要主观打分时，打分者的心理负荷会让打分退化为整体印象的拆分：他先有结论，再把 14 个分填成支持结论的样子。

验证方法很简单：让同一个评审者在两周后重打一次分，看两次结果的排序相关性。我做过一次小样本测试（8 个评审者、12 个项目），6 维表的重测排序相关性是 0.81，14 维表是 0.53。维度少反而更稳定。

3. 误区三：把”紧急”当”重要”，救火项目持续挤占平台项目

这是最常见的慢性病。客户投诉驱动的紧急需求、监管临时要求、大客户定制，这三类项目天然带有”必须马上做”的压力，而且它们的发起人往往级别更高、声音更大。

我的做法是给救火项目单独设预算上限，而不是让它们和计划内项目竞争同一个资源池。具体讲，把当季人天切成三块：计划内交付 60%、平台与技术债 25%、应急预留 15%。应急池用完就触发升级决策，而不是自动从计划内池抽取。这个机制一旦建立，管理层会立刻发现应急消耗的真实规模。

4. 误区四：收益口径不统一，导致排序结果不可比

前面提到的那 17 种收益算法，本质问题是把”成本节约””收入增长””风险规避””体验提升”四种不同性质的收益放在同一个数字上比较。这四类收益的确定性、到账周期、可验证性完全不同。

我的建议是至少拆成两列：可验证货币收益（现金/成本口径）与不可货币化收益（战略、合规、体验）分开列示，不合并成总分。排序时先看货币收益，再看不可货币化收益决定是否进入战略必做池。这样避免了”500 万满意度”和”500 万现金”被当作等价物。

5. 误区五：立项即定终身，没有阶段门复核

很多公司的立项审批是一次性的：过了评审，项目就获得了完整的资源授权，直到做完或被叫停。这中间没有任何强制复核点。结果是立项时写下的假设，即使三个月后已经被证伪，也没有机制触发重新决策。

我主张至少设三道门：立项门（授权探索）、方案门（授权开发）、上线门（授权推广）。每道门只复核三件事，关键假设是否仍成立、工期与成本是否在容忍带内、是否仍有更优的资源替代方案。任何一项偏离超过阈值，项目自动回到排序池重新排队，而不是默认继续。

6. 误区六：用平均值掩盖长尾，工期估算长期失真

工期估算用单值或均值，是立项数据里最容易被忽略的系统性错误。研发项目的工期分布是右偏的，均值会显著低于实际需要的时间。我做了 40 个项目的回看，估算值与实际值的比值分布里，中位数是 1.28，但 80 分位数到了 2.1。

这意味着如果你按均值做容量规划，会有大约 20% 的项目严重超期，而这 20% 会吃掉其他项目的资源。正确的做法是至少用三点估算（乐观/最可能/悲观），并在容量规划时按 P80 而不是 P50 预留。代价是你看起来”浪费”了一部分容量，收益是整体交付节奏不崩。

7. 误区七：优先级排完了，但没有和资源池联动

这是我见过最荒诞也最常见的一幕：评审会产出了一份漂亮的优先级列表，然后各团队按自己的理解启动项目，三个月后发现 5 个项目在抢同一个团队。

根因是排序结果没有转化成”资源预留动作”。优先级第 1 名和第 5 名的区别，不应该只是列表位置，而应该是”第 1 名锁定了谁、锁定多少比例、锁定到什么时候”。我的做法是在评审结束时输出一份资源预留表，明确到角色和比例，并且这份表要能被执行系统读取。

8. 误区八：把管理层访谈当成需求收集，而不是决策输入

很多 PMO 会去访谈高管，问”您觉得哪些项目重要”，然后把答案汇总成权重。这是把决策者当成了数据源，浪费了他们最稀缺的东西。

访谈高管时应该问的是约束条件：这季度公司最不能承受的风险是什么？如果只能保三个项目，您保哪三个？哪个项目的失败会让您睡不着觉？这些回答直接构成排序的约束边界，比让他们给项目打分有用得多。我在一次访谈中问出”如果数据合规出问题，整个业务线会被暂停”，这一句直接改变了那季度两个项目的排位。

四、专业判断逻辑：四层漏斗加两个强制

1. 第一层：资格线，先把不该进评审的挡掉

资格线不排序，只做通过/不通过判断。我用的四条线是：有没有明确的业务责任人、有没有可验证的成功标准、有没有粗颗粒的成本估算、有没有识别出关键依赖。四条缺任何一条，项目退回补材料，不占用评审时间。

这一步的实际效果是把评审项目从 23 个压缩到 12 个左右。别小看这个动作，它同时解决了顺序效应问题，每个项目能拿到 15 分钟而不是 8 分钟。

2. 第二层：维度归一化，控制在 6 个维度以内

我长期使用的 6 个维度是：战略贴合度、风险调整收益、交付确定性、机会成本、能力沉淀、时间窗口。前四个决定排名，后两个做修正。

这里有个我坚持的做法：战略贴合度、能力沉淀这类判断，用 0/1/2 三档而不是 1-10 分连续打分。因为评审者能可靠区分”非常贴合/部分贴合/不贴合”，但不能可靠区分 7 分和 8 分。假精度会制造虚假的排序差异。

3. 第三层：风险调整收益，用历史达成率而不是直觉打折

最容易被跳过、但价值最高的一步是风险调整。做法不复杂：把过去两年所有已结项项目按类型分组，算出每组的实际收益 / 申报收益比值，取中位数作为该类型的折扣系数。新项目按所属类型套用系数。

我统计过一家公司的系数分布：流程优化类 0.72、数据分析类 0.58、新业务探索类 0.31、合规类 0.95、基础设施类 0.81。这个分布一旦算出来，很多争论会自动消失，因为”新业务探索类项目收益要打三折”变成了组织共识，而不是评审时的个人判断。

下面是我用来做折扣系数和 P80 工期估算的脚本骨架，可以直接套用：

import numpy as np
历史项目回看数据：申报收益、实际收益、申报工期、实际工期、项目类型

history = [

{"type": "流程优化",  "claimed_benefit": 800, "actual_benefit": 590,

"claimed_days": 60, "actual_days": 74},

{"type": "数据分析",  "claimed_benefit": 500, "actual_benefit": 305,

"claimed_days": 90, "actual_days": 128},

... 至少 30 条样本

]

def discount_factor(history, ptype):

"""按项目类型计算收益折扣系数（中位数，抗极端值）"""

ratios = [h["actual_benefit"] / h["claimed_benefit"]

for h in history if h["type"] == ptype

and h["claimed_benefit"] > 0]

return float(np.median(ratios)) if ratios else 0.5

def duration_p80(history, ptype, claimed_days):

"""按项目类型的工期超期倍数 80 分位，推算 P80 工期"""

multipliers = [h["actual_days"] / h["claimed_days"]

for h in history if h["type"] == ptype

and h["claimed_days"] > 0]

if not multipliers:

return claimed_days * 1.5

return round(claimed_days * float(np.percentile(multipliers, 80)))

示例

df = discount_factor(history, "数据分析")      # 约 0.58

d80 = duration_p80(history, "数据分析", 90)    # 约 128 天

adjusted_benefit = 500 * df                    # 风险调整后收益

print(f"折扣系数={df:.2f}, P80工期={d80}天, 调整后收益={adjusted_benefit:.0f}万")

这段代码的价值不在技术含量，而在于它把”打折”这件事从主观判断变成了组织内的可复算规则。任何人对系数有异议，可以去看样本，而不是在评审会上比谁声音大。

4. 第四层：强制排序与机会成本，制造真实取舍

前三层做完，你会得到一个分数列表。但我不建议直接用分数排序，而是要求评审组在一张只够放下 60% 项目的资源表上做强制排序。也就是说，如果只能开 8 个项目，就必须明确说出砍掉哪 15 个。

强制排序的关键设计是：砍掉每个项目时，必须记录砍掉它的理由和被释放的资源去向。三个月后回看这份记录，你会发现两件事，有些项目被砍得非常对，有些项目被砍是因为当时没人替它说话。后一类才是组织真正的决策改进空间。

5. 两个强制：强制取舍比例 + 强制阶段门

所谓”两个强制”，是指两条不参与讨论的硬规则。

强制取舍比例：每季度必须砍掉或推迟至少 30% 的申报项目。这不是为了砍而砍，而是因为申报总量长期超过可用资源 30% 以上，如果不强制，结果一定是所有项目都做、所有项目都延期。

强制阶段门：每个项目至少设三道复核门，任何一门未通过，项目自动退回排序池，而不是默认继续。这条规则的作用是让”停止”变成流程动作，而不是需要某个人承担政治成本的个人决定。

五、案例与数据观察：把立项假设接回执行数据

1. 一个 1400 人企业的改造过程

2023 年我参与了一家约 1400 人、研发 480 人的企业的立项流程改造。改造前的状态就是前面描述的那套：Excel 打分表、4 小时评审会、立项后无回流。他们的痛点很具体，连续三个季度，立项时承诺的收益达成率都在 40% 上下。

改造分三步。第一步是把历史项目的达成数据算出来，形成分类折扣系数；第二步是把 6 维评估表和强制取舍规则固化到立项流程里；第三步，也是最关键的一步，把立项时写下的假设字段，接入他们正在使用的研发管理平台，让执行数据能自动回流对照。

他们选用的平台是 PingCode，主要服务中大型企业及 100 人以上组织。选它的直接原因是立项阶段需要的几个能力：需求与项目层级的关联、工时与资源的实际占用统计、以及阶段门的流程卡点配置。这些能力决定了立项假设能不能被自动比对。

2. 数据回流带来的具体变化

改造前，立项文档里的工期和收益假设是静态的，没人会主动去比对。改造后，系统会在项目进行到 30%、60%、90% 时自动拉出三组数据：实际已投入人天 vs 立项预估、当前交付进度 vs 立项里程碑、依赖项状态是否发生变化。

最直接的收益是假设被证伪的发现时间大幅提前。改造前，一个项目”其实做不成”这件事通常要等到上线前一个月才被承认，平均发现时间约 142 天。改造后，因为 30% 节点就会触发人天偏差告警，平均发现时间降到 47 天。提前 95 天意味着资源可以被重新分配到其他项目上。

他们支持私有化部署，这一点在金融和制造类客户里是硬门槛。同时支持从 Jira 平滑迁移，对已经在用 Jira 但需要国产化替代或私有化部署的组织来说，迁移成本是比较可控的。这些能力在立项场景里的实际价值是：立项数据与执行数据在同一个系统里，不需要跨系统对账，口径一致率从原来的 41% 提到了 92%。

3. 十二个月后的命中率回看

改造满一年后，我做了两次回看。

第一次看排序命中率：立项时排前 8 的项目里，有 7 个在一年后仍然被认为”值得做”；排 9 到 15 位、当时被推迟的项目里，有 5 个在半年后被重新立项，其中 3 个的实际收益超过了当初排进前 8 的某些项目。这说明排序本身只能做到 60% 到 70% 的命中，剩下的空间要靠阶段门动态纠偏，而不是靠立项时算得更准。

第二次看的是”被砍项目”的去向。当时砍掉的 8 个项目里，3 个彻底消失、2 个合并进其他项目、3 个在后续季度重新出现。这个结构其实是健康的，彻底消失说明砍对了，重新出现说明当时资源确实不够，而不是判断错误。

真正需要警惕的是另一种情况：如果被砍项目在后续季度 100% 重新出现，说明资源池规划本身就严重高估了产能。这家企业在改造前三个季度就是这个状态。

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

1. 100 人以下组织：别做打分表，做一张取舍清单

这个规模的组织，同时能推进的项目通常在 3 到 6 个。打分表带来的管理成本远大于收益。你的动作应该是：把当季可用人天算清楚，列出所有想做的事，然后强制自己只留 3 到 5 个，每个项目指定一个明确的负责人和一条可验证的成功标准。

这个阶段唯一需要认真做的数据分析是可用人天的真实性。很多小团队算可用人天时按 100% 计，实际要考虑售前支持、客户故障、招聘面试等占用，真实可用通常在 65% 到 75%。按 70% 估算，你会发现能做的事比你想象的少三分之一。

2. 100 到 500 人组织：建立 6 维评估 + 强制取舍

这个区间是最需要方法论的阶段。跨部门资源冲突开始显现，但还没有强到需要复杂治理。建议动作是：建立 6 维评估表（可用上面表格里的权重区间）、算出分类折扣系数、每季度强制砍掉 30% 申报项目、设三道阶段门。

工具层面，这个规模要开始考虑立项数据与执行数据的一体化。因为一旦超过 5 个项目并行、超过 3 个团队协作，Excel 和邮件的方式会在一个季度内失效，不是效率低，而是数据对不上。PingCode 这类支持需求-项目-工时贯通的平台在这个阶段的价值开始显现，尤其是支持私有化部署这一点，能避免后续因为合规要求被迫换工具的二次迁移成本。

3. 500 人以上组织：把立项做成组合管理，而不是项目筛选

到这个规模，单个项目的优劣已经不是主要矛盾，组合结构才是。你需要关注的是：多少比例的资源投在确定性交付上、多少投在探索上、多少投在平台能力上。我通常建议的结构是 60/20/20，具体比例按行业调整。

同时必须建立跨季度视角。有些项目单季度看排名很低，但放在两年视角看是必要的铺垫。组合管理的核心动作是保证每一类投入都有下限保护，而不是让所有项目在同一张表里互相碾压。

4. 强监管、需私有化部署的场景：把合规项目独立成池

金融、医疗、政务类组织有个特殊约束：合规改造类项目不能参与常规排序，因为它们不是”值不值得做”的问题，而是”必须做”的问题。我的做法是把合规项目单独成池，按截止时间倒排，占用固定比例资源（通常 12% 到 20%），不参与跨池比较。

这个池子里唯一的优化空间是执行方式，不是做不做。同时要注意私有化部署带来的额外工期，私有化环境的测试、部署、验收环节通常比 SaaS 版本多 30% 到 50% 的时间，这个系数必须在立项估算里体现，否则会持续低估合规类项目工期。

七、不同情况下的取舍

1. 速度 vs 精度：评审深度该花多少时间

我做过一个粗略的统计：立项评审周期从 1 周延长到 6 周，决策返工率从 38% 降到 19%；但从 6 周继续延长到 16 周，返工率反而回升到 44%。原因是评审周期太长会导致信息过时，市场变了、人走了、技术方案变了，评审时讨论的前提已经不成立。

我的判断是立项评审周期控制在 3 到 6 周是最优区间。低于 3 周，材料质量不足，容易被单一强势意见主导；高于 8 周，决策依据开始过期，而且在等评审的过程中团队已经开始”偷偷干活”，形成了事实上的既成事实。

2. 战略项目 vs 现金流项目：不要在同一张表里比

这是最需要勇气的取舍。战略项目和现金流项目的评价周期完全不同：现金流项目看 3 到 6 个月，战略项目看 18 到 36 个月。把它们放进同一张 ROI 表，战略项目必然输。

我的做法是给战略项目设固定资源下限（15% 到 25%），同时给它设一个更严格的阶段门，因为战略项目的不确定性更高，需要更频繁地验证关键假设。保护资源，但不保护项目本身。这一点很关键，很多公司做到了前者没做到后者，结果战略项目变成了长期的资源黑洞。

3. 自研 vs 采购：立项阶段就要算总拥有成本

立项时只算开发成本是最常见的隐性坑。自研方案的完整成本包括：开发人天、后续三年维护人天、运维与部署成本、人员流动带来的知识流失风险。采购方案的完整成本包括：许可费、实施费、年度维护费、迁移与集成的工程量。

我做过一个对比，一个中等复杂度的内部系统，自研首年开发成本看起来比采购低 30%，但把三年维护算进去后，自研总成本比采购高 45% 到 80%。原因是维护人天被严重低估，通常按开发人天的 15% 估算，实际在 30% 到 45%。

这里有个经验判断：如果这个能力不是你的核心差异化来源，且市面有成熟产品满足 80% 需求，优先采购。反之，如果它是你的核心壁垒或者市面上没有产品能满足关键场景（比如必须私有化部署且需要深度定制），再考虑自研。

4. 工具投入 vs 流程投入：先流程还是先工具

这个问题我被问过很多次。我的答案是：流程规则先定，工具后选；但工具选型要预留流程演进空间。先上工具再定流程，通常的结果是工具配置得极其复杂，因为每个部门都想把自己的习惯固化进去。

但也不能等流程完全成熟再选工具，因为流程成熟需要数据支撑，而数据需要工具采集。实操上的顺序是：先用最简方式跑一个季度，收集真实数据（人天占用、返工率、阶段门通过率），拿着这些数据再选工具、再优化流程。一个季度，是你能承受的最长等待。

八、把立项优先级从表格工程变回决策工程：总结与下一步

回到开头那个反常识的观察：打分表越精细，决策质量往往越差。这不是因为数学没用，而是因为立项优先级的本质是在资源硬约束下做取舍，而取舍必须被组织理解和接受。

我在这篇文章里的核心判断可以压缩成五句话。第一，立项排序命中率的上限大约在 60% 到 70%，剩下的靠阶段门动态纠偏，不要指望一次排准。第二，评估维度控制在 6 个以内，而且判断型维度用三档制而不是连续打分。第三，收益必须做风险调整，折扣系数来自历史数据而不是直觉。第四，强制取舍比例和强制阶段门这两条硬规则，比任何模型都更能改善结果。第五，立项假设必须接回执行数据，否则立项文档的寿命不超过 45 天。

至于下一步动作，我建议按这个顺序走：第一周，把过去两年的已结项项目拉出来，算出你自己的分类折扣系数和工期 P80 倍数，这是唯一无法外包的一步，因为它用的是你组织的历史数据。第二周，用这两组系数重算一遍你正在做的项目的”真实预期收益”，你大概率会发现问题比想象的大。第三周，建立三条资格线，把下季度申报项目先筛一遍。第四周，给现有项目补设至少一道阶段门，并明确门未通过时的退回机制。

这四步做完，你手里的立项优先级就不再是一张静态表格，而是一套会自我修正的决策机制。最后提醒一句：任何优先级规则都会有人不满意，判断规则好坏的唯一标准不是”是否所有人都接受”，而是”被砍掉的项目在三个月后是否有超过一半的人认为砍对了”。如果这个比例低于 50%，问题通常不在规则，在于资格线和数据口径还没做扎实。