思步网

查看: 34621|回复: 21
打印 上一主题 下一主题

[案例分析] 项目组内踢皮球事件

[复制链接]
项目组内踢皮球事件


       事件回放
      某项目部署给客户后,重现了一些以前已经解决的问题,而这些问题测试时并没有出现。经检查,发现测试的版本不是部署的版本,不知道为什么老版本部署给客户了。领导要追究责任,于是大家各有说法:
       开发人员说:我是按要求打标签的,没有问题。
       测试人员说:我是在提交区中取版本来测试的,我没有出错。
       实施人员说:我是按照开发给我的版本去部署的,我没有过失。
       最后终于有人说:是之前已经离职的某某弄错版本号导致的。

     思考
     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的两个人,都一致同意让我来做这项工作!我只能说:很无语……

     有些事情我们可能控制不了,但如果咱们能带领一个团队的话,我们应该在能力范围内做一些对团队各人都有益的事情,尽量打造好的团队气氛,挡住影响团队气氛的外部的不利影响。对你的团队成员好,将来得到的回报肯定会远远大于你的付出!





上一篇:需求工程结构图
下一篇:PMBOK第五版的6大变化
[发帖际遇]: delia2010 被钱袋砸中进医院,看病花了 5 (金) 金币. 幸运榜 / 衰神榜
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 支持支持 反对反对
回复 论坛版权

使用道具 举报

这种事情很普遍,大多是没有责任心造成。
很受用,收藏了。
[发帖际遇]: 天线宝宝 乐于助人,奖励 2 (金) 金币. 幸运榜 / 衰神榜
说到心坎了,收藏备用。来自: Android客户端
勇于承担责任,
写得真好,学习分析问题的方法和思路。。。
[发帖际遇]: 一抹淡然 发帖时在路边捡到 2 (金) 金币,偷偷放进了口袋. 幸运榜 / 衰神榜
以我的经验来看,楼主的想法是可以执行的~
追求一個夢幻團隊一直是所有管理者與團隊成員的夢想,雖然我至今尚未覓得,不過我仍懷抱希望...
[发帖际遇]: dommay 在网吧通宵,花了 1 (金) 金币. 幸运榜 / 衰神榜
楼主总结的很有意思,赞一个~学习到了!
[发帖际遇]: pmp2015 在论坛发帖时没有注意,被小偷偷去了 3 (金) 金币. 幸运榜 / 衰神榜
不错 支持一个了
看帖要回,回帖才健康,在踩踩,楼主辛苦了!
very good.
我了个去,顶了
看帖要回,回帖才健康,在踩踩,楼主辛苦了!
不错 支持一个了
very good.
您需要登录后才可以回帖 登录 | 注册

本版积分规则



思步组织思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心
© 2007 思步网 浙ICP备10212573号-4(首次备案号:浙ICP备07035264号)|邮箱:service#step365.com(将#换成@)|服务热线:0571-28827450
在线培训课程|求职招聘|思步文库|官方微信|手机APP|思步问答|微博平台|官方QQ群|交流论坛|软件工程透析|关于我们|申请友链|
点击这里给我发消息     点击这里给我发消息
思步 step365 过程改进 CMMI中文 质量保证 质量管理 流程体系 需求跟踪矩阵 敏捷开发 Scrum 软件度量 项目评审 全员改进 流程管理 人力资源 6sigma 信息安全 ISO27001认证 IT服务管理 ISO20000认证 ISO9000认证 软件测试 SQA 配置管理 IPD 软件工程 PMP认证 PMP试题 PMBOK中文 精益研发 agile 顾问式管理培训
返回顶部