如果您在行业中工作了一段时间，您可能知道通常会有不同类型的请求来自客户（或您的PM，或者，嗯，有时是您的创始人/总裁/ CEO等），但我们只打给您为了简单起见，他们也是客户）。 这些请求中的一些请求的优先级较低或正常，而其他请求则是紧急的（这包括超级紧急的请求，直到完成后才回家）。 有些对您和您的应用程序的大多数最终用户非常有意义，另一些似乎像某人在拖延运动，或者像是市场营销人员在集思广益时喝了太多咖啡。 但是，在该领域工作了几年之后，您有时会觉得这些类型是如此典型，甚至特定于软件开发。 但是真的吗？
艾森豪威尔决策矩阵
您只需要不时重读一些书，对我来说，其中一本是斯蒂芬·科维（Stephen Covey）的《高效能人士的七个习惯》（1988）。 它的重要部分专用于所谓的艾森豪威尔决策矩阵（又称时间管理矩阵）。 让我们快速地了解所有内容。
因此，这是一个2×2矩阵，将您可能必须执行的所有任务划分为四个组（象限），具体取决于它们的紧急程度或紧急程度以及重要或不重要。 本质上，它看起来像这样（有关某些示例任务，请参见图像）：
- 紧急且重要：这是需要我们立即关注并为实现我们的目标而努力的目标（无论这些目标是什么）。 简而言之，这里就是您的危机和截止期限的所在地。
- 并不紧急，但很重要：这里的任务使我们更加接近目标，但不一定必须立即完成。 直到为时已晚，他们才移至第1象限。
- 紧急，但并不重要：这些主要是来自其他需要您提供帮助的人的请求。 有趣的是，这些任务对他们可能很重要（属于它们的象限1），但是对您来说，它们只是些干扰。
- 不紧急也不重要：本质上，您根本不应该做某事。 这些事情不仅对您的目标没有用，而且还浪费了您宝贵的时间来应对紧急情况。 显然，象限4是拖延症的主要来源。
因此，科维在书中提出的主要思想（并在后来的《第一件事》中发展）很简单：应该引起大家最大关注的任务生活在第2象限中。如果及时且适当地照顾好他们，它将最大程度地减少到达象限1的任务数量。对于其他两个类别，应彻底质疑象限3的任务，并且大多数任务是消除或委托的，而象限4的任务应被简单地删除，因为这些只是分散注意力。
应用于软件开发
现在，尽管如此优雅，如何将这一概念应用于软件开发？ 让我们来看看。
- 紧急和重要：这里有所有严重的bug（显然应该将这些bug的发生率降至最低，但仍然很难保证100％避免这些错误）。 接下来，这是此象限的最大部分，您实际上只是在项目管理上很差：未正确定义的任务，未及时传达的截止日期，妄想性的估计和/或未咨询开发团队而做出的承诺当然，有时还会有一些异常的功能请求，这些请求既重要又必须尽快完成，但这就是它们：异常。 如果它们每周发生一次，则意味着它们不再是例外，并且您与客户的关系中有可能出了问题。
- 并不紧急，但很重要：除了定义明确的正常优先级功能和足够的期限外，该象限还包含所有那些经常被不公平地忽略的任务：重构，减少技术债务，培训。 另外，在此处添加一些与优化规格和长期开发计划有关的任务是适当的，因为通常可以通过向前看并与团队分享观点来避免很多关键问题。
- 紧急，但并不重要：此象限的内容可能取决于您的具体情况，但是它可能是例如个别客户的一些功能要求：乔致电客户支持，并说他绝对需要拥有一个列表视图以及他上传的图像的缩略图，以及他像昨天一样需要的缩略图，并以某种方式放入票证中，得到批准，确定优先级并开始开发。 因为，我们都喜欢乔，所以他是一个很好的客户。 不要误会我的意思，我真的很希望看到每个客户满意，但有时您只需要说“不”即可。 实际上很多次。 ‘原因：a）Joe请求的此功能可能会疏远其他（数十万？）客户（并且功能标志通常不会使您的生活更轻松或使您的代码库更清洁），b）您的团队有可能忙于做一些c）更紧急的事情，而且绝对是更重要的事情，c）而且，即使是乔，实际上，甚至可能都不需要此功能，并且只会使用它几次。 可以在这里找到的另一种请求是内部请求不足，例如，市场部门认为我们应该在首页上放置一个轮播，因为好了，XYZ网站对此有要求，并检查它们的酷炫程度，等等。
- 不紧急也不重要：在这里，我们通常可以看到与象限3中的请求非常相似的请求，减去紧急程度。 这些都是不错的选择，积压的长笔交付以及在某些时候刚刚停止使用的功能。 奇怪的是，出于各种原因，他们仍然经常去开发，主要的原因是，您必须让开发人员忙碌，对吧？
瞄准象限2
当然，这些只是一些示例，但是Covey的概念在这里也很适用。
首先，我们需要对第二象限中的任务进行优先级排序，不仅要对具有适当期限的正常优先级功能进行优先级排序，而且还要重构代码库，最大程度地减少技术负担，对开发人员进行培训（以便他们编写更好的代码）。 在大多数情况下，这可能并不明显，但是将大量时间用于这些额外的任务非常重要，因为这可以防止我们随着时间的流逝而夸大象限1。 确实，例如，使我们的代码具有更好的形状会导致更好的估计（因此，客户会更快乐）。 而且，较小的技术债务意味着我们可能会很少受到不可抗力的打击，更不用说它提供的更好的敏捷性和更高的开发速度。
接下来，查看象限3中发生的情况。理想情况下，应该通过取消或委派任务来最大程度地减少从此处开始开发的任务数量。 学会对不重要的请求说“不”，尤其是因为市场营销部门可能自己能够完成该报告，并且客户支持可以教育客户如何从旧系统迁移到新系统，等等。 。
最后，停止在象限4中执行操作。停止。 查看您的积压，对于其中的每张票，都要问问自己，是否符合目标。 如果没有，请将其删除。 而且，每当您遇到停机时间并想从积压中获取无用的请求时，请转到Quadrant 2：计划，制定策略，进行重构。 您花费在使代码变得更好上的每一分钟总是胜过您用一些可疑功能填充代码库的那一刻。
结论
当然，在现实世界中，它可能永远不会完美，而您很有可能总是要处理紧要的请求，无论是重要的还是不重要的。 但是，通过专注于对您真正重要的任务，而这些任务在变得紧急之前（或生成任何紧急任务/问题），则可以使您的开发团队更加高效和敏捷（从这个词的真实意义上来说）。 即使大多数公司都倾向于忽略这一事实，并使他们的开发人员将自己从一个紧急项目转移到另一个紧急项目，但谁说您必须以同样的方式进行呢？
