收藏本站 收藏本站
积木网首页 - 软件测试 - 常用手册 - 站长工具 - 技术社区
软件测试 > 其它管理相关 > 正文

首页 | 领域细分: 游戏测试 安全测试 手机测试 Web测试 | 技术研究: 单元测试 入门教程 用例设计 性能测试 功能测试 | 测试职场: 面试精选 职场发展 面试试题

测试管理: 配置及流程 - 需求管理 - 质量验收 - 缺陷管理 - 其它管理相关 | 开发语言: PHP技巧 - PHP基础 - PHP实例 - PHP错误代码

测试工具: LoadRunner JiRa QuickTestPro RoBot WinRunner TestDirector 其它测试工具 | 数据库: Mysql数据库 Oracle数据库 CSS/DIV基础 HTML基础

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

来源:互联网 日期:2014-01-26 16:30

  现象

  最近和一位项目经理聊天。这位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的人,以及以后希望在这方面有发展的人一些帮助。

版权声明:本文出自 fairyfox 的51Testing软件测试博客,欢迎转载......

本周排行

别人正在浏览

强悍的草根IT技术社区,这里应该有您想要的! 友情链接:b2b电子商务
Copyright © 2010 Gimoo.Net. All Rights Rreserved  京ICP备05050695号