项目经理职责[很好很强大].docVIP

HYPERLINK /yihui823/article/details/6769887 \o 项目经理问：为什么总是只有我在加班 – 挂包袱现象 项目经理问：为什么总是只有我在加班 – 挂包袱现象 转自： HYPERLINK /yihui823/article/details/6778351 /yihui823/article/details/6778351 现象 最近和一位项目经理聊天。这位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的人碰到的现象大差不差。 对于项目经理甲来说，他分包袱的工作太随意，并且没有跟踪小组成员解包袱的进度，直接导致了最终的结果:所有的包袱都在自己的手上。这就是我所说的，挂包袱现象。 很多技术牛人，都会不服气项目经理，认为这个人只是在分