在网上看见有一个笑话是这样的：

  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. 历史的重演是必然的。

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

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

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

一个管理者如果对自己