竹磬网-邵珠庆の日记 生命只有一次，你可以用它来做些更多伟大的事情–Make the world a little better and easier

项目经理问：我怎么有做不完的事情 – 事件篮方法

如何管理好自己的时间

原创文章，如有转载，请注明出处：http://blog.csdn.net/yihui823/article/details/6826353

时间管理，本身就是一门艺术。时间是最公平的，每个人的时间都是一样的。如何在相同的时间里，做出不同的事业，这就是个人水平的体现。

一、     故事

这里先讲一个故事。故事是抄来的，我修改了其中的一部分，使其更贴近我要说的主题。

有两个和尚他们分别住在相邻的两座山上的庙里。左边的山上住着瘦和尚，右边山上住着胖和尚。这两座山之间有一条溪，于是这两个和尚每天都会在同一时间下山去溪边挑水，久而久之他么变成为了好朋友。两个和尚都喜欢游泳。胖和尚经常在挑水的时候，顺便游上那么一会儿，而瘦和尚却极少在溪水里游泳。

不知不觉五年过去了。有一天，瘦和尚竟然没有带扁担来挑水，而是直接在溪里面游泳。胖和尚很纳闷，就问瘦和尚，你今天不挑水，怎么有水喝啊。瘦和尚说，这五年来，我每天做完功课后都会抽空在庙后面挖一口井，即使有时很忙，能挖多少就算多少。如今终于让我挖出井水，我就不用再下山挑水。现在我终于可以放心的游泳了。

于是，每天瘦和尚都可以自在的游泳，而胖和尚还是只能游一会儿就得挑水回庙里。突然有一天，两座庙同时失火了。瘦和尚很快就用井水把火扑灭了。而胖和尚还得跑到溪里面去挑水灭火，结果火灭的时候，庙已经烧掉了一大半了。

接下来，胖和尚每天除了要安排时间挑水，还得花大部分时间去修补破庙。而瘦和尚在游泳之余，还潜心书画。故事完毕。

二、     重要度/紧急度

故事说完了，我们再来重头分析做事情的顺序。

根据重要度和紧急度来区分事件，是一个非常常用的方法。但是，到底什么叫重要，什么叫紧急呢？

重要的事情：对以后的工作生活、对以后的发展等，会产生明显的影响的事情，对目标的达成有显著推动的事情。

紧急的事情：需要立即处理的事情。

 

 

 

我们按照以上的象限图，来说一下事件的重要度和紧急度。

4：即不重要，又不紧急的事情。

即不对以后会产生重要的影响，又不是立即需要处理的事情。类似于和尚的游泳事情。此类事情，一般都是些兴趣爱好，或者受人之托，或者偶然的想法。

3：紧急不重要的事情

只是立即需要处理，但是并不会对将来产生重要影响的事情。类似于和尚的挑水，每天必须做，不做不行，但是做了也就是解决当前问题

2：重要不紧急的事情

不是当前必须要立即处理的，但是对以后会产生深远影响的事情。类似于瘦和尚的挖井，不挖也没事，但是一旦挖成功了，后面就可以不挑水了。如果当前有明确的目标，这类事情可以是对目标达成有明显帮助的事情。

1：重要紧急的事情

当前必须处理，不处理会立刻造成很严重的后果。类似于和尚们的庙失火，不立刻救火，就没有住的地方了。

三、     分类处理

以上的四类事件，该如何分别处理呢?

很显然，最优先做的，是做重要紧急的事情，我想这谁都知道。而且这类事件，一般都是很容易标识出来的，也是非做不可的，人们一般都不会忘掉。

但是，并不是所有的事件都是重要紧急的。重要紧急的事件，一般都是救火类的事件，也就是说，是因为工作不好，或者一些意外造成的。那么，我们的正常工作中，充满了其他三种类型的事件，又应该如何各自的时间分配呢？

同样很显然，不紧急不重要的事情，尽量不要做。但是这个说起来容易，做起来却不容易。因为这类事件既然列出来了，就会有其诱惑性。例如很多人喜欢看电视，喜欢打游戏，喜欢看小说等等。就算在工作中，这类事情也是每个人都喜欢做的事情。很多项目经理会安排自己去编码，就是因为技术出身的，往往就喜欢去编码。所以说，这类事情，需要克制住，一定要克制住自己去做不重要不紧急的事情的冲动。

那么，剩下的2和3，需要怎么处理呢？

一个很普遍也很正常的理解，就是先做紧急不重要的，再做重要不紧急的。

坦率来说，这个想法也很正常。既然事情很紧急，那么我当然需要马上处理。重要不紧急的事情，等有空再说吧。

其实，很不然！

紧急不重要的事情，往往都是些日常的工作，都是或者都是些助人为乐的工作，容易做，周期又短，对将来不会造成多大的影响。也就是说，做了最好，不做也影响不大。但是，重要不紧急的事情，一般都是对将来会造成影响的事情，这类事情，往往都是不愿意做、周期长、难做的事情。

打个比方吧。项目组的新人比较多。项目经理需要整理一份技术培训资料，给新人们集中培训。这个就是重要不紧急的。而新人们有时候碰到问题，就直接跑来找项目经理求助，项目经理需要去帮他们解决问题，这就是紧急不重要。

如果项目经理频繁的打断手头上的事情，去帮新人们解决问题，则技术培训资料迟迟无法做出来，那么新人们的问题就会层出不穷，绵绵不断。这个就是个恶性循环。

如果项目经理能够果断的先出培训资料，争取早日把培训做起来，则问题会逐渐减少，这就是个良性循环。

还有一个更生动的例子。假如你在洗澡，满身都是泡泡，这个时候听到来了一个电话。接电话就是紧急不重要的事情，如果你去做了，结果就是满地的肥皂泡泡要打扫，就造成了一堆的紧急不重要事件。

所以说，要想把时间控制在自己手上，最需要做的事情就是：

重要不紧急

这类事件，周期长，难度大，所以需要日积月累的去坚持。这才是解决问题的王道。

四、     疑点分析

很多人都会说，说起来容易做起来难。我们来分析几个疑点的地方。

1.      紧急不重要的事情层出不穷，怎么办？

还是用刚才那个例子，如果新人们的问题不断，我总不能放任不管吧。

其实，就算你不立即去帮他们解决问题，他们也只是郁闷一阵子而已。这种时候，可以让他们先把问题都整理出来，整理清楚，并尝试着自己解决。然后在某个固定的时间段内(例如每天下午2点到3点之间)，你集中帮他们解决即可。或者可以把解决问题的事情分摊在项目的其他几个技术高手身上。

2.      一下子又做不完的事情，总是没有动力去做。

这类事件，一般都不是立马见效的。需要制定一个长期的计划，每天都安排固定的时间去做。不管多少，要保证每天都有进展。

3.      我喜欢做的事情，就没时间做了啊。

    相信我，只有把重要不紧急的事情做完备了，才会有更多的时间去做你喜欢做的事情。瘦和尚挖井成功了，就会有更多的时间游泳了。

4.      不做重要不紧急的事情，不也是一样的嘛。

    防火和救火的概念。如果只是做好当前的事情，每天做好紧急不重要的事情，那么一旦出现意外，则会造成更严重的后果，以后的事情都会变成重要紧急的。如果不把时间掌握在自己手上，那么就是每天都在救火状态。

五、     处理流程

以前有一种做法，是每天上午，把要做的事情都列出来，然后每天晚上再把工作都整理一下，看看哪些做了，哪些没做。现在信息化社会，每天都会面临大量临时发生的事情。所以，现在可以用“事件篮”的方式来做。

现在开始，你准备一个“篮子”。这个篮子，可以是一个便签，也可以是一个小软件。作者用的是outlook的“任务”工具，这个可以和windows mobile手机同步。其他的工具也一样，只要能随身带着就行。

一旦你接受到一个任务，或者发现要处理的事件，先扔进“事件篮”里面。这个就像编码的时候发送消息到消息队列一样，不是同步处理的，也就是说，不是立即处理，再紧急也不是立即处理。

扔进去之后，判断这个事件是不是“重要紧急”。如果是老板喊你，或者工厂失火等重要紧急的事件，那么立即放下自己手上的活，去处理。

如果不是“重要紧急”的事情，那么就先让它在“事件篮”里呆上一会儿吧，专心把你自己当前在处理的事情做完。

做完了当前的事件，回顾你的事件篮。如果还有未识别的事件，则识别一下，按重要度很紧急度标识上。然后，看看你今天的重要不紧急的事件有没有处理，如果没有处理，则优先处理重要不紧急的事情。

经常性的，例如每周，都回顾一下自己的事件篮，把各个事件的重要紧急度重新识别一下。

六、     经验

好记性不如烂笔头

不要以为自己的大脑有多狠，事情一多肯定会乱掉。设置合理的提醒机制，提醒你开会等定时的事情，会让你少很多心理负担。

不要同时做两件事情

    不要把自己当作CPU。同时做两件事情，结果是没有一件能做好。完整的做完一件事情之后，再去找其他事情做吧。不要总是被打断工作，有些事情不立即处理，是不会有什么坏处的。

要找出“重要不紧急”的事情

    很多需要被人推着走的人，是找不到“重要不紧急”的事情的。对于项目来说，经常的去识别风险，经常去想想项目可能会碰到的问题，提前预防，这都是“重要不紧急”的事情。千万不能任其自然发展，等到出事的时候，就是到处“重要紧急”的事件了，就疲于奔命了。

认准目标

识别“重要不紧急”的事件，最重要的标志，就是对终极目标是否有利。远大的目标，永远是大于眼前目标的。如果只是看准眼前目标，那么永远找不到“重要不紧急”的事情，或者永远找不对。

项目经理问：为什么总是只有我在加班 – 挂包袱现象

现象

最近和一位项目经理聊天。这位PM之前是个技术大牛，没什么搞不定的东西，而且做事也认真，也卖命。领导没理由不提拔这种牛人。所以，这个项目让这哥们当PM。

聊着聊着，这位牛人发出一声感慨，现在的员工不好带啊，每天到了晚上7点，就只剩我和另一个小组长了。项目组10多个人，都跑的精光。

我乐了。其实这种情况，我也是碰到过的，在我带的第一个项目，也是类似的情况。我不敢武断的下决定，就跟他多聊了几句。

问：那你大概几点下班的？

答：每天都11点之后。

问：任务很重吗？

答：其实也不重。

问：那些走了的人，你没有安排任务给他们吗？

答：安排不了。

问：为什么不能给他们安排任务呢？

答：他们搞不定。

问：为什么搞不定啊？

答：我也不知道。我尝试给他们分配了任务，但是到头来，那些问题又到我和XXX（另一个小组长）手上了。

后面我也不需要多问了，大概就是我估计的情况。

我把这种情况，称之为：挂包袱现象。

分析

为什么叫包袱现象呢？我们可以这么来描述。

每个项目，其实是一个大包袱。一个公司有大大小小的许多包袱，每个包袱合理完整的解开了，里面就有利润。但是如果包袱解开不正确，就会减少利润，甚至破坏利润。

那么每个包袱，都交给一个项目经理来解。项目经理带领一帮兄弟，负责把这个包袱合理的解开。而包袱是可分解的，也就是说，包袱可以分成大大小小的子包袱，如何解开子包袱，也是每个项目组成员的工作。

对于一个项目经理来说，最重要的工作，是如何把大包袱，合理的分解成小包袱，然后合理的分配给项目组成员来解，并且需要随时监控小包袱的解开情况，一旦发现有小包袱解开的步骤不合理，立即予以干预；如果发现有大包袱分解方式不合理，也必须尽早的改正。

项目经理最重要的工作是不是，自己亲自撸袖子去解包袱呢？

答案很容易说，当然不是。但是，一般初次做PM的人，就容易走进这个圈套。

例子

我们来说一个例子吧。

项目经理甲，在项目一开始分配任务的时候，这么安排的：

A同学，你做###1模块；B同学，你做###2模块；C同学，你做###3模块。剩下最难的###4模块和framework我来做。要求5天完成。

OK，貌似挺合理的，ABC三位工程师就去干活了。

A同学比较聪明，第一天就完成了50%，下班就走了。第二天就做完了，下班也走了，然后就优哉游哉的玩了三天，等着最后的时候昂首挺胸的汇报佳绩。

B同学很卖力，但是偏偏###2模块比较麻烦。B同学第一天完成了50%，加班到8点下班了。第二天碰到一个难题，搞不定了。于是向甲求助。甲无奈去帮B同学分析了一下午，终于把这个问题解决了。这时甲延迟半天。第三天，B同学又碰到一个难题，再次请教甲，甲分析了一上午，搞不定了，于是扔下一句话：这个等我有空来看吧。于是，B同学第三天努力的分析问题，加班到10点。第四天，B同学想着反正甲答应解决的，于是在下班后就回家了，也没有加班。

C同学是个新人，对于环境也不熟悉。第一天熟悉了一天开发环境。第二天毛毛糙糙的做了一点东西，感觉还不错。于是，第三天第四天，不用加班就把东西做出来了。第五天，C同学很开心的汇报说，工作做完了。

第五天下班的时候，甲自己已经延迟了2天的进度，其中1天是因为帮助B同学，还有1天是因为各种会议、各种报销等闲杂事情，忙的焦头烂额。甲随便的问了下ABC的进度，发现A和C已经完成了，B的问题需要甲自己解决。

于是，甲周末来加班了。在吃午饭的时候，随便瞄了一眼C的代码，乖乖，和自己的预期差的十万八千里。于是，只好把C的东西去掉，自己开始从头做。

于是第二周，ABC都在等着甲。A等着甲分配任务，B等着甲帮着解决问题，C等着甲改造自己的程序。而甲还得赶紧把###4模块做出来，framework还有一堆BUG要改。

于是，甲开始向周围的人抱怨，说自己的项目组如何不努力。在公司领导的干预下，甲公布了一条规定：每周一二三四，必须晚上9点钟下班。

在第二周的周五，甲拖着疲惫的身躯，向大家宣布：项目进展不顺，周六加班。于是在抱怨声中，ABC只能无奈的周末来加班，陪着甲去解决问题。

以上是个简化的描述，但是和大多数初当PM的人碰到的现象大差不差。

对于项目经理甲来说，他分包袱的工作太随意，并且没有跟踪小组成员解包袱的进度，直接导致了最终的结果:所有的包袱都在自己的手上。这就是我所说的，挂包袱现象。

很多技术牛人，都会不服气项目经理，认为这个人只是在分配任务，整天追着我们要工作进度，自己不做事，碰到难题就扔给我。但是一旦他自己做到了项目经理的位置，他就应该知道，分配任务，追着要进度，这就是项目经理的工作重心！

我只是说工作重心，不是全部的工作。我也不会说，项目经理不需要写代码。项目经理适当的写些代码，对控制项目会有很大的帮助。这个我们以后再讨论。我们来分析下，项目经理如何去规避“挂包袱”的问题，让项目组成员能够一起来完成项目呢?

改进

1.      首先，不要把组员想象的那么坏。

很多项目经理，一旦看到项目组的组员弃自己不顾，径直就下班走了，就会大发雷霆，然后把组员定义为：坏孩子。然后，就不敢分配给组员任务了，什么东西不如自己做。就经常听到有PM抱怨，现在80后不好管，没有责任心。其实，我带过的80后，虽然个性强一点，但是责任心并没有想象的那么糟糕。虽然也有责任心不强的，但是不会一个项目组都那么差吧。出了问题，要从自己身上找原因。

如果任务安排合理清晰，我想大多数工程师都会把任务的责任给担起来的。所以要注意以下几点：

a)      定义任务，一定要清晰明确。

b)      分配了任务，不能到最后再去检查。

c)      随时根据任务完成情况，来调整后面的工作。

d)      不要随意把任务收回来。

2.      其次，不要把组员想象的那么笨。

很多技术牛人提拔上来的PM，都不敢相信自己下属的能力。他们一旦看到下属的代码写的不好，结构不好，用的API不对，注释不够清晰等等，就对下属的技术能力打上一个叉叉。在之后的工作中，什么都不敢放给下属做。下属一旦工作有点失误，就大发雷霆。

记住，哪怕你的确是这个项目组里技术最牛的，你也不要这么做。为什么？

a)      公司无法给10个像你这么牛的人，让你做项目经理

b)      如果真的给了10个人让你来管，你未必管的了他们

c)      你如果太牛了，下属哪里来的机会去犯错。没有犯错的机会，怎么得到成长

 

3.      最后，不要把自己想象的那么神。

这句话看上去跟前面两句差不多，其实还是有差别的。最大的意义就是：不要什么事情都自己做。记住，PM的目标是把项目做好，不是一个人的表演。你再牛，你也没法一个人做完10个人的项目。就算你做完了，也是10个人的功劳，不是你一个人的。所以，要放手给下属去做。

改进例子

我如果是项目经理，以上那个例子，我会这么安排。

A去做最难的###4模块和framework。B做###2模块，C做###3模块，我自己做###1模块。

第一天，       我不会立即开始做###1模块。先看每人的工作。发现C做的代码不好，就安排B去辅导。

第二天，       B告诉我###2模块搞不定。我让他自己解决。我开始做我的###1模块。

第三天，       B还是搞不定。我帮他搞一上午，我发现了问题，然后告诉他如何解决，让B花一下午去解决。

第四天，       B还需要帮助C，所以时间不够了。我告诉B，你不要帮C了，你专心完成###2模块吧。我自己来帮C。A来向我抱怨工作太多，我说表现你的技术实力的时候到了。

第五天，       B又碰到问题了。我让他先自己解决。C已经完成了###3了，我让C帮我做###4，我同时看B的问题。

第六天，       如果项目紧张，可以加班一天。如果在BUFF的控制范围内，那可以在下周一完成。A做完了###4和framework，B的问题自己终于解决了，虽然我也解决了，但是我不告诉他，只是夸他做的很棒。C把###4也做完了，虽然我还要把###4再改进一下。

我想，虽然工作很紧张，但是大家都加一天班(或者项目里程碑延期一天)，基本上就都搞定了。每个人都有机会做出贡献，虽然忙，但是项目组的气氛还是不错的。

挂包袱现象，是我自己提炼的，希望能给才做PM的人，以及以后希望在这方面有发展的人一些帮助。