关于软件开发的笑话有很多，下面这个是我刚在QQ群里的看到的：

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的程 序员拿到项目奖金，而同样辛苦工作的测试人员却被拖欠薪资，除了表现出管理者对他们的工作内容的不了解，以及对质量管理工作的不重视以外，还表现出管理者 完全不会管人，这是一种谋杀团队的行为——谋杀一个团队远比建设要容易得多。

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

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

担任项目经理的职位一年了，尽管自己到现在为止仍然是个不合格的项目经理，但是毕竟站在这个岗位上，主要从事的还是设计和程序实现的工作，加上自己也有志于在这个方向上发展，所以做一个年度总结是有必要的，也希望领导给以指点。

这一年来，主要管理了有两个项目，一个是EAI课题及A公司项目，一个是B公司的二次开发。

EAI课题是今年5月份开始提出来，并由我来担任项目经理的。我很积极的开始工作，并努力配合前方调研和方案建议的撰写。从5月份到7月份是一个EAI课题的调研和需求分析阶段。需求分析由我撰写，并通过公司内部评审；8月份进入设计阶段，概要设计和数据设计由我撰写并通过公司内部评审。9月份开始编码，并在9月底完成代码的编写。

10月份由于公司接到A公司项目的需求，和EAI课题内容很吻合。所以就把原EAI课题实施计划顺延，改变由以A公司的应用集成为主线。10月中旬进入调整期，并在10月底对A公司进行调研和分析，并写出概要设计，通过公司内部评审。

11月份开始编码，并使用两周的时间完成极限编程，11月下旬开始在A公司进行安装调试。其间因为A公司内部的需求有所改变，所以开发也有所影响，致使在12月上旬正式在A公司安装调试，并顺利通过项目验收。

12月份我们就主要开始对EAI课题的另外一个实施方－B公司进行调研编码，在12月份中旬完成对B公司的编码开发工作，12月份下旬安装调试，并顺利通过课题验收，同时得到了用户的认可和肯定。

在EAI课题及A公司项目这个项目当中，时间紧凑也富有挑战性，我合理的安排时间，并对手下的资源充分利用。根据我手下的资源的一些特性，对其分派的任务也有所不同，以下是我在这个项目当中，对资源管理的一些总结：

学 生们可能对企业的实际业务不很了解，就是即使把企业的实际业务抽象的很好，并让学生们去理解，他们对其业务也有很多的疑惑。所以，我对学生在编码上的做法 是：把企业的实际业务抽象成一种计算机语言，并告诉学生这些类主要完成什么功能，对数据库是如何操作的，应该注意的是什么和完成的操作效果是什么。这样做 的话，学生往往能够很快的完成自己的工作。

对项目的控制和质检是必要的，这个对项目的完成质量有很大的关系。因为我的编码实现主要是由学生来完成，所以我对代码的质检是对其代码的检查。对其处理的事务进行细致的查看，所以项目的进度得到了有效的控制。

其次，另外一个项目是对B公司项目的二次开发。

我们主要的工作是二次开发的工作，是对DYNAPDM系统的二次开发，所以我们从刚刚开头时，没有急于编程，而是努力学习，并让手下的资源完成一些TEST功能实现，等到大家对之比较熟悉了，我们才开始编码，尤其这一段时间我们对DYNAPDM的开发总结进行了归档。

等 到我们正式接受B公司的需求并二次开发时，我们的二次开发就开始变得朴素迷离了，因为B公司项目需求的多次变更和完成模板的多次调整，使得我们的二次开发不断 的跟着他们的需求在变更。为此，我们严格了他们对我们的需求，每一个需求是需要共同确认才予以编程，使得后来的编码才有所规范。最终及时完成了B公司项目的 二次开发。

从对DYNAPDM的二次开发来说，我们有以下的总结:

首先，DYNAPDM现行版本不太稳定，导致我们在开发时有所影响。

其次，B公司项目的需求不是太多，也不是太难，但是他的需求多次调整牵扯到我们的很多精力，并且有很多的工作都是无效的，所以以后在对企业调研时应该深入细致的为用户的需求进行判断和确认，免得用户的“拉抽屉”的需求。

最后，我们的员工很努力，虽然项目更改很多，但是我们还是最终及时的完成的项目的二次开发。

总之，这一年又要过去了，虽然工作比较累，但是我在其中也学习到了很多的管理知识，尤其是建立一个规范、高效的开发团队上我已经积累了很多经验。明年将是技术革新最重要的一年，WEB2.0将占据我们的技术生活，很快他将成为业界开发的新的标准。对于我们以技术为主的软件公司来说，应该珍惜这次变革的机会，成为应用这个技术为先的公司，为赢得市场先机而努力。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　我

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2005-12-20