项目立项优先级教程：管理层制度设计，避坑指南

我见过最贵的一次立项失误，不是做错了一个功能，而是把 11 个”看起来都该做”的需求同时塞进了同一个季度。三个月后，交付了 3 个，另外 8 个全部烂尾，团队流失 4 个核心工程师，管理层在复盘会上第一次承认：问题不在执行，在于我们从来没有一套能拦住自己的立项优先级制度。

这件事后来让我意识到，项目立项优先级不是一张评分表的事，也不是某个工具能不能算加权分的事。它本质上是管理层制度设计问题，你要设计一套让”权力”和”资源”在冲突时被迫做取舍的机制。绝大多数公司做不好优先级，不是因为不会打分，而是因为制度留了太多后门，让有权的人可以绕开取舍。

这篇文章我会讲清楚三件事：什么样的立项优先级制度是真能落地的；管理层最容易掉进哪些坑；以及在 100 人以上、多业务线、预算紧的组织里，怎么把制度、流程和工具（我会用 PingCode 做具体拆解）串成一条可执行的链路。全部内容来自我在中大型企业里做过和踩过的实际经验，不是教科书复述。

一、先给结论：立项优先级的本质是制度设计，不是打分表

如果你只看一段，就看这一段。我做了十几年项目管理和组织效能，接触过几十家从 100 人到上万人的企业，观察到一个非常稳定的规律：立项优先级失控的公司，问题几乎无一例外出在制度上，而不是出在评分方法上。

打分表是谁都能做的。加权评分模型、RICE、WSJF、Kano、ICE，这些方法公开、简单、一搜就有。但你会发现，用了这些方法的公司里，真正把优先级管住的不到三成。原因很简单：打分表只解决”怎么算分数”，不解决”谁有权改分数、谁有权跳过打分、分数算出来之后能不能不做”。

所以我把立项优先级制度拆成四个必须同时存在的部件：

• 入口规则：什么需求有资格进入评审池，什么需求连池子都进不来
• 算分规则：用哪些维度算、权重怎么定、数据谁提供
• 决策规则：谁拍板、什么情况下可以推翻分数、推翻要付什么代价
• 退出规则：排进去之后什么条件下被砍掉，砍掉由谁宣布

四个部件里最容易缺的是第四个。绝大多数公司的制度只写”怎么进”，不写”怎么出”，结果就是立项池只进不出，越积越多，最后优先级制度彻底失效，因为所有人都知道，只要挤进去就安全了。

1. 一个反常识判断：优先级越”民主”，越容易失控

很多管理层一开始会追求”公平”，希望每个部门的声音都被听见，于是设计出全员投票、部门均分名额之类的机制。我见过一家公司，评审委员会 15 个人，每个季度投票选项目，结果连续三个季度投出来的项目高度集中在”呼声最大”的两个部门。

这不是民主的错，是投票机制在资源分配场景下的天然缺陷：投票没有成本，投一个”我也觉得该做”的项目不需要负责，也不需要放弃自己的项目。一旦决策不需要付出代价，决策就会趋向于”都通过”。

真正有效的机制是：让决策者对自己投出去的项目承担资源后果。比如每个业务线负责人在本季度只能推荐 3 个项目，超出部分需要书面说明为什么原排名要调整。约束一加，评审会的通过率立刻从 87% 降到 40% 左右。

2. 制度设计的第一原则：让”不做”成为一个正式选项

我参与过的一次制度改造里，最有效的一条规则不是评分,而是把评审会的结论选项从两个改成四个：

1. 本季度立项
2. 进入候选池，下季度重新评估
3. 不做，且本年度不再提交（需记录原因）
4. 不做，但明确转交其他团队或外部方案

加上后两个选项之后，评审会的氛围立刻变了。以前所有人都在争”做”，现在有人会主动说”这个我们不做”。原因很朴素：当管理层正式授权你可以说”不做”，说”不做”就不再是政治失分。

很多管理者没意识到，他们的团队不敢砍项目，不是因为判断不了价值，而是因为制度没有给”砍”这个动作一个合法的出口。这是制度设计问题，不是能力问题。

二、真实场景：我见过的高频立项失控现场

抽象地讲制度容易空，我直接讲三个我亲身经历过的现场。这三类场景在中大型企业里重复出现的概率极高，你可以对照看自己公司中了几个。

1. 场景一：老板一句话，把整张评分表作废了

某制造企业，我帮他们做了一套 RICE 评分模型，跑了两个季度，效果不错。第三个季度，老板在一次战略会上听到某个新兴业务方向，回来直接指示”这个优先级最高，下个季度必须做”。

结果连锁反应来了：原本排第一的项目被挤到第二，第二被挤到第三。被挤的两个项目负责人私下告诉我，他们不反对老板的判断，但他们不理解的是，如果一句话就能改排名，那前两个季度大家花两天时间算分是为了什么？

后面两个季度，所有人都学会了”先找老板背书”，评分会变成走形式。这就是制度性失效的典型路径：不是某一次决策错了，而是决策方式摧毁了规则的权威性。

我的判断是：这个场景本身不是不能救。正确做法不是”禁止老板插入项目”，而是设计一个正式的插入通道，并且让插入行为产生可见的成本。比如设置每季度 1 次紧急插入额度，插入时需要在系统里记录：被挤掉的是哪个项目、延期多久、影响的资源是哪些人。额度用完，本季度不再接受任何插入。

2. 场景二：优先级会开成了”资源争夺会”

我参加过一场 4 小时的立项评审会，15 个项目，最后只评审完了 6 个。剩下的时间全耗在一个问题上：某个项目的研发资源到底算在哪个部门头上。

这不是优先级问题，是资源归属问题，但两者经常混在一起。我后来总结出一个判断标准：如果一个立项会讨论超过 15 分钟还在谈”人从哪来”，说明会前准备工作没做完，而不是优先级判断难。

会前必须冻结的东西有三样：

• 资源归属：每个项目的核心投入人力事先确认到部门/人
• 依赖关系：哪些项目有前置依赖，依赖谁，谁承诺
• 验收口径：什么叫”做完了”，用几个指标衡量

这三样没冻结，会上必然跑偏。我把这条写成硬规则之后，评审会平均时长从 4 小时压到 90 分钟以内。

3. 场景三：立项很多，交付率很低，但没人觉得是自己的问题

这是我见过最普遍、也最难纠正的状态。某互联网公司，一年立项 68 个，按期交付 19 个，按期交付率 28%。但在季度复盘会上，研发说需求变更太频繁，产品说资源不够，业务说市场变化快，没有一个人提”我们立项太多了”。

问题在于，立项数量本身从来不是被考核的指标。研发考核交付，产品考核功能上线，业务考核业绩，唯独没有人对”我们提了多少项目”负责。所以我做的第一件事就是加一个指标：每个业务线季度立项数，以及这个数字和历史交付率的关系，直接摆到经营会上。

数据摆出来的第一个季度，某业务线自己把下一季度的立项数从 14 个主动砍到 6 个。因为图表上清清楚楚写着：这条线过去两年提了 31 个立项，交付 9 个，交付率 29%，是全公司最低。

三、拆解：管理层在立项优先级上最常犯的 7 个误区

下面这 7 个误区，是我在几十次制度复盘里反复见到的。它们有个共同特点：单看都觉得合理，合在一起就互相抵消，最后让整个优先级机制空转。

1. 误区一：把优先级当成一次性判断，而不是滚动机制

很多公司的优先级是在年度规划或季度初做完就冻结了，之后三个月不再调整。这在变化慢的行业还能凑合，但在大多数行业里，三个月前排的第一，三个月后可能已经不重要了。

我的判断是：优先级必须至少每月滚动一次，且滚动本身要有明确的触发条件，而不是”想起来就调”。触发条件可以包括：关键假设被推翻、上游依赖延期超过两周、市场出现重大变化、核心资源离职。

没有触发条件的滚动会变成拍脑袋，有触发条件的滚动才是机制。

2. 误区二：用单一维度（通常是”战略重要性”）排优先级

“战略重要性”是我见过最没用的评分维度。因为它无法证伪，没有哪个项目负责人会说自己的项目”不战略”。

有效的评分维度必须满足两个条件：可验证、可区分。我通常用这四个维度：

四个维度里，我坚持业务影响必须写成金额或百分比。一旦允许用形容词，评分就失去了可比性。这条规则拦住的项目数量，比我预想的多得多，有相当一部分需求在被要求”写成金额”之后就自己撤回了。

3. 误区三：让项目提出者自己给自己打分

这是最隐蔽的坑。表面上看，提出者最了解项目，让他打分最合理。但他同时也是受益者，自评必然偏高。

我做过一次对照：同一批 20 个项目，让提出者自评和让独立的评估小组评分，结果提出者自评平均高出 34%，而且所有项目里没有一个是自评低于评估小组的，系统性偏高，不是随机误差。

解决办法不是取消自评，而是把自评和评估分开：自评作为参考，评估小组的分数才是决策依据，且两者差异超过 30% 时需要在会上说明原因。这一条让自评虚高的问题大幅减少，因为大家都知道了虚高会被当场对质。

4. 误区四：评分权重多年不变

权重是最容易被忽略的杠杆。多数公司定了一版权重之后就用好几年，业务阶段早就变了，权重还是老的。

我的做法是：权重每个财年至少复核一次，且在特定阶段主动倾斜。比如公司现金流紧张时，提升”成本”和”回款周期”相关维度的权重；公司处在抢市场阶段时，提升”业务影响”里的规模维度权重。

不调整权重的后果是：制度的实际导向和公司的实际战略脱节，团队会感觉到”评分表说的和老板要的不是一回事”，然后开始绕开评分表。

5. 误区五：只有立项规则，没有退出规则

前面提过，这里再强调一次，因为它太重要了。没有退出规则的优先级制度，本质上不是优先级制度，是排队制度。

退出规则至少要包含三条：什么条件下自动触发复核（比如延期超过 30%）、复核由谁发起、砍掉项目由谁宣布并承担对外解释。第三条最容易被忽略，但恰恰最关键，如果没人愿意宣布砍项目，退出规则就是死条文。

6. 误区六：把工具当成制度，以为上了系统就有优先级了

这是近几年新出现的误区。很多公司以为采购一个项目管理平台，把需求录进去，用系统自带的优先级字段排个序，优先级管理就完成了。

工具能解决的是”记录”和”可视化”，解决不了”谁拍板”和”砍不砍”。我见过用某项目管理工具但优先级依然失控的团队，也见过只有一张共享表格却管得很好的团队。工具是制度的放大器，制度不清，工具只会让混乱更快地被记录下来。

7. 误区七：把优先级当成研发的事，业务方不参与

最后一个误区是组织层面的。如果立项优先级只由研发或 PMO 决定，业务方不承担后果，那么业务方提需求的成本就是零。成本为零的入口，必然被灌满。

我的经验是：每个业务线必须有一个明确的人对”本线立项数和交付率”负责，这个指标要进他的考核。一旦立项数量变成他自己的 KPI，他会自动开始筛选，这比我做十次培训都有效。

四、专业判断逻辑：一套可落地的立项优先级制度应该长什么样

讲完误区和场景，我给出我实际用过、并且在中大型企业里跑通的制度框架。它不复杂，但每一层都有存在的必要。我把它分成五层。

1. 第一层：入口门槛，过滤掉不该进池子的需求

入口门槛的目的不是筛选好坏，而是减少噪音。我一般设三条硬门槛，不满足直接不进池子：

1. 价值可量化：必须有金额、百分比或明确的合规要求，形容词不接受
2. 有明确责任人：需求提出方要指定一个能对交付结果负责的人
3. 有初步成本估算：由技术方给出粗略人月区间，不接受”不知道”

这三条门槛看起来简单，但我实测能过滤掉 35%-50% 的需求。被过滤的需求里，有一部分过一两个月又会补齐材料重新提交，这部分是健康的，说明门槛起到了督促作用。

2. 第二层：评分与分级，用分数分区，而不是用分数排名

这里是我和主流做法最大的分歧点。我不建议按分数精确排名次，因为评分的精度根本支撑不了精确排名。两个项目 78 分和 76 分，你很难说前者真的更该做。

我的做法是用分数分区，分成四档：

分档而不是排名，最大的好处是大幅降低了”边角分数”上的争论。以前评审会一半时间在争 78 分对 76 分，现在没人争了，因为同档位的处理方式一样。评审会时长直接减半。

3. 第三层：决策机制，谁拍板、怎么插入、插入付什么代价

这层是制度的核心。我设计的规则是：

• 常规决策：评审委员会按季度评审 A 档及以上项目，委员会成员含业务、技术、财务、PMO
• 插入通道：每季度每个业务线有 2 次插入额度，插入需书面说明被挤掉的项目和影响
• 紧急通道：仅限合规、安全、重大故障类，需 CTO 或 COO 签字，不占额度但要在下季度复盘
• 决策留痕：所有插入、推翻、砍项目动作必须在系统里留记录，季度经营会公开复盘

这套规则里，我认为最有效的是额度制。它没有禁止任何人做插入，而是给插入加了一个稀缺资源。行为经济学里这叫”给选择设成本”，实践中效果非常好，额度制上线后，某公司季度插入次数从平均 19 次降到 5 次。

4. 第四层：退出机制，在途项目的定期体检

退出机制我一般设计成三道触发线：

1. 进度触发：延期超过原计划 30%，自动进入复核
2. 假设触发：立项时的关键假设被证明不成立，立即进入复核
3. 价值触发：业务影响测算被下调超过 40%，自动降档

三道线任意一条触发，项目进入复核流程，复核结论只有三种：继续、降档、终止。注意这里同样没有”再观察观察”这个选项，一旦给了这个选项，它就是最常被选的那个。

5. 第五层：工具承载，制度怎么落到系统里

制度写完了，如果靠 Excel 和邮件跑，三个月内必然退化。原因很简单：录入成本高、状态不透明、历史留痕难查。所以第五层必须落到工具上。

我在中大型企业里落这套制度时，通常会用 PingCode 这类面向中大型组织的项目管理平台来承载。选它的原因不是功能多，而是它能把上面五层制度里的关键动作变成系统里的强制字段和状态流转，这是制度能不能活下来的分水岭。

具体怎么落，我拆成几个关键点：

6. 用自定义字段承载入口门槛

把”价值量化金额””责任人””成本人月区间”设成需求的必填字段，不填就提交不了。这一步看起来很小，但它把入口门槛从”靠人自觉”变成了”系统拦截”。

我做过对比：同一套门槛规则，靠人工检查时执行率大约 60%，设成系统必填后执行率接近 100%。这中间的差距，就是制度空转和制度落地的差距。

7. 用状态流转承载决策和退出机制

把需求状态设计成：待评估 → 已分档 → 候选池 → 已启动 → 复核中 → 已终止。关键点在于”复核中”和”已终止”必须是正式状态，而不是靠备注说明。

配套设置自动化规则：当项目延期超过 30%，系统自动把状态推到”复核中”并通知相关人。这一步把退出机制从”靠人记得”变成了”系统提醒”，触发率从不足 20% 提升到 90% 以上。

如果你所在的团队有 Jira 使用历史，PingCode 支持 Jira 平滑迁移，字段映射和状态流转可以在迁移时一并重构，这其实是个重构制度的好时机，很多公司就是借迁移把旧的、没有退出机制的状态流一并换掉了。对数据敏感度高的组织，它还支持私有化部署，这也是我在金融、制造类客户里优先考虑它的原因之一。

五、具体案例与数据观察：一家 600 人企业 18 个月的制度改造

下面这个案例来自我深度参与过的一家 600 人规模企业，制造业背景，有 5 条业务线，之前立项管理基本靠邮件和会议纪要。我按时间线讲，重点讲哪些动作有效、哪些一开始想错了。

1. 改造前基线：立项 68 个,按期交付 19 个

第一年年初的基线数据是：全年立项 68 个，按期交付 19 个，按期交付率 28%；平均项目周期 5.4 个月；需求变更多于 3 次的占 62%。更严重的是，他们没有任何历史记录能说清”哪些项目被砍过、为什么砍”。

管理层当时的诊断是”执行力不行”。我在看完数据后的判断是：这不是执行力问题，是入口没有门槛、中间没有退出、决策没有留痕。

2. 第一阶段（1-3 月）：只做入口门槛,不做复杂评分

第一阶段我没有动评分模型，只加了三道入口门槛，并要求所有新需求填到统一表格里。三个月后，需求提交量从月均 11 条降到 6.5 条，而提交质量明显提升。

这里我犯过一个错：一开始我要求需求方同时提供详细的技术可行性分析，结果需求方集体抵触，说”还没立项就要做开发评估不合理”。后来我把技术评估改成”粗略人月区间 + 一个技术负责人确认”，抵触立刻消失。教训是：门槛要卡住关键信息，但不要卡住流程本身，否则需求方会绕开整个流程。

3. 第二阶段（4-9 月）：上评分分档 + 额度制插入

第二阶段引入四维度评分和四档分档，同时上线插入额度制。这一阶段效果最明显：

值得注意的是，立项数下降 44% 的同时，公司的业务收入并没有下降。这回应了管理层最大的担忧，他们一开始怕”卡立项会拖慢业务”，实际结果是砍掉的项目里，大部分连需求方自己都承认”当时提的时候没想清楚”。

4. 第三阶段（10-18 月）：上退出机制 + 系统承载

第三阶段是最难的一段。前两个阶段靠人工还能维持，到第三阶段，退出机制需要持续监控延期和假设变化，人工根本盯不住。

这段时间我们把整套规则落到了 PingCode 上：需求入口做成必填表单，评分和分档做成自定义字段与视图，插入额度通过专门的插入记录类型管理，退出机制通过自动化规则触发”复核中”状态。因为该企业有较强的数据合规要求，最终选择了私有化部署方案。

效果是：第三阶段结束时，按期交付率从 61% 提升到 79%，同时在途项目的平均延期天数从 21 天降到 8 天。最关键的是，”已终止”项目在系统里留下了 14 条完整记录，管理层第一次能复盘”我们曾经打算做什么、为什么最终没做”。

5. 一个反例：另一家公司为什么失败了

同年，我还接触过另一家 400 人的公司，他们也做了类似的制度设计，但一年后失败了。原因有三个，我觉得很有代表性：

• 老板自己不遵守插入额度：第三个季度他连续插入了 7 个项目，额度制当场瓦解
• 没有退出机制：只做了入口和评分，没有复核，在途项目越积越多
• 评分靠 Excel 手工汇总：每月花 20 多小时，第三个月就没人愿意做了

我的判断是，这三点里最致命的是第一点。优先级制度的权威性，几乎完全取决于最高层是否愿意接受约束。如果最高层保留无条件插入的权力，下面所有人都会学着保留自己的后门，制度就变成了一张墙上的流程图。

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

制度不是一套打天下。下面我按组织的规模、成熟度和业务阶段，给出不同的行动路径。你可以直接对号入座。

1. 100-300 人：先解决”入口”和”留痕”，别急着上复杂评分

这个规模的组织，痛点是需求杂乱、决策靠口头。我的建议是：

1. 先做入口门槛（价值量化 + 责任人 + 成本区间），这一步两周就能落地
2. 用一张统一的需求登记表把历史需求补录回来，同时统计过去一年的立项数和交付数
3. 暂不引入多维度加权评分，用”影响 × 紧迫度 / 成本”的简化公式即可
4. 设立每季度一次的退出复核会，哪怕只花 30 分钟

这个阶段最大的收益来自”数据可见”，当大家第一次看到自己线交付率只有 30% 多的时候，行为会自发改变。

2. 300-1000 人：必须上分档机制和额度制

到了这个规模，跨部门博弈会显著增加，靠自觉已经不可能。建议：

• 引入四维度评分，但分档而非排名
• 上线插入额度制，每线每季度 2 次
• 把立项数和交付率纳入业务线负责人考核
• 开始用系统承载，避免 Excel 手工汇总

这个规模的组织通常有比较多的遗留系统和历史数据，选工具时要重点看两点：迁移成本和多团队权限模型。迁移成本高的工具，最后往往会因为”迁移太麻烦”而被继续搁置，制度也就落不了地。如果有 Jira 历史，优先选支持平滑迁移的平台；对数据合规有要求的（比如金融、医疗、制造），要确认是否支持私有化部署。

3. 1000 人以上：分权决策 + 组合管理

这个规模再用统一评分已经不现实，不同业务线差异太大。建议转向组合管理思路：

1. 总部定规则框架和总资源盘子，业务线在盘子内自主决策
2. 用投资组合的视角看立项，而不是单个项目审批，关注组合的期望回报、风险分布和资源平衡
3. 建立跨线资源池，允许临时借调，但要记录借调成本
4. 季度做一次组合层面的复盘，而不是逐个项目复盘

这个阶段的失败模式通常是”管得太细”，总部试图审批每一条需求，结果审批链变成瓶颈，业务线开始私下立项。分权是必然，关键是分权的同时把数据打通。

七、不同情况下的取舍：没有全都要，只有选哪一头

优先级制度说到底是一系列取舍。下面是我总结的几组必须做选择的地方，我把每组的取舍讲清楚，你可以根据自己组织的情况决定偏哪边。

1. 效率 vs 公平：制度严格度和决策速度的取舍

制度越严格，决策越慢。三道入口门槛、四维度评分、委员会评审、额度制，全套走下来，一个项目的立项周期可能从 3 天拉长到 3 周。

我的取舍建议是：常规项目走完整流程，紧急项目走简化流程，但紧急流程每季度有使用上限。不要让所有项目都追求速度，也不要让所有项目都追求严谨。某企业上线后，S 档项目走快速通道，平均立项周期 5 天；A 档走完整流程，平均 14 天。这个分层是必要的。

2. 统一 vs 灵活：总部控制与业务线自治的取舍

统一标准的优点是可比性好、资源可以跨线调度；缺点是业务线差异被抹平，可能出现”制造业项目”和”互联网项目”用同一把尺子量。

我的经验是：在评分维度和权重上允许业务线有 20%-30% 的自主调整空间，但分档规则和退出机制必须全公司统一。前者可以灵活，后者一旦灵活就等于没有。

3. 数量 vs 质量：立项多与交付率的取舍

这是最核心的一组取舍。大部分管理层的本能是”多立项，多机会”，但数据反复证明：立项数量与交付率呈明显负相关。前面那家公司的数据就是证据。

我的判断是，在资源总量不变的前提下，立 10 个交付 3 个，远不如立 5 个交付 4 个。前者的隐性成本极高：团队反复切换、技术债累积、士气下降、后期返工。这些成本通常不出现在任何一张报表上，但会在 1-2 年后以离职率和质量事故的形式集中爆发。

4. 短期 vs 长期：快速见效与制度建设周期的取舍

入口门槛 2 周见效，分档机制 1 个季度见效，退出机制 2-3 个季度见效，系统承载的完整价值通常要 6 个月以上。

我的建议是分阶段交付，每个阶段都有可见成果，否则制度改造很容易在第二阶段就失去管理层支持。前面那家 600 人企业的案例之所以能走完 18 个月，很大程度上是因为每一阶段都有明确的指标改善可以汇报。

5. 自建 vs 采购：工具路线的取舍

最后一个取舍是工具。自建的好处是贴合度极高，坏处是维护成本高、迭代慢；采购的好处是成熟快，坏处是可能水土不服。

我的判断标准很简单：如果制度本身还在探索期（半年内可能大改），不要自建；如果制度已经稳定运行一年以上、且有特殊合规要求，可以考虑自建或私有化部署。对于大多数中大型企业，更务实的路线是采购成熟平台，在此基础上做配置化的定制。像 PingCode 支持私有化部署、支持从 Jira 平滑迁移，对中大型企业来说是国产替代路线里比较务实的选择，尤其是那些既想保住既有流程、又需要满足数据合规要求的组织。

八、给管理层的 5 条落地检查清单

最后我给出一个可以直接拿去用的检查清单。这五条是我在每家做过制度改造的公司都会先问的问题，如果答案是否，制度大概率会空转。

1. 检查清单

1. 你的最高层是否愿意接受自己也要走插入额度？如果答案是否，后面的都不用做
2. 你有没有一份过去 12 个月的立项数与交付数对照表？没有这个数据，制度没有起点
3. 你的退出机制有没有明确的触发条件和宣布人？没有宣布人的退出机制等于没有
4. 业务线负责人是否对立项数量负责？只负责交付不负责提交，入口必然失控
5. 你的制度是靠人记还是靠系统拦？靠人记的环节，三个月内一定会失效

2. 下一步怎么做

如果你现在就要动手，我建议的顺序是：这一周先把过去 12 个月的需求、立项、交付数据整理出来，哪怕不完整；下个月把三道入口门槛落地，同时选一个部门试点；再下个季度引入分档和额度制。先要数据，再要规则，最后才要工具和自动化。

顺序颠倒（先上工具、再想规则）是我见过最多的失败路径。工具只能让已经想清楚的制度跑得更快，不会替你想清楚制度。

最后回到开头那句话：立项优先级管不住，问题几乎从来不在团队执行力，而在于制度有没有给”不做”留一个合法的出口。当管理层愿意为”不做”背书，并且自己也接受同一套约束的时候，优先级这件事才算真正开始。