如何轻松优化任务管理

在处理不同类型的任务和优先级时，经常会错误地将紧迫性和重要性视为同义词，从而使用错误的方法来管理任务，资源和时间。

紧急情况通常是由外部或紧急因素驱动的：客户请求，期限短，阻塞性错误。 重要性通常由内部因素驱动：众所周知的技术债务，所需的重构，性能和优化改进。 您可能会在网上找到有关这两个特征的几个定义。 在这里，我们将尝试着重于他们在IT项目中使用的设备，以及它们如何改善我们对优先级的认识以及生产力的有效性。

因此，更好地管理时间和任务分配的第一步是区分什么是紧急的（什么不是紧急）和什么是重要的（什么不是紧急）。 您可能会猜到，这些特征最多可以生成四种不同类型任务的组合，如下所示：

• 不紧急，不重要 ：考虑错误的日志信息，图形界面标签中的错字错误：任务列表中出现的内容很容易修复，对客户端来说并不紧急。
• 紧急，不重要 ：考虑与上述相同的信息，但与客户和审核员更相关：包含错误信息并用于生成报告的审核记录，这很容易解决，对内部而言并不重要，但对用户来说很紧急。
• 不紧急，不重要 ：事情变得重要，但是客户可能并不了解（大多数情况下他/她不应该）：这可能是重构，性能问题，必须在内部加以解决，并担心IT架构师，因为如果短期内不进行纠正，可能会给整个团队和项目带来麻烦。
• 紧急，重要 ：影响软件体系结构几层的阻塞性错误或错误的算法实现会影响客户端，并将其传播到产品的多个组件。

需要特别注意的是，以上四种组合并不代表静态：它们代表一组任务，它们是动态的，因为受客户意愿，时间限制和产品发展的影响。 因此，任务可以从一种组合移动到另一种组合（然后从产品积压日志移动到另一种），融合（应用悲观但通常是现实的模式）到最坏的一种，如下所示：

如果影响客户服务干预以确定意外错误的来源，则错误的日志信息对于客户来说可能变得很紧急（“不紧急不重要”>“紧急不重要”）； 如果其他表和关系需要所需的数据，则客户需要的报表表中但内部不重要的新列可能突然变成非常相关的内容（紧急不重要>紧急重要）； 如果阻止了新的必需功能（不是紧急的重要>紧急的重要），则推迟重构可能变得很紧急。 而且，自然而然，任何紧急和重要的事情都只会随着时间的推移而增加其紧急性和重要性（紧急重要>真正紧急重要）。

因此，在最坏的情况下，每个任务都可以收敛到更紧急和更重要的任务。 确实，任务绝不能进一步使两个状态错位，从而在项目中发现错误的预测或未纠正的需求：如果“不紧急且不重要”的任务（如应该是简单且孤立的错误）变成了“紧急且重要”的问题，那么它肯定会标记为一开始被低估了。 更现实的是，“非紧急”和“不重要”任务将在该状态下保留很长时间，从待办事项迁移到另一个，并且在实际变旧或由于重构和相关修复而消失时可能会变得有些紧急。 这绝对是正常的，因为根据分配的组合，您应该按以下建议不同地管理任务：

紧迫任务和重要任务应始终优先于其他任务：您没有太多选择，您（或团队的任何高级开发人员 ）必须尽快对其进行处理。 您还应该尽可能地将重点放在“非紧急但重要的”任务上，并花费时间来识别它们，为它们分配正确的时间和资源，以避免将来出现紧急情况和压力：这些是使IT架构师和一个高级开发人员很忙。 紧急但不重要的任务通常很容易解决，不需要很多时间，但必须作为即将发布的版本的一部分，因此您可以在不紧急和不重要的任务下进行处理或尝试委派给经验丰富的团队成员可能被委派给新手或初级开发人员 ，他们需要从事一些简单任务的项目，这些任务会通过缩小的错误修复和较小的任务将他/她介绍给产品。

而已。 实际上，我们只是通过应用四种不同的任务组合来进行资源和时间管理，就这么简单。 重构您的想法，因此，以不同的方式看待紧迫性和重要性，优化您的日常任务清单并提高工作效率。

翻译自: https://www.javacodegeeks.com/2013/05/how-to-easily-optimize-task-management.html