本文主要是介绍艾森豪威尔法则（四象限法则），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
把工作按照重要、紧急程度分成四象限;
- 优先做重要紧急的事情；
- 重要不紧急的事情可以暂缓做，但是要持续推进；
- 紧急不重要的事情可以酌情委托给最合适的人做；
- 不重要不紧急的事情可以考虑不做。
原则四：闭环思维
你是否遇到过这样的场景：参加了一个设计（或需求）评审，大家兴致勃勃地提了很多合理的意见，等到再次评审的时候，却发现第一次提的很多问题都没有得到改进，很多讨论过的问题需要从头再开始讨论。这种情况就是一种典型的工作不闭环。
之前看过一句话：一个人是否靠谱，就看他能否做到凡事有交代，件件有着落，事事有回音。这就是闭环思维的重要性。它强调的是一种即时反馈闭环，如果别人给我们分配了一个任务，不管完成的结果如何，一定要在规定的时间内给出明确的反馈。
例如在跨部门的沟通会议中，虽然各方达成了一致，会议发起者已经将最终的记录周知大家。但是，到这一步其实并没有完成真正的闭环，在落地执行过程中很可能还存在一些潜在的问题。例如，会议纪要是否经各方仔细核对并确认过？会议中明确的To Do进展是什么？完成结果有没有Check的机制？如果这些没有做到的话，就会陷入“沟通-发现问题-再沟通-再发现问题”的恶性循环中。
真正的闭环，要求我们对工作中的事情都能够养成良好的思维习惯，沟通要有结论，通知要有反馈，To Do要有验收。
“闭环思维”还要求能够定期主动进行阶段性的反馈。刚参加工作时，我接了一个工期为两个月的项目。整个项目需要独自完成，自己每天按照计划，有条不紊地进行开发。大概过了两周之后，Leader询问项目进度，虽然我已经跟他说没问题。然而，Leader告诉我，因为我每天对着电脑也不说话，让他心里很没底。
这时，我才意识到一个很重要的问题，我跟Leader之间存在信息不对称。从那以后，我就时不时得跟他汇报一下进度，哪怕就只有简短的一句话，也可以明显感觉，他对我的信心增加了很多。特别是我做Leader之后，对这种闭环反馈的理解，就更加深刻了。从Leader的角度看，其实只是想知道项目是否在正常推进，是否遇到问题需要他协助解决。
这篇关于艾森豪威尔法则（四象限法则）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
