优秀的开发者学会了区分二者之间的不同，但这只是容易的部分。
难点在于当业务部门中的某个人要求你紧急完成某事，但那件事并不是最重要的时候。在这种情况下，如何处理紧急但不重要的任务是一条难以走稳的细绳。
随着你的职业生涯变得更加高级，这种细绳变得更加重要。
我以前曾经写过关于紧急与重要的文章，不想再多谈了。
我想更加具体一些。你如何决定一个任务是否重要？你如何有效地降低不重要但紧急的任务的优先级？
如何决定一个任务是否重要
这是我思考紧急与重要问题的框架。
这个框架并不完美，但我已经看到它在许多场合中都很有用，所以值得分享：
重要的任务创造价值。这个价值可以是经济价值（$$$），也可以是其他类型的价值，比如伦理、关系或健康等等。
紧急任务通常减少风险。你会在最后一刻收到请求，因为有人在拼命修复漏洞、避免失去客户、补丁安全漏洞或以其他方式快速解决弱点。
重要的任务往往是积极的。它们是前瞻性的，驱动价值的活动。
紧急任务几乎总是被动的。它们是对感知到的风险或弱点的响应。
将这个框架应用到实践中
这个定义应该可以帮助你确定一个给定任务是否重要、紧急、两者兼而有之，或者两者都不是。
以下是一些你可以问自己的问题：
这个任务会为我或我的公司赚钱吗？—— 重要（可能也紧急！）
它会为我、我的团队或另一个业务单位节省时间/提高生产力吗？—— 重要
这个任务有很大的上升空间吗？—— 重要
我只是做这个任务来限制损失的风险吗？—— 紧急
这个问题的快速解决是否意味着我能保住工作，保护我的团队声誉，或让客户留存下来？—— 紧急（可能也重要！）
我是否在做这项任务作为对其他事情的交代？- 紧急
你可能已经能感觉到，在紧急和重要之间的区分是模糊的。有时候很清楚，但大多数情况下很难确定某个任务是紧急的、重要的还是两者兼具。
随着你使用这个框架的实践，你会变得更擅长区分。此外，随着你作为一名高级工程师的经验增加，你将在紧急和重要之间做出许多取舍。你会对区分有一种直觉感。
但是，仅仅因为一项任务很重要并不意味着它会立即被提升到优先级。
同样，紧急任务即使在大局中不重要，也很难降低它们的优先级。
管理关系和期望
当你作为一名开发人员处理工作请求时，你会一直收到紧急的请求。
至关重要的是，在你开始工作之前，你需要问“为什么”和“为什么现在？”优秀的开发人员确保他们校准了任务的紧急性和重要性，然后再开始工作。
在分配任务的过程中，管理关系可能非常困难。每个人都希望他们的项目立即得到优先考虑！这是你作为开发人员的社交技能比技术技能更重要的众多领域之一。
学会管理关系和期望，以便在最小化与他人的关系和声誉损失的情况下缩小项目的范围或优先级。
降低紧急但不重要的任务优先级
以下是我过去用过的几个问题，可以用来回应紧急请求并调整其重要性：
这个问题有什么影响？这项工作是否阻碍用户做某些事情？有多少用户？是哪些用户？是一直阻碍还是偶尔阻碍？
其他团队是否在等待这项工作？我们当前的任务阻塞了哪些其他工作？那些工作有多重要？
是否存在截止日期？那些截止日期的存在是为什么，还是只是随意设定的？如果错过了截止日期会发生什么？
这里还有三件我团队正在处理的事情：x、y、z。这个请求比另外三件事情更重要吗？你会建议我按什么顺序去处理它们？为什么？
这些简单的问题可以帮助迫使请求者证明其需求的必要性。
它们还可以强调这个新的紧急请求所花费的时间会从其他重点任务中占用。请求者应该提供有关其请求的目的和时间性的详细信息。
在许多情况下，你会发现仅仅稍微反驳一下，引入一些澄清性的问题和障碍，就会极大地减少到达你手中的紧急请求的数量和范围。
当它们最终出现时，你将更清楚地了解它们为什么需要以及它们在优先级中的位置。
每日清单
喜欢这里的内容吗？我每天早上都会为2,000名软件开发人员撰写新的内容。
如果你喜欢我的文章，点赞，关注，转发！
