软件工程师

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