思步网

楼主: 放手去爱
打印 上一主题 下一主题

[心得体会] 笑话?软件开发管理

[复制链接]
业界流传着这样一个笑话:

1. 程序员写出自认为没有Bug的代码。

2. 软件测试,发现了20个Bug。

3. 程序员修改了10个Bug,并告诉测试组另外10个不是Bug。

4. 测试组发现其中5个改动根本无法工作,同时又发现了15个新Bug。

5. 重复3次步骤3和步骤4。

6. 鉴于市场方面的压力,为了配合当初制定的过分乐观的发布时间表,产品终于上市了。

7. 用户发现了137个新Bug。

8. 已经领了项目奖金的程序员不知跑到哪里去了。

9. 新组建的项目组修正了差不多全部137个Bug,但又发现了456个新Bug。

10. 最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职。

11. 公司被竞争对手恶意收购。收购时,软件的最终版本包含783个Bug。

12. 新CEO走马上任。公司雇了一名新程序员重写该软件。

13. 程序员写出自认为没有Bug的代码。

要我说,如果真有这样的公司,不倒闭对不起人民。

这个笑话从程序员开始,到程序员结束,从头到尾都在说程序员的不是。但是我要说的是,这完全是管理者的失败,从整个过程中,看不到任何管理工作。

这种管理者不但无知无能,还很无耻——将自己的失败责任推给程序员。

1. 程序员凭什么证明他的代码没有Bug?有Test case吗?有Code review吗?这个环节管理缺失。

2. 测试发现Bug有进行Bug管理吗?有跟踪吗?这个环节管理缺失。

3. 凭什么证明程序员已经把那10个Bug修改好了?另10个又为什么不是Bgu?Bug的评价标准难道是程序员说了算?这个环节管理缺失。

4. 5个不能工作的Bug修改问题有没有追究责任?增加新Bug是修改过程中不可避免的事情,但是如果有有效的单元测试机制,可以大大减少这种情况。这个环节管理缺失。

5. 迭代是正常的,但是问题处理于发散而不是收敛发展,可见没有有效的管理调控。这个环节管理缺失。

6. 过于乐观的时间表和不可能达到的最后期限,都表现出管理者的无知和无能。而在这样的情况下强行推出产品,那就是无知者无畏了。

7. 这是对用户的不负责任,管理者要负最大的责任。

8. 这样的情况还能发项目奖金,只能说管理者不是一般的愚蠢。

9. 管理工作没有任何的改进,问题仍然处于发散迭代状态。管理工作依然没有到位。

10. 拖欠测试部门工资体现出管理者对质量管理工作的忽视以及对人力资源管理方面一无所知。

11. 送被收购者两个字:活该。送收购者两个字:瞎眼。

12. 可见新管理者与原管理者半斤八两,都没有认识到问题的根本所在。不过也只有这样的管理者才会作出收购这种公司的决策。

13. 历史的重演是必然的。

一个正常的企业或是项目,其运作必须应该是循环向上进行的。而保障这种运行的工作就是管理。而管理工作的主要内容就是控制,包括控制循环的节奏——不能太快也不能太慢,控制发展的方向——只能向上不能向下,控制运作的稳定——不能大起大落或时聚时散等。

而这一切,在这个例子中都看不到。

在这个笑话的例子中,一切都是以开发工作在驱动,这首先就是一个方向性错误,产品是为用户服务的,当然应该是以用户和市场作为驱动,并且结合自身的能力最终 确定工作的重点。这一错误折射出管理者对被管理的内容很不了解,只好任由比较了解的程序员摆布——事实上他们除了技术,并不会了解更多。
一个管理者如果对自己所管理的内容不了解,他就不可能管理得好。

这是一件毫无疑问的事,可是国内的软件业似乎总是不相信这一点。中国软件业中流毒最深的谎言之一就是:

管理者只要懂管理就可以,不需要懂技术。

其实这不过是那些无知无能无耻的管理者为了骗钱而编出来的,相信这句话的人必将付出金钱的代价。

其次是质量管理。基本的质量管理常识告诉我们,每次循环结束前,最重的工作就是总结改进。只有这样才能保证循环运作是向上发展,而不是失去控制地向下发展。也只有有效的质量管理,才能保证迭代过程是收敛发展,并最终达到目标。但在这个例子中,这个部分显然是缺失的——其中虽然有测试部门,但是他们的作用仅仅是质量管理中的质量检测环节,管理部分还是缺失的。

然后是人力资源管理。软件开发是一项劳动密集型的工作,虽然这是脑力劳动,但同样意味着人在因素在其中占有决定性的地位。而例子中未改完BUG的程序员拿到项目奖金,而同样辛苦工作的测试人员却被拖欠薪资,除了表现出管理者对他们的工作内容的不了解,以及对质量管理工作的不重视以外,还表现出管理者完全不会管人,这是一种谋杀团队的行为——谋杀一个团队远比建设要容易得多。

最后,这个失败的管理者把他的经历编成这个笑话,让大家看到他被程序员们害得多惨,把程序员妖魔化为一群骗子。但只要稍懂管理的人简单分析一下就可以看出来,只不过是这个人的无知和无能造成了他现在的结果,而把责任推给别人的行为更是表现出他的无耻。

作为身居高位的管理者,如果连应该承担的责任都要推卸,他们还能胜任什么事情呢。




上一篇:谁有通信设计院项目管理的台账表格啊?最好是全套的. 1132727599@qq.com
下一篇:项目管理培训(3)之项目生命期与组织
[发帖际遇]: 放手去爱 在论坛发帖时没有注意,被小偷偷去了 4 (金) 金币. 幸运榜 / 衰神榜
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 支持支持 反对反对
回复 论坛版权

使用道具 举报

我也来顶一下..
很有借鉴意义,先收藏了,谢谢楼主。
很有借鉴意义,先收藏了,谢谢楼主。
路过 帮顶 嘿嘿
支持,赞一个
好帖是需要鼓励的~
看帖要回,回帖才健康,在踩踩,楼主辛苦了!
我是个凑数的。。。
不错 支持一个了
我了个去,顶了
顶不错 支持下
路过的帮顶
还不错哦,如果再能多分享一些就perfect了!
以我的经验来看,楼主的想法是可以执行的~
您需要登录后才可以回帖 登录 | 注册

本版积分规则



思步组织思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心
© 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 顾问式管理培训
返回顶部