挨踢项目求生法则-团队建设篇
作者:网络转载 发布时间:[ 2011/12/1 9:58:57 ] 推荐标签:
由“踢皮球”事件想到的
事件回放:
某项目部署给客户后,重现了一些以前已经解决的问题,而这些问题测试时并没有出现。经检查,发现测试的版本不是部署的版本,不知道为什么老版本部署给客户了。领导要追究责任,于是大家各有说法:
开发人员说:我是按要求打标签的,没有问题。
测试人员说:我是在提交区中取版本来测试的,我没有出错。
实施人员说:我是按照开发给我的版本去部署的,我没有过失。
后终于有人说:是之前已经离职的某某弄错版本号导致的。
该事件暴露了很多问题,但我想说的是团队建设的问题,没有任何一个人首先从自己身上找原因,第一反应是推卸责任!
唐僧四师徒西天取经,如果每个人都是这样,不是自己内斗死,是被妖怪吃掉!的团队能“自动”解决很多问题,如何才能打造良好的团队文化呢?
良好团队文化的源泉是什么?
良好团队文化的根本其实是老板的管理思想了,不同的管理思想,老板会设计不同的部门规划和考核办法。
有朋友提到他的Boss喜欢工厂化管理,硬生生将员工分成两类人,设成两个部门。一个部门叫设计部门,负责需求和设计;一个部门叫实施部门,负责编码、测试、实施。设计部门通过一个任务管理系统向实施部门下单,实施部门根据这些工单来工作。该老板还设计了自以为很牛的考核办法,如果实施部门不能按时按质完成工单,则会影响考核;如果设计部门的工单被实施部门退回,则会影响设计部门的考核。于是两个部门之间的扯皮时间天天发生,以前完成一个工作很简单的,现在要扯来扯去。设计部门自认为需求、设计等文档已经写得很清楚,实施部门认为已经按照这些文档完成工作,或者是认为这些文档说得不够具体,要退单。当文档主要用来任务交接的时候,文档会变成茶几上的杯具!
还有一些老板喜欢用bug数量、文档缺陷率、工期延误率等所谓客观的量化的数据来考核,同样只不过是杯具的另一种形式而已。
软件研发活动是人类复杂的高级智力活动,是需要team work的活动。如果明白这个道理,如果懂软件开发,不会设计出这些傻瓜的管理措施,将软件研发团队的每个人变成机械人、卸责人。研发团队中的每一个人都应该是值得尊重的、有血有肉的、充满激情和战斗力的专家!
作为Team Leader应该怎样做?
Boss的想法我们无法控制,虽然无法从根本上改变公司的部门设计和考核制度,但作为Team Leader来说,在能力范围内还是可以做很多事情的。Team Leader应尊重每一位Team Member,平等地对待他们,充分发挥他们的潜力,给予足够的支持和成长空间等。对大家好,大家是知道的,将来会给你带来更大的回报。
下面一些法则供你参考。
法则1:一荣俱荣,一损俱损
项目组由项目管理、需求分析、软件设计、编码、测试、实施等各方面的专业人士组成,每位成员在自己专业领域内发挥主导作用,并可以为项目的成功提出非自己领域内的建议。终的项目成果是各位专业人士共同努力的结果,所有人对终成功承担同等的责任。
如果系统部署后,系统出现了一个严重缺陷,请问谁应该负责?
项目经理?测试?开发?……
都不是,而是项目组全体都要负责!
软件中某个功能做得很炫很好用,请问谁应该受到表扬?
项目奖励发下来了,请问谁可以分到这份奖励?
以上问题相信你应该有答案了!
项目组全体是共同承担连带责任的,要死一起输死,要活一起活。如果项目组中有人受罚,有人会得到好处,这个Team是很难团结和有战斗力的。
法则2:让 Team Member 当家作主
项目组中难免有部分成员是新手,经验和水平不足,某些工作可能一时不能胜任。而我们往往迫于项目进度压力,某些任务会直接安排给他做,不让他提出自己的想法和见解。而我们这些接受了中国式教育的人,不少人喜欢以“接受任务”的方式来工作,而不是主动迎接挑战。于是有时候你可能遇到一些成员会跟你说“工作已经完成!”“我按照任务要求来做的,我没有错!”之类的活活会气死你的说话。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11