项目立项优先级教程：产品经理入门指南，避坑指南

三年前我第一次主持季度立项评审会，准备了一套 RICE 打分模型，把 37 个提案拉成一张看起来无懈可击的排序表。会议从下午两点开到六点半，我们郑重地选出了分数最高的 12 个项目立项。三个月后，真正上线的只有 5 个，其中 2 个上线即下线，还有一个做到一半被叫停。更讽刺的是，当时排在第 19 位、差点被砍掉的一个小项目，最后成了那个季度唯一被业务方主动追加预算的东西。

这件事让我把”立项优先级”彻底重做了一遍。我发现绝大多数产品经理学到的立项方法，本质上是”给想法排序”；而真正决定成败的，是”在资源约束下淘汰想法”，以及在淘汰之后，如何让被淘汰的项目不变成组织里的政治债务。这两个问题，市面上的教程几乎都不讲。

下面这篇内容，是我在 3 家不同规模企业（一家 40 人创业公司、一家 220 人 SaaS 公司、一家 800 人集团事业部）做立项流程改造后的完整复盘。里面有一套四层漏斗筛选法、一张防倒推的打分卡、七个我亲手踩过的坑，以及我在中大型组织里用 PingCode 承载立项流程时观察到的真实数据。所有数据都标注了来源和口径，凡是模拟推演的部分我都会明确说明。

一、先给结论：立项优先级的第一性问题不是排序，是淘汰

如果你只从这篇文章里带走一句话，我希望是这句：立项优先级的本质是资源约束下的机会成本分配，不是价值最大化排序。这两者的差别，决定了你的评审会是在做决策，还是在进行一场耗时四小时的集体表演。

1. 反常识一：打分表排出的顺序，几乎不是最终立项的顺序

我在 220 人那家公司做过一次统计。那个季度 120 个提案进入打分环节，我们把 RICE 得分按 20 分一档做成直方分布，结果是：41-60 分区间挤了 47 个提案，61-80 分区间挤了 36 个，两头加起来只有 16 个。

问题来了：当 47 个提案的得分集中在 41 到 60 之间，第 3 名和第 27 名的差距可能只有 4.2 分。而这点差距，只要把”实现成本”的权重从 0.25 调到 0.30，排名就会彻底翻转。也就是说，我们其实是在用噪声做决策，却把它包装成了科学。

更麻烦的是打分是倒推的。我后来做过匿名访谈，120 个提案里有 68 个的作者承认，他们会先在心里定一个”我大概应该拿多少分”，再反推各个维度的赋值。这不是诚信问题，这是激励结构问题，打分卡的输入项全是主观估计，而输出项直接决定资源归属。

2. 反常识二：优先级最高的项目，往往不是价值最大的，而是时间窗口最窄的

我早期排序的思路是”价值除以成本”，这个公式最大的缺陷是它假设时间是均匀的。但真实世界里，项目有一个维度叫”不可逆性”。

举个我经历过的例子。某 SaaS 公司要接入一家大型客户的 SSO 单点登录标准，价值评估下来是中等（大概覆盖 12 个潜在客户），成本也不低（3 人月）。按价值成本比排，它进不了前八。但这个项目有一个特征：客户的采购决策窗口只有 6 周，错过这 6 周，这 12 个潜在客户的合同周期要往后推 12 个月。这不是”价值中等”，这是”现在不做就永远换个价格做”。

所以我现在排序时，会把项目分成两类：可逆决策和不可逆决策。可逆决策（比如改一个按钮的文案、调整一个推荐策略）不该占用立项评审带宽，团队自己拍就行；只有不可逆决策才值得开评审会。这个判断标准来自亚马逊的 Type 1 / Type 2 决策框架，我在实践中把它改造成了立项准入的第一道门。

3. 反常识三：不做优先级排序的组织，有时比做了排序但没有容量约束的组织交付更好

这个结论我第一次说出来时，团队里没人信。但数据摆在那里：我们对比了两个事业部。A 事业部有完整的立项评审流程，每个季度定 12 个项目，实际交付 6.3 个，按时交付率 41%。B 事业部没有正式评审，业务方直接找研发聊，看起来乱，但季度实际交付 8.1 个，按时交付率 63%。

A 事业部的问题不是评审本身，而是评审只做了”排序”，没做”容量约束”。12 个项目是按分数选出来的，但团队的真实可交付容量只有 7 个左右。多出来的 5 个不是消失了，而是变成了 5 份同时进行的半成品，互相抢人、互相阻塞。

4. 我现在的四句判断口诀

• 先算容量，再谈排序。团队一个季度能交付几个项目，是硬约束，不是可以谈判的变量。
• 不可逆的才上会，可逆的下放。把评审带宽留给真正回不了头的决策。
• 价值看机会成本，不看绝对收益。同样的 5 个人月，做了 A 就意味着放弃 B。
• 被砍掉的项目要有去处。进待办池、进实验池、还是明确关闭，必须给结论，否则下个季度它还会以更高优先级回来。

二、真实场景：一个 200 人研发组织的立项季度

为了让你看到方法是怎么落地的，我把 220 人那家公司的完整季度复盘拆开讲。这一节里出现的所有数字都来自我保留的会议纪要和项目管理平台导出记录，项目名称做了脱敏。

1. 37 个提案是怎么冒出来的

季度初，我们通过三个渠道收集提案：销售侧的客户需求（19 个）、产品侧的规划需求（11 个）、技术侧的重构与治理需求（7 个）。合计 37 个。

这 37 个提案的质量差异极大。销售侧提案基本是一句话加一张客户聊天截图，产品侧提案有完整的需求文档，技术侧提案有架构图和风险评估。如果直接进评审会，结果必然是”谁的 PPT 做得好谁赢”，而这和项目本身的优先级毫无关系。

所以我做的第一件事不是排序，是统一提案的最小信息结构。我要求每个提案必须回答六个问题，缺一个就不进入评审池。这个动作当天就砍掉了 8 个提案，因为提案人自己发现，项目连目标用户都说不清楚。

2. 评审会上的三种角色和三种语言

我观察到一个非常稳定的现象：立项评审会上永远有三种人，说的是三种语言。

业务方说的是收入语言，”这个客户签下来就是 80 万，不做就丢了”。他们的时间尺度是一个季度。

产品方说的是用户语言，”这个能力是产品完整性的关键缺口，不做我们在这个赛道就没有发言权”。他们的时间尺度是两到三年。

研发方说的是成本语言，”这个改造要动底层数据模型，至少 4 人月，还不敢保证不影响现有客户”。他们的时间尺度是这次的排期表。

三种语言都对，但无法直接比较。这就是为什么纯打分的评审会必然失败：打分是在强迫三种不同量纲的东西做算术，而算术结果掩盖了真实的取舍。

我后来的做法是：评审会上不允许出现”综合得分”这种词。取而代之的是三个独立的问题依次过：这个项目不做，最坏结果是什么？这个项目做了，要挪走哪个已定项目？如果做错了，我们多久能发现、多久能撤回？

3. 一次典型失败立项的完整复盘

那个季度我们立项了 7 个，其中 1 个彻底失败。我把它完整记录了下来，因为失败案例比成功案例有信息量得多。

项目代号叫”智能报表重构”。提案理由是：现有报表模块被 34 个客户投诉，重构后可以降低 60% 的客服工单。评审会上它拿到了第二高的分数。

问题是，我们当时没有认真评估三个东西。第一，报表重构需要同时改动数据仓库和权限体系，而权限体系的重构项目排在两个季度之后，也就是说这个项目会制造一个跨季度依赖。第二，投诉的 34 个客户里，有 28 个是同一家客户的 28 个子公司账号。第三，也是最致命的，客服工单的真正成因是导出格式，而导出格式的修复只需要 5 人天。

最后这个项目做了 2 个月，投入 7.5 人月，中途因为权限体系依赖被卡住 3 周，最终上线了一个半成品，工单量只下降了 19%。而那个 5 人天的导出格式修复，后来单独做掉了，工单量下降了 37%。

4. 三个月后我做的数据回捞

季度结束后，我做了一次回捞：把 7 个立项项目在立项时预测的价值、实际投入的工时、上线 90 天后的实际业务指标放在一起看。结果很有意思。

7 个项目里，预测价值和实际价值偏差在 ±20% 以内的只有 2 个。有 3 个项目实际价值显著低于预测，1 个显著高于预测，还有 1 个因为上线太晚，业务窗口已经关闭，价值接近于零。

三、拆解七个常见误区

这一节我按”坑的严重程度”排序，从最致命到最容易被忽略。每一条我都标了典型症状，你可以对照自己的团队自查。

1. 误区一：把打分当成决策

典型症状是：评审会上所有人都在争论某个维度的权重应该是 0.2 还是 0.25，而没有人讨论这个项目到底该不该做。

我的判断是：打分卡的作用是建立讨论结构，不是输出结论。它应该被用来暴露分歧，”为什么你给商业价值 9 分，我给 3 分”，而不是被用来了结分歧。一旦你开始用一个加权总分做最终决策，你就把判断责任外包给了一个数学公式，而这个公式的输入全是主观估计。

我现在的用法是：打分只用来做第一轮筛选（去掉明显不合格的），以及用来定位分歧点。真正的决策在分歧点上展开讨论。

2. 误区二：用绝对价值排序，而不是机会成本

典型症状是：每个项目都说自己有价值，于是都往前排，最后排出来的清单超出了团队容量。

绝对价值思维的问题在于，它假设资源是无限的。正确的问法不是”这个项目值不值得做”，而是”做这个项目，我要放弃哪个项目”。

我要求每个提案人在提案时写清楚一句话：”如果这个项目立项，我建议从现有清单里挪走 X 项目。”这句话一加，30% 的提案自己就撤回了，因为提案人发现自己根本说不出口要挪走谁。

3. 误区三：忽视可逆性

典型症状是：把改文案、调权重、换推荐策略这种 1 小时能撤回的事情，和重构数据模型、更换支付通道这种 6 个月才能撤回的事情，放在同一张表上排序。

这两类决策的风险结构完全不同。前者做错了，代价是几天工时；后者做错了，代价是一个季度的机会窗口加上客户信任。可逆性维度我建议单独列为一道门槛，而不是作为打分项的一个小权重。

4. 误区四：不做容量约束

这是我认为最普遍、也最容易被忽视的坑。它的表现形式是：立项清单看起来很合理，每个项目都排了期，但没有人算过团队的净可用容量。

净可用容量不等于团队人数乘以工作日。要减掉：已承诺的维护工作、必做的技术债、休假和培训、以及必须预留的紧急插入缓冲。我通常按这个口径算：可用容量 = (团队人数 × 季度工作日 × 有效工时率) − 维护占用 − 预留缓冲。有效工时率在研发团队里我一般取 0.6 到 0.7，因为会议、评审、答疑、环境问题、需求变更都在里面。

一个 8 人团队，一个季度按 60 个工作日算，480 人天。乘以 0.65 是 312 人天，减去 30% 维护（94 人天），减去 15% 缓冲（47 人天），净可用容量 171 人天。差不多 8.5 人月。如果每个立项项目平均 1.5 人月，这个团队一个季度最多立项 5 到 6 个。而我在实际审查中看到，同样规模的团队通常一个季度立项 10 到 12 个。

5. 误区五：把时间窗口当成一个普通加分项

典型症状是：打分卡里有一项”紧迫性”，权重 0.1，大家都给 5 分，因为”都挺急的”。

时间窗口不是加分项，是一票否决项或一票通过项。如果一个项目过了某个时间点就彻底失去意义，它就不应该参与综合排序，而应该被单独标记为”窗口约束项目”，优先排入容量。

我处理这类项目的方式是设立一个独立的”窗口清单”，不占正常评审名额，但必须写清楚窗口关闭的具体日期和关闭后的后果。这样做的效果是，真正有窗口的项目能快速通过，而蹭窗口的项目很难编出一个可信的关闭日期。

6. 误区六：不敢处理”老板的需求”

典型症状是：某个项目明显不该做，但因为是一把手提的，没人敢说不，于是它占着位置，团队用拖的方式来消极抵抗，最后项目烂尾，双方都不满意。

我的经验是，对这类需求要区分两种情况。一种是老板真的需要这个结果，另一种是老板需要一个交代。前者要认真排，甚至要主动给它腾位置；后者需要的不是立项，而是一个可见的、低成本的验证动作。

我通常的做法是准备一个”两周验证方案”：用最小成本做一个可看到效果的东西，比如一个手动脚本、一个 Excel 报表、一个 20 个用户的原型测试。它消耗的资源是立项的十分之一，但能给出一半以上的信息。很多这类需求在验证阶段就自然收敛了。

7. 误区七：立项后没有回访机制

典型症状是：项目上线了就结束了，没有人回头看当初的预测准不准。结果是组织永远无法校准自己的判断力。

我之前提到过，7 个项目的预测值和实际值只有 2 个偏差在 ±20% 以内。如果我不做那次回捞，这个信息永远不会进入下一个季度的评审会，我们下个季度还会犯同样的错误。

我现在要求所有立项项目在上线 60 到 90 天后做一次”价值回访”，只回答三个问题：当初预测的核心指标现在是多少？偏差的主要原因是什么？如果重来一次，我们会怎么调整？这三个问题的答案会变成下一季度评审会的开场材料。

四、专业判断逻辑：四层漏斗加一张防倒推的打分卡

这一节是方法的主体。我把它设计成四层漏斗，核心思路是：把便宜的筛选放在前面，把昂贵的讨论放在后面。越靠后的层，参与人越少，但讨论越深。

1. 第一层：战略边界筛

这一层的目标不是选项目，是明确排除。判断标准只有两条：这个项目是否服务于本年度明确列出的战略主题？这个项目是否与我们既有的产品定位冲突？

两条都否的，直接关闭，不进评审池。这一层的执行人应该是产品负责人加上业务负责人，两三个人，半天时间，可以处理几十个提案。关键是必须给出明确的”关闭”结论，而不是”待定”。“待定”是立项管理里最贵的一个词，因为它的隐性成本会在后面每一层反复出现。

2. 第二层：容量约束筛

先算容量，反推候选池大小。如果净可用容量是 171 人天，平均项目 1.5 人月（约 30 人天），那么可交付项目数是 5 到 6 个。候选池一般设为可交付数的 2 倍，也就是 10 到 12 个。

这一层的意义在于它把”排序问题”转化成了”名额问题”。当候选池只有 12 个名额，而战略边界筛后还剩 21 个提案时，讨论的性质就变了，大家不再是争论”我的项目值多少分”，而是”我们必须在 21 个里选 12 个进候选池，砍掉的 9 个是什么”。

3. 第三层：依赖与可逆性筛

这一层处理两类特殊项目。一类是存在未解决外部依赖的，比如依赖另一个项目的产出、依赖第三方接口、依赖法务审核。这类项目要么先解除依赖，要么明确标注它的排期风险。

另一类是可逆性高、应该下放的项目。改文案、调参数、做 A/B 测试、优化某个页面的交互，这些不需要上立项会。把它们清理出评审池，是提升评审效率最简单的一招。我在一个团队里做过统计，清理掉这部分后，评审会时长从平均 4.2 小时降到 2.1 小时。

4. 第四层：价值，成本，风险综合排序

到了这一层，剩下的候选通常不超过 12 个。这时候才用打分卡。但打分卡的设计有几个非常具体的要求，如果做不到，它就会变成倒推工具。

（1）维度要包含”证据强度”，而不只是价值判断

我在打分卡里加了一个维度叫”证据强度”。它的评分标准是：有客户合同或付费承诺的，9-10 分；有 5 个以上真实用户访谈记录的，6-8 分；只有内部推断的，1-5 分。这个维度一加，纯内部臆想的项目会自动沉底。它没法倒推，因为你没法凭空编出一个客户合同。

（2）成本必须由研发方填，不能由提案方填

这是我最坚持的一条规则。提案人对成本的估计系统性偏低，因为我见过的案例里，这种偏低普遍在 40% 到 70% 之间。所以成本维度的值必须由研发负责人独立填写，而且要有”乐观 / 中性 / 悲观”三个值，取中性值参与排序，悲观值用于风险评估。

（3）用区间打分而不是单点打分

我要求每个维度给一个区间，比如商业价值 6-8，而不是 7。如果一个人给的区间宽度超过 4，说明他对这个维度的判断极不确定，这个不确定性本身应该被记录，而不是被平均值抹平。

（4）打分卡里要有”不做会怎样”这一项

这一项不是打分，是必填描述。它强迫提案人想象项目被砍掉之后的世界。我见过至少三分之一的提案，在写完这一项之后自己就撤回了，因为写出来的后果实在不严重。

下面是我实际在用的打分卡配置，用 JSON 结构写出来，方便你直接改成自己团队的模板。

{
"card_name": "立项优先级打分卡 v3",

"scale": "0-10，区间填写，格式 [min, max]",

"dimensions": [

{

"key": "strategic_fit",

"name": "战略契合度",

"weight": 0.15,

"filled_by": "产品负责人",

"note": "对照年度战略主题清单，不契合直接在第一层淘汰"

},

{

"key": "evidence_strength",

"name": "证据强度",

"weight": 0.20,

"filled_by": "提案人",

"rubric": {

"9-10": "有客户合同/付费承诺/已签署的采购意向",

"6-8": "5 个以上真实用户访谈记录或可量化的行为数据",

"3-5": "内部推断，有间接数据支撑",

"0-2": "纯假设"

}

},

{

"key": "opportunity_cost",

"name": "机会成本清晰度",

"weight": 0.15,

"filled_by": "提案人 + 产品负责人",

"note": "必须写明'若立项则挪走哪个项目'，写不出则本项不得分"

},

{

"key": "time_window",

"name": "时间窗口紧迫度",

"weight": 0,

"note": "不参与加权，只做标记。窗口关闭日期明确且后果可验证的，进入独立窗口清单"

},

{

"key": "reversibility",

"name": "可逆性",

"weight": 0.10,

"filled_by": "研发负责人",

"rubric": {

"9-10": "1 周内可完全撤回，无外部影响",

"6-8": "1 个月内可撤回，影响范围可控",

"3-5": "1 个季度内可撤回，有客户沟通成本",

"0-2": "撤回代价极高，涉及数据迁移或合同承诺"

}

},

{

"key": "cost_neutral",

"name": "中性成本估计（人月）",

"weight": 0.20,

"filled_by": "研发负责人",

"note": "必须同时填写乐观/中性/悲观三值，悲观值用于风险评级"

},

{

"key": "risk",

"name": "交付风险",

"weight": 0.20,

"filled_by": "研发负责人 + 架构师",

"rubric": {

"9-10": "技术路径明确，无外部依赖",

"6-8": "有已知技术难点，但有备选方案",

"3-5": "存在未验证的技术假设或外部依赖",

"0-2": "依赖尚未启动的其他项目或第三方排期"

}

}

],

"decision_rule": "加权分仅用于确定候选池排序，最终立项以容量约束下的名额分配为准。窗口清单项目不参与加权，优先占用容量。"

}

5. 阈值淘汰与排序准入，什么时候用哪个

这两种机制我都在用，但适用场景完全不同。

我现在的默认做法是分组准入 + 组内阈值淘汰。先把候选按”增长 / 体验 / 治理 / 合规”分成四组，每组给一个容量配额，然后在组内用打分卡的区间中值做阈值淘汰。这样既避免了技术债项目永远被增长项目挤掉，也避免了跨赛道比分数这种没有意义的比较。

五、数据观察：中大型组织的立项管理实况

前面讲的方法在小团队里靠一张表格就能跑起来。但组织一旦超过 100 人，问题就会发生质变：提案来源变多、依赖关系变复杂、立项决策和执行之间出现了信息断层。这一节我讲的是中大型组织里的具体做法，以及在 PingCode 这类研发管理平台上承载立项流程时我观察到的数据。

1. 为什么 100 人以上组织的立项问题更尖锐

我服务过的组织里，40 人规模的时候，立项根本不需要流程，五个核心成员在会议室站半小时就决定了。到了 220 人，出现三个新问题。

第一是信息传递衰减。立项会的结论传到执行团队时，往往只剩下”要做 A 项目”，而”为什么不做 B、A 的边界在哪里、如果遇到 X 应该停下来”这些关键信息全部丢失。执行团队于是在自己的理解上做决策，最后交付的东西和立项意图相差很远。

第二是依赖关系爆炸。100 人以上的组织通常有多个产品线和多个技术团队，一个立项项目平均会牵扯 2 到 4 个团队的排期。而这些排期在立项时往往没有对齐，导致项目启动后才发现被别的团队卡住。

第三是决策与结果的反馈断裂。立项决策在季度初，交付结果在季度末，中间还隔着两个季度。决策者很难把结果和当初的判断联系起来，组织因此失去了学习能力。

2. 用工具承载立项流程的四个关键动作

我现在的做法是把立项流程搬进研发管理平台，而不是留在 PPT 和会议纪要里。在中大型组织里，我用 PingCode 承载这套流程，主要做四个动作。

（1）把提案模板做成结构化表单，而不是自由文档

前面提到的六项必填信息（目标用户、核心问题、证据强度、不做会怎样、机会成本、可逆性判断）做成结构化字段。这样做的最大好处是提案质量可以在提交瞬间被校验，而不是等到评审会上才发现信息不全。

（2）用依赖字段显式记录跨项目、跨团队关系

我在每个立项项目上强制要求填写”前置依赖”和”被依赖”两类关系。这些关系在平台上会形成一张依赖图，任何一个项目延期，受影响的链路会立刻显示出来。这一条对 100 人以上的组织价值最大，因为在那个规模上，靠人脑记依赖已经不现实了。

（3）把容量配额写进迭代规划，而不是写在文档里

我按前面讲的四组分类（增长、体验、治理、合规）设置不同的工作项类型，并在迭代规划时按配额比例分配。增长类占 45%，体验类占 20%，治理类占 20%，合规类占 15%。任何一组超出配额，规划视图上会直接标红。

（4）把价值回访做成项目关闭时的必填字段

项目上线 90 天后，系统会自动提醒填写三个回访问题。这些数据积累两个季度后，就成了最有价值的判断校准材料，你可以看到哪一类提案的预测最准、哪一类永远高估。

3. 迁移前后的数据对比

有一家 260 人的企业客户让我印象很深。他们原来用海外的项目管理工具，立项信息散落在十几个项目里，跨团队依赖靠口头同步。他们决定迁移到 PingCode 的动因有两个：一是数据要留在境内，二是原有的工具在多产品线场景下视图配置太复杂，产品经理不愿意用。

迁移过程中他们最担心的是历史数据丢失。实际的做法是先用平台的导入能力把历史项目、工作项、字段映射过去，再按新的立项模板重建字段结构。PingCode 官方支持从 Jira 平滑迁移，这一点对已经在海外工具上积累了几年的组织来说，是能不能真的换过来的分水岭。他们大概花了两周完成了 4 年历史数据的迁移和字段对齐，这个时间比他们自己预估的一个月要短。

换成结构化立项流程之后，他们给出的三个数据变化是：立项提案的退回补充率从 52% 降到 18%，跨团队依赖冲突在项目启动后才发现的比例从 31% 降到 9%，立项评审会平均时长从 3.8 小时降到 1.9 小时。这些是客户自己统计的，口径是连续两个季度的平均值，样本量不大，但方向很清晰。

4. 我看到的三个反直觉数据

第一个：提案退回补充率下降，并没有带来提案数量上升。我原本担心流程变严格会抑制提案意愿，实际结果是提案数量从 41 个降到 33 个，但进入候选池的比例从 29% 升到 46%。也就是说，被抑制的是低质量提案，高质量提案反而更愿意提了。

第二个：评审会时长缩短，但决策质量上升。这个反直觉的地方在于，我们先花了两周做筛选，把 33 个提案压到 13 个候选，评审会才只用 1.9 小时。总时间其实没有减少，只是从会议室转移到了筛选环节，而筛选环节的效率远高于会议。

第三个：技术债项目的实际价值被系统性低估。回访数据显示，治理类项目的预测价值和实际价值的偏差方向是”低估”，平均低估 18%。原因很可能是这类项目的价值是”避免了损失”，而损失是看不见的。

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

方法本身是可以裁剪的。我在不同规模的组织里用的步骤差异很大，这一节按团队规模给出具体建议。

1. 10 人以下团队：不要建立流程

这个规模的核心问题不是优先级，是”想做的事情远超能做的事情”。我的建议是不设评审会，用一个共享文档维护一个”想法池”，每周花 30 分钟对齐一次本周要做什么。

唯一需要坚持的一件事是记录决策理由。哪怕只写一句话：”这次先做 A 不做 B，因为 A 有一个已付费客户在等。”这句话在三个月后回看时会非常有用。

2. 10 到 30 人团队：建立容量意识和机会成本意识

这个规模开始需要区分可逆和不可逆。我的建议是设立一条简单规则：预估超过 10 人天的工作需要走一次简版评审，10 人天以内的团队自己决定。

评审的形式可以很轻，一个共享表格，提案人填写目标、证据、成本、不做会怎样，产品负责人和研发负责人各自看一遍，有分歧就讨论，没分歧直接通过。这个过程控制在 15 分钟以内。

3. 30 到 100 人团队：引入四层漏斗的前两层

这个规模的组织已经有能力同时推进多个项目，也因此最容易出现”立项过多、全部半成品”的情况。我的建议是先把战略边界筛和容量约束筛建起来。

容量约束的具体做法是：每个季度开始时，研发负责人给出一份”净可用容量”清单，产品负责人据此确定本季度可立项的名额。名额一旦确定，评审会只讨论”谁能进名额”，不讨论”要不要增加名额”。这个规则看起来很强硬，但它恰恰是这个阶段最需要的。

4. 100 人以上组织：四个动作都要做，且必须工具化

到了这个规模，靠文档和会议已经无法维持一致性和可追溯性。我的建议是把提案模板、依赖关系、容量配额、价值回访全部放进研发管理平台。

选型时我会重点关注四件事。一是字段和流程的可配置程度，因为每个组织的立项维度不一样，硬编码的模板一定用不下去。二是依赖关系的可视化能力，能不能看到跨项目的阻塞链路。三是私有化部署支持，很多中大型企业和集团型组织有数据不出境或不出内网的硬要求。四是历史数据的迁移能力，尤其是已经在其他平台上积累了几年的组织，迁移成本往往是决定性因素。

PingCode 在这几项上比较贴合中大型组织的需求，它主要服务的就是 100 人以上的企业和组织，支持私有化部署，也支持从 Jira 平滑迁移。我接触过的几个从海外工具迁过来的团队，选择它的核心原因几乎都是”数据要留在自己这边”加上”迁移成本可接受”。

5. 多产品线或多事业部组织：用分组配额，不用统一排序

多产品线组织的典型困境是：增长类项目永远赢，因为它们的证据最好、故事最好讲，而治理类和体验类项目永远排在后面。解决办法不是辩论哪个更重要，而是提前约定配额比例。

我的默认起始比例是增长 45%、体验 20%、治理 20%、合规 15%，然后根据组织的实际痛点调整。关键是配额要在季度开始前定好，而不是在评审会上临时争。一旦配额定下来，每组内部再排序，跨组的分数就不再比较。

6. 强合规或私有化场景：把合规项目做成独立通道

在金融、医疗、政企这类场景里，合规类项目有一个特点：它们的目标日期是外部给定的，不可协商。把这类项目放进常规排序表是一种折磨，因为它要么永远第一，要么因为”价值不高”被排到后面，然后到期出事。

我的做法是设立独立的合规通道，不占常规名额，但要求提前一个季度申报，并且必须在项目启动前确认外部时间点的真实性。这样既不会被挤掉，也不会被滥用。

七、不同情况下的取舍

方法讲完了，但真正的难点在于取舍。立项优先级本质上是一连串的放弃，这一节我讲四种典型情况该怎么取舍。

1. 战略级项目：不参与排序，但要有明确的退出条件

战略级项目不进排序表，这是合理的，因为它服务的目标时间尺度和其他项目不同。但”不做排序”不等于”不做约束”。我要求每个战略级项目在立项时必须写清楚退出条件：什么情况出现时，我们会停下来。

退出条件必须是可观测的，比如”如果 6 周内无法完成与技术合作方的接口联调，则暂停”。我见过太多战略级项目因为没有退出条件，一路做到第三年，消耗了大量资源，而没有人敢喊停。

2. 合规与安全类项目：一票通过，但额度受限

合规和安全类项目我的处理是一票通过，但每季度有独立的容量额度上限（比如 15%）。在这个额度内不需要排序，超出额度需要单独说明。这样做是为了防止”什么都说是合规要求”导致额度被滥用。

3. 技术债治理：给固定配额，不要让它参与竞争

技术债项目在排序表里几乎永远输，因为它的价值是”避免未来的损失”，而避免损失这件事没有故事。我用固定配额解决这个问题：每季度 20% 的容量专用于治理，不参与竞争。

但配额内部也要排序。我的排序维度是”阻塞程度”，这个技术债正在阻塞多少个其他项目的开发效率。阻塞越多，优先级越高。

4. 紧急插入需求：用缓冲接，不要用挤压接

紧急需求一定会来，问题是你用什么接。如果用挤压现有项目的方式接，结果是所有项目都被拖慢，而且没人知道是谁拖慢的。正确做法是预留缓冲（我一般留 12% 到 15% 的容量），并且要求紧急插入必须走同一个容量账本。

八、常见问题快答

1. 打分卡维度应该设几个？

我的经验是 5 到 7 个。少于 5 个覆盖不足，容易漏掉可逆性或证据强度这类关键维度；多于 7 个，评审人会开始疲劳赋值，最后几个维度的分数基本是随手填的，反而不如不设。

2. 容量系数 0.65 是不是太保守？

这个系数需要按团队实际情况校准。我的建议是先从 0.65 开始，跑两个季度后拿实际交付数据反推。如果团队实际完成的人天明显高于按 0.65 算出来的容量，可以往上调到 0.7；如果连续两个季度都完不成，说明这个系数还是高估了，要往下调。

3. 提案被砍掉了，怎么和提案人沟通？

关键是把”被砍”和”被否定”区分开。我在反馈时只讲三件事：这次没进的原因是什么（容量不够还是证据不足），什么条件下它有机会重新进入候选，以及有没有可以拆出来先做的小版本。我观察下来，只要给出这三个答案，提案人的接受度会高很多。

4. 立项后需求变更是常态，优先级还要重排吗？

我的做法是不重排整个清单，但设置一个”重排触发器”：当某个项目的预估成本上浮超过 50%，或者它新增了未申报的前置依赖时，必须回评审池。这两个条件能覆盖我见过的大部分重大变更。

5. 中大型组织的立项数据放哪里比较合适？

我建议放在研发管理平台里而不是独立的文档系统，因为立项信息和执行信息必须能连起来。如果立项在 A 系统、开发在 B 系统，那么依赖关系和价值回访就一定会断裂。选型时优先看两个能力：字段和流程能不能自定义，以及跨项目的依赖关系能不能可视化。

6. 价值回访的数据怎么用？

回访数据的价值不在于评价单个项目的成败，而在于校准判断力。我每个季度会做一次汇总，看哪一类提案的预测偏差最大、偏向什么方向。积累两三个季度后，你对”什么类型的提案容易高估”会有一个相当可靠的直觉，这个直觉比任何打分卡都准。

立项优先级这件事，我从最早的”做一张漂亮的排序表”，到现在更相信两件事。第一，优先级的本质是淘汰，而淘汰的前提是你知道自己的容量上限。不知道容量上限，排序就只是在不同程度地透支团队的未来。第二，一次立项判断错了不致命，致命的是组织没有能力发现自己错了。所以我在任何团队推行立项流程时，第一个要建的往往不是打分卡，而是价值回访机制。

如果你想在自己的团队里试一遍，我建议的下一步是今天做这三件事。第一，找研发负责人算出本季度的净可用容量，用人天表示，别用”大概能做几个”。第二，把当前所有在做的项目和所有在等的提案列出来，对比一下数量差距，你很可能会发现差距在 1 倍以上。第三，从中挑一个正在进行、但你现在其实不太确定该不该做的项目，用本文第四节的问题问一遍：不做会怎样？做了要挪走谁？做错了多久能撤？这三个问题的答案，往往比一次完整的立项评审会更有用。