软件的质量问题引起的不仅仅是安全问题，更容易导致时间表失衡、预算超支、不能执行或执行可能性较低等问题的出现。因此，在软件开发过程中，任何个人（从初级程序员到高级经理）的不适当操作行为，都可能导致软件客户对我们交付的产品价值失去信心。

作为软件开发人员，取得正式的资格证书（证明一个人能够胜任某项特定的工作）并不是最重要的要求。一味强调开发人员具备资格证书，只会增加开支和助长官僚作风，并不会导致工作质量的提高。事实上，许多工作相当出色的人们并不具备其相关领域的学历。相反，很多取得学历的人们却并非能够胜任本职工作。

我们需要的是什么？
首先，我们需要采用一种方法，能够对软件工程师的操作和管理能力进行有效的测试评估。在dot-com时期，人们争相阅读《Learn （C++/Java/Visual Basic/etc） in 21 days》系列丛书，并在求职简历中声称自己是程序员。他们因此迅速争取到超过其自身价值的高额薪水，而具备真实技能的程序员也仅仅是处于相同的薪水标准。是的，"21 Days"系列丛书很多时候被认为是成为优秀软件工程师的入门书籍。但由于缺乏有效的评估和测试手段，使具备工作能力的人员与不能胜任工作的人员，基本上没有薪水或职位的差异。

在《人月神话》（Mythical Man Month）一书中，Frederick Brooks指出：一个不能胜任工作的程序员与一个优秀程序员相比较，两者之间的工作效率相差十倍。（Frederick同时指出：根据统计显示，各人的阅历与其工作效率之间并不存在直接的关联性。）

我们面临的问题是：如何对能力差异进行断定？在许多情形中，我们都能够意识到（至少是部分意识到）差异的存在。举一个例子：一个工作多年的程序员，他的新同事拥有35万美元的年薪，而他仅仅只有1.4万美元的年薪。他或许工作相当努力，但他努力工作所创造出的价值却极为有限，是否公司根本不值得雇用这样的员工？针对这种情形，让许多经理感到为难的是，他们缺乏勇气对一个努力工作的员工指出他不能胜任这份工作。事实上，我们能够认识到许多持有资格证书的程序员并不能胜任他们的工作，但由于没有及时纠正或改变这种状况，最终可能导致工作的严重失误。

概括的来说，有很大一部份所谓的"软件工程师"并没有做出任何有价值的贡献（尽管他们的工作相当努力），甚至可能影响整个团队的工作效率；然而，他们的薪水却与能够创造价值的人们保持一致。

从管理者的角度考虑，尽管我们的大多数程序员并不能为公司创造更多的价值，但不能以最低工资标准对他们进行支付；同时，也不能将他们全部解雇，而仅仅保留工作效率高的程序员。因为这将严重影响员工的士气。基于上述考虑，公司临时解雇所有的程序员，并将他们的工作转移到印度，可以用低于最低标准工资的待遇雇用到所需要的所有程序员，并且有希望获得最佳的工作效率。

这种做法的正确性和合理性不容置疑。对于管理者来说，解雇那些不能胜任工作的程序员或者试图改进他们的工作，都是很棘手的问题。因此，充分利用国外廉价的人力资源无疑是个明智的选择。

我们再来关注一下资格证书的问题。资格证书是衡量程序员能否胜任工作的标准么？回答是否定的。因为只有在实际工作中才能体现程序员的真实才能。许多有才能的人们并不具备正式的学历背景；同样，具备良好学历背景的人们却不一定能够胜任他们的工作。因此，经理应该对他们的开发人员进行实际有效的评估和考查。

我们要求经理客观公正地对程序员的工作能力进行评估。然而，有哪些确定的方法能够对软件工程师的个人工作表现进行跟踪测定呢？此外，我们还应该认识到，客观的测评工作可能仅仅只是一种形式。因为没有人愿意唱黑脸，将不能胜任工作的坏消息转告给当事人。

我们必须做出选择
当我们决定开除那些不能胜任工作的程序员时，面临的问题是：大部分不安全和缺乏功能性的软件却遗留了下来。在出现问题之前，人们基本上不会注意到这些不安全软件潜在的隐患。但是在项目的开发过程中，总是伴随着需求增长、逾期超支等问题。为什么会出现这些问题？归根结底，是由于人们对遗留的问题软件可能导致的不良后果，缺乏事先的预估和防范。因此，在系统的可靠性、安全性、可扩张性、以及可升级性的开发过程中，不得不耗费现有程序员的大量时间。正如他们所说的那样："我们对现有的代码库（Code Base）缺乏足够的信心。如果我们的时间再宽裕一个月，就能够对整个代码库进行重构（refactor）。然而我们缺少这一额外的时间。"此外，维持一个可扩展、可升级系统的正常运行同样会增加开支。

令软件工程师倍感沮丧的问题，是他们创造出的优秀软件得不到推广和应用。与一个具备更多稳定性的系统相比较，经营者更愿意交付具备更多特征的功能。原因很简单，因为这是用户所期望的。客户往往对代码本身并不感兴趣，他们更关注的问题是软件的实用性。他们会指责说："你使用的代码违反了面向对象（object-oriented）的所有设计原则。你将如何为软件增加新的特性？"或者提出："你应该对所有静态和综合的变量进行考虑，对系统进行重新编写，才能满足更多的扩展性要求。你编写的软件或许能够满足10个用户的要求，但它是否能够满足1000个用户的需求呢？"或者说："你完全没有考虑到事务处理的互隔离性问题，以及一致性问题。未来6个月中，一旦事务处理出现问题，我的数据库出现错误数据时，如何继续开展工作呢？"

此外，客户对系统也有诸多要求，例如："你使用EJB了么？我希望能够使用EJB的系统。我还需要使用XML......"我们没有理由对客户提出的诸多要求感到不满。作为软件工程师，帮助客户做出明智的决定正是他们的工作之一。

【 发表评论 0条 】