程序员的生产效率源于需求，而不是所谓工具！
你确定你真的知道到底是什么促使一个程序员高效率的吗？是因为使用了 VIM 和 Emacs 这些强大的编辑器，还是因为应用了最新的 Haskell Web 框架，抑或是你最喜欢的 NoSQL 数据库？
很抱歉，如果你注重的是工具、框架，甚至是进程，那么我不得不说，你搞错了！程序员生产效率的真正起源是：正确的需求。
为什么你作为一名程序员也必须关心需求——而不仅仅是业务人员！
显然，产品负责人必须满足客户的需求，因为这样才能让客户心甘情愿地付出报酬。对此，开发人员又是怎么看的呢？
曾经有位开发人员说出了大多数人的心声：“直接构建。出现了问题，就放到开发过程中处理。这样，至少我们开了一个头，不是吗？“
我们将这种做法称之为：马上启动，永不结束——一开始构建的时候没有什么准确的目标，至少有一半的内容是尚不清楚的。
你怎么知道你已经搞定了？
由于并不是 100％ 了解，所以在开发过程中状态百出——不知道接下来该做什么，自以为快完成了却这里忘记了，那里有遗漏，功能不匹配，等等等等。
再问一句，请问你打算如何去测试模糊不清的需求呢？对此，你最喜欢的 BDD 工具可是束手无策的哦。
如果输入是不明确的，测试也是不明确，那么输出就更加不明确了。
你总是特别有积极性，可能吗？
所有开发人员都非常讨厌的一种情况是，业务人员频繁地给出不确定的需求。这表明业务人员本身也不知道客户真正想要什么功能。
而这也意味着，很多你构建的东西会被弃之于垃圾桶。一鼓作气，再而衰，三而竭，程序员的积极性就是这样给磨灭的。
那么什么样的才算是正确的需求？
现在说说什么样的才是正确的需求？是不是一句写在索引卡上的话——“作为一个用户我希望能够使用亚洲建行信用卡”，好了，over，就 ok 了呢？
一个正确的需求包括（1）经过业务人员和程序员双向的沟通和研究；（2）反复解构，解构，再解构；（3）论证，其中包括我们常说的”angling“和”skinning“。
拜托！我是一个程序员，需求不是我的工作！
的确，在一些大型的公司中，通常会有专门的业务分析人员，其唯一的工作职责就是在递交给实施团队之前先整理出详细的需求说明。在理想的情况下，你只要照着说明编码就行了，但是，这在现实中显然是不可能的。
而且，企业越小，程序员的工作就混杂。可能你的老板就是这么认为的：你，作为一个” 程序员 “不仅要知道怎么实施，也应该清楚需求。
无论如何，你都应该专于此！
升级 AngularJS 2.0 路径肯定比研究客户的问题领域和需求要有趣的多——这是毋庸置疑的。
但是，你的技术技能，你的框架，还有你的算法都只是你每天日常工作的一部分。而所有开发工作的依据却是：正确的需求。
今日话题
关于需求和工具
欢迎在评论里面分享你的感受哦~
金秋十月与你饮酒论道
SACC2017
作为国内最受欢迎的架构师盛会，2017 第九届中国系统架构师大会 (SACC) 将于将于 2017 年 10 月 19-21 日在北京新云南皇冠假日酒店震撼来袭。
大会以 “云智未来” 为主题，云集国内外顶级专家，围绕云计算、人工智能、大数据、移动互联网、产业应用等热点领域展开技术探讨与交流。本届大会共设置 2 大主会场，18 个技术专场；邀请来自互联网、金融、制造业、电商等多个领域，100 余位技术专家及行业领袖来分享他们的经验；并将吸引 4000 + 人次的系统运维、架构师及 IT 决策人士参会，为他们提供最具价值的交流平台。
点击“阅读原文”，立享8.8折购票优惠哦~
原文作者：；如有侵权，请联系管理员删除。
