企业管理的108个问题 · 第90问

上一问我们聊了敏捷开发方法是否适用于非IT团队（第89问），核心结论是：敏捷不是程序员的专利——但需要”本地化”调整，不能照搬。

但不管是敏捷还是传统瀑布——你都会遇到一个”老问题”：

事情太多，时间太少，什么都想干——最后什么都干不好。

这就是项目优先级排序的问题。

你一定经历过这样的场景：老板说”A项目很重要”——市场部说”B项目很紧急”——客户说”C项目不能拖”——技术说”D项目再不修要出大事”——团队只有10个人——但”重要的事”至少有20件。然后——每个人都在”救火”——做不完的——加班——加完班——抱怨——再下一轮。

不解决优先级排序的问题——再”敏捷”也敏捷不起来。

一、为什么”排序”这么难？

不是”你排不好优先级”——是”这事本身就很难排”。

原因一：所有的”优先级”，都是”站在不同立场”的结果

老板的优先是”赚钱”，销售的优先是”客户催最急”的，市场的优先是”品牌影响力”，技术的优先是”降低技术债务”，财务的优先是”省钱”——没有一个人是错的。但资源是有限的——当所有”正确的事”放在一起——就变成了”冲突的事”。

排序的本质不是”谁对谁错”——是”在有限资源下，做最有价值的选择”。

原因二：紧急≠重要——但我们经常”混为一谈”

大多数团队被”紧急”牵着走——忽略了真正”重要”的事。团队一直在”救火”——但火越救越多——因为”防火”（重要但不紧急）的事没人做。

原因三：排序的结果——意味着有人要”被拒绝”

说”A优先”——就等于说”B靠后”。很多人宁愿”全都要”——也不愿意”排序”。但”全都要”的结果——就是”全都没做好”。

二、四个”实战优先级排序方法”

方法一：Eisenhower矩阵——简单、直接、够用

把任务按”紧急”和”重要”分成四个象限：

方法二：RICE评分法——用”分数”说话

RICE = Reach × Impact × Confidence / Effort

操作： 把项目打分 → 算分数 → 从高分到低分排序 → 先做高分项目。

方法三：WSJF（加权最短作业优先）——“增量价值最大化”

不是”哪个项目总价值最高”——而是”哪个项目单位时间价值最高”。

WSJF = 商业价值 / 工期

一个总价值40万但工期仅0.5个月的项目（WSJF=80）——比一个总价值200万但工期5个月的项目（WSJF=40）——优先级更高。先把”短平快”的做完——释放能力——再做大的。

方法四：Kano模型——“用户角度看优先级”

三、一个”组合排序流程”

Step 1： 把”必须做”（合规、安全、已承诺）和”可选做”分开
Step 2： 用Eisenhower矩阵做初筛——砍掉三四象限
Step 3： 用WSJF做精排——从分数最高的开始做
Step 4： 用Kano模型验证——别让”基本型需求”排到后面

四、优先级管理的”组织机制”

1. 一个”优先级决策委员会”：3-5人核心管理层，每月一次
2. 一个”唯一受控的项目清单”：所有项目必须进清单，不进不给资源
3. 预留”20%缓冲”：永远不排满100%资源，给突发任务留通道

五、最后的话

优先级排序——不是”怎么把清单排好”——是”怎么勇敢地说不”。

一个团队能否成功——不取决于”做了哪5件”——而取决于**”果断放弃了哪5件”**。

排序的本质不是”选对的”——是**”放弃对的、去做更对的”**。

好的优先级——不是”所有人都满意”——而是”所有人都清楚：为什么这么排”。

做一个清醒的决策者——而不是”什么都想做、什么都做不好”的忙碌者。 🎯

明日预告：第91问 —— 项目复盘该怎么做才能真正提炼经验？