程序员的生产力始于需求而非工具

Marco Behler是一位资深开发者与市场营销人员，同时也是Marco Behler GmbH的创始人。近日，Behler就程序员生产力这一话题展开 论述 ，在社区产生了较大的影响。

你真的知道影响程序员生产力的关键因素是什么吗？是VIM、Emacs、最新的Haskell Web框架，还是钟爱的NoSQL数据库呢？遗憾的是，如果你将关注点放在工具、框架或是流程上，那就说明你还是没有真正理解这个问题。我认为，影响程序员生产力的关键因素在于起点：恰当的需求。

作为开发者缘何要关注需求，这难道不是业务人员的事情？

当然了，创始人/产品经理/团队领导必须要关注这个问题：到底开发什么才能让客户最终埋单呢？但如果从开发者的视角看待这个问题会是怎样的呢？有时会出现这样的情况，有人拍打桌子，大叫：现在就开始开发XYZ，马上，立刻，如果中间出现问题，我们可以在开发过程中解决，这就叫做先发优势？其实，我们称之为：尽快开始，但永远不会结束。很有可能你所开发的一半以上的东西都是不清晰的。

你怎么知道自己完成了？

意料之中的，如果不能完全理解需求，那就会导致遗漏，当问起什么时候能够开发完，你可能会忘记这个，忘记那个。那么该如何测试不清晰的需求呢？这与你喜欢的BDD工具没有任何关系。如果输入不清晰，那么测试也不会清晰，输出就更不清晰了。

你总是自我激励，对吗？

不过更糟糕的是，频繁的不清晰的需求是个信号，表示业务人员不确定客户到底想要什么。遗憾的是，这也表示你所开发的很多工作都是徒劳无益的。如果这种情况频繁出现，就会对程序员的生产力造成很大的破坏，这将严重影响程序员的效率。

到底什么才是恰当的需求？

那么什么才是恰当的需求呢？我认为恰当的需求的制定过程应该是下面这个样子的：

• 需要业务人员与程序员共同讨论，并且经过双方充分的沟通
• 需要不断拆解、拆解、再拆解
• 不断打磨，经得起推敲

我是个程序员，需求的事与我无关？

诚然，在大型组织中可能会有专门的业务分析师，他们的主要工作就是在将详细的需求规范传递给实现团队之前对其进行不断的完善。在理想情况下，这么做是完美无缺的，你只需坐在那儿编写代码就行，不过实际情况却并非如此。

无论怎样，组织的规模越小，程序员需要处理的事情就越多。公司的创始人可能会拍着桌子大喊：作为程序员的你不仅要负责实现，还要关注需求的产生过程。

无论怎样，你都应该成为一名专家

对于你来说，可能阅读AngularJS 2.0的升级路径要比与客户讨论领域问题和需求更有趣。不过，我想说的是，你的技术、对框架或算法的理解只是你每天工作的一部分。对于所有开发工作来说，基础则是“恰当的需求”。

Behler的文章刊出后很快就引起了众多开发者的共鸣，很多人也纷纷表达了自己的观点，下面摘录出一些典型反馈以飨读者：

Sasi Pallekonda说到：

说得太棒了！开发者不仅要考虑该使用什么数据结构，还需要思考需求是如何匹配最终用户的，并且如何实现需求，读了Behler的文章获益匪浅。

Erik Gollot说到：

非常同意文中的观点，我现在对如何编写好的需求非常感兴趣，因为根据我的经验，用户故事是远远不够的。

Wes Higbee说到：

非常同意Behler的看法，对此我也做了深刻的思考，我认为：方向要比速度更为重要，只有确定了方向，速度才是有意义的，否则再快的速度也是徒劳无益的。

Jussi Laasonen说到：

很多时候，人们都认为敏捷软件开发只不过是“立刻开始构建XYZ”，但事实上，这么做是完全错误的。

Fayez Naccache说到：

我已经在我们称之为精益创业的组织中工作6个多月了。在这期间，我们没有计划、没有详细需求、没有你所说的恰当的需求。我觉得工作起来非常困难，一点动力都没有。我很喜欢文中的这句话：尽快开始，但永远不会结束；还有无论怎样，组织的规模越小，程序员需要处理的事情就越多。这对我现在的工作来说真是再恰当不过的描述了。

Eliseu Monar说到：

Behler关于程序员生产力的文章引起了很多人的共鸣，同时他也专门编写了一本名为 Customer Requirements 的图书。该书主要介绍了需求沟通的技巧、如何恰当地进行估算、如何防止模糊不清的需求产生、如何与同事和客户沟通需求、恰当合理的需求对于开发与测试会产生哪些积极影响，同时每一章都提供了实际的例子供大家参考。

程序员生产力这一话题是每一个开发人员都津津乐道的，那么对于你来说，影响生产力的因素都有哪些呢，不妨分享出来我们一同讨论。