对很多项目经理而言，是没有什么所谓的“我的时间”的，因为他们不是在管项目，而是被工作的潮水带着跑而已，他们的时间被工作主宰了。项目经理必须要主动的管理自己的时间，合理安排自己的工作，才能真正“翻身”做自己时间主人。
1.谁动了我的时间
时间对于每个人而言，都是最稀缺的资源，对于一个管理者更是如此，时间不够用成为几乎所有管理者共同的问题。如果要对项目经理常说的话做一个调查的话，想信 “我很忙”一定可以名列前茅。以我的经验，当要求项目经理按时提交项目材料，或者临时支援某件紧急事务的时候，经常会听到同样的回答：“我很忙”。
多年以前，我就从经理那里听说，厉害的管理者都是很轻松的，因为他的工作全部交出去了，根本不用自己操心，所以他们出去度假十天半个月，一切工作都会如常进行。从那时起，我就充满了对管理的神往，可是后来我才发现原来这只是个传说，现实中忙忙碌碌的经理比比皆是，而轻松自如的管理者则是众里难寻。
为什么管理者都这么忙呢？是谁动了他们的时间？实际上，这是一个综合性的问题，既有内部原因，也有外部原因，既有主观原因，也有客观原因。总的来说，让经理们不堪重负的因素有三：
(1)工作
对于一个程序员来说，他的工作是比较单纯的，基本上是单线程运作，只需要项目经理交待开发任务即可，可是当上了项目经理就不一样了。以前好比在游泳池中游泳，现在是在大海里冲浪，各种事情如潮水一般向你涌来，让你顾此失彼，手足无措。
(2)下属
下属也是一种资源，即人力资源，这种资源与时间一样，同样具有稀缺性。其实我们可以设想一下极端情况，如果你的下属人数足够，能力也很强的话，你完全可以像我的经理说的一样，把你的全部工作授权给你的下属，你自己也就不用整天焦头烂额了。
因为你的下属不给力，所以你总是要自己来制定计划、自己来做系统架构、自己来监控进度、自己来检查质量、自己来写文档、自己来汇报工作、自己来解决重要问题、甚至自己来编写代码，你整天忙忙碌碌，就是在忙这样的事情。
然而，千万不要怪你的下属，因为他们不给力正是老板雇佣你的原因，况且资源的稀缺性是永远存在的——从原始社会到将来的共产主义社会。要知道，老板做项目为了赚钱，而不是让管理者更轻松，如果每个项目都是精兵强将，你只要一声令下工作就会自动完成，你倒是轻松了，但老板还要你来做什么？
(3)自己
既然资源受限是一定的，项目经理还是应该反求诸己，从自己身上找到解决之道。这就好比天下雨了，你怪老天是没有用的，只能怪你自己没有带雨伞。经常问一问自己，我对工作安排合理吗？我抓住了主要问题吗？我在旁枝末节的事情上浪费时间了吗？我有充分发挥下属的能力吗？我自己工作拖拖拉拉吗？…通过不断的自省，改善自己的管理方法和行为习惯，我们对时间利用也必然会变得越来越高效。
2.时间管理的本质是对工作的梳理
要破解忙的难题，必须要有意识的对时间进行管理。其实时间本身是没法管理的，因为无论你怎样管理，时间既不会变多，也不会变少，既不会变快，也不会变慢。所谓的时间管理，其实就是如何更有效的利用时间的问题，更加直白地说，其本质就是工作管理，即通过对工作的梳理，让我们在有限的时间内，使得工作更有条理、更有成效。
必须要主动、有目标地对工作进行梳理，这是对一个管理者的基本要求。工作梳理就好比整理房间，你不去整理它，杂物就会堆积得越来越多，你房子最终会变得不适合人类居住。一个好的家庭主妇，必定善于将各位物品分门别类，并且适时扔掉一些用处不大的物品。一个好的项目经理也一样，同样需要对工作进行分类，对不同类型工作采用不同的策略，有些工作要现在就做，有些可以晚点做，或者不做；有些工作一定要自己做，有些工作则可以请其他人来完成。
通常对工作梳理，可以采用5W1H法，即：
Why——为什么干这件事？（目的）；
What——什么事情？（对象）；
Where——在什么地方执行？（地点）；
When——什么时间执行？什么时间完成？（时间）；
Who——由谁执行？（人员）；
How——怎样执行？采取哪些有效措施？（方法）。
在一般的项目中，Why和where往往不是什么问题，或者说对项目经理的时间管理影响较小，因此我们不妨将其简化为3W1H，也就是确定要做什么，不做什么；先做什么，后做什么；谁来做；怎样做才更有效。基于此，项目经理可以按以下三个步骤来梳理工作：
（1）分析要做什么、不做什么，以及先做什么、后做什么
解决What和When的问题。事有轻重缓急，事情的重要程度和紧急程序直接决定其处理的优先级。虽然很多事情来势汹汹，但并不表示一定要当即处理，有些事情只是静静的躺在那儿，也并不意味着要“等有了时间再做”。
（2）分析由谁来做
解决Who的问题。虽然我们提倡项目经理要以身作则、亲力亲为，但并不是说每件事项目经理要亲自去做。对于下属可以胜任的事情，就把它分配出去。如果出现项目经理很忙、下属很闲的情况，那就说明项目经理你做得太多了，不要和你的下属抢事情做。
（3） 如何让工作更有成效
做不做、什么时候做以及谁来做的问题都解决了，剩下就要解决怎么做才能让工作更有成效的问题了。在这里我们不是要讨论编码或写文档的技巧，而是个人的习惯和认识，这对工作成效的影响更是本质上的。
3.做事要分轻重缓急
老外就是善于总结，中国有词语叫“轻重缓急”，可是到了国外摇身一变，变成了“时间管理四象限法”——自从美国总统艾森豪威尔提出以来，人人将其奉为圭臬，成为时间管理领域最重要的方法论。
所谓的“四象限法”，就是将工作按照重要程度和紧急程度两个维度进行分类。我们找一张白纸，以紧急程度为纵轴，以重要程序为横轴，在纸上划上一个十字，将纸面分为四个象限，然后将当前所有要做的工作放到这个四个象限中。
一个典型的项目经理四象限图如下所示：
（1） ***象限：重要紧急
这一类往往是火烧眉毛的事情，需要马上去处理，否则项目会受到重大影响，比如客户服务器崩溃。
（2） 第二象限：重要不紧急
这类事情一般是预防型的工作，例如制定项目计划、团队建设等，它们不需要你停下手上的工作马上去做，但如果没做好的话，可能就会导致产生项目危机。许多***象限工作产生的原因，正是因为第二象限的工作没有去做。
（3） 第三象限：紧急不重要
这类事情虽然不重要，却需要马上去处理。一个典型的例子就是桌上的电话响了，你接还是不接？当然要接，因为你不知道是谁。接通后，发现是推销保险的，你又不好意思立即挂掉，只好被对方折磨一番了。
（4）第四象限：不紧急也不重要
这类事情看上去最不需要做了，例如上网偷菜、看新闻、写博客等，但如果你在办公室走上一圈，就会发现很多人正在干着这些不需要干的事情。
我们到底该怎样安排四个象限的工作呢？对于一个普通的管理者，其工作的优先级一般是这样的：***象限>第四象限>第二角限>第三象限。可是，等做完了***、四象限的工作，根本就没有时间来人做第二象限的工作，于是项目到了后期项目经理只好四处救火。
管理大师彼德.德鲁克十分推崇“时间管理四象限法”，并将其总结为“要事***”的原则。根据这个原则，每个象限的工作处理策略是不一样的。
（1）重要紧急
优先级***，需要尽快处理。很多人都玩过《植物大战僵尸》的游戏吧，那你一定知道“一大波僵尸正在逼近”的感觉，是的，你必须要马上打死它们，不然它们就会冲进你的房子，吃掉你的大脑！
（2）重要不紧急
这类事情看上去可以暂缓，但考虑到其重要性，应当与***象限的工作并行去做。如果不及时去做，它们就会转移到让你头疼的***象限中去，或者在***象限产生更多新的“僵尸”。所以，要在僵尸还没有逼近的时候，就好防御工事，并尽快打死它们，如果等到它们冲了过来，你还能不能保住大脑，就要看你的运气了。
（3）紧急不重要
它们就像是在你耳边“嗡嗡嗡”地叫着的苍蝇，你必须要花时间去赶走它们。这多少让人有些无奈，但这些事情确实层出不穷。有些公司在实施紧急项目时，经常采用封闭式开发，这样做的一个重要原因就是要回避那些紧急不重要的事情。很多管理专家建议我们在必要的时候勇敢说“不”，其实就是针对这类事情。如果实在无法说不，建议安排或委托其他人来做。
（4）不紧急也不重要
如果不是时间充裕的话，建议不要去做。如果碍于人情的话，建议安排或委托其他人来做。它们就像一群在几百米远处飞的苍蝇而已，你完全不必要放下手中的饭碗，举起苍蝇拍跑过去和它们决斗。
因此，对于一个卓有成效的管理者，其优先级应该是这样的：***象限=第二象限>>第四角限。第三象限就像数学中的无穷小一样，被舍弃了。
写到这里，我想起了前不久一位项目经理的故事：
项目定于当天上线，项目组决定搬到客户现场办公，以应付可能出现在的突发事件。项目成员电脑已经全部打包好，都围在项目经理周围等待。原来项目经理正在理一大堆发票准备报销，于是发生了这下面这样的对话：
我：“大家都在等你，怎么还在填报销单呢？”
项目经理：“今天是公司的报销日，不填好单子，又得推后很久。”
我：“你的电脑打包了没有？”
项目经理：“没有”
我：“放行条开了没有？”
项目经理：“没有”
我：“申请用车了没有？”
项目经理：“没有”
我不知道说什么好了。要知道公司的报销单粘贴和填写非常严格，经常被打回重新弄，那一堆发票，显然不是十几分钟可以搞定的事情。还有公司的用车也比较紧张，不赶紧申请，说不定就没有了，到时就只能租车或打的，这无疑又会耽误更多的时间。更何况六七个同事都在等项目经理一个人，耽误的时间还得要乘以他们的人数。万一系统上线，状况频出，客户火烧眉毛，项目组却仍然在路上，这样的后果是很严重的。
贴报销单看上去一件重要紧急的事情，实际上它既不重要也不紧急，因为今天不报销，以后还是可以报销，可是因此耽误的宝贵时间，却无法再要回来。如果项目经理更加理智一些，分清楚什么才是真正紧急重要的事，也就不会出现这样的状况了。
原文链接：http://www.cnblogs.com/watsonyin/archive/2013/02/19/2917764.html
