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

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 说到：

Eric Evans 曾介绍过一种“普适语言”，可以消除团队成员之间沟通的障碍，我非常喜欢这本书。Martin Fowler 对此也有过介绍： 普适语言是 Eric Evans 在 Domain Driven Design 一书中所使用的术语，用于描述如何在开发者与用户之间构建出一种通用且严格的语言。该语言应该基于软件开发中的领域模型，因此它应该是非常精确的，因为软件是无法处理模糊问题的。

Evans 表示在与领域专家沟通时使用普适语言是非常重要的，这有助于测试和领域模型的实现。此外，普适语言（以及模型）还应该随着团队成员对于领域理解的不断增强而不断演化。

普适语言的提出者 Eric Evans 对此则认为：

通过大规模使用基于模型的语言，我们可以构建出一个完整且可理解的模型，该模型由一些简单元素构成，这些简单元素最终能够表达出复杂的概念。领域专家应该对那些笨拙且无法传达领域含义的术语或结构持反对意见，开发者应该警惕那些影响设计的模糊之处与不一致性。

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

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