如果说专业技能决定了一件事情能不能”做”，那么职场软实力决定了一件事情能不能”成”。「职场系列」的内容源于我的真实经历及引发的思考，记录的是我关于职场软实力的思考和感悟。
在我的观察中，身边不少人时常会发生这样的抱怨：
- 为什么业务方需求做不完，越做越多，越做越紧急？
- 为什么我们一直在到处救火？
- 怎么年初定的方向规划，半年过去了还没开始？
- 永远是被别人驱动做事情
这样的情况显然对团队、个人、服务的业务方都是不利的。当然，在业务发展初期或某些特殊情况下是存在这样的情况，但团队如果长期停留在这样的状况下，一定是某个环节出了问题。今天我们从事情优先级的角度，来聊一聊作为 TL，应该如何决定一件事情的优先级。
四象限法则
下图是我们经常听到的一个四象限法则，这个法则给了我们两个非常好的维度，「紧急程度」和「重要程度」来帮助我们做判断。
理论上讲，我们只要将要决定的事情按「紧急程度」和「重要程度」归类，就可以放入对应的象限。对于这四个象限，优先级可以这样划分：
- 「重要且紧急」对应高优先级
- 「不紧急不重要」对应低优先级
- 「紧急不重要」和「重要不紧急」对应中等优先级（但我们更期望做「重要」的事情）
多数人犯的错误
两大类错误：
- 决策者进行决策时，对事情本身的性质没有判断清楚，即「紧急程度」和「重要程度」出现判断偏差
- 决策者对事情在未来的发展趋势没有判断清楚，即没有看到一件事情的性质在未来可能会发生改变
举例如下：
- 紧急程度判断错误：例如在面对强势业务方时会更倾向于将事情定为「紧急」
- 重要程度判断错误：例如项目前期调研不够充分，以偏概全，错误地将”小需求”当成”大需求”
- 未看到事情发展趋势：例如基础服务即将大规模上量时，没有看到潜在的维护成本，迟迟不建立高效的运维工具，使用人工成本进行填充
- ….
什么是重要 & 紧急？
重要的事情，即是和团队当前阶段发展方向和目标一致的事情，重要程度的衡量标准，是这件事情能多大程度上为当前阶段的长期目标而服务。
以基础架构的视角为例，早期更多是以支撑业务需求，帮助业务上手基础服务软件为主；中期更多是通过场景深入、性能优化等手段，扩大基础软件服务的影响范围，在已有用户基础上进一步做技术的沉淀和支持，并逐步拓展到更多的业务方；成熟期是以稳定性为主，保证服务的 SLA，让用户对产品能够完全信任，并成为公司内部某一场景的事实标准。
紧急的事情，是指在短期内，会对当前团队和方向产生根本性影响的事情。
这里的”根本性影响”包括方向影响力的影响、团队长远利益的影响等，比如丢失某行业的标杆客户，损害团队的信誉度等。紧急程度的判断需要团队从自己的视角去看问题，以促成全局利益最大化为目标，而不是完全的”自私”或者”有求必应”。事实上，如果你的团队是提供基础服务，可想而知如果从问题反馈方的角度出发，那么大多数问题都会被业务方定义成紧急问题，这样显然是不合适的。
应该怎么做？
明确当前阶段的长期目标
明确当前阶段的长期目标是确定事情重要程度的前提。这个长期目标一定是清晰的、上下达成一致的、不轻易变化的、经过深思熟虑的产物。
仍旧以我所在的基础服务团队为例：
某团队在早期为了打磨基础软件的场景多样性，来自各个业务方的需求几乎做到了”有求必应”，设计了大量的 API 和功能模块。后期随着业务规模增大，产品使用逐渐上量，大量 API 和功能模块逐步成为了该团队的运维负担，并且每一次迭代都比上一次要更加地困难，最后出现了”干的越多，错的越多，团队越辛苦，反而越没产出”的情况。
那么上述的情况如果继续恶化下去，问题数量将会和使用的业务规模呈正比，最后只会有两个结果：业务规模上不去，或者运维能力跟不上。早期将”支持业务需求”作为重要的事情，是符合早期的发展目标，但后期阶段的发展目标，应该是在已有用户和业务的基础上，全力将系统打磨好，这里包括系统级别的重构、降低运维压力、制定标准等。
退一步考虑事情
我观察到尤其是工作经验不长的同学，考虑事情喜欢直接上手就干，头脑一热就忽略了时间成本和工作的 ROI。实际上，只要不是拍脑门的决策，大部分事情经过一些思考后，就会发现其实并没有这么的紧急。更多情况下，是一个将事情在多方团队利益下权衡好的一个工作。很多事情往往不是今天非做不可，或是这周非做不可，如果退一步，用更多的时间换一个更好的方案，对于团队、合作方、业务、以及多方信任度和影响力都达成了一个多赢的局面。
从自身方向/团队角度出发，我在判断事情时，更多时候会问问自己：
- 这件事情提出是要解决什么问题？最佳的解决方案是什么？
- 这件事情今天做、下周做、下个月做，区别是什么？
- 工作能否适当拆解，尽可能减少需要赶工期的事情？
- 如果是协同项目，是否影响到其他团队的工作安排？
- 是否影响团队/方向在受损业务中的信誉度和影响力？
- ….
使用长期思维
上面四象限的法则里，提到的四类事情，在未来是有可能发生相互转换的：
- 「不紧急不重要」，未来某一时间会变成「紧急不重要」
- 「重要不紧急」，未来某一时间会变成「重要且紧急」
- 「紧急不重要」，某些条件下（如反馈增多）会变成「重要且紧急」
- 「不紧急不重要」，某些条件下（如反馈增多）会变成「重要不紧急」
这里的长期思维指的是结合未来可能出现的情况，在当下做一个较合理的判断。 举一个项目管理中常见的错误：
很多团队在做 sprint 规划时，会将事情分为 P0/P1/P2 三个优先级，由于 P0 和 P1 都是需要高优完成，所以会造成 P2 的数量随着时间越来越多。然而，这些 P2 级别的事情是真实存在的，并不会因为排不上优先级而消失，并且随着反馈增多、规模扩大，这些问题的量变可能引起质变，如果不及时看到风险并且收敛，会让一个团队在未来四处救火，变成一个兜不住事情的 “筛子”。
这里有一些分工管理上的小建议：
- 今天选择不做某事时，想想未来是否需要做，以及未来会以什么形式来做；
- 定期 Review 方向内部的遗留问题，同类问题及时归纳，发现有爆发的趋势时提前干预介入，解决掉潜在风险；
- 发现团队有”到处救火”的现象时进行反思，并及时摆脱这种困境；