本文主要是介绍案例分析：项目组内踢皮球事件，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
摘要：你的项目出了严重问题，客户向你公司的领导投诉，你的领导兴师问罪要追究责任！这是测试的错？开发的错？PM的错？还是研发流程的错？中国教育制度的错？社会的错？反正、总之、一定、必须不是我的错！
事件回放：
某项目部署给客户后，重现了一些以前已经解决的问题，而这些问题测试时并没有出现。经检查，发现测试的版本不是部署的版本，不知道为什么老版本部署给客户了。领导要追究责任，于是大家各有说法：
开发人员说：我是按要求打标签的，没有问题。
测试人员说：我是在提交区中取版本来测试的，我没有出错。
实施人员说：我是按照开发给我的版本去部署的，我没有过失。
最后终于有人说：是之前已经离职的某某弄错版本号导致的。
思考：
1.该事件反应了什么问题？将来应该如何改进？
2.这么多问题中，最大的问题是哪个问题？
在继续往下阅读之前，建议你先写写对以上问题的想法，然后再继续阅读。
本事件并没有什么标准的答案，下面分析仅供大家参考，欢迎大家提出自己的想法！
事件的补充说明：
这是发生在我以前公司的真实个案。第一次听说时，我觉得很不可思议，也觉得非常的丢人！
客户当前版本是1.1，我们打算为之安装1.2版本，安装后客户反馈怎么以前已经解决的缺陷又再次出现了？检查后发现，原来我们安装的是1.0版本的程序。相当于大家辛辛苦苦地奋战了数天，最后竟然没有将工作成果给客户，而是将以前的东西给客户了。作为 软件公司来说，这是一个超级低级的错误！
经过检查，终于发现了问题的真正原因：开发人员A让实施人员B直接在他的电脑上取安装程序，而不是根据研发流程的要求到配置库中取，而该开发人员A让实施人员B所取的版本，是1.0版本的老程序，而不是最新的1.2。这个事情是实施人员B交代的，但开发人员A已经离职了，“死无对证”！
似乎整个事件需要负责任的就是这位已经离职的仁兄，而该仁兄已经离职，更加是百口莫辩。我的领导对于这样的结论，苦笑说：呵呵，这样好，推到一个离职的人身上！
问题1：某些人员失职，没执行流程！
开发人员A和实施人员B违反了相关规定，严重失职，应为此负责。而开发人员A已经离职，故应由实施人员B来负担主要责任。这样处理是否合适呢？
问题2：研发流程和公司制度有漏洞，应进一步改善！
研发流程虽然规定了要从配置库中取安装程序，但没有版本 确认的步骤，而且安装程序应该由配置人员提供，而不应该由实施人员直接问开发人员要，这是流程中需要改善的。
于是 配置管理员提出建议：规定所有的安装程序只能由配置管理员提供，不能通过其他途径！
但项目经理、开发、实施都反对，因为经常需要加班，往往在加班的时候需要提供安装程序，但这个时候配置管理员往往已经下班了，无法向配置管理员要安装程序。如果配置管理员就算没事干都好，愿意一起加班的话，可以这样规定。
于是配置管理员就再无意见了……
另HR提出，此事其实是开发人员A付主要责任的，出现这样的问题原因之一是离职交接没有做好，工作没有检查好。此意见一出，项目组、负责交接A工作的开发、同意A离职的部门经理，几乎全部晕倒了！交接已经做得很不错了，什么问题都要防住，你叫这个交接怎样做？
研发流程和制度确实需要不断完善，但如果老是从细节上规定，是不是有点本末倒置呢？研发工作中的问题总是很多的，不太可能规定所有细节的，而且一旦规定了一些细节，似乎避免了一个问题，但会带来更多的问题。
问题3：喜欢做好好先生、好好小姐！
事件中其实很多人大概知道问题所在的，但就不指出来，不想得罪人，要做“好人”。如果要追求责任，那么最好将错赖在一个不能追究责任的人身上，就是那位可能是很无辜的已经离职的仁兄。或者将错赖在制度和流程上，这招是最绝的，没有人需要负责，这是制度的错、社会的错！
问题4：没有人首先从自己身上找原因，每个人首先想到的是推卸责任！
研发工作中的很多成果，是经过一系列的环节和各人的配合作出来的，任何一个环节有问题，都可能会导致最终成果出问题。那似乎将各环节责任、流程等定义好，就可以很好地追求责任了？
如果某个环节都留下一些隐患，但不至于马上出问题，但经过多个环节累积之后，问题爆发！这时应该哪个环节负责呢？
如果前面某个环节出现一些问题，但下一个环节的人发现了并及时提出来，最终不影响最终成果，这是不是一种很好的效果呢？
如果每个人除了做好本职工作，还主动提醒他人，主动提供一些有利于项目的建议，帮助项目成功，这是不是非常好呢？
软件研发中的问题，往往不是某个环节造成的，而是各种因素作用逐步导致的。项目需要团队一起努力、互相纠正、互相提醒，每个人都应该为项目的最终成功负责！某项目出问题了，是不是应该整个项目组都应该负责呢？是不是大家应该首先从自己身上找原因呢？
哪个问题更加严重？
个人认为问题4是最严重的问题，流程、制度、职责等这些，如果为了解决某一问题而去修改和细化，可能会陷入无休止的类似工作中。这和修复一个bug的道理是一样的，每修复1个bug，可能会带来10个bug。过于从细节上细化流程和制度，我个人是不太赞同的，会陷入某种死循环。
我们喜欢说依法办事，往往用法律来比喻，我们研发过程也需要有法可依。法律规定的一般是不能做什么，但我们流程中规的的往往是必须做什么、应该做什么等，一旦规定应该怎样做，就很容易出问题。研发活动是很复杂的智力活动，不应该在一些细节上套太多的框框条条。
做好 团队建设，树立良好的团队观，项目团队应该是“一荣俱荣，一损俱损”的！要打造这样的团队是不容易的，但也不是很难，其实取决于公司领导的管理思想。以目标来驱动，鼓励创新，允许犯错，奖励自我批评，这些都有助于良好的团队建设。但有些领导喜欢工厂化管理，喜欢将工作细化，喜欢根据工作职责来考核，喜欢根据问题多少来考核，这样难以避免这些踢皮球事件了。
这个事件我有什么责任？
说了这么多别人的问题，我是不是应该从自己身上找找原因呢？
我不直接负责该项目工作，是公司的常务副总，公司中的大部分员工都是经过我 面试进来的，我一直在尽力打造良好的团队文化，而研发流程大部分是由我制定的，或者是经过我批准的。要兴师问罪的是公司的大领导，不是我，其实如果要问起罪来，可以说公司内部的跟研发相关的所有问题，我都需要负责任！因为这些事基本上都是我管的。
出现踢皮球事件，我觉得很无奈。自己一直以来期望做到的团队“一荣俱荣、一损俱损”，在事到临头的时候，只是一种口号而已，我需要检讨自己的做法和想法。那种美好的团队建设可能只是一种乌托邦，可能难以实现甚至无法实现，但我觉得我还是应该继续为之努力的。
其他的一些想法：
这只是一个小小的案例，但相信很多朋友会经历过类似的情况。推卸责任可能是人的本能反应吧，我也会这样。大家都能主动从自己身上找原因，这可能是一个遥远的梦。
我曾经试过参加一个会，两个高层在PK，老板在一旁看，PK一大通后，最后那项大家都不想干的工作落到了一直没有出声的我的头上，刚才PK的两个人，都一致同意让我来做这项工作！我只能说：很无语……
有些事情我们可能控制不了，但如果咱们能带领一个团队的话，我们应该在能力范围内做一些对团队各人都有益的事情，尽量打造好的团队气氛，挡住影响团队气氛的外部的不利影响。对你的团队成员好，将来得到的回报肯定会远远大于你的付出！
作者：张传波
创新工场创业课堂讲师
《火球——UML大战需求分析》作者
www.umlonline.org 创办人
这篇关于案例分析：项目组内踢皮球事件的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
