original="http://ittopic.gotoip1.com/qee/wordpress/wp-content/uploads/2013/07/employee-productivity-800x450.jpg" />
英文原文：There's No Such Thing As Software Productivity
通过反复的交谈，Bill Caputo 最终说服了我，让我相信了一些不可思议的事情。这些事情改变了我整个看问题的方式，也让我重新思考如何更好的工作。
软件开发中没有“生产效率”。
几乎正如 10 年前 Martin Fowler 发现的，用生产效率来衡量软件开发工作没有任何意义。原因就在于，它们不属于同一范畴。换句话说，生产效率不具有作为衡量软件开发工作的适用性。“今天创造了多少代码/软件？”这是一个没有意义的问题。即使可以这样测量，软件开发工作上的生产效率也不能以任何有意义的方式估计出它的商业价值。
这是因为，软件开发这种工作并不一定非要生产出什么东西。让我来举个例子：比如说，碰巧有两个程序员分别在开发两个完全一样的项目，他们在同一天被分配了相同的任务。第一个人，弗兰克，回到电脑前，写出了一个有 1000 行代码的框架，完美的解决了问题。代码规范书写，全面测试，有详细的文档描述部署和操作的流程。第二个程序员，皮特，转身去了公园，在哪里，他一边喂鸽子一边思考问题。大概在下午4：45 分，皮特溜达回办公室，删掉了 200 行代码，并部署了他的修改…问题就这样解决了。
这两个程序员，今天的“生产效率”谁的更高？答案是：这无关紧要。紧要的是，皮特解决了问题，同时为团队消减了长期维护的成本。弗兰克同时也解决了问题，但他因为生产了代码，提高了维护成本，所以，(在其它方面完全等效的情况下)他的方案差一些。而把皮特称作更有“生产效率”，则完全从实效性上扭曲了这个比喻。
我认为，优秀的程序员，他所做的事情应该是去除问题。而相对的则是生产出什么。所以，技术上的生产产物，例代码，文档，数据等，对于实现“去除问题”的目标来说，都是必要但有害的。这就是为什么有时候，这最有效的解决方案是 5 分钟的交流沟通。
对这种思考模式最有力的支持：当你用这种思维去看待软件开发后，很多棘手的、能看得到但无法测量的问题突然间变得很容易理解。例如，为什么当程序员和他们的客户隔离开时会显得缺乏效率。难道让他们避免打搅不会提高工作效率吗？答案是不会，按常理这会使他们更有效率…但也会造成他们更没效率。因为他们的工作是为客户解决问题，与客户的隔绝导致他们无法找到问题，确定问题。相反，跟有问题的人保持沟通能更有效的解决问题，甚至有时候你一天 8 小时手指根本不需要碰键盘。
这将我们引向了另外一个问题：为什么软件开发中维护成本相比起其它方面的成本显得很难接受？为什么我们永远无法在第一次做出“正确”的东西？一种解释就是，软件是一个对可能变化的问题的固定解决方案。当问题发生变化时(或我们对它的理解发生变化时)，问题和解决方案之间就出现了裂痕。这种随着问题的演变而不停的修补产生的缝隙的活动代价高昂。这也解释了为什么相对于其它软件项目，视频游戏通常的维护成本较低。这是因为它们需要解决的问题(让人们去买这个游戏，玩这个游戏)基本上是根据人类心理学，而这是不常变化的。
好的程序员和坏的程序员之间 10 倍之差的“生产效率”又是从何说起？每个人都说这是事实，但事实上没有人能直接的测评。我们的理论同样能解释这个问题。相比起工作效率来说，“解决问题”是一种更容易“调控”(金融词汇)的东西，使得产生一个数量级差别的效果很容易实现。解决问题需要的是信息和洞察力。你要么有，要么没有。不需要原材料，没有生产能力限制。并不是差的程序员打字速度慢。并不是如果他们努力就能做得更好。他们是缺乏这种高效解决问题的眼界和必要的信息。也许无法测量好程序员和差程序员在生产效率上的差别的原因就在于没有东西可测量。
还有很多现象都可以用这个理论来解释。如果你去找，一定能发现一些。最近我一直在搜罗这方面的案例….试一试，看看这个理论是否也体现在你的工作中。每当发现自己在说提高“生产效率/工作效率”时，问问自己是否是在用正确的方式解决问题。铭记在心：如果不通过生产任何东西就能解决问题，那生产出的任何东西都是一种浪费。
相关文章
