项目立项优先级教程：管理层最佳实践，避坑指南

项目立项优先级教程：管理层最佳实践，避坑指南

2023 年 11 月，我坐在一家年营收 32 亿元的装备制造企业的会议室里，参与他们的年度立项评审。会议室 19 个人，投影上是 217 个待评审项目，议程原定 4 小时，实际开了 9 小时 20 分钟。会议结束时，163 个项目被”原则上通过”。

8 个月后我回访。这 163 个项目里，真正交付上线的只有 36 个；51 个连需求文档都没写完；29 个在系统里挂着”进行中”，而项目负责人已经离职。财务口径上被计入年度预算的研发投入，有接近四成消耗在了不会产出任何结果的项目上。

这不是个例。过去 7 年，我参与过 20 多家企业的立项流程改造，覆盖装备制造、银行、医疗器械和 SaaS。我逐渐确认一件事：绝大多数企业的立项优先级机制失败，原因不是”评分模型不够科学”，而是把排序问题当成了全部问题。排序只占整个机制的 30%，剩下 70% 是资源口径、否决机制和重排纪律。

这篇文章不讲教科书上的优先级矩阵，我讲的是我在真实会议室里看到的、能落地也能踩坑的东西。文中数据来自我参与的项目台账与经验观察，涉及具体企业时做了脱敏处理，模拟推演的数据我会明确标注。

一、核心结论：立项优先级的本质是资源承诺，不是排序

先给结论，后面再展开论证。如果你只记得一段话，记这一段。

1. 优先级的单位不是”分”，是”人天”

我见过太多企业把立项优先级做成一张打分表，最后输出的是每个项目的综合得分，比如 A 项目 84.5 分、B 项目 82.1 分。然后管理层看着这张表，凭感觉挑选。

问题在于，”84.5 分”这个数字不约束任何东西。真正能约束决策的单位是资源：人天、预算额度、关键岗位的排期。一个项目被排到 P0，意味着某个 8 人团队未来 6 个月被占用 4800 人天。如果这个团队同时被排了 3 个 P0，那这个 P0 就是假的。

我现在的做法是：任何进入 P0/P1 的项目，必须在评审现场确认”由哪个团队、投入多少人天、从哪个月开始”。确认不了的，直接降到等待池，不管它战略意义多大。

2. 门槛和权重是两码事，混在一起必出事

合规、数据安全、技术可行性、资源可得性这四类因素，必须做成门槛（一票否决），不能做成加权项。一旦做成加权项，就会出现”这个项目合规性差一点，但业务收益高，加权后还是排第一”的情况。

我见过一家银行把”是否符合数据分级规范”设成了 10 分权重项。结果 3 年里有 4 个项目带着违规的数据出境方案进入了开发阶段，最后全部在安全评审时被拦下，白白消耗了 6000 多人天。如果这项是门槛，这 4 个项目根本不会进入排序环节。

3. 没有重排机制的优先级表，6 个月内必然失效

年度立项做完，很多企业就把优先级表锁进抽屉，直到第二年。但业务环境不会等你一年。我统计过手上 6 家企业的台账：年度立项时排在 P1 的项目，到年中仍被认为应该保持 P1 的，只有 41%。也就是说，近六成的优先级判断在半年内就已经失真。

缺失重排机制的后果不是”判断不够准”，而是”没有人敢终止项目”。项目一旦立项就获得了合法性，即使它已经不再重要，也没人有权力把它拿掉。

4. 优先级机制的四个部件

把上面几点收拢，一个能跑的立项优先级机制由四部分组成。缺任何一个，机制都会退化成形式主义。

下面这张图展示的是我参与的 3 家企业台账合并后的立项漏斗。它说明了一件事：从申报到交付，真正被消耗掉的不是评审环节，而是资源不可得和后期停机。

二、真实场景：为什么 200 个立项申报最后只交付 40 个

要理解优先级机制为什么难做，得先看清它是被什么力量推着走的。我把它拆成三个层次：结构性缺口、动机博弈、时间错配。

1. 结构性缺口：申报量天然大于交付能力

这不是管理不善，而是组织运行的自然结果。每个部门负责人都有动机多申报：申报成本低（一份 PPT），不申报的机会成本高（万一别人拿了预算）。

我做过一个粗略测算。一家 800 人规模、研发 320 人的企业，年度可投入研发的有效人天约为 320 人 × 200 天 = 64000 人天，扣除运维、技术支持、缺陷修复等常规占用（通常占 35%-45%），真正可用于新立项的约 38000 人天。

一个中等规模的立项项目平均需要 1200-1800 人天，意味着这家企业一年能真正承接的新立项大概是 21-31 个。而它的年度申报量是 217 个。缺口近 10 倍。

这个数字很残酷，但它就是现实。机制设计的第一步，是承认”大部分项目必须被拒绝”，而不是假装通过评审的项目都能做完。

2. 动机博弈：三类立项动因的行为差异

我在评审现场观察到的项目，基本可以归为三类。它们的评估难点完全不同，用同一套评分卡去打分是无效的。

（1）战略驱动型

由公司级战略解码下来，通常有明确的责任高管。这类项目战略对齐度高，但收益往往模糊、周期长、验收标准难定义。评估难点是如何避免用”战略”两个字豁免所有质疑。

（2）机会驱动型

来自客户订单、渠道机会或竞品动作。这类项目收益可验证性高，但容易造成资源插单、打乱既有节奏。评估难点是如何区分”真机会”和”销售承诺倒逼”。

（3）政治驱动型

由部门预算压力、个人绩效或内部竞争产生。这类项目最大的特征是不缺预算，缺的是业务方。评估难点是如何让它在不撕破脸的前提下被降级。

下面这张雷达图是我对某企业 47 个立项项目按三类归因后的六维评分均值，样本为该企业 2023 年度立项台账（示意推演，非行业统计）。

3. 时间错配：评审周期和机会窗口的冲突

年度集中评审有一个天然缺陷：它假定所有项目机会都出现在同一时间。但机会驱动型项目的窗口期往往只有 2-4 周。

我见过一家企业为了保持”评审严肃性”，规定所有立项必须走完 21 天的完整评审流程。结果是：过去两年里，这家企业丢掉了至少 5 个有明确客户付费意向的机会型项目，累计损失的年化收入约 1800 万元。而他们坚持这套流程的理由是”避免拍脑袋立项”。

正确做法是把评审分成两条通道：常规通道按季度节奏走，快速通道只做门槛校验（4 道门槛 + 资源确认），48 小时内出结论，但同时要占用该部门的年度弹性产能额度。用额度约束来替代流程约束。

三、七个高频误区：我见过的失败模式

这一节讲的每一条，我都至少在两家企业见过完整版本。它们的共同点是：看起来都很合理，做起来都很顺，出事的时候已经来不及了。

1. 满分制打分导致区分度坍塌

100 分制打分最大的问题是心理锚定。评委倾向于把熟悉但不突出的项目打在 75-85 分，把不熟悉的项目打在 70 分左右，把明确要拒绝的项目打在 60 分以下。结果是大量项目挤在中间区间，无法区分。

我抽取过一家企业 217 个项目的评分分布，结果如下。注意 70-89 分区间占比高达 59.4%。

2. 权重平均化：每个维度 10 分

我见过一份评分卡，12 个维度每个 10 分，总分 120 分。设计者的初衷是”全面”，实际效果是”战略被稀释”。

当战略对齐、技术难度、团队能力、市场前景、客户满意度、可维护性、学习价值各占 10 分时，一个战略价值极高但技术难度中等的项目，得分会和一个战略价值一般但各方面均衡的项目几乎持平。权重平均化的本质，是拒绝承认公司有优先级。

我现在建议的做法是：主评分卡不超过 5 个维度，且维度之间必须是加法关系而非乘法关系。更重要的战略导向，通过门槛和预算分配来体现，不要塞进评分卡。

3. 只算收益不算机会成本

几乎所有评分卡都有”预期收益”这一项，但极少有”机会成本占用”这一项。

假设两个项目都申报使用同一支 12 人的数据团队。A 项目预期年化收益 500 万元，B 项目预期年化收益 800 万元，看起来 B 优先。但如果 A 只需要占用团队 3 个月，B 需要占用 9 个月，那么 A 的实际单位收益是 1667 万元/年化人力，B 是 1067 万元/年化人力。结论反转。

收益必须除以资源占用，而不是简单比较绝对值。这是我在所有改造项目里最先调整的一条。

4. 立项即定级，永不重排

我在一家企业看到过这样的记录：一个 2021 年立项的 P1 项目，从 2022 年起就没有任何进展，负责人换了三任，最近一次更新状态是在 2023 年 4 月，内容是”等待业务方确认需求”。

它在系统里依然是”进行中”，依然占用着预算科目，依然出现在季度汇报的”在跑项目”计数里。这类僵尸项目的危害不是浪费了已投入的资源，而是污染了整个资源视图，管理层看到的产能利用率是虚高的，导致新项目无法被合理评估。

我建议的纪律是：连续两个季度无实质进展的项目，自动进入”待终止”状态，需要业务方书面说明理由才能恢复。默认动作是终止，不是继续。

5. 把合规项做成加分项

这条前面提过，但值得单独说，因为它是唯一会带来外部风险的类型。

合规、数据分级、行业监管、开源许可证、安全审计，这五类必须是一票否决。它们不存在”部分符合”的状态。把它们做成加权项，等于告诉组织：合规是可以被收益交换的。

6. 由 PMO 独评，业务方不承诺资源

这是最隐蔽也最致命的一条。PMO 熟悉流程、擅长打分，但 PMO 没有资源。一个没有资源承诺的立项，本质上是 PMO 的一厢情愿。

我经历过一次典型的翻车：PMO 评出了 12 个 P0 项目，评分都很漂亮。三个月后复盘发现，只有 3 个项目真正开工，其余 9 个都卡在”团队腾不出人”。原因是评审时业务方代表只是”列席”，没有做资源承诺，也没有签字。

现在的做法很直白：每个进入 P0/P1 的项目，必须有承接团队负责人当场确认人天和起始月份，确认不了的直接进等待池。这一个动作，就能把虚假的 P0 数量砍掉一半以上。

7. 用绝对分值代替分桶

前面说了满分制区分度差，更深层的问题是：分数是连续的，而决策是离散的。

管理层不需要知道 A 项目 82.1 分、B 项目 81.7 分，他们需要知道的是：哪些必须做、哪些应该做、哪些可以做、哪些不做。这是四个桶，不是一条数轴。

我坚持用分桶法的另一个理由是：分桶天然支持资源约束。你可以说”P0 桶的总人天不能超过可用产能的 60%”，但你没法说”分数超过 82 分的项目总人天不能超过 60%”，后者听起来毫无道理，前者直接可执行。

四、专业判断逻辑：门槛 + 证据 + 资源 + 分桶

这一节给出完整的判断框架。如果你要直接拿走用，只抄这一节就够。

1. 第一层：四道硬门槛

门槛的作用是筛选资格，不是排序。通过门槛的项目才进入评分环节，不通过的直接出局，不参与后续讨论。

1. 战略对齐门槛：项目必须能对应到公司年度战略主题清单中的至少一项。对应不上的，走”探索性小项目”通道，额度单独封顶，不占用主预算。
2. 合规与安全门槛：数据流向、权限设计、行业监管、开源许可证四项检查，任一不合格即出局。
3. 技术可行性门槛：由架构组评估，重点看是否引入新的技术栈、是否有单点依赖、是否有无法满足的非功能需求。
4. 资源可得性门槛：这是最容易被忽略的一道。项目必须明确承接团队和大致时间窗，且该团队当前负载不超过 80%。超过 80% 的，项目进入等待池，无论分数多高。

2. 第二层：给收益打证据折扣

这是我认为最有价值的一个机制，也是最少被采用的。核心思想是：不同来源的收益预测，可信度差异极大，必须用折扣系数体现。

下面这张横向条形图是我们现在通用的一套折扣系数。它是经验值，不是统计结论，但在我参与的项目中验证过多次，方向是对的。

3. 第三层：把成本口径统一到人天

如果你想只做一件事来改善立项质量，我会推荐这件：把所有项目的成本口径统一成人天，包括非研发项目。

原因很简单：钱可以印，可以调预算，但人天是物理约束。一个 12 人的团队一年就是约 2400 人天，不会因为预算增加而变化。

统一口径之后，很多原本模糊的争论会变得清晰。比如”市场部要做一个数据看板”和”研发要重构订单模块”，原本无法比较，换算成”占用数据团队 120 人天 vs 占用后端团队 900 人天”之后，讨论就能落到具体取舍上。

4. 第四层：分桶而非排名

分桶的具体规则我建议这样设定，括号内是我在多个项目上验证过的经验阈值。

关键约束在第二列，资源上限是可执行的硬约束，分数不是。当 P0 桶的总人天超过 45% 时，必须降级某个项目，而不是”再挤一挤”。

5. 第五层：季度重排与自动降级

重排不是重新评审一遍。重排只做三件事：

1. 检查每个 P0/P1 项目的进展证据（代码提交、里程碑验收、需求冻结记录）。
2. 重新核算各团队的实际负载，与立项时的承诺对比。
3. 把连续两个季度无实质进展的项目自动移入待终止状态。

下面是一段资源冲突校验的逻辑示意，我们在多个客户场景里用同样的思路做过校验脚本，把它贴在评审会的屏幕上，降级决策会快很多。

capacity = team.capacity_person_days_per_quarter
demand = {}

for bucket in ["P0", "P1", "P2"]:

for project in bucket.projects:

demand[project.team] += project.estimated_person_days

for team, load in demand.items():

cap = capacity[team]

if load > cap * 0.8:

overload = load - cap * 0.8

触发降级：优先降证据等级最低、终止成本最小的项目

candidates = sorted(

bucket.projects_of(team),

key=lambda p: (p.evidence_grade, -p.termination_cost)

)

degrade_until(candidates, overload)

这段逻辑解决的是一个非常具体的问题：评审会上说”都能做”，到了执行时才发现做不完。把校验前置到评审现场，让超载可见，降级就从”政治博弈”变成了”机械执行”。

6. 收益折扣的完整计算过程

前面讲了证据折扣，这里给出一个完整的瀑布示意。这是我对一个真实项目的还原，年化收益的名义值 1200 万元，经过四层调整后剩下 550 万元。这个数字后来在实际执行中兑现了约 610 万元，误差在可接受范围内。

五、案例观察：一家 800 人企业 12 个月的改造数据

这一节我把一个完整的改造案例摊开讲。企业信息做过脱敏，但数据是真实台账。

1. 改造前的状态

这是一家汽车零部件企业，800 人规模，研发 320 人分布在 5 个团队。2022 年上半年我介入时，他们的情况是：在跑项目 87 个，平均每个项目延期 3.8 个月，交付准时率 52%，资源冲突投诉每月 23 次。

他们的立项机制是年度集中评审 + Excel 打分表，评分卡 12 个维度各 10 分。评审后的结果存在一个共享文件夹里，团队负责人需要人天时找 PMO 口头协调。

另外他们当时正面临一个额外的约束：使用的项目管理平台是海外产品，数据合规审查越来越严，且内部有国产化替代的明确要求。

2. 做了四件事

改造方案不复杂，但执行到位花了 5 个月。

1. 评分卡从 12 个维度砍到 5 个，并把合规、安全、技术可行性提到门槛层，不再参与打分。
2. 建立人天台账，把 5 个研发团队的有效产能按季度录入系统，作为 P0/P1 分桶的硬约束。
3. 引入证据等级折扣，所有收益预测必须标注证据来源，未标注的按 15% 系数处理。
4. 建立季度重排会议，固定为每季度第一周，2 小时，只处理降级和终止，不新增项目。

在工具层面，他们需要把立项池、资源池和项目执行数据打通，否则前三件事都会退化回 Excel。他们选择的方案是 PingCode。

3. 为什么选 PingCode，以及实际用法

我参与了这个选型过程，理由有三个，都比较具体。

（1）规模匹配

PingCode 主要服务中大型企业及 100 人以上组织，这家企业的 320 人研发规模正好落在它的典型客户区间。我们评估过一些面向小团队的工具，在项目集管理、跨团队资源视图、权限层级上支撑不了这种复杂度。

（2）私有化部署满足了合规要求

这家企业对研发数据的出境有明确限制。PingCode 支持私有化部署，数据可以留在企业内网，这一点在选型阶段是硬性条件而非加分项。

（3）迁移成本可控

他们原来用的是 Jira。PingCode 支持 Jira 平滑迁移，字段、工作项类型、状态流的映射工作量比预期小。实际迁移花了 3 周，包括数据校验，没有出现工作项丢失。

对于当时正在做国产替代评估的他们来说，能同时满足私有化和迁移平滑这两点的选项并不多。用他们技术负责人的原话是：”不是非要换，是换的时候不能把历史数据丢了。“

4. 12 个月后的观察数据

改造启动于 2022 年 9 月，以下是 2023 年 9 月回访时核对的数据。我把两组核心指标放在一张双轴图里：左侧是项目数量，右侧是交付质量指标。

除了项目层面的指标，流程效率的变化也很明显。这组数据来自他们的 PMO 台账。

5. 工具能做什么，不能做什么

这一点我想说清楚，因为我在很多场合看到对工具的过度期待。

工具能做的：统一口径（人天字段强制填写）、留痕（每次降级和终止都有记录）、硬约束（资源超载自动告警）、把评分卡字段化（避免评审后临时改标准）、让历史数据可追溯（迁移后能回看两年前的立项依据）。

工具不能做的：替你拍板终止一个由高管发起、但已经没有价值的项目；替你面对部门之间的资源争夺；替你在评审会上说出”这个项目我们不做了”。这些是管理动作，工具只能让它们变得有据可依，不能代替它们发生。

我见过最失败的案例，是企业买了一套完整的项目管理平台，把所有字段都配好了，但没有人愿意在评审现场说”不”。半年后系统里的数据全部失真，项目数量又回到了 80 多个。

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

前面讲的是通用框架。但企业规模、行业属性、历史包袱不同，落地路径差别很大。这一节按情况分类给建议。

1. 50 人以下团队：不要做评分卡

这个规模做评分卡是浪费。团队负责人对每个项目的价值判断已经足够准，缺的不是模型，是纪律。

我的建议是：一页纸的立项清单，每月更新一次，内容包括项目名、负责人、预计占用谁多少时间、什么时候能出第一个可见成果。重点是最后一项，如果一个项目三个月内说不出第一个可见成果，它就应该被重新讨论。

2. 100-500 人组织：门槛 + 分桶，先跑起来

这个规模开始出现跨部门资源争夺，需要机制。但不要一上来就做复杂的评分模型。

• 先建四道门槛的书面审查流程，这一项不需要任何工具支撑，用共享文档就能跑。
• 再建 P0/P1/P2 三个桶，明确每个桶的资源上限。
• 评分卡最多 5 个维度，第 6 个维度出现时，问自己”这个能不能做成门槛”。
• 季度重排必须固定下来。宁可会议只有 1 小时，也不能取消。

3. 500-2000 人组织：双层评分 + 资源池 + 组合视图

这个规模的核心矛盾是：单个项目的判断可能是对的，但组合起来是错的。你需要的不是更好的单项目评估，而是组合层面的可见性。

关键动作是建立资源池视图。按团队、按技能、按季度展示负载，让”哪些团队已经满了”变成公开信息。这一步用 Excel 也能做，但一旦超过 3 个季度就会失控，建议用支持私有化部署的项目管理平台承接。这也是 PingCode 这类产品在这个规模段最被需要的地方，不是因为功能多，而是因为人天口径统一之后，跨团队的超载能被自动暴露出来。

4. 2000 人以上组织：先分钱，再分项目

这个规模上，逐个项目评审已经不可行了。正确的做法是两级预算制：先把年度预算按战略主题分配给各业务线，再由业务线在自己的额度内立项。

总部的角色从”审批每个项目”转为”设定战略主题和额度、审查门槛合规性、监控组合健康度”。我给一家 3000 人企业的建议是：总部只审批超过 500 人天的项目，其余全部授权，但要求季度上报组合视图。他们的年度评审会从 12 天压缩到了 2 天。

5. 强合规行业：把合规做成前置条件

银行、医疗、能源这类行业，合规项必须前置，且不能参与打分。我见过最有效的做法是：合规审查在立项申请提交时就完成，作为受理条件。合规不通过，项目连进入评审池的资格都没有，而不是在评审会上”再讨论一下”。

另外建议把合规审查结果做成一个独立的字段，在组合视图里可以一列看到所有项目的合规状态。这样在季度重排时，合规状态的变化能第一时间被发现。

6. 正在做工具迁移的团队：先标准化字段

如果你正在从其他平台迁移，无论目标是什么产品，有一条经验值得听：不要直接搬数据，先花两周做字段标准化。

我见过一个团队直接迁移了 4 年的历史数据，结果是工作项类型有 63 种，其中 20 多种只被用过一次，状态流有 8 套互相冲突。迁移完成后三个月，他们就放弃了在新的项目管理平台上做组合分析，因为数据根本没法聚合。

正确的顺序是：先确定目标字段模型（工作项类型不超过 8 种、状态流统一为 1-2 套），再做映射，再做增量迁移验证，最后才做全量。这个顺序会让迁移周期从 3 周变成 6 周，但省下的是后面两年的数据治理成本。

七、不同情况下的取舍：没有全赢的方案

这一节讲取舍，因为我在评审现场听到最多的一句话是”这个我们都要”。立项管理里没有”都要”。

1. 评审速度 vs 决策质量

完整的评审流程，从申报到决策需要 15-25 天，能覆盖更多信息。快速通道 48 小时出结论，但只能做门槛校验，无法充分评估收益证据。

我的建议不是二选一，而是分配。用年度弹性产能的 15%-20% 专门承接快速通道项目，剩余 80% 走完整流程。关键是弹性产能要有额度上限，否则它会吞噬掉整个流程。

2. 透明度 vs 组织现实

完全透明的评分和资源视图，理论上最优，但在一些组织里会引发部门之间的直接对抗。我见过一家企业把所有项目的评分在全员群里公示，第二周就有三个部门负责人去找 CEO 争论。

折中方案是：评分过程对评委透明，评分结果对项目负责人透明，组合视图对管理层透明，但不做全员公示。透明度的目的是防止暗箱操作，不是制造比较压力。

3. 集中决策 vs 授权

集中决策能保证口径统一，但会形成瓶颈；授权能提升响应速度，但容易失控。

我建议的判断标准是资源占用规模。低于某个阈值（我常用 200 人天）的项目，由业务线自主决定，只做事后备案；超过阈值的走集中评审。这个阈值随着组织的资源紧张程度调整，资源越紧张，阈值越低。

4. 定量 vs 定性

纯定量的评分卡在战略类项目上会失效，因为战略项目的收益往往无法量化；纯定性的讨论则容易被声音大的人主导。

我的做法是分层：用定量方法处理资源占用和证据等级，用定性讨论处理战略价值和取舍顺序。不要试图给”战略意义”打分，那只会产生无法验证的数字。

5. 工具 vs 流程

最后一条取舍最重要。工具是流程的固化器，不是流程的替代品。流程没跑通就上工具，等于把混乱自动化，结果只会更糟。

我给的建议顺序是：先用 Excel 或共享文档把门槛、分桶、重排跑 2 个季度，确认机制有效；确认后再迁移到专业平台，把这些规则固化下来。反过来做的企业，我见过不止一家，都在半年内放弃了工具。

八、下一步：30 天内可以做完的五件事

这篇文章的框架不小，但落地不需要等一年。如果你认同前面的判断，我建议按这个顺序在 30 天内做完五件事。

1. 第 1 周：清点存量。把所有”进行中”的项目拉出来，标注最后实质进展日期。超过两个季度没有进展的，全部标为待终止。这一步不需要任何人同意，PMO 自己做就行。
2. 第 2 周：确定四道门槛。把合规、安全、技术可行性、资源可得性从评分卡里摘出来，做成通过/不通过的前置检查项。这一步需要合规和架构负责人各出一个人。
3. 第 3 周：统一人天口径。把 5 个研发团队下两个季度的有效产能录入，作为 P0/P1 的资源上限。这一步完成后，你会第一次看到真实的产能缺口。
4. 第 4 周：开第一次分桶会。把项目分到 P0/P1/P2/等待池，重点是当场确认 P0 的承接团队和起始月份。确认不了的一律进等待池。
5. 持续动作：把季度重排写进日历。每季度第一周，2 小时，只做降级和终止，不新增项目。这一条最容易做，也最容易被取消，所以要用日历硬锁。

最后回到我自己的判断。立项优先级这件事，真正的难点从来不是”怎么排”,而是”怎么把已经立项的项目停下来”。排序是技术问题，终止是组织问题。我见过所有把这件事做成的企业，共同点不是评分模型多精巧，而是管理层愿意在每个季度花 2 小时，面对一份写着”这个项目我们做不下去了”的清单，并且签字。

如果你现在只能做一件事，就做那件：在下一次评审会上，要求每个 P0 项目当场确认承接团队和人天。确认不了的，让它进等待池。这个动作不需要任何工具，不需要任何预算，而且当天就能看到效果，你会立刻知道，你真正能做的项目，到底有几个。