四象限法则

“四象限法则”，是由著名管理学家史蒂芬·科维(Stephen R. Covey)提出的一个时间管理理论，把工作按照重要和紧急两方面的不同程度进行划分，基本上可以分为四个象限：重要而且紧急、重要但不紧急、不重要但紧急、不重要而且不紧急。

    第一象限包含的是一些紧急而重要的事情，这一类的事情具有时间的紧迫性和影响的重要性，无法回避也不能拖延，必须首先处理优先解决。

    第二象限不同于第一象限，这一象限的事件不具有时间上的紧迫性，但是，它具有重大的影响，对于个人或者企业的存在和发展以及周围环境的建立维护，都具有重大的意义。

    第三象限包含的事件是那些紧急但不重要的事情，这些事情很紧急但并不重要，因此这一象限的事件具有很大的欺骗性。很多人认识上有误区，认为紧急的事情都显得重要，实际上，像无谓的电话、附和别人期望的事等事件都并不重要。这些不重要的事件往往因为它紧急，就会占据人们的很多宝贵时间。

    第四象限的事件大多是些琐碎的杂事，没有时间的紧迫性，没有任何的重要性，这种事件与时间的结合纯粹是在扼杀时间，是在浪费生命。（摘自百度百科）

四象限法则：不是每个人都能做到

    一项将要被做的工作，要被划分到某个象限，需要根据不同的人、不同的事情、不同的环境、不同的形势由管理者来做出判断。

举例1：

举例2：

    当前版本正在测试，本周五下班前要出版本，开发人员正在忙着做Review的工作和修复测试人员提出的BUG。同时，按着下个版本的计划，产品需求要进入评审阶段了（或许这种时间规划根本就不是很合理，因为安排项目进度计划的人，并不是很了解开发人员在上线前要做很多的Review工作）。产品人员催促开发人员参加需求评审（参加需求评审，提出实现上不是很合理或者有问题的需求疑问是开发人员应该做的一部分事情），如果不赶紧做掉，下个版本很可能就会延时交付，或者至少他们的PRD得延迟交付。这会影响到他们的整体绩效。在这样看来，似乎产品的要求并不过分，也是合情合理。

    作为开发人员，应该认真Review当前版本代码还是去参加下个版本的PRD评审呢？

这个时候就需要有人能站出来重新审视，大家这么忙碌的最终的目标是什么？是做好的产品，吸引更多的用户，产生更多的订单。而目前最重要的是什么？当然是当前产品了，这才是最紧急重要的事情。每次都把更好的期待放在下一个版本上，就是一种破罐子破摔的结局。当你看到这里觉得你所在的公司也在上演同样的一幕，不能说产品不识大局，也不能说开发这偷懒懈怠，说明你们缺少真正有能力的管理者。没有真正有能力的管理者协调，大的团队，有能力的员工，也只落得碌碌无为的结局。

项目管理中的四象限法则判别原则

    作为一个开发人员，目标是按照需求，完成自己负责模块的功能。加上一些专业精神，让代码尽量的更健壮，好扩展。

    作为一个测试人员，目标是根据PRD，测试开发人员的产品是否符合并满足需求。测试开发人员是否很好的完成了功能，是否有BUG。

    作为项目管理人员，目标是项目在正常的运转，符合整体的项目进度需要。没有出现进度阻塞。如果出现阻塞了，把相关负责人叫到一起，沟通找出一个解决方案。把阻塞打通。如果出现了冲突，需要根据就需要根据一些原则来判断把不同的事务划分到四个不同的象限去。一些基本的原则：

项目的目标是引领项目走向成品的旗帜。其他杂物靠边站，项目一力本向前。项目目标是判别事务紧急重要程度最直接最本质的原则。但有些时候，只根据项目目标也没法判别事务的紧急重要程度。比如产品有两个显示BUG，在订单填写页面，产品点评按钮和下单按钮都显示不出来，两个BUG的修复都是符合项目最终目标的。可以修复BUG的时间非常短暂，作为开发人员，你会选择先修复那个BUG？

    想想假如自己作为公司最大的BOSS的话，会选择修复哪一个？肯定是下单按钮了。公司做这一切的目标都是为了用户下单，用户用这个产品的目标也是为了完成下单和预订，产品点评看不到还可以看到详情。但是没法点击下单按钮就什么都做不了。从公司绩效和用户的角度来开。都应该选择修复下单按钮。

结语

    四象限法则看上去很简单，但是在身临其境的时候，不是每个人都能在当场作出最明智的选择。优秀的管理者懂得站在整体的角度考虑问题的紧急重要程度。这种全局观需要的不是技术、不是耐心、不是心态，而是一种智慧。夸海口的说，这是一种很深入的哲学思考。

赠上一句爱因斯坦的名言：一边人很懂得把事情闹的更大、更复杂，但是相反却需要更多的智慧