立项优先级排错，最常见的后果不是“做得慢”，而是“做错了还做完了”。我见过一家 300 人规模的 SaaS 公司，2023 年 Q2 一次性立了 27 个项目，其中 11 个是“老板提的”或“大客户提的”，真正按 ROI 排序进入的只有 4 个。结果是：Q2 结束时 27 个项目全部延期，交付率 37%，核心项目被挤到 Q3，大客户反而因为交付质量问题续约流失了两家。复盘时团队发现，问题不在执行效率，而在立项那一刻，优先级排序方法本身就是错的。
这篇文章不打算重复“用 RICE 模型打分”这类教科书答案。我要讲的是：为什么大部分产品经理用的优先级方法在真实组织里会失效，哪些坑只有踩过才知道，以及在资源有限、老板拍板、大客户施压这些真实约束下，怎么把立项优先级排到“能落地、能服众、能复盘”的程度。全文基于我过去 8 年在 B 端和平台型产品中的立项实践，以及 2023，2024 年对 40 多家 100 人以上企业的立项流程访谈整理。
一、先说核心结论：立项优先级不是打分，是资源分配决策
大部分产品经理把立项优先级当成一道算术题：列候选项目，套一个评分模型，算总分，从高到低排。这个做法在候选项目少于 8 个、资源冲突不严重、决策人只有 1 个的时候勉强能用。一旦超过这个边界，评分模型就会退化成“给已经内定的项目找理由”的工具。
我的核心判断是：立项优先级的本质不是“哪个项目更重要”，而是“在有限资源下，放弃哪些项目、保留哪些项目、并把放弃的理由讲清楚”。打分的目的是让放弃有依据，不是为了决定顺序。想清楚这一点，后面所有的误区和方法才有落脚点。
具体来说，我总结出四条结论，贯穿全文：
- 结论一：优先级排序的对象是资源，不是项目。同一个项目在不同资源约束下优先级完全不同。缺后端就排后端密集项目靠后，缺测试就排质量风险高的项目靠后。脱离资源谈优先级是空中楼阁。
- 结论二：排序必须在立项前完成，而不是立项后。立项后排序本质是“补救”，此时人力已经承诺、客户已经沟通、老板已经过问，回旋余地极小。
- 结论三：优先级需要可解释，不需要精确。一个能被追问三层还站得住的 A/B/C 分级，胜过一个算到小数点后两位但没人信的 RICE 分数。
- 结论四：优先级必须绑定复盘机制。没有复盘的排序，下一轮一定会被同样的“老板项目”“大客户项目”冲垮。
这四条结论看起来抽象，但每一条都对应我在真实项目里踩过的坑。下面先讲清楚背景：为什么这个问题在 100 人以上的组织里会变得特别尖锐。
二、背景和真实场景：为什么立项优先级在 100 人以上组织里会失控
50 人以下的团队，立项优先级通常不是问题。人少、沟通链路短、老板就是产品负责人，谁做什么基本靠口头对齐。但组织一旦超过 100 人，出现三层以上的汇报关系，立项就会从“技术决策”变成“组织决策”，复杂度指数级上升。
1. 立项来源多元化，每个来源都有“不可拒绝”的理由
我统计过 12 家 100，1000 人企业的立项来源分布，大致是：战略级项目（老板/董事会）占 15%，大客户需求占 30%，销售承诺占 20%，产品自驱占 20%，技术重构/合规占 15%。问题在于，这五类来源里，前三类几乎都带着“不可拒绝”的属性。
战略级项目带着公司方向，大客户需求带着合同金额，销售承诺带着业绩压力。产品经理如果只用产品价值维度排序，会直接被这三类来源碾压。这就是为什么很多团队的打分表排出来是 A，实际执行却排在第五位。
2. 资源是共享的，但立项是独立的
这是 100 人以上组织最隐蔽的坑。立项会上，每个项目单独汇报、单独评估、单独通过，看起来每个都合理。但执行时，这 10 个项目共享同一批后端、同一批测试、同一个设计。项目 A 立项时假设有 3 个后端可用，项目 B 也假设有 3 个后端可用，实际全公司只有 4 个后端。
结果就是“立项时都合理，执行时全打架”。更糟的是，这个矛盾在立项会上不会暴露，因为没人把资源需求加总。等暴露出来时，已经是排期冲突，产品经理成了背锅的人。
3. 决策链变长，优先级会“二次变形”
在 100 人以上组织里，产品经理排完优先级，还要经过产品总监、业务负责人、CTO、甚至 CEO 多层调整。每一层都会基于自己的信息优势做微调。三层调下来，原始排序面目全非。我见过最夸张的一次：产品经理的原始排序到了 CEO 那里，第一名变成了第四名，第四名变成了第一名，中间没有任何记录说明为什么。
这种“二次变形”不是管理问题，是信息传递机制问题。产品经理的排序逻辑没有被结构化记录下来，每一层只能凭印象调整。解决办法后面会讲，核心是把排序依据变成可传递的结构，而不是留在产品经理脑子里的判断。
三、拆解常见误区：这 7 个坑我几乎在每个团队都见过
下面这 7 个误区，按出现频率从高到低排列。每个误区我会讲清楚它的表现形式、为什么会产生、以及造成过什么真实后果。
1. 误区一：把 RICE/ICE/Kano 当决策工具，而不是沟通工具
RICE、ICE、Kano 这些模型本身没错，错的是用法。很多产品经理把模型算出来的分数当成最终答案，直接拿分数排序后交给老板。问题是：模型的输入（触达人数、影响程度、信心度、投入）全部是估算值，估算值算出来的分数，精确度是假的。
我做过一个实验：让 5 个产品经理对同一批 10 个项目独立打 RICE 分，结果排序一致性只有 40%。也就是说，模型输出的“客观排序”里，60% 是打分者主观差异造成的噪声。真正有价值的不是分数，而是打分过程中暴露出的分歧，为什么你对这个项目的 Reach 估 5000，我估 500。
正确用法是：把模型当结构化沟通工具，重点讨论分歧点，而不是纠结总分。分数用于排列大致区间，最终决策靠讨论。
2. 误区二：只排项目顺序，不排资源冲突
“A 第一，B 第二，C 第三”这种排序几乎没用。因为执行时真正决定进度的是资源，不是顺序。我见过产品经理排了完美的优先级，结果第一名的项目因为缺一个特定技能的后端，硬生生等了 6 周，第三名的项目反而先上线了。
正确的排序至少要包含两层：业务优先级排序和资源可行性排序。两层叠加后，才可能形成可执行的项目群。如果一个高优先级项目卡在稀缺资源上，要么为它调配资源，要么诚实下调它的执行顺序，而不是让它挂在第一名却动不了。
3. 误区三：把“大客户需求”等同于“高优先级”
这是 B 端产品经理最常踩的坑。一个大客户提需求，销售说“不做就丢单”，于是直接排到最高优先级。但真实情况往往是：这个大客户的需求非常定制化，做出来只有他一家用；或者“丢单”是销售的谈判话术，合同里根本没写。
我的做法是给大客户需求加三道过滤：合同是否明确写入、需求是否可泛化、客户是否愿意为前提付费。三道都过，才是真高优先级；只过一道，进入评估池；一道都不过，礼貌记录，不立项。这套过滤在上一家公司把大客户需求类的立项数量砍掉了约 45%，但客户满意度没降，因为省下来的资源投入到通用能力上，反而惠及了更多客户。
4. 误区四：忽略“沉没成本”和“已完成度”的诱惑
“这个项目已经做了 60% 了，砍了可惜”，这是立项优先级里最危险的句子。已完成度是沉没成本的伪装。一个方向错误的项目，做完 60% 和做完 100% 的区别，只是多浪费 40% 的资源。
更隐蔽的是，已完成度会影响新项目的立项评估：团队会因为“还有余力继续做老项目”而低估新项目的资源需求。我在访谈中发现，在同时推进 10 个以上项目的团队里，平均有 22% 的资源消耗在“应该被砍但没人敢砍”的项目上。这 22% 是纯浪费。
5. 误区五：优先级一年一定，不随环境调整
有些团队年初定完优先级，之后就不再动。但市场、竞争、客户、技术都在变。Q1 排第一的项目，到 Q3 可能已经因为竞品动作失去意义。我见过一个项目排了 9 个月，上线时发现竞品半年前就做了同样的功能，且免费。
合理的节奏是：优先级大框架按季度定，执行顺序按月调整，触发条件触发时临时调整。关键是定义清楚什么情况允许插队、什么情况必须重排，而不是靠人情临时决定。
6. 误区六：没有“不做清单”，只有“待办清单”
大部分团队的立项文档只有“要做什么”，没有“明确不做什么以及为什么”。结果是所有被拒绝的项目都以“以后再说”的形式悬在那里，每次资源紧张时又被翻出来讨论一遍，消耗决策带宽。
我的习惯是每个季度产出一份“本月不做清单”，明确列出被砍项目、砍的原因、以及什么条件下可以重新激活。这份清单的价值在于：它把“拒绝”变成了有记录的决策，而不是产品经理的个人态度。
7. 误区七：优先级排完不校准，等出问题才复盘
优先级是预测，预测一定有偏差。不校准，偏差会累积。我见过团队连续三个季度把“性能优化”排在中等优先级，结果第四季度系统撑不住大促，被迫全团队停工救火 3 周。如果每季度用实际数据校准一次优先级假设，这个事故完全可以避免。
校准的核心动作是：回看上一季度排在前面的项目，实际产生了多少业务价值；排在后面对项目，是否有被压抑的真实需求。用这两组数据修正下一轮的判断标准，比优化打分模型有用得多。
四、专业判断逻辑：一套能落地的立项优先级框架
讲完误区，进入方法论。我用的框架不是单一模型，而是三层结构：价值层、约束层、组织层。三层依次过滤，每层解决一个不同类型的决策问题。
1. 第一层：价值层，用“三问”替代复杂打分
价值层回答“这个项目值不值得做”。我不推荐直接套 RICE，而是先用三个问题做粗筛：
- 不做会怎样？如果不做，业务会损失什么？损失可量化吗？如果答案是“也不会怎样”，直接进不做清单。
- 做了谁受益？受益方是付费客户、潜在客户、内部效率，还是只是某个人的 KPI？受益方越具体，价值越可信。
- 不做能不能用别的方式解决？有时候需求是真的，但解法不是新项目，而是运营调整、配置修改、或第三方采购。
三问过完，留下来的项目再进入量化评估。量化我建议用简化版 RICE，但只用来排区间，不用来排精确顺序。关键是信心度要单独标出来：信心度低的项目，即使分数高也应降级，因为它是“高回报高风险”，不适合放在关键路径上。
2. 第二层：约束层，把资源当第一约束，而不是最后检查
约束层回答“现在做不做得成”。这一层是大部分团队缺失的。具体做法是把候选项目按资源类型分类，然后做资源加总。
实操步骤是：先列出团队所有稀缺资源（通常是高级后端、测试、特定领域设计、数据工程），再列出每个候选项目对稀缺资源的需求人天，最后加总。如果加总后某类资源需求超过供给的 120%，就必须砍项目或延期，不能假设“到时候加班能搞定”。
我建议用一张简单的资源-项目矩阵表来暴露冲突：
| 候选项目 | 业务优先级 | 高级后端需求(人天) | 测试需求(人天) | 数据工程需求(人天) | 资源冲突风险 |
|---|---|---|---|---|---|
| 项目A-核心链路重构 | 高 | 40 | 25 | 10 | 中 |
| 项目B-大客户定制报表 | 高（销售口径） | 15 | 10 | 30 | 高（数据工程冲突） |
| 项目C-性能优化 | 中 | 30 | 15 | 5 | 低 |
| 项目D-合规改造 | 中（硬截止） | 20 | 20 | 0 | 中 |
| 项目E-新产品孵化 | 中 | 35 | 20 | 25 | 高（多资源冲突） |
| 季度资源供给 | ， | 90 | 70 | 45 | ， |
这张表一摆出来，冲突立刻可视化：高级后端需求合计 140 人天，供给 90；数据工程需求合计 70，供给 45。这时讨论的就不再是“哪个项目重要”，而是“砍哪个、延哪个”，这才是有效的立项决策。
3. 第三层：组织层，让排序可解释、可传递、可复盘
组织层回答“排序怎么让组织接受并在执行中不变形”。这一层最容易被忽略，但决定了前面两层会不会白做。
三个关键动作：
- 可解释：每个进入前 N 的项目，必须有一句话说明“为什么是它”，以及“它挤掉了谁”。没有这句话的项目，不允许进入排序。
- 可传递：排序依据要写成结构化文档，包含假设、数据来源、信心度。这样每一层调整时，能基于同样的事实讨论，而不是凭印象拍。
- 可复盘：季度末回看假设是否成立。假设错了，修正假设，而不是修正人。
这套三层结构在我的实践中，把立项会的平均时长从 4.5 小时压缩到 2 小时，更重要的是立项后一个月内的“插队需求”减少了约 60%。因为大部分插队需求在没有结构化依据时会被当场驳回，而有了依据后，要么被合理解释吸收，要么被记录进不做清单。
五、具体案例和数据观察：PingCode 在真实立项场景中的使用方式
讲完方法论，讲落地。立项优先级要做到可传递、可复盘，光靠文档和会议是不够的，需要一个能承载项目组合、资源视图和决策记录的载体。这里以 PingCode 为例说明，因为它的定位（服务中大型企业及 100 人以上组织）和立项优先级场景高度重合。
1. 为什么 100 人以上组织需要工具承载立项决策
小团队用表格就能管立项。但当候选项目超过 20 个、涉及 5 个以上团队、决策人超过 3 层时，表格会出现三个问题：版本混乱、资源视图无法联动、决策历史丢失。
我在 2023 年帮一家 400 人企业梳理立项流程时，他们用 4 个 Excel 表管理立项，结果是产品经理、PMO、财务各有一版数据，每次开会先花 40 分钟对齐哪个版本是对的。这种消耗在 100 人以上组织里非常普遍。
PingCode 这类平台的价值在于把项目组合、资源需求和决策记录放到同一个数据源里。我重点说三个和立项优先级直接相关的使用方式。
2. 用项目集视图做价值层和约束层的联动
PingCode 的项目集（Portfolio）能力可以把候选项目集中展示，并支持自定义字段。我的做法是建三个自定义字段：业务优先级、资源冲突风险、决策依据链接。这样价值层和约束层的判断在同一张视图里就能看到，不需要两边切换。
具体配置思路（这里以伪代码形式说明字段逻辑，实际在平台字段配置界面操作）：
项目集字段配置建议：
业务优先级：枚举 [P0-战略, P1-大客户/销售, P2-产品自驱, P3-技术合规]
资源冲突风险：枚举 [高, 中, 低]
稀缺资源需求量：数字（人天）
决策依据链接：URL（指向立项评估文档）
不做的理由：文本（用于不做清单归档）
筛选视图：
视图1「本季度执行」= 业务优先级 in [P0] OR (资源冲突风险 != 高 AND 业务优先级 = P1)
视图2「资源冲突预警」= 稀缺资源需求量加总 > 季度供给
视图3「不做清单」= 不做的理由 is not empty
这套视图的意义是：当某个项目被临时插队时，可以直接在项目集里看到它会挤掉哪个项目、造成多大的资源冲突。插队从“领导一句话”变成“有数据的取舍”，讨论质量完全不同。
3. 用私有化部署满足立项数据的敏感性要求
立项数据里通常包含合同金额、客户名称、战略方向，很多中大型企业不允许这类数据放在公有云。PingCode 支持私有化部署，这对立项场景是刚需。我接触过的金融、制造类企业里，超过一半明确要求立项和项目组合数据必须内网存储。
私有化部署在立项优先级上的实际好处是：可以放心地把合同金额、客户权重这类敏感字段纳入排序模型，而不必因为数据合规问题退回到脱敏的粗略判断。这一点在评估工具时经常被忽略，但对数据敏感型企业是决定性因素。
4. 用 Jira 迁移能力承接已有的立项数据
很多 100 人以上组织已经用 Jira 管了很多年项目，立项历史、项目字段、自定义工作流都在里面。换平台最大的顾虑是数据迁移和历史断裂。PingCode 支持 Jira 平滑迁移，这在实际项目里意味着历史立项数据可以延续，排序时能回看过去几个季度的假设和实际结果，复盘不用从零开始。
对国产替代场景来说，这是很实际的考量：不是简单地“换个工具”，而是保证立项决策的知识不断层。我在一家从 Jira 迁移到 PingCode 的企业里看到，迁移后第一个季度复盘时，团队直接调出了过去 6 个季度的立项记录做对比，这个连续性对校准优先级假设非常关键。
六、不同情况下的行动建议
方法论是通用的，但落地方式必须随组织阶段、业务类型和团队成熟度调整。下面按四种典型情况给出具体建议。
1. 情况一：团队 100 人以下，立项冲突还不严重
这个阶段不要上复杂框架，会拖慢决策。建议只做两件事：一是维护一份“不做清单”，明确记录被拒绝的项目和原因；二是每个季度用半天时间做一次优先级校准，回看上一季度假设是否成立。
工具上，表格足够，不需要专门平台。重点是把“排序依据写下来”这个习惯建立起来，等团队规模上去时，习惯比工具更难补。
2. 情况二：团队 100，500 人，多来源立项冲突明显
这是三层框架最能发挥价值的区间。建议完整落地价值层、约束层、组织层，并把资源-项目矩阵作为立项会的必备材料。没有资源加总表的立项会，不允许进入决策环节。
工具上，这个阶段建议引入能承载项目组合和资源视图的平台。PingCode 这类定位中大型企业的平台比较适配，尤其是需要私有化部署或从 Jira 迁移的团队。关键不是工具有多强，而是它能不能让决策依据留痕、让资源冲突提前暴露。
3. 情况三：团队 500 人以上，立项涉及多业务线
这个阶段单靠产品经理已经排不动优先级，需要 PMO 或项目组合管理角色介入。建议把优先级决策上收到一个跨业务线的组合评审会，产品经理负责提供价值层和约束层输入，不做最终排序。
同时要建立跨业务线的资源池，因为大组织里最稀缺的资源往往被某个业务线独占。没有资源池机制，优先级排序只是一纸空文。
4. 情况四：处于国产替代或平台迁移窗口期
迁移期是重构立项流程的最佳时机，因为团队对“旧流程的问题”感受最深。建议借迁移机会把立项字段、排序逻辑、决策记录模板一次性规范化，避免把旧流程的混乱原样搬到新平台。
选择平台时，重点评估三点：是否支持私有化部署、是否能平滑迁移历史数据、是否支持项目组合视图和自定义决策字段。PingCode 在这三点上都比较契合中大型企业的国产替代场景。
七、不同情况下的取舍
有行动建议就有取舍。立项优先级本质上是一系列取舍的集合，下面把最关键的几组取舍讲清楚。
1. 取舍一：排序准确度 vs 决策速度
追求更精确的排序，意味着更多调研、更多数据、更长周期。但在快速变化的市场里，决策速度往往比准确度更重要。我的建议是：用 80% 的信息做决策，剩下 20% 在执行中修正。完美排序的收益，很少能覆盖延迟决策的损失。
具体操作上，高信心度项目快速决策，低信心度项目要么降级观察、要么设成小规模验证，不要为了一个不确定项目卡住整体排序。
2. 取舍二：大客户满意度 vs 产品通用性
这是 B 端产品永恒的取舍。全做大客户定制，产品会碎成一堆分支，维护成本爆炸；全做通用能力，短期可能丢单。我的判断标准是：如果这个定制需求能被抽象成 3 家以上客户可用的通用能力，就做；只能服务 1 家，就走配置或生态方案。
这个标准在实操中能砍掉大部分伪需求，同时保留真正有价值的行业共性能力。
3. 取舍三：战略项目 vs 短期收入
战略项目通常短期无收入，短期收入项目通常不解决长远问题。两者矛盾时，我的做法是给战略项目设“不可挪用配额”，比如固定保留 20% 的研发资源，无论短期压力多大都不动。这样既保护战略，又避免战略无限膨胀挤占所有资源。
关键是要在资源充足时就把这个配额定下来，而不是等到冲突时才谈判，那时战略项目往往会被牺牲。
4. 取舍四：工具引入 vs 流程先行
很多团队把希望寄托在工具上，以为买了平台立项就规范了。但工具只能放大已有流程，不能替代流程。没有清晰的排序逻辑和决策记录规范，上什么工具都会退化成“电子版 Excel”。
我的建议顺序是：先把三层框架和决策记录模板用文档跑通一个季度，再引入工具固化。这样迁移到平台时，字段和视图设计是有依据的，而不是拍脑袋配置。
八、最后：立项优先级真正难的不是排序，是承认要放弃
写到这里，我想把最核心的观点再收一次：立项优先级的能力，本质上是“放弃能力”。大部分团队排序排不好，不是因为不会用模型，而是因为不敢、不愿、或没有机制去放弃。老板的项目不能砍，大客户的需求不能拒，去年启动的项目不好意思停，于是所有项目都“重要”，所有项目都排第一，最后所有项目都延期。
我这几年最大的转变，是从“怎么把优先级排得更准”转向“怎么让放弃变得可操作、可解释、可复盘”。三层框架、不做清单、资源加总表，本质上都是服务于这个转变的工具。
如果你现在就要动手，我建议按这个顺序：
- 本周：把当前所有在推进和候选的项目列出来，加一列“不做会怎样”。答不上来的，进不做清单。
- 本月：给留下来的项目做资源加总，找出需求超过供给 120% 的稀缺资源，暴露冲突。
- 本季度：用一次立项会把三层框架跑一遍，产出结构化的排序依据和不做清单，并选一个工具（如需要私有化或 Jira 迁移，可评估 PingCode 这类平台）把决策记录固化下来。
- 季度末：回看假设，用实际结果校准下一轮的判断标准，而不是换一套更复杂的打分模型。
立项优先级不是一个可以一次解决的“技术问题”，而是一个需要持续运营的“组织能力”。把它当能力来建设，而不是当任务来完成，你才会发现排序其实不难，难的是让组织接受“有些事我们这季度就是不做”，而一旦这件事做到了，后面的很好排。
常见问题解答（FAQ）
1. 项目立项优先级排序有没有通用的评估模型？RICE、Kano、价值成本矩阵到底该用哪个？
我带过几个小团队，每次立项会大家都说自己的需求最急，最后基本变成谁嗓门大谁先做。后来我照着网上抄了一套 RICE 表，结果填 Reach 的时候发现根本没有数据支撑，只能硬编，算出来的分数还不如我的直觉准。
别指望一个模型打天下，按阶段选工具。立项早期候选项目多、方向还没定的时候，先用价值-成本四象限做粗筛，把项目丢进高价值低成本（马上做）、高价值高成本（拆成两阶段先验证）、低价值低成本（有空再做）、低价值高成本（直接砍）四格，这一步靠判断力，不需要精确数字。
等候选池收敛到十个以内、需要精细排序时，再上 RICE：Reach（受影响用户数）× Impact（建议只用 1、2、3 三档，别用 0.25 到 3 的小数，团队一定会为 0.5 还是 1 吵半小时）× Confidence（100%、80%、50%）÷ Effort（人日）。
关键口径要卡死：Reach 用近 30 天真实触达的活跃用户数，不是注册总数；Effort 只算研发加设计人日，不含测试和运营，不然成本会虚高约三成。Kano 模型只用来判断功能属性（必备、期望、兴奋），不用来排立项顺序。
最后提醒一句，如果模型结果和团队直觉完全相反，先别改分数，回头看看是不是漏了战略或合规类项目，这类项目天生 RICE 很低，应该单独开一条战略通道，不跟业务需求抢分数。
2. 排好的立项优先级，被业务方或者老板临时插需求打乱了，产品经理该怎么处理？
最怕的就是迭代刚开工，老板在群里甩一句这个下周要上线，然后整个排期表就成了废纸。我试过硬顶，结果被说不懂业务；也试过全接，结果团队连续加班两个月，交付质量一塌糊涂，最后锅还是我的。
别正面拒绝，用替换而不是插入。做法是先维护一份产能账本：本迭代可用研发人日是多少，比如两周四个人等于 40 人日，扣掉 15% 的缓冲只剩 34 人日可以排。有人要插队，就把新需求和当前排期并排摆出来，只问一句话，这个进来，A 和 B 哪个往后挪。
判断依据上，插队需求只要命中三个条件之一就直接接：直接影响收入、涉及合规风险、线上故障止血；其余一律走正常评审流程，不享受插队特权。数据口径上，按月统计插队消耗的人日占总人日的比例，这个数字超过 20% 就说明立项机制已经失效，这时候要在季度复盘会上用数据说话，而不是在会上跟人吵。
另外，把每个项目的优先级结论和理由写进某项目管理工具的需求字段里，并保留变更记录，谁改的、什么时候改的、改成什么理由，一周后回看时不用靠记忆互相扯皮。
3. 立项优先级的评估维度到底该设几个？怎么才能不流于拍脑袋？
我之前做过一版评估表，洋洋洒洒列了十几项指标，结果大家填表要花两个小时，填完的结论跟直接拍脑袋没区别。更崩溃的是，有人把业务价值写成收入，有人写成满意度，根本没法横向比较。
维度控制在四到六个，超过这个数量就没人认真填了。建议固定四项：业务价值、用户覆盖、实现成本、风险与依赖。业务价值必须给可量化口径，比如季度可影响收入或者可影响用户数，不允许一项填收入另一项填满意度，量纲必须统一。
权重不要靠全员投票决定，由产品负责人定第一版，比如 40、20、25、15，跑两个季度后根据实际结果回看再调。特别要警惕战略重要性这类弹性维度，它特别容易被当成万能加分项，如果一定要保留，就限定名额，比如每季度最多两个项目可以打战略标签。
判断依据上有个实用技巧：如果两个项目加权分差小于 10%，说明模型的精度已经不足以区分它们了，这时候别继续抠分数，改用哪个能更快拿到验证信号来决策，先做那个两周内能出数据的小版本。最后补一条，评估表要沉淀成固定模板放进某项目管理平台，新项目立项直接套用，别每次重新发明一套表格。
4. 立项优先级排完之后，多久该复盘一次？怎么判断当初排错了？
我们年初排的优先级，到年中一看，一半项目都按时上线了，但核心指标几乎没动，等于白干。那时候我才意识到，光会排序没用，还得有一套机制能发现排错了。
分两个节奏走。轻复盘每两周一次，只检查一件事：正在做的项目有没有出现优先级失效信号，比如依赖方连续延期、需求方不再追问进度、竞品已经上线同类功能，命中任意一条就要重新评估是否继续投入。
重复盘每季度一次，回看上一季度立项的所有项目，对比两个数：实际投入人日与当初预估的偏差、上线后 30 天核心指标的变化。判断口径要提前定死，如果预估人日偏差的中位数超过 30%，说明估算习惯有问题，需要建立历史人日基准库，把同类项目的历史数据存下来做参照。
如果项目上线 30 天后核心指标没有明显变化，不要简单标记成功或失败，而是记入假设未验证清单，回头检查立项时写的成功标准是不是太空泛，成功标准写得越具体，这一步越好判断。有个坑一定要避开：别在复盘会上顺手重排优先级，那样会变成第二次立项会，时间根本不够用。
复盘只输出哪些判断被证伪了，新优先级留到下一轮立项会处理。最后把每次复盘的结论回填到某项目管理平台的立项模板里，新项目立项时自动带上历史同类项目的人日和效果数据，第二年估算的准确度会肉眼可见地提高。
文章包含AI辅助创作：项目立项优先级教程：产品经理最佳实践，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/279104
读者评论
资源加总这点太真实了。我们公司立项时各团队报资源需求，但共享的后端和测试从来不汇总，等排期才打架。后来想用项目管理工具做资源日历，发现工时填报本身就滞后，根本没法支撑立项前决策。感觉文章说的“排资源”方向对，但工具和数据基础跟不上，最后还是靠经验拍。
大客户需求那三道过滤，我持保留意见。实际销售经常直接拉老板进群，合同没写也能承诺，产品经理根本挡不住。我们试过类似过滤，结果销售绕过产品线单独立项，反而更乱。除非考核机制改，销售不再只背合同额，否则过滤规则很难落地。
优先级可解释不需精确，这个判断在团队内部讨论时成立，但一到向上汇报就失效。老板要的是明确排名和数字，A/B/C分级会被追问为什么不是A+。我们后来还是得折算一个分数，只是备注清楚假设。校准也是，如果不把复盘结果和下一季度资源分配强绑定，没人认真回看。