从一个笑话看软件开发管理(转帖)

从一个笑话看软件开发管理

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吗?这个环节管理缺失(三点关键:要把关键的功能列出Test Case,其余bug自己管理;另外重要功能或者技术难点应该预研;技术高手要自己培养)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 一个管理者如果对自己所管理的内容不了解,他就不可能管理得好。

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

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

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

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

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

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

时间: 2024-08-12 15:07:25

从一个笑话看软件开发管理(转帖)的相关文章

从一个程序员笑话看软件开发管理(转载)

从一个程序员笑话看软件开发管理 原文出处:猛禽的编程艺术 原文链接:http://blog.csdn.net/raptor/article/details/727299 有一个笑话是这样的: 1. 程序员写出自认为没有Bug的代码. 2. 软件测试,发现了20个Bug. 3. 程序员修改了10个Bug,并告诉测试组另外10个不是Bug. 4. 测试组发现其中5个改动根本无法工作,同时又发现了15个新Bug. 5. 重复3次步骤3和步骤4. 6. 鉴于市场方面的压力,为了配合当初制定的过分乐观的发

Atitit。 沉思录 与it软件开发管理中的总结 读后感

Atitit. 沉思录 与it软件开发管理中的总结 读后感 1. <沉思录>,古罗马唯一一位哲学家皇帝马可·奥勒留所著 2 2. 沉思录与it软件开发管理中的总结 2 2.1. 要有自己的培训..(不要总是依靠公共图书馆) 2 2.2. 要做大架构,优先大架构 2 2.3. 各司其职 世间万物各有所用,各司其职 2 2.4. 优秀的培训不一定能造就出强大的成员...但总比没有强 2 2.5. 顺势而为,随遇而安. 2 2.6. 看穿生死,淡泊名利. 2 2.7. 保持理智,洞察世事 2 2.8

成为一个优秀的软件开发工程师应该具备的能力

很多人都希望成为一个优秀的软件开发工程师,那么,成为一个优秀的软件开发工程师应该具备哪些能力呢? 下面是我个人的见解,有不同想法的欢迎提出讨论. 在学习之初,我们往往强调的是开发技术,对于软件开发者而言,这是最初级也是最简单的要求. 我们想要把我们学到的知识运用到工作生活中,就需要了解行业知识了. 遇到问题如何解决就需要我们的思维能力了. 只有把这三者有效的结合起来,我们才可能成为一个优秀的软件开发工程师.

开发的本质 从更高点看软件开发的侧重点

在技术外行人看来所有的程序员都是一样写代码的.但是深入之后才知道不同程序员他们具体负责的职责却如此千差万别.写PHP的不一定擅长前端,写iOS的不懂Java,写C++的搞不好Java. 我们先来看看技术语言的演变发展. 总体来说行业内是先有汇编,再有C.C++.Java.PHP这些语言.然后它们不断升级推动软件系统极大丰富.后面有了各种系统产品,浏览器等.拿浏览器举例,围绕这个方向又多了Java.HTML,CSS...各种技术.基于Java 又有了基于Java的各种框架,像jQuery. 表现在

关于看软件开发视频教程的感悟

如第一视频教程,包括网页设计,软件设计等. 网上培训视频教程,包括张孝祥Java视频教程,北大青鸟软件视频教程,达内网上视频教程,毕向东视频教程,后盾网,兄弟连PHP视频教程,硅谷学院,51cto视频学院,还包括李炎恢的北方网视频教程,以PHP网站开发,软件测试实战为基础,还有李全福从实例学习vc+视频教程,and陶益动态网页开发教程,收费的,但有效果. 有些教程很好,有些视频重理论,实战性不强,有些学员至今未搞懂,老师讲的太深奥,学员难以领悟. 有些学员英文不行,老师讲的英文代码太多,只有高水

怎么用snapman一个人在三天内开发出一个复杂的软件开发项目管理系统

snapman是一个简单而强大的团队协作软件,在上面的信息可以是数据.可以是规则.也可以是自动化代码:最重要的它是一个可以开发的协作平台,所有信息都可以作用到所有人或机器上,大大减少了工作的复杂度.软件开发项目是人类工程中对人力.脑力的配合度要求最高的项目.所以高智商的人才开发出各种项目定义实施流程:PMBOK.CMMI.IPD.SCRUM.XP等,这些流程的实施离不开各种强大的信息系统.但是这些系统只适合于大公司大流程,到单个的项目组级别很难为项目具体的特点做适配,随心所欲的更改.比如做10个

如何选择一个好的软件开发公司?

北京华盛恒辉科技有限公司,是一家北京软件开发公司,是专业的软件产品研发与销售企业,立足于数据领域,为航天.军工.铁路等大型企事业单位提供以数据为核心的平台级信息化解决方案.公司在数据采集.数据清洗.数据存储.数据计算与挖掘.大数据可视化等方面有着深入的研究. 同时,公司在高端软件定制方面,为中国航天科工集团.中国航天科技集团.火箭军(原二炮).总参谋部.总后勤部等提供军工信息化解决方案.

管理从砖瓦进化为人——浅谈传统软件工程到敏捷软件开发之变革

管理从砖瓦进化为人 --浅谈传统软件工程到敏捷软件开发之变革 前言 如果把软件开发过程比作修筑一座建筑的话,传统的软件工程方法对人的管理就像是把人化作一砖一瓦,秩序地堆砌,一层一层构建起摩天大厦. 显然地,人是不同于砖瓦那样的死物的.人作为一种复杂的动物,软件开发者会有喜怒哀乐,枯燥重复的工作内容会使他们提不起兴趣而缺乏激情:客户想法会随变动的现实而一天天有所转变,软件需求很难保持一成不变:开发者与测试者对于项目的认识会存在差异,而差异将导致效率的降低--因而传统的有些"反人类天性"的

精益软件开发与精益管理:从一家关闭的汽车厂重焕青春说起

“把工厂搞砸的是系统,不是人!” 弗里蒙特汽车装配厂是通用汽车于1982年关闭的工厂,当时劳资关系几近崩溃,工人们边工作边酗酒和赌博.1984年通用与丰田成立了合资企业:NUMMI,启动了弗里蒙特的工厂并重新雇用了原来的工人.这些工人被送到日本的丰田城学习丰田生产系统(TPS),之后短短三个月内,NUMMI就生产出了质量近乎完美的汽车,而且成本比以前工厂时期低很多. 持续改善 当你倾听那些从弗里蒙特装配工厂开始一直坚持到NUMMI结束的工人们谈话时,一个反复被提及的主题就是团队协作.这也许有些老