由“踢皮球”事件想到的

　　事件回放：

　　某项目部署给客户后，重现了一些以前已经解决的问题，而这些问题测试时并没有出现。经检查，发现测试的版本不是部署的版本，不知道为什么老版本部署给客户了。领导要追究责任，于是大家各有说法：

　　开发人员说：我是按要求打标签的，没有问题。

　　测试人员说：我是在提交区中取版本来测试的，我没有出错。

　　实施人员说：我是按照开发给我的版本去部署的，我没有过失。

　　最后终于有人说：是之前已经离职的某某弄错版本号导致的。

　　详情可参阅《案例分析：项目组内踢皮球事件》一文：http://www.51testing.com/html/95/n-248795.html

　　该事件暴露了很多问题，但我想说的是团队建设的问题，没有任何一个人首先从自己身上找原因，第一反应就是推卸责任！

　　唐僧四师徒西天取经，如果每个人都是这样，不是自己内斗死，就是被妖怪吃掉！优秀的团队能“自动”解决很多问题，如何才能打造良好的团队文化呢？

　　良好团队文化的源泉是什么？

　　良好团队文化的根本其实就是老板的管理思想了，不同的管理思想，老板会设计不同的部门规划和考核办法。

　　有朋友提到他的Boss喜欢工厂化管理，硬生生将员工分成两类人，设成两个部门。一个部门叫设计部门，负责需求和设计；一个部门叫实施部门，负责编码、测试、实施。设计部门通过一个任务管理系统向实施部门下单，实施部门根据这些工单来工作。该老板还设计了自以为很牛的考核办法，如果实施部门不能按时按质完成工单，则会影响考核；如果设计部门的工单被实施部门退回，则会影响设计部门的考核。于是两个部门之间的扯皮时间天天发生，以前完成一个工作很简单的，现在要扯来扯去。设计部门自认为需求、设计等文档已经写得很清楚，实施部门认为已经按照这些文档完成工作，或者是认为这些文档说得不够具体，要退单。当文档主要用来任务交接的时候，文档就会变成茶几上的杯具！

　　还有一些老板喜欢用bug数量、文档缺陷率、工期延误率等所谓客观的量化的数据来考核，同样只不过是杯具的另一种形式而已。

　　软件研发活动是人类复杂的高级智力活动，是需要team work的活动。如果明白这个道理，如果懂软件开发，就不会设计出这些傻瓜的管理措施，将软件研发团队的每个人变成机械人、卸责人。研发团队中的每一个人都应该是值得尊重的、有血有肉的、充满激情和战斗力的专家！

　　作为Team Leader应该怎样做？

　　Boss的想法我们无法控制，虽然无法从根本上改变公司的部门设计和考核制度，但作为Team Leader来说，在能力范围内还是可以做很多事情的。Team Leader应尊重每一位Team Member，平等地对待他们，充分发挥他们的潜力，给予足够的支持和成长空间等。对大家好，大家是知道的，将来会给你带来更大的回报。

　　下面一些法则供你参考。

　　法则1：一荣俱荣，一损俱损

　　项目组由项目管理、需求分析、软件设计、编码、测试、实施等各方面的专业人士组成，每位成员在自己专业领域内发挥主导作用，并可以为项目的成功提出非自己领域内的建议。最终的项目成果是各位专业人士共同努力的结果，所有人对最终成功承担同等的责任。

　　如果系统部署后，系统出现了一个严重缺陷，请问谁应该负责？

　　项目经理？测试？开发？……

　　都不是，而是项目组全体都要负责！

　　软件中某个功能做得很炫很好用，请问谁应该受到表扬？

　　项目奖励发下来了，请问谁可以分到这份奖励？

　　以上问题相信你应该有答案了！

　　项目组全体是共同承担连带责任的，要死一起输死，要活一起活。如果项目组中有人受罚，有人会得到好处，这个Team是很难团结和有战斗力的。

　　法则2：让 Team Member 当家作主

　　项目组中难免有部分成员是新手，经验和水平不足，某些工作可能一时不能胜任。而我们往往迫于项目进度压力，某些任务就会直接安排给他做，不让他提出自己的想法和见解。而我们这些接受了中国式教育的人，不少人喜欢以“接受任务”的方式来工作，而不是主动迎接挑战。于是有时候你可能遇到一些成员会跟你说“今天工作已经完成！”“我按照任务要求来做的，我没有错！”之类的活活会气死你的说话。