急迫性/重要性矩阵
Urgency–importance matrix
用急迫性和重要性两个维度判断任务或问题的优先级。
多个任务争抢有限时间，需要结合目标和实际期限讨论先后顺序时使用。重要性应对应当前角色和目标。
任务、期限依据、目标影响、可用时间及必须履行的职责。
带理由的处理顺序、待协商安排和需要重新评估的任务。
先理解，再动手
使用步骤
重要性依据目标贡献与不做的后果，急迫性依据真实期限与时间压力；分别判断后再安排、委派或减少。每项任务保留分类依据。
- 01
列出待处理事项
- 02
分别评估急迫性和重要性
- 03
放入四象限
- 04
对高重要事项安排资源，对低价值事项减少占用
- 05
定期复查分类是否变化
象限不自动授权取消或委派任务。先确认职责、同事容量和承接意愿；个人可用工时不代表团队总工作量。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
急迫性/重要性矩阵 · 空白提纲 什么时候用：多个任务争抢有限时间，需要结合目标和实际期限讨论先后顺序时使用。重要性应对应当前角色和目标。 需要准备：任务、期限依据、目标影响、可用时间及必须履行的职责。 预期产出：带理由的处理顺序、待协商安排和需要重新评估的任务。 使用边界：象限不自动授权取消或委派任务。先确认职责、同事容量和承接意愿；个人可用工时不代表团队总工作量。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：需要立即处理什么，截止时间及后果是什么？ 1. 重要且急迫： 填写说明：要为长期目标预留哪些时间？ 2. 重要不急迫： 填写说明：哪些可协调或委派，交接如何确认？ 3. 急迫不重要： 填写说明：哪些可以减少或取消？ 4. 不急迫不重要： 检查清单 □ 急迫性与重要性没有混为一谈。 □ 优先事项数量被控制。 □ 高重要低急迫事项被纳入计划。 考虑下一个框架 PERT图: 优先任务已经选定，但完成顺序受前置条件影响时，用 PERT 梳理依赖、估算路径和排程风险。 https://bizthinkframe.com/zh/frameworks/pert-chart BizThinkFrame · https://bizthinkframe.com/zh/frameworks/urgency-importance-matrix
跟着案例走一遍
虚构教学案例给项目经理的一周排优先级
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
星港企业服务组同时处理系统上线和日常内部支持。
经理总在回应催促，影响季度交付的风险无人处理。
手头有哪些材料
- 周一规划本周可投入的管理时间，共12小时
- 上线故障、备份演练、例行统计和会议邀请同时出现
如何使用这个框架
- 先以客户影响和季度交付目标判断重要性，再判断截止时间。
- 把备份演练从“以后做”改成日历中的固定安排。
- 委派时同时说明完成标准，避免只把压力转给他人。
计划将 12 小时管理时间分为故障 4 小时、演练 2 小时、上线风险 4 小时和检查委派 2 小时，不代表已执行。
放进象限前，先核对目标、截止与容量
第一，没说清目标与本人职责时，先别分类。对经理较次要的请求，可能是同事必须履行的重要工作。说明它对客户、交付、安全或既有义务的影响，让别人能够核对重要性，而不是按催促者级别或消息数量判断。
第二，紧急需要真实的截止、依赖与延误后果。被反复催问本身不是截止日期；没人催的合规或运维义务也可能有硬时限。矩阵用于讨论取舍，不能因为某项看起来不显眼就授权忽略义务。
第三，没有容量与交接同意时，计划应暂停。把卡片移到“委派”不会自动产生别人的时间；接收人的工作量与经理检查时间必须分开。线上事故已有升级程序时，应先按程序处置，不能为争论象限而拖延止损。
优先级、排期与分工回答不同问题
矩阵保留重要性和紧急性两种判断，不估工期，也不给同象限的任务自动排名。下一次决定需要不同产出时，再选下表的方法，不必全部走一遍。
| 材料与问题 | 方法 | 产出及边界 |
|---|---|---|
| 任务、目标与真实截止时间 | 急迫性／重要性矩阵 | 讨论行动类别；不自动分配资源。 |
| 多个可行方案及明确标准 | 决策矩阵 | 说明取舍依据；分数不是历时。 |
| 活动、估时、依赖与人员 | 甘特图 | 检查排期冲突；估计仍需确认。 |
| 已有工作，但执行与批准角色不清 | RACI矩阵 | 与相关人澄清角色；不自动取得委派同意。 |
星港的一周：把12小时管理投入真正算清
以下是完整的虚构教学材料：经理周一盘点，本周可安排管理时间共12小时；拟用4小时当天组织修复登录故障，2小时周三做备份恢复演练，4小时检查上线风险，另留2小时检查拟交给值班同事的重复统计。还计划取消一次没有议题的例会。实际投入、故障恢复时点、交接接受与完成结果都未给定。
先看后果：登录故障已经影响服务；备份恢复与上线风险工作则是在未来事故之前保护交付，因此即使没有当下催促，也需要进入日历。演练并非永远“不紧急”，如果截止变化或备份失败，分类就可能改变。把当前依据和时间一起写在任务旁。
再算经理投入：4＋2＋4＋2＝12小时，给定管理容量已经排满，没有在这12小时内留下机动时间。这是计划暴露出的风险，不是已经加班的事实。不能自创备用额度，也不能把“组织修复4小时”理解为所有技术修复只需4小时，统筹与实际修复是不同贡献。
| 工作与拟定动作 | 依据 | 需要确认 |
|---|---|---|
| 登录故障：当天组织，4小时 | 服务已受影响 | 按事故程序，确认技术负责人。 |
| 周三演练2小时，上线风险4小时 | 在事故前保护交付 | 保留日历时间，约定具体产出。 |
| 重复统计拟交接，经理检查2小时 | 标准工作可能转交 | 同事确认范围、容量与完成标准。 |
| 无议题例会拟取消 | 当前目的不清 | 先核对取消权限与既有义务。 |
复查实际选择，不凭排满日历宣布高效
结论是一份内容齐全但容量排满的提议。向值班同事说明统计范围、模板和质量要求，记录本人是否接受；若不能承接或时间不足，就重开安排。会议也要等有权者实际决定后才算取消。材料没有会议时长，不能计算节省多少小时。
拟周五复查时，分别对照四项计划与实际管理投入，并核对事故状态、恢复证据、已检查的上线风险和被接受的统计产物。记录插入事项与未完工作。预约日历不等于交付，动作完成也不等于上线安全；若要说事故减少，另需可比记录和观察期。
最后追问预防性工作为什么被保护或挤掉。临时急事可能确实合理，下一周应改的也许是升级路径或容量预估。保留周一分类，再追加后续变化，避免事后把所有完成的事都改成“重要”，失去复查价值。
检查你的思考
再问自己几个问题
- 如果不马上处理，会出现什么后果？
- 这个事项对长期目标的贡献有多大？
- 哪些紧急事项其实来自前期规划不足？
完成前的检查清单
- 急迫性与重要性没有混为一谈。
- 优先事项数量被控制。
- 高重要低急迫事项被纳入计划。