小余

灵感源于交流,创新出自思考

导航

 

终于结束了近一个小时的枯燥会议,每周五公司级别的项目周会就像一个例行的检查,多少有点不痛不痒的味道,大部分的时候就是一个例行贯事,每个项目组按照顺序汇报一下各自项目组的情况和需要,如果不出现大的问题的话,也就是有本上奏,无本退朝的一个过程。或许有些人觉得这是一个比较浪费时间而且意义不大的会议,每周浪费大伙一个小时的时间去再次陈述这些本来在邮件中已经说明的问题和项目进度,不过存在就有价值,这个会议的最大的功能在于能尽量使各个项目组之间有部分的消息互通,至少能让大家了解到一点,其他人都在做什么,从而避免了每个项目组过于孤立的现象。

       今天的周会时间有点长,主要由于两件事情的讨论超出了会议的议程安排,第一件事情是大伟负责的项目目前进度出了问题,目前人员处在一个持续加班的紧张状态,即便如此,对于项目的最终Release时间还是比较确定的状态,用大伟的话来形容就是:“我们能够按时完成,但是可能会有点小问题。”一句比较含糊的托词,如果说套用官方的言词就是:“对于项目能够按时完成,我们还是谨慎乐观。”另外事情对于公司来说是一个好消息,公司将在下个月启动一个新的项目,这个项目是今年规模最大的一个项目,其业务方向主要针对美国的医疗领域,规模大概有150/月。

这个项目将会被安排到我们项目组来处理,消息对于我来说就是一个挑战,对于自己来说,这个规模的项目也是超过了以往的一切项目,在会议上听到这个项目将由我来接手处理,不由小小的兴奋了一把,但是这股兴奋的感觉很快就被冲淡,自己粗略的考虑了一下项目组内目前的工作量和目前的人员情况,不由感觉到这个活不太好揽。不过有压力才有动力,这是我一贯的做事风格,类是这种明知会将苦重重的活,我越能够信心十足。我简单的在自己的记事本上写下了以下下周的关健工作内容:确认项目的具体开始时间和结束时间;调整目前项目组内的工作内容;向客户先要部分的开发相关资料;了解一下公司内部其它项目组的人员状况。

       会议后半程的内容我没有听多少,只是对于大伟的问题大家有部分的讨论,我才回过神来参与,大伟虽然说自己还是有信心能够保证项目的进度,但是为了保险起见,希望从其它的项目组借调两个人来协助他们做一些类是测试的工作,这样的话总的进度就可以进一步得到保证。以目前公司的架构模式,每个项目组相对独立的运作模式,如果说希望从其它的项目组借调人员,这种短期人员的借调有时候是比较困难,因为每个项目组目前来说都处于比较繁忙的阶段,目前闲暇的人员不多,即便其它项目组肯借人,大多放出去的人员也都是能力相对比较弱,正常情况下人不可能把项目组内部优秀的人员借调出去,这或许也是人的一种私心。

       在公司的协调安排之下,最后还是给大伟支援了两个人员,这才把讨论不休的会议打住。会议结束后我还在会议室坐了一会,我的脑袋里还在考虑下周的工作顺序,盯着自己的笔记本在对刚刚写的问题进行细化,把工作分解到下周的每一天。突然一股浓浓的烟味直接灌进我的鼻子,我不用抬头就能猜出是大伟,这个烟枪一天最少一包烟,如果遇到加班或则心情不好的话,估计两到三包都有可能。

       “少抽点烟,怎么心情不好?”看着大伟吐着烟圈,我问道。

       “没有,只是有点累。”大伟嘴里叼着烟,目无表情的应道。

       “我看到你们项目组的那些去年刚刚毕业的学生,最近是天天加班到晚上11点左右。这是怎么回事?”

       “噢,那时我故意的。”

       “故意?”我一时没有明白,疑惑的问道,“为什么要故意呢?”

       “我是按照我自己的工作能力给那些新人安排工作,如果说我是能够在上班时间内完成工作的话,那么那些新人肯定需要加班了。这样他们才能进步。”大伟的表情中开始露出得意的神色。

       “怪不得他们要加班,你工作了多少年,他们才工作多少年,再说了你拿的工资和他们那得工资能一样吗?”

       “我就告诉他们,如果你想工资那得和我一样,那么这些工作你能够准时完成,那么你就有机会。”大伟熄掉手中烟头,用双掌在脸上使劲得措动。

       “那你该不会是按照你的能力来做的项目估算吧?”对于大伟的这个逻辑我并不能苟同,但是我还是想了解项目的问题。

       “嗯…..”大伟支吾着回答到。

       “哈哈,你这是自作自受。”我对着大伟带着嘲讽的笑声说道。

       对于大伟的做法我却是无法苟同,虽然他的失误在于前期的估算过于乐观而且并不准确。但是对于给新人安排工作的方式上存在有比较大的问题,如果说前期的估算出现失误,这些错误在后期项目开始过程中还可以进行添加人员的方法进行补救的话,那么对于人员使用不当的问题,就像整个项目过程的绝症,其会影响到整个项目过程。

       项目组中开发人员从能力上有几个不同的级别,系统架构师(Systems Architect,高级工程师(Senior Engineer,中级工程师(Middle Engineer)和初级工程师(Junior Engineer)等等。对于每个级别上的人员的能力和开发技能都有一定的差异。这些就像我们手的手指一样,五指有长短,能力个不同。不同能力的人员应该在项目组中相应的工作内容和工作量。

       在正常的项目中我们讲究的是人尽其用,但是不能把一个项目在开始的时候就设想是通过发挥项目组人员的超水准的基础上来完成。很多人都说人在一定的压力之下,能够超能力的发挥出他们的水平,但是比代表说所有的人都能够在这种环境下能够有说突破,很多人在持续长时间的高压下会显得精神不振,萎靡的情况。所以作为项目管理来说,不能再项目一开始的时候就采用这个立足点来进行开发工作。

       对于大伟所说的那种歪论,我只能回应以自作自受的答案。我们给个人都是在逐步的学习和进步,如果说有一定压力灾,对于学习确实是一个比较有效的促进。但是作为项目经理来说,需要明白的是一个问题,我们的职责在于项目,而不是在于锻炼新人,新人进入项目组织后,通过项目过程的工作和学习能够提高他们的能力,这些是项目的副产物。而我们首先要保证项目的进度,质量。我在实际的项目开发过程中,对于给新人的工作计划都是按照其能力的80%-90%进行安排,很少会针对新人能力的100%进行工作任务分派,因为新人由于缺乏经验,所以在项目实际过程中如果遇到问题,他们解决这些问题的所采用的方法和思路都存在有时间的风险,有时候他们可能由于一个问题会难住他们,消耗掉很长的时间。即便我不断强调说如果有遇到问题,在一个小时内解决不了的话,就要把问题抛出来给大伙来共同处理,但是往往这个问题被最后迫不得已提出来的时候,都是在一天或则更长的时间之后。新人在开发过程中遇到这些问题的概率非常高,所以在工作安排工程中必须要考虑到这种风险。所着一旦推倒第一张加班的牌,那么后续的将是多米洛效应,加班将一发不可收拾,进入恶性循环阶段。

       对于实际的项目中我会采用减算安排工作的方式,那是因为我需要保留对项目整体的进度有更大的回旋缓冲时间。无论对新人还是对高级工程师,中级工程师和初级工程师我都会采用一样的策略,因为人脑不是机器,所以我们无法保证我们时时刻刻都能正常的满负荷运转。但是在平常的学习过程或者非实际项目的锻炼过程中,我会采用超负荷的工作安排模式,这个时候给人员的工作量安排都是100%-120%的程度,因为这个时候我的主要目的在于人员培养,所以需要一种超强度的环境,营造一种压力的气氛。其实开发过程何尝不是一个不见硝烟的战场,如果你想要在战场上不受伤,只有在平时多多受伤,这样在真实的战场上才能从容应对。

       对于项目组中我们需要比较清楚的了解每个成员的能力和个性,如果对于他们的能力了解能够像看着我们手指头那么清楚,我们就能够依据他们的长短,让他们协调发挥出水平来。我们需要避免工作不分能力,均等划分的安排方式,更不能把项目寄托在成员的超水平发挥的基础上。在工作中我们需要明白项目的最终目的,项目成功还是锻炼人员,从而采用减算还是加算得工作安排方式。


 

作者:Yice(小余)

出处:http://www.yice800.cn

本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。