软件开发管理工作中的团队管理.docVIP

软件开发管理工作中的团队管理 可能世界上最难管理的团队就是软件开发团队了.?软件开发管理和普通的管理不一样,它非常需要发挥人的创造性思维,往往在开发中一个巧妙的技巧就能节约n天的加班劳动.软件开发最需要的是一种发挥创造性?思维的内动力,而对这一点,几乎任何带有强制性的规定都无效,这个结论可以这样来证明:无论管理人员定下多少强制性的规章制度,只要愿意,每个开发人员都?可以在完全遵守规则的情况下交出一件平庸的产品.其实在程序员眼里,那些被管理者奉为圣典的诸如规定工作时间,规定代码量,规定文档数量的管理制度看起来?是多么的可笑.这完全可以说明:在软件开发中强调采用规章制度的过程管理,至少在目前来说,是毫无意义的. 在软件开发管理中,不能采用明令制度的?方式,必须要有办法激励人的内动力,而激励人的内动力最好的办法是将付出和收益紧密的结合.其实传统的管理也有这一招,比如浮动的奖金制度,但是远远不?够,一个最优秀的程序员的生产力可以达到一个最平庸的程序员的数十倍,并且还不能通过将数十个平庸的程序员加在一起合作的方式来达到这种生产力.因此我认?为,在一个水平参差不齐的团队中,团队成员的收益分配比例达到十倍以上是非常正常事情. 但是优秀的程序员也有可能会有懒惰的时候,而今天平庸的程?序员有可能在明天就变得很优秀,所以最后还是需要一种方式来量化工作成果,但是不幸的是,软件开发的工作成果非常难以被量化,几乎找不到任何一种形式上的?检查手段.但是,具体谁对项目的贡献有多少,其实每个团队成员自己心里是最清楚的,费尽心思的找量化标准和工具,为什么不问问团队成员呢?我觉得,关于最后利益的分配,完全可以采用无记名投票的方式来决定每个成员 包括团队管理人员 的分配比例.在投票前,每个成员都要进行最后的工作总结,说明自己为项目作出了多少贡献,参加投票评分的除了项目组成员以外也可以包括项目组以外的人员,比如公司领导,但是不应过多. 在开发的过程中,不能强制性的要求谁来完成什么任务,而是由项目经理根据经验来给每个任务的难度系数进行一个评估,然后给团队开发人员自由选择.难度大的任?务同样也分数高,难度小的任务分数也低.假如出现了一个难度很低的任务被误打了一个很高的分数,那么必然会出现多人同时争要这个任务的情况.这时,可以逐?渐降低任务的分数,直到最后只有一个人选择.假如一个任务因为难度过高,而无人选择的时候,也可以逐渐提高该任务的分值,直到有人选择该任务.需要说明的?是,难度最高的任务分数和难度最低的任务分数相差几十上百倍是非常正常的情况.开发人员在最后所获得总分数会影响到利益分配时的投票.任务的接受可以是一?个人,也可以是多个人.每个出现的任务必须要有人负责,不能出现没有人负责的任务. 假如有一个人的生产力非常高,他在完成了自己的任务之后,可以?被其他团员邀请共同解决任务 至于分数的分配可以由他们之间自由协商 ,也可以以较低的分数申请要求解决其它人还没有开始进行的任务,也可以给自己放个假?休息休息.项目经理必须密切的关注每个任务的完成进展,假如某任务完成进度与计划相差较大,需要详细了解情况,采取一些必要的措施. 这样做的目的?是为了在项目团队中形成一个良性的竞争环境,让能力强的人获得应该得到的高利益,而能力低的人获得的较低利益也会心服口服 任务是自己挑的,票是大家投?的 ,那么平时就少休息点,多努力提高自己的能力,争取下次能多完成分数高的任务.假如团队成员有人不积极,手头任务完不成,接的任务也被人慢慢的转接过?去,项目经理一般也不需要对他进行严厉斥责,他的惩罚自然会在最后的利益分配时体现出来.这样可以很大程度的降低管理难度,因为没有人愿意去得罪别人. 最后还有一种情况,一些研究性质的任务,往往可能会因为一些不可逾越的障碍而失败,但是这并非开发人员的过失.这种情况,需要针对情况特殊处理,比如开发人?员把研究过程中的心得以及失败原因拿出来分享了,这也是对项目的一种贡献.大家心里自然有数,投票时也都会考虑到这些问题.另外一些非开发类人员,比如项?目经理,业务顾问,配置管理员,测试人员等,虽然没有太多实际的任务得分.但是也需要用某种形式让大家知道自己所做的工作.Blog是一个解决这个问题的?非常好的方式,团队的每个成员都会养成写Blog的习惯.经常写写Blog,一是可以让大家都知道自己在做什么事情 增加印象分 ,二是项目结束时方便写?最后的工作总结 许多工作自己当时不纪录也忘记了 ,三是利于提高自己的水平 工作和学习写点总结会系统的总结和归纳思路,进步很快 .?