项目立项优先级教程：产品经理制度设计，避坑指南

去年我接手过一个很典型的诊断案例：一家 600 人左右的 B2B 软件公司，有一套 12 个维度的立项评分卡，Excel 模板做得相当漂亮，权重、公式、条件格式一应俱全。但当我问研发负责人”过去 9 个月里真正决定项目做不做的因素是什么”，他给的原话是：”每周一早上老板在群里发的那句’这个先做’。”（案例经过脱敏与合并处理，涉及数据均为区间值）

这就是我想在这篇教程里先摆出来的反常识判断：立项优先级做不好的团队，99% 不是排序算法的问题，而是制度设计的问题。你换一套打分模型、加两个维度、调三次权重，只要”谁能说不”和”说了算不算数”这两个问题没解决，三个月后一定回到原地。我见过太多团队把精力花在评分卡的精致程度上，却从来没有定义过”什么项目该被砍掉”。

这篇内容会按七步走：先给核心结论，再讲真实背景，然后拆解常见误区，给出可落地的专业判断逻辑，用一个大中型企业的真实重构过程做数据观察，最后分别给出不同规模团队的行动建议与取舍框架。如果你正在做明年规划、正在被”所有需求都很重要”折磨，或者正在选一款能承载立项制度的项目管理平台，这篇可以直接当工作手册用。

一、核心结论：立项优先级是制度问题，不是排序问题

先把结论压缩成四句话，后面所有内容都是对这四句话的展开。

第一，优先级制度的本质是”放弃机制”，不是”排序机制”。排序的产出是一张有序清单，放弃的产出是一个被明确拒绝的项目集合。大多数团队只有前者，所以清单越排越长，最后谁都不信这张清单。

第二，一套评分卡只能服务一类项目。战略型项目、客户承诺型项目、技术债型项目、合规型项目的价值来源完全不同，用同一套分子分母去比，结果必然是”会填表的人赢”。

第三，优先级必须绑定产能约束才有意义。一个排序结果如果不告诉你”砍掉谁才能做新的”，它就不是决策，只是愿望清单。

第四，制度的载体是工具里的字段和状态机，不是会议纪要。如果立项申请、评审结论、变更记录、复核时间点没有沉淀在系统里，制度会在第三次人员变动后消失。

二、背景与真实场景：立项为什么越来越难排

要理解制度为什么必须重构，先要理解这十年立项环境发生了什么变化。我把变化拆成供给端、需求端和组织端三层，这三层的叠加效应才是”排不动”的根因。

1. 供给端：需求来源从 3 个变成了 9 个

十年前的立项申请主要来自三个口子：销售、客户、老板。现在通常有九个：直销、渠道、客户成功、实施交付、技术支持、市场、合规法务、研发自提技术债、以及产品经理自己的洞察。每个口子背后都有一个 KPI 在推动，没人会因为”提得太多”被批评。

我统计过一个 400 人规模团队的季度需求来源分布：直销占 31%，客户成功占 22%，老板直接下达占 14%，研发自提占 12%，实施交付占 9%，合规占 6%，其余渠道合计 6%。真正由产品经理主导提出的立项，只占 6% 左右。这个数字非常关键，它意味着产品经理如果只做”排序”，实际上是在给别人提的需求做排班表。

2. 需求端：研发产能的增速远低于需求增速

需求条目年均增长 40%-60% 是常态，而研发人力的年均增长通常在 5%-15% 之间，并且随着组织变大，管理开销还在吃掉有效产能。这两条曲线的剪刀差，就是”所有需求都很重要”这句话的物质基础。

3. 组织端：中大型企业的立项复杂度是非线性的

100 人是分水岭。100 人以下，产品负责人能记住所有在研项目，口头排序就够用；一旦跨过 100 人、出现两条以上产品线或三个以上交付团队，口头排序立刻失效，因为没人能同时知道其他团队的排期。

我服务过的中大型企业（普遍在 500-3000 人区间）通常会同时面对四种立项诉求：年度战略项目、大客户定制承诺、平台技术债治理、以及监管合规改造。这四类的决策周期、评审人、价值口径完全不同，硬塞进一张评分表，是后面所有误区的总源头。

三、六个高频误区：我在现场见过最多的问题

这一节把最常见的六个误区逐一拆开。每个误区我都会给出”症状，根因，后果”三段式，你可以对照自己团队的情况做一次自检。

1. 误区一：一套评分卡打天下

症状：所有立项申请都填同一张表，维度包括”业务价值、用户影响、实现难度、紧急程度”，各占 25%。

根因：评分卡的设计者默认”价值可以被同一把尺子度量”。

后果：大客户定制项目因为”业务价值”写得具体（合同金额摆在那里），分数天然高于平台技术债治理项目，于是技术债永远排在最后，直到某次线上故障把所有人的季度目标清零。我在一家公司看到过极端案例：连续 7 个季度，技术债类立项的平均得分都是垫底，第 8 个季度一次数据库迁移事故导致全线停服 11 小时。

2. 误区二：把分数当成决定

症状：评审会流程是”念分数，排序，通过”，全程 45 分钟结束。

根因：团队希望用数字规避争论。

后果：分数变成了政治工具。想推的项目就把分子做大、分母做小，收益估算从”保守”变成”乐观”再变成”科幻”。我复盘过一个团队连续 12 个立项的收益预估与实际回收：预估中位数是 180 万元年化收益，实际回收中位数是 47 万元，偏差接近 4 倍，而且偏差方向高度一致，全部高估。

3. 误区三：没有沉没成本隔离机制

症状：已经做了两个季度的项目，即使价值假设已经失效，也继续投入。

根因：立项评审只管”上马”，不管”下马”。没有人对”终止”负责。

后果：大量僵尸项目长期占用 20%-30% 的研发产能。终止一个项目的政治成本，远高于让它慢慢烂掉，这是组织激励设计的必然结果，不是个人品质问题。

4. 误区四：立项即承诺，缺少中途复核点

症状：项目在立项会上承诺”Q3 交付 12 个功能点”，之后再也没有正式的重新评估节点。

根因：制度只定义了入口，没有定义检查站。

后果：价值假设随市场变化而失效，但资源依然按原计划投入。我建议的最小复核节奏是：立项后第 4 周做一次”假设校验”，第 12 周做一次”继续/调整/终止”三选一。

5. 误区五：优先级会议变成汇报会

症状：两个小时里，一个半小时在讲各项目进展，最后 30 分钟拍板。

根因：会议议程没有区分”信息同步”和”决策”。信息同步完全可以异步完成。

后果：真正需要争论的排序冲突被压缩到最后半小时，决策质量急剧下降，且往往由职位最高的人拍板收尾。

6. 误区六：工具只是看板，不承载制度

症状：立项申请走邮件和 Excel，工具里只放已经确定要做的项目。

根因：团队把工具当成”展示层”，而不是”制度执行层”。

后果：制度的所有中间状态（谁提的、谁评的、为什么被拒、什么时候复核）全部丢失，人员一变动，制度归零。

四、专业判断逻辑：三层过滤 + 双轨评分 + 一条硬约束

下面是我在过去几年里反复迭代出来的一套结构。它的设计目标不是”算得更准”，而是”让不该做的项目在早期就被便宜地拒掉”。

1. 第一层：战略过滤（决定有没有资格进池子）

这一层不做打分，只做是非判断。我给客户的标准是三问：

1. 这个项目和本年度 3-5 个战略主题中的哪一个直接相关？如果答案是”都不太相关，但也很重要”，那就是不相关。
2. 它是否触发了合规、安全、合同违约等红线？触发红线的项目走快速通道，不参与排序。
3. 如果现在完全不做，最坏后果是什么？如果答案是”客户抱怨几句”，那就是可以不做。

这一层的产出只有三种状态：进入评分池、走红线快通道、退回补充信息。大约 40%-60% 的立项申请会在这一层被退回或合并，而且退回成本极低，不需要开会，产品负责人 5 分钟内就能给出结论。

2. 第二层：双轨评分（战略轨与需求轨分开算）

这是整套逻辑里最关键的设计。我把评分拆成两条互不干扰的轨道，各自算分，各自排序，最后在产能分配阶段统一。

（1）战略轨评分公式

战略轨得分 S = 3 × 战略主题匹配度
+ 2 × 不可替代性

+ 2 × 时间窗口紧迫度

5 × 合规红线触发（0 或 1）

各项取值 1-5 分，满分 35 分。

判定门槛：S ≥ 24 进入战略轨排序队列。

字段定义：

战略主题匹配度：直接支撑年度战略目标 = 5；间接支撑 = 3；无关联 = 1

不可替代性：不做则战略目标无法达成 = 5；可被其他项目替代 = 2

时间窗口紧迫度：窗口期在本季度内关闭 = 5；可延后一年以上 = 1

（2）需求轨评分公式

需求轨得分 D = [年化收益(万元) × 收益可信度]
/ [人天成本 × 单位人天成本 + 挤占机会成本]

× 风险调整因子

其中：

收益可信度：有合同/数据支撑 = 0.9；有客户书面承诺 = 0.7；仅口头反馈 = 0.4

挤占机会成本：被挤占项目的当期D值 × 挤占比例（0-1）

风险调整因子：技术方案成熟 = 1.0；存在未验证依赖 = 0.7；强外部依赖 = 0.6

判定门槛：D ≥ 1.5 进入需求轨排序队列。

这两条轨道的关键差异在于：战略轨用的是绝对分，需求轨用的是比值。好处是战略项目不会因为”算不出钱”而被淘汰，需求项目也不会因为”讲不出战略故事”而插队。

（3）两轨如何合并

我的做法是给战略轨预留固定产能，而不是让两轨的分数直接比较。通常战略轨占当期总产能的 30%-40%，剩余产能按需求轨得分排序填满。这样一来，战略项目不需要赢过客户定制项目，它只是走另一条通道。

3. 第三层：产能约束与硬门槛

前两层产出的是”该做”，第三层产出的是”现在能做”。这一层需要把评审通过的项目映射到具体团队和具体人天，并且显式列出被挤占的项目。

我在实操中要求每个立项申请必须附带一句话：“本项目立项，将导致 XXX 项目延后 N 周或终止。”这句话写不出来的立项申请，一律退回。这一个小动作，把我的客户里”通过评审但无法开工”的积压率从平均 40% 降到了 12% 左右。

4. 一条硬约束：在研项目数上限（WIP Limit）

这是整篇内容里我最想强调的一条。同时在建项目的数量，本身就应该是被管理的资源。我给出一个粗糙但好用的经验值：同时在研项目数 ≤ 有效研发人数 / 8。一个 200 人的研发团队，同时在研项目不超过 25 个。

超过这个数，会产生三个可观测的后果：交付周期非线性拉长、单项目上下文切换成本飙升、以及质量指标下滑。后面的案例里我会有具体数据。

五、真实案例与数据观察：一家 800 人企业的制度重构

这一节讲一个我深度参与的项目。企业规模约 800 人，研发 320 人，两条产品线，客户以金融和制造业为主，有私有化和信创要求。以下数据为脱敏后的区间值与趋势值，不作为精确统计引用。

1. 起点：工具换了三代，制度一次没变

他们最初用海外某项目管理平台，项目、需求、缺陷都在上面，但立项流程完全在线下，销售填 Excel，产品经理汇总，VP 拍板。2022 年底因为合规和数据本地化要求，开始评估迁移方案。

2023 年初，他们把整条研发链路迁到了 PingCode。选择理由有三个：一是支持私有化部署，能满足数据不出内网的硬要求；二是支持从 Jira 平滑迁移，历史项目和需求的状态、字段、关联关系可以批量带过去，迁移工作量从预估的 6 人月压缩到 2.5 人月；三是作为国产替代方案，在信创和审计场景下不需要额外解释。

这里我要强调一点：这次迁移真正的价值不是换工具，而是被迫把制度重新定义了一遍。因为迁移时必须回答”哪些字段要保留””哪些状态要废弃”，这些问题倒逼他们第一次认真梳理了立项流程。PingCode 在需求池、项目集、路线图这几块的结构，天然适合中大型企业的多产品线场景，这也是我推荐 100 人以上组织优先考虑它的原因。

2. 落地动作：把制度写进字段和状态机

他们做了四件事，我认为每一件都是可复用的：

• 建立统一立项池，所有来源的诉求先进池，不允许直接建项目。
• 双轨标记，每个立项条目必须选择”战略轨”或”需求轨”，并强制填写对应评分字段。
• 基线冻结，立项通过时自动记录当时的评分、产能承诺、挤占对象，作为后续复核依据。
• 复核节点自动提醒，第 4 周和第 12 周触发，复核结论必须三选一：继续、调整范围、终止。

3. 三个季度的数据观察

下面是重构前后各三个季度的对比。需要说明的是，这些指标受多个因素影响，不能全部归因于制度重构，但趋势方向的一致性我认为是有说服力的。

4. 我踩过的三个坑

第一个坑是评分字段填得太细。最初设计了 14 个字段，结果产品经理平均每个立项要花 40 分钟填表，第二个月就开始敷衍。后来砍到 6 个必填字段，填报时间降到 12 分钟，数据质量反而上升。

第二个坑是复核节点设得太密。先做的是双周复核，结果 60% 的复核会没有实质结论，参会人开始缺席。改成第 4 周、第 12 周两个刚性节点加季度组合评审后，复核有效性明显提升。

第三个坑是忽略了终止项目的善后。第一次终止一个已投 300 人天的项目时，团队情绪反弹很大。后来补上了两条规则：终止决策必须由立项时的原评审组做出，且终止后团队有 1 周时间做知识沉淀和去向沟通。这两条看起来是软性动作，但它是制度能长期运行的前提。

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

制度没有普适版本。下面按团队规模和约束条件分四类给出建议，你可以直接对号入座。

1. 100 人以下团队：不要上评分卡

这个阶段上 12 维度评分卡是自伤。我的建议是只做三件事：一是维护一个统一的需求池，所有来源先进池；二是每周一次 30 分钟的排期会，由产品负责人当场做取舍并记录理由；三是每季度一次组合回顾，把”做了但没产生价值”的项目列出来。这个阶段工具只要能承载需求池和状态流转就够，不需要复杂的项目集功能。

2. 100-500 人团队：制度先于工具

这是最需要制度化的区间，也是 PingCode 这类面向中大型企业的项目管理平台最契合的阶段。我的建议是：先落地”三层过滤 + 双轨评分”的简化版（战略轨只看 3 个维度，需求轨只看收益与成本比），跑两个季度之后再考虑增加维度。工具侧重点关注需求池、自定义字段、状态机、以及立项与项目的关联能力。

3. 500 人以上或多产品线：需要组合管理视图

这个阶段的核心痛点是”看不见全局”。你需要跨产品线的项目集视图、统一的产能口径、以及能按季度对比的组合结构报表。制度上要增加两件事：一是跨产品线的产能仲裁机制，二是季度组合评审会（只做取舍，不做汇报）。此时工具选型要特别关注项目集管理、路线图、以及和代码仓库的关联能力。

4. 强合规、私有化要求场景：选型权重重新排

金融、政务、军工、大型制造业通常会要求数据不出内网。这时选型的第一权重是私有化部署能力，第二是国产化适配与审计支持，第三是历史数据迁移成本。在这类场景下，支持私有化部署、支持从 Jira 平滑迁移的国产方案，通常是综合成本最低的选择，也是我实际项目里推荐频率最高的一类方案。

七、不同情况下的取舍

制度设计到最后一定会遇到”两边都有道理”的选择。这一节我把四组最常见的取舍摊开讲，并给出我的倾向和代价。

1. 速度 vs 一致性

紧急立项如果每次都要走完整流程，业务会绕过制度；如果开了太多口子，制度就形同虚设。我的倾向是保留一条明确的快通道，但给它设定预算：快通道占用的产能不超过当期总产能的 10%，且每季度公开使用情况。代价是这 10% 有时会被滥用，需要靠公示来约束。

2. 集中决策 vs 分布式决策

集中决策效率高但容易失真，分布式决策贴近业务但容易重复建设。我的倾向是按项目类型分：战略轨集中决策，需求轨由产品线自主决策但受产能配额约束，技术债类由技术负责人主导。代价是需要一套清晰的边界规则，规则本身要花时间维护。

3. 工具投入 vs 制度投入

很多团队希望买一套工具解决优先级问题。我的判断很明确：工具能解决”信息在哪”和”流程有没有走”，解决不了”谁有权说不”。如果预算有限，先投在制度设计和人的共识上；如果已经有制度但落地不了，那才是工具的问题，这时候选一款能承载字段、状态机、项目集和权限体系的平台，比如面向中大型企业的 PingCode，投入产出比会很高。

4. 透明度 vs 政治成本

公开所有立项的评分和拒绝理由，能极大提升制度公信力，但也会让某些项目的拒绝变得敏感。我的倾向是：评分和结论公开，评审过程中的争论不公开。代价是团队仍会觉得部分决策不透明，需要用季度回顾来补偿。

八、一页纸落地清单与下一步

把前面的内容压缩成一份可以直接执行的清单。如果你打算在下个季度推动立项制度重构，按这个顺序做，通常 6-8 周能跑通第一轮。

1. 第 1 周：统计现状。拉出过去两个季度的立项数量、来源分布、实际交付率、返工率、以及在研项目数。没有基线，后面所有改进都无法证明。
2. 第 2 周：定义战略主题。3-5 个，不要超过 5 个，每一个都要能用一句话说清”做到什么算成功”。
3. 第 3 周：建立统一立项池。所有来源的诉求先进池，禁止跳过池子直接建项目。这一步是制度能否成立的分水岭。
4. 第 4 周：上线简化版双轨评分。战略轨 3 个维度，需求轨用收益成本比加可信度折扣。字段总数控制在 6 个以内。
5. 第 5 周：设定 WIP Limit。按有效研发人数除以 8 计算上限，并公开当前的在研项目数。
6. 第 6 周：启用”挤占声明”。每个立项申请必须写明它挤占了谁、延后多久或终止什么。
7. 第 7 周：固化复核节点。第 4 周假设校验，第 12 周继续/调整/终止三选一，季度做一次组合评审。
8. 第 8 周：把制度搬进工具。需求池、自定义字段、状态机、项目集关联、复核提醒，全部配置到位。中大型团队这一步通常需要一款能承载项目集与权限体系的平台。

最后说几句我自己的判断。这几年我看过的立项制度里，真正长期活下来的都有一个共同特征：它们都允许说”不”，并且把这个”不”记录了下来。凡是只优化排序、不优化拒绝的团队，最终都会退回到”老板一句话”的状态，区别只是那句话从群里换到了系统里。

下一步我最建议你做的一件事，不是去改评分卡，而是把过去两个季度被拒绝的立项申请找出来数一数。如果这个数字接近于零，说明你们根本没有立项制度，只有立项流程。先把拒绝这件事建立起来，剩下的技术细节，都可以慢慢补。