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个又为什么不是BUG？BUG的评价标准难道是程序员说了算？这个环节管理缺失。 4、5个不能工作的BUG修改问题有没有追究责任？增加新BUG是修改过程中不可避免的事情，但是如果有有效的单元测试机制，可以大大减少这种情况。这个环节管理缺失。 5、迭代是正常的，但是问题处理于发散而不是收敛发展，可见没有有效的管理调控。这个环节管理缺失。 6、过于乐观的时间表和不可能达到的最后期限，都表现出管理者的无知和无能。而在这样的情况下强行推出产品，那就是无知者无畏了。 7、这是对用户的不负责任，管理者要负最大的责任。 8、这样的情况还能发项目奖金，只能说管理者不是一般的愚蠢。 9、管理工作没有任何的改进，问题仍然处于发散迭代状态。管理工作依然没有到位。 10、拖欠测试部门工资体现出管理者对质量管理工作的忽视以及对人力资源管理方面一无所知。 11、送被收购者两个字：活该。送收购者两个字：瞎眼。 12、可见新管理者与原管理者半斤八两，都没有认识到问题的根本所在。不过也只有这样的管理者才会作出收购这种公司的决策。 13、历史的重演是必然的。 一个正常的企业或是项目，其运作必须应该是循环向上进行的。而保障这种运行的工作就是管理。而管理工作的主要内容就是控制，包括控制循环的节奏——不能太快也不能太慢，控制发展的方向——只能向上不能向下，控制运作的稳定——不能大起大落或时聚时散等。 而这一切，在这个例子中都看不到。 在这个笑话的例子中，一切都是以开发工作在驱动，这首先就是一个方向性错误，产品是为用户服务的，当然应该是以用户和市场作为驱动，并且结合自身的能力最终 确定工作的重点。这一错误折射出管理者对被管理的内容很不了解，只好任由比较了解的程序员摆布——事实上他们除了技术，并不会了解更多。 一个管理者如果对自己所管理的内容不了解，他就不可能管理得好。 这是一件毫无疑问的事，可是国内的软件业似乎总是不相信这一点。中国软件业中流毒最深的谎言之一就是： 管理者只要懂管理就可以，不需要懂技术。 其实这不过是那些无知无能无耻的管理者为了骗钱而编出来的，相信这句话的人必将付出金钱的代价。 其次是质量管理。基本的质量管理常识告诉我们，每次循环结束前，最重的工作就是总结改进。只有这样才能保证循环运作是向上发展，而不是失去控制地向下发 展。也只有有效的质量管理，才能保证迭代过程是收敛发展，并最终达到目标。但在这个例子中，这个部分显然是缺失的——其中虽然有测试部门，但是他们的作用 仅仅是质量管理中的质量检测环节，管理部分还是缺失的。 然后是人力资源管理。软件开发是一项劳动密集型的工作，虽然这是脑力劳动，但同样意味着人在因素在其中占有决定性的地位。而例子中未改完BUG的程序员 拿到项目奖金，而同样辛苦工作的测试人员却被拖欠薪资，除了表现出管理者对他们的工作内容的不了解，以及对质量管理工作的不重视以外，还表现出管理者完全 不会管人，这是一种谋杀团队的行为——谋杀一个团队远比建设要容易得多。 最后，这个失败的管理者把他的经历编成这个笑话，让大家看到他被程序员们害得多惨，把程序员妖魔化为一群骗子。但只要稍懂管理的人简单分析一下就可以看出来，只不过是这个人的无知和无能造成了他现在的结果，而把责任推给别人的行为更是表现出他的无耻。 作为身居高位的管理者，如果连应该承担的责任都要推卸，他们还能胜任什么事情呢。 |
联系客服
