项目立项优先级教程：跨部门团队最佳实践，避坑指南

去年我参与了一场跨部门立项评审：12 个项目、7 个部门、4 个小时。最终投票选出 5 个项目进入排期。三个月后复盘，5 个项目里 3 个卡在资源上没启动，2 个被业务方自己叫停，真正推进到交付的只有 1 个，而那个项目，恰恰是当初评分排第 7、差点被淘汰的那个。

这不是个例。我在过去六年里参与、主持、复盘过大约 40 场跨部门立项评审，覆盖制造业、金融科技、SaaS 和一家千人规模的集团公司。我发现一个稳定的规律：立项评审会开得越热闹、评分表做得越漂亮的组织，三个月后的执行偏差往往越大。

问题不在“大家不会排序”，而在于大多数团队把“优先级”理解成了一场投票，而不是一份资源配置契约。这篇文章我会把跨部门立项优先级这件事拆开讲：先给结论，再讲真实场景、常见坑、判断逻辑、案例数据，最后给不同规模组织的行动建议和取舍清单。

一、先给结论：立项优先级的本质是“稀缺资源的分配契约”

如果你只有五分钟，先看这三条结论。它们是我在几十次评审翻车和纠偏里反复验证过的，也是后面所有方法论的骨架。

1. 优先级不是给项目排序，是给资源排序。排序的对象永远是“谁的人、谁的预算、谁的时间窗口”，而不是“哪个需求听起来更重要”。
2. 跨部门优先级之争，90% 是口径之争，不是利益之争。两个部门吵得面红耳赤，多数时候是因为他们心里那杆秤的刻度根本不一样。
3. 任何需要超过 6 个维度才能算清楚的模型，在跨部门场景里都会死。不是模型不对，是维护成本超过了它能带来的决策收益。

1. 为什么“排序”这个词本身就是错的

“排序”暗示了一个隐含前提：资源是无限的，我们只需要决定先后。但现实是，一个 200 人的研发组织，同一季度能同时推进的中大型项目通常不超过 5 个（这是我在多个组织里观察到的经验区间，受团队规模、技术债和运维负担影响很大）。

当候选项目有 12 个、实际能承载 5 个时，你要做的不是排序，而是淘汰。排序是在“都做”的前提下排先后，淘汰是在“只能做一部分”的前提下做取舍。这两个动作的心理成本完全不同，前者大家都能接受，后者会得罪人。

所以我后来在所有评审开场白里都会先说一句：“今天的目标不是排出前五名，是明确哪七个今年不做。”这句话一出口，会议的性质就变了，从“争名额”变成“共同面对约束”。

2. 优先级失灵的三个早期信号

在坏结果出现之前，通常已经有征兆。以下三个信号，只要出现两个，我就知道这套优先级机制有问题了。

• 信号一：会议时间超过 90 分钟且没有产出淘汰名单。说明大家在争排序，而不是在解决约束。
• 信号二：评分表里出现“综合分”这个词，但没人能解释 8.3 分和 7.9 分的区别是什么。小数点后一位的精度，掩盖的是评估口径的粗放。
• 信号三：会后两周内，有项目以“老板临时关注”为由插队。说明这套机制从来没有被真正授权。

3. 一个反常识判断：先定“不做什么”，再定“做什么”

大多数组织的立项流程是“收集需求 → 评估 → 排优先级 → 分配资源”。我建议把它倒过来一半：先定资源容量上限和淘汰规则，再收需求。

原因很直接。如果先收需求再谈容量，你就会陷入“每个需求都有道理”的泥潭，因为需求本身确实都有道理。但如果你先明确“本季度研发总容量是 42 人月，其中 60% 已被存量维护占用，只剩 16.8 人月可分配给新项目”，那么讨论就从“哪个更重要”变成了“这 16.8 人月怎么花最值”。

后者的讨论效率，通常是前者的三倍以上。这是我用会议时长和决策耗时两个指标反复对比过的。

二、跨部门立项会的真实场景：为什么总是吵成一锅粥

要解决问题，先要看清楚问题长什么样。下面三个场景是我亲身经历过的，几乎每家 200 人以上的组织都能对号入座。

1. 场景一：12 个项目 4 小时，选出的是“最会讲的人的项目”

那场会上，每个项目负责人有 15 分钟路演时间。第一个上场的讲得非常漂亮：用户痛点清晰、市场空间大、竞品分析详尽。第七个上场的讲了 15 分钟的业务逻辑，PPT 全是表格，没人听得进去。

最后的投票结果，前三个都是“讲得好”的。这不是因为评委不专业，而是因为路演形式天然奖励表达能力，而不是奖励项目价值。当评估信息全部来自现场陈述时，你评估的其实是演讲水平。

我后来把这种会议改成“材料前置 + 现场只答疑”，评审前 3 天所有项目的一页纸材料必须上传，会上不允许重复介绍，只回答质疑。效果立竿见影：那些“讲得好但价值一般”的项目，在第一轮就被筛掉了一半。

2. 场景二：两个部门用两套 ROI 算法，吵到最后比的是嗓门

这个场景更隐蔽。业务部门算 ROI 用的是“收入增量 ÷ 开发投入”，技术部门算的是“长期维护成本 ÷ 一次性建设成本”，财务部门算的是“回收周期”。三个部门算出来三个结论，谁也说服不了谁。

关键问题是：他们不是在对同一个数字吵架，而是在对同一件事用三把不同的尺子。这种争论永远不会收敛，因为它本质上不是分歧，而是度量缺失。

解决办法不是让大家统一算法（那太慢），而是统一到一套“相对刻度”上。比如把 ROI 从绝对金额改成 1-5 分的相对评级，并给每一分配上锚定案例。这件事我在第四节会详细讲。

3. 场景三：优先级定完了，资源没定，三个月后集体烂尾

这是最致命的一种。会上大家达成共识，5 个项目按顺序推进。但会议纪要里只写了“A 项目优先级最高”，没写“A 项目由 B 部门出借 2 名后端，从 3 月 15 日起，为期 10 周”。

三个月后复盘，A 项目还在等资源。原因是那句“优先级最高”在 B 部门眼里，只是一句客气话，他们自己季度初也排了活儿，没有书面承诺就没有排期调整。

没有资源承诺的优先级，等于没有优先级。这是我在所有方法论里最强调的一条，也是最容易被跳过的一条。

4. 优先级失控的隐形成本，比你想的贵

大多数人只算“做错项目的损失”，却忽略了优先级混乱本身的成本。我做过一次粗略拆解，把四类隐性成本量化出来，结果比项目本身直接损失还高。

• 反复评审成本：一个项目平均被评审 2.7 次，每次涉及 8-12 名中高层，按人均人力成本折算，单项目约 1.2-2.5 万元。
• 资源空转成本：项目等资源期间，团队处于“半启动”状态，产能利用率通常只有 40%-60%。
• 切换损耗：一个人同时挂 3 个以上项目时，有效产出会下降约 20%-35%（这是我在 3 个团队用任务流数据观察到的区间）。
• 信任损耗：最难量化但最贵。当“承诺了又不做”发生 3 次以上，跨部门协作的沟通成本会显著上升。

三、五个最常见的坑：每一条我都踩过

这一节是避坑指南的核心。以下五个坑，按踩中概率从高到低排列，我会说清楚“为什么错”和“改法是什么”。

1. 坑一：用“重要性”排序，而不是用“约束条件”排序

“这个项目很重要”“那个项目也很重要”，当评估词是“重要”时，所有的项目都会得到高分，因为几乎没人会说自己提的项目不重要。重要性是一个主观形容词，不是可比的度量。

改法：把“重要性”拆成可验证的约束。具体问三个问题：如果不做，会发生什么？这件事有没有时间窗口？做完能解锁什么其他事情？这三个问题答不上来的项目，通常真的可以往后放。

2. 坑二：把 ROI 当成万能尺子

ROI 只适用于“收益可量化、周期短、不确定性低”的项目。而跨部门立项里大量的项目属于另外三类：合规驱动的（不做会罚款）、能力建设型的（短期无收益但长期降本）、依赖解锁型的（本身没收益但卡住别人）。

用一把尺子量四类东西，结果一定是错的。我见过最典型的案例是一个数据合规改造项目，ROI 算出来是负的，险些被砍，最后是法务介入才保留，三个月后新规落地，同行业多家公司紧急整改，成本是它的三倍。

改法：按项目类型分类，不同类型用不同评估组。我在下面第四节会给出具体的三层漏斗。

3. 坑三：没有统一口径，各算各的分

这是最普遍也最难改的。表现是：每个部门提交的立项材料里，都有自己的一套评分维度，有的用 1-10 分，有的用高/中/低，有的干脆只有一段文字描述。

汇总的时候，评审组要么凭感觉合并，要么强行换算。无论哪种，都会失真。口径不统一的评分，比不评分更危险，因为它给了决策一个“看起来客观”的假象。

改法：统一七个维度、统一 1-5 分制、统一锚定案例。维度数量不要超过 7 个，否则打分人会疲劳，最后都是差不多的分。

4. 坑四：优先级一旦定下就冻结，不设复议窗口

有些组织为了防止“插队”，把季度优先级冻结得死死的。听起来很纪律，但现实中市场会变、政策会变、竞品会变。一个季度 13 周，外部环境变化足以让某个项目从高优变低优。

改法：设定“有条件的复议机制”。我的建议是：每季度设 1 个正式复议窗口（通常在季度中期），复议需要满足明确条件（比如外部合规要求变化、关键客户合同变更、重大技术风险暴露）。有条件的复议，比完全冻结更有效。

5. 坑五：只排项目，不排资源

这条在第二节已经说过，但值得单独列出来，因为它是最高频的失败原因。优先级决议如果不落到“谁、什么时候、投入多少人天”，它就是一份愿望清单。

改法：每个进入排期的项目，必须附带一张资源占用表。表里至少包含：责任部门、参与角色、投入比例、起止时间、占用方式（专职/兼职）。没有这张表的项目，不允许进入下一阶段。

四、专业判断逻辑：三层漏斗 + 一套可落地的打分机制

我试过至少五六种主流优先级框架，包括 RICE、WSJF、Kano、MoSCoW 等。它们的共同问题是：设计逻辑都很优雅，但跨部门落地时缺少“谁来打分、怎么校准、争议谁裁决”这三个环节。

下面这套三层漏斗是我在实际项目里迭代出来的版本，它不追求理论完备，追求的是“能在一个季度内稳定跑起来”。

1. 第一层：战略闸门（Go / No-Go）

这一层不做排序，只做过滤。目的是一票否决掉明显不该做的项目，减少后面的评估量。通常能过滤掉 30%-40% 的候选项目。

闸门条件建议控制在 3-4 条，且必须是二值判断（是/否），不要用分数：

• 是否直接服务于本年度公司级战略目标？（不服务于任何战略目标的，直接出局）
• 是否存在强制外部约束？（合规、监管、合同义务，有一票通过权）
• 是否与现有项目高度重复？（重复的合并或取消）
• 是否有明确的业务负责人？（没有责任人的，直接出局）

最后一条看似官僚，实际非常有效。没有明确业务负责人的项目，在执行阶段 100% 会烂尾，因为没人真正为结果负责。

2. 第二层：约束校准（Capacity Constraint）

这一层是大多数框架缺失的。它要回答的问题不是“哪个项目好”，而是“我们到底有多少资源”。

具体做法是建立一份“资源容量账本”，按角色（而不是按人头）统计可用产能：

这张表的威力在于：它把“资源紧张”从一句抱怨变成了一个可计算的数字。当数据/算法剩余可分配是 0 时，任何需要算法资源的项目自动进入下一季度候选，不需要争论。

我特别建议按“角色”而不是按“部门”统计。因为跨部门协作的核心瓶颈往往是某个具体角色（比如数据分析师、资深架构师），而不是整个部门。

3. 第三层：加权排序（Weighted Scoring）

只有通过前两层的项目，才进入打分排序。我用的七维度模型如下，每个维度 1-5 分：

1. 战略契合度：与年度战略目标的直接关联程度（权重 25%）
2. 业务价值：收入增量或成本节约的相对量级（权重 20%）
3. 风险与合规：不做会带来的风险敞口（权重 15%）
4. 依赖解锁价值：完成后能解锁多少其他项目（权重 15%）
5. 交付确定性：技术可行性与团队经验（权重 10%）
6. 时间窗口：是否存在明确的时间紧迫性（权重 10%）
7. 资源占用：以人月为单位，作为分母而非加分项（权重 5%，计入分母）

计算公式可以简化成这样：

def priority_score(item):
"""

item 各字段均已归一化到 1-5 分

effort 单位为"人月"，最小取值 0.5 防止分母过小导致分数畸高

"""

value = (

item.strategic_fit * 0.25 +

item.business_value * 0.20 +

item.risk_reduction * 0.15 +

item.unblock_value * 0.15 +

item.delivery_confidence* 0.10 +

item.time_window * 0.10

)

effort = max(item.effort_in_person_month, 0.5)

return round(value / effort * 10, 2)

注意最后一步用了“除以人月”而不是“加上资源分”。这是从 RICE 框架借鉴的关键设计。把资源作为分母，可以让“小而高价值”的项目自然浮上来，这在跨部门场景里非常重要，因为大项目往往由话语权强的部门提出，容易挤压小项目空间。

4. 打分表设计：锚定法与反刷分机制

任何评分表一旦投入使用，就会有人研究怎么拿高分。这是我踩过最深的坑之一：第一版评分表上线两个季度后，所有人都学会了“战略契合度打 5 分”，因为反正没人能证伪。

我后来加了三道防线：

（1）锚定案例库

每个维度的每个分值，都配一个真实的历史项目作为锚点。比如“战略契合度 5 分”的定义不是“非常重要”，而是“等同于 2023 年的 XX 项目，该项目直接支撑了年度三大战略之一”。打分时必须说明“本项目与锚点项目的可比性”。

（2）双人独立打分 + 差异复盘

每个项目由两个不同部门的评估人独立打分，差异超过 1.5 分的维度，必须在评审会上解释。这一条把主观分差暴露出来了，效果非常明显。

（3）反方陈述

给每个进入候选池的项目，指定一个“反方”，只有 5 分钟，任务是论证“为什么这个项目应该往后放”。这招听起来有点对抗性，但实际效果是让评估信息更完整。

5. 冲突裁决：谁有最终票

这是所有框架里最少被讨论、但最决定成败的一环。我的建议是三条规则：

• 合规与安全事项，法务/安全负责人有一票否决权，无需排序。这是唯一应该有无条件否决权的角色。
• 资源冲突时，由资源归属部门的负责人决定是否出借，但必须说明理由并记录在案。不允许用“我们也忙”这种模糊理由拒绝。
• 总分接近（差距小于 10%）的项目，由业务负责人而非技术负责人裁决。因为接近时，胜负取决于对业务的理解，而不是技术判断。

五、一个 1200 人组织的真实改造案例

下面这个案例来自我深度参与的一家制造与软件混合型企业，员工约 1200 人，研发序列约 380 人，业务横跨 4 个事业部。出于保密，我隐去公司名称，但数据是实际跟踪的。

1. 改造前的状态

这家企业当时的立项流程是这样的：各事业部在季度初提交需求文档，IT 部门统一收集，季度评审会上逐个汇报，最后由分管副总拍板。问题集中表现为三点：

• 立项周期长。从需求提交到资源到位，平均 19 个工作日，最长的拖到 35 天。
• 决议不稳定。42% 的项目在决议后两个月内被重新讨论，理由是“业务情况变了”。
• 跨部门扯皮多。每月平均有 9 次立项相关争议需要升级到副总级别裁决。

最关键的问题在技术侧：四个事业部各有自己的工单系统，需求数据和管理数据分散在四五套工具里，评审时连“去年类似项目实际花了多少人月”都查不出来。

2. 我们做的四件事

第一件：把资源容量账本先建起来。这是所有工作的起点。我们花了三周时间，逐个角色盘点了产能占用情况，包括存量维护、运维值班、技术支持这些通常被忽略的部分。做完之后发现，实际可用于新项目的产能只有账面人数的 38%。

第二件：统一七个评估维度和锚定案例。我们选了 12 个历史项目作为锚点，覆盖每个维度的 1 分、3 分、5 分。评估人在打分前必须先看锚点库，这一条把打分的随意性降了很多。

第三件：把立项流程搬进统一平台。这一步的关键不在于工具本身，而在于把“需求、评估、资源承诺、排期”这四个环节的数据串起来。以前它们是四张 Excel，现在是一条可追溯的链路。

第四件：建立季度中期复议窗口。每个季度第 7 周开放一次复议，需满足明确条件。这一条让决议的稳定性大幅提升，因为大家知道“还有机会调整”，不会在初始评审时死磕。

3. 工具选型与迁移的实操细节

在工具选型阶段，我们对比了几类方案。考虑到这家企业的几个硬约束，研发团队超 380 人、需要私有化部署、有历史数据迁移需求、有数据不出内网的合规要求，最终选择了 PingCode。

选它的几个实际原因，我说得具体一点，方便你对照自己的情况判断：

• 私有化部署能力成熟。数据完全留在内网，这对有合规审计要求的制造业客户是硬门槛。我们实测部署在一套 8 核 32G 的内网环境上，200 人并发使用响应正常。
• 支持 Jira 平滑迁移。这家企业原来用 Jira，历史项目有 6 年数据。迁移时最怕的是字段丢失和工作流错乱。实际迁移过程中，PingCode 提供了字段映射工具，自定义字段和工作流状态可以对应过去，我们分了三个阶段做灰度：先迁 1 个事业部试点，再迁 2 个，最后全量。
• 国产替代路径清晰。对于需要从海外工具链切换的组织，迁移成本和风险是决策关键，这块的实际支持程度比宣传口径更重要。
• 多项目集与跨部门视图。这是我们最看重的功能。四个事业部的项目可以汇总到一个资源视图里，谁在做什么、占用多少产能，一眼能看到。

迁移过程中踩的两个坑，我也说一下：一是历史数据里的自定义字段命名不规范，同名不同义的情况有 30 多处，迁移前必须做一次字段清洗；二是旧系统的部分工作流状态在新系统里没有直接对应，需要重新设计状态机，这部分我们花了大约两周做映射方案。

我的经验判断是：工具迁移的成本，70% 花在数据治理上，30% 花在工具本身。如果你打算做类似迁移，先把数据盘干净，比选哪个平台更重要。

4. 三个季度的数据变化

改造从第二季度启动，我把三个季度的关键指标记录下来：

需要说明的是，这些改善不是单一因素造成的。工具、流程、评分机制、复议制度四件事是一起上的，无法剥离开来归因。但从访谈反馈看，“资源容量账本”和“锚定案例打分”这两项的贡献最大，分别被 11 位和 8 位受访者主动提及。

这里我要特别提醒一个反直觉的观察：按期交付率从 51% 提到 78%，主要不是因为项目做得更快了，而是因为立项时淘汰得更狠了。进入排期的项目数量从每季度 11 个降到 6 个，但总产出反而提升了。这就是“少做但做完”的价值。

六、不同规模组织的行动建议

同一套方法论，在 80 人和 800 人的组织里做法完全不同。下面按规模给建议，你可以直接对号入座。

1. 100 人以下：不要做模型，做“一张纸 + 一个会”

这个规模的组织，最大的优势是沟通链路短，最大的风险是流程过重。我见过 60 人的团队引入五维度评分表，结果每周多花 6 小时维护表格，得不偿失。

我的建议是：

• 不建评分模型，改用“一页纸立项”：项目目标、预期收益、投入人月、负责人、时间窗口，五栏写完。
• 不做季度评审，做双周排期会，每次 30 分钟，只处理“接下来两周做什么”。
• 资源容量用最简单的方式管：白板或共享表格，列出每个人的占用比例即可。
• 唯一必须坚持的纪律：没有资源承诺的优先级不成立。这条在任何规模都适用。

2. 100-500 人：建轻量评分机制，重点在口径统一

这个区间是最容易混乱的阶段：项目多、部门多、但还没到需要专职 PMO 的规模。核心矛盾是“口径不统一”。

建议动作：

1. 建立七个维度的统一评分表，但先只用在“需要跨两个以上部门”的项目上，单部门项目走快速通道。
2. 每月一次校准会，时长控制在 60 分钟，只做一件事：对打分差异超过 1.5 分的项目做对齐。
3. 建立锚定案例库，初期 6-8 个案例就够用，后面逐步补充。
4. 把资源容量账本做成月度更新的活文档，不要一季度才盘一次。

这个规模的另一个关键决策是工具。100 人以上、有多个并行项目集、又需要跨部门资源视图的组织，通常已经超出通用协同工具的能力范围了。这时候考虑引入专业的研发项目管理平台，收益会比较明显。

3. 500 人以上：三层漏斗 + 专职机制 + 平台化

这个规模的组织，靠人的自觉已经无法维持优先级秩序，必须靠机制和工具。建议：

• 完整落地三层漏斗，战略闸门、容量校准、加权排序层层过滤。
• 设立专职或半专职的 PMO 角色，负责容量账本维护、评分校准、争议记录。1 名 PMO 可以支撑约 300-400 人的研发组织。
• 数据必须集中。四个事业部四套系统的情况下，任何优先级机制都会失真。这时需要评估是统一到一套平台，还是建立数据汇聚层。
• 对私有化和合规有要求的组织，选型时要提前确认部署方式，不要等到采购阶段才发现不支持。

前面提到的那个 1200 人案例，就是走的这条路。他们的选择是把分散的工具链收敛到一个能满足私有化、多项目集和跨部门视图的平台，同时把历史数据迁过去。这个决策的收益，在第三个季度才开始显现。

七、取舍：什么情况下应该放弃精细模型

方法论讲完了，但真正考验判断力的是“什么时候不用它”。以下三组取舍，是我这几年反复权衡过的。

1. 取舍一：速度 vs 精度

评分模型的精度和决策速度是负相关的。七个维度、双人打分、锚定案例，这套流程跑完一个项目大约需要 2.5-4 小时。如果候选项目有 40 个，光打分就要 120 小时以上。

我的判断标准是：如果项目的平均投入低于 20 人月，用完整模型是不划算的，改用“快速三问”（不做会怎样、有没有时间窗口、能解锁什么）就够。只有投入超过 50 人月、或涉及三个以上部门的项目，才值得走完整流程。

具体来说，我会做分层：A 类项目（投入大、跨部门多）走完整流程；B 类项目（中等投入）只走战略闸门 + 快速打分；C 类项目（小投入）由部门自行决策，季度报备即可。经验上，A 类通常占候选项目的 15%-25%。

2. 取舍二：统一 vs 自治

统一口径的好处是可比，代价是灵活性。有些事业部业务节奏快，需要更短的决策周期；有些事业部受监管约束，需要更重的评审。

我的建议是“统一维度，不统一权重”。七个维度的定义和打分锚点全公司统一，但权重可以按事业部调整。比如合规敏感的事业部，把“风险与合规”权重从 15% 提到 30%，这是合理的。但维度名称和分值定义不能改，否则数据就没法横向对比了。

3. 取舍三：自建 vs 采购

这是我被问得最多的问题之一。我的一般判断是：

• 100 人以下、流程简单：用通用协同工具 + 表格，自建成本更低。
• 100-500 人、流程开始复杂：采购成熟平台更划算。自建一套能支撑跨部门资源视图的系统，实际投入通常在 30-60 人月，且需要长期维护。
• 500 人以上、有私有化和合规要求：必须评估平台的部署能力和迁移路径。这时要看的不是功能列表，而是“历史数据能不能迁过来、迁移要多久、出问题谁兜底”。

关于自建的成本，我给一个粗略的量化参考：一个支持多项目集、资源视图、权限隔离、审计日志的自建系统，首年投入约 40-70 人月（含开发、测试、部署、运维），后续每年维护约 12-20 人月。按人均成本折算，三年总成本通常高于采购成熟平台。这是很多团队在决策时容易低估的部分。

八、下一步怎么做：一份可以直接抄的行动清单

前面讲了太多判断，最后给一份可以立刻上手的清单。我按“本周、本月、本季度”三档来分，你按自己的节奏取用。

1. 本周就能做的三件事

1. 统计一次真实容量。把团队所有角色列出来，标出存量维护、运维值班、技术支持的占用比例。这个动作大约需要 2-3 小时。做完你大概率会发现，可用产能比想象的低 20 个百分点以上。
2. 把最近一次立项决议翻出来，检查有没有资源承诺。如果没有写清“谁、投入多少、什么时候开始”，那这份决议实际上没有约束力。这是一个快速的自检。
3. 找出一个“讲得好但没做成”的项目，和一个“讲得一般但做成了”的项目。对比它们的评估分数和实际产出。这个对比会成为你说服团队改机制的最有力材料，比任何方法论都管用。

2. 本月可以推进的两件事

• 建立锚定案例库。挑 6-8 个历史项目，覆盖你评估维度的 1 分、3 分、5 分档位。每个案例写两句话：这个项目当时什么情况、为什么打这个分。这件事一个人两天就能做完。
• 把七个维度和权重定下来，走一次试运行。不要追求一次到位，先拿 5 个候选项目试跑一遍。试跑的目的不是得出正确结论，而是发现“哪个维度大家理解不一致”。

3. 本季度值得投入的一件事

如果你们组织的研发人数超过 100 人，并且已经出现“跨部门项目排期对不齐”的情况，那么这个季度值得投入的一件事，是把立项、评估、资源承诺、排期这四个环节的数据串到一条链路上。

不一定要马上采购新平台。你可以先用一个共享表格把四个环节串起来，跑一个季度，看看瓶颈在哪里。如果瓶颈出现在“信息分散、无法追溯、资源视图缺失”，那就是工具层面需要升级了。这时候再去评估是对私有化有要求、还是有历史数据迁移需求、还是需要多项目集视图，选型会理性得多。

最后回到开头那场评审。那个评分第 7、差点被淘汰、最后唯一做完的项目，之所以能做成，是因为它有一个非常明确的业务负责人，并且占用的资源恰好是当时最不紧张的那个角色。它赢的不是评分，是约束条件的匹配度。

这句话，可能是我做立项优先级六年里最重要的一个体会：优先级从来不是“哪个更重要”的问题，而是“在这个时间点、用这些资源、哪个能被真正做完”的问题。想清楚这一点，跨部门立项评审的难度会下降一大半。