需求两个字放在不同的语境里会有不同的理解，首先给软件开发行业的需求下个定义：系统原来并不具备但用户又需要的内容可以归为需求，需求的实现伴随着沟通确认&开发实现。
只有自身具备开发能力的人才能沟通清楚需求吗？答案是否定的。总有人会说，我不是开发人员，我怎么搞的明白，这是不对的。
具备开发能力的人去沟通需求会有优势吗？答案是肯定的。需求的最终实现会经过先理解需求和落地呈现两个过程，落地呈现是把需求的理解具象化，这个转化过程往往还会反推出一些“疑点”，具备开发能力的人思考点容易陷入实现的困难。
具备开发能力的人就一定能沟通清楚需求吗？答案是否定的。不管哪个岗位总有人只能是个执行者。
我对既具备开发能力又能理清需求、既很懂业务又精通技术的人怀有敬佩之心。
举个例子，大家更容易理解什么是需求、需求沟通中容易出现的问题以及需求该怎么沟通。
100多年前，福特公司的创始人在市场上做调研，问所遇到的每一个人：“您需要什么样的交通工具？”，几乎所有的人都回答需要一匹更快的马。
福特：“您为什么需要一匹更快的马？”
消费者：“因为可以跑的更快。”
福特：“你为什么需要跑的更快？”
消费者：“因为这样就可以更早到达目的地。”
福特：“所以，你需要一匹更快的马的用意是？”
消费者：“用更短的时间、更快的到达目的地。”
在需求的沟通过程中，很多人往往是直接要结果（要一匹更快的马），而并没有传递真正的需求（更快到达目的地），而接受需求的人也比较容易或比较习惯直接就结果出方案，整个过程因为忽略了真实的需求，导致最终结果会差强人意，做了但不知道为什么做的情况时有发生。所谓行业的经验实际是在每次沟通中沉淀。
工作越久越怀有敬畏心，结论太快可能会有偏差。我常常这样表达：“你一定要知道，业务是一直真实存在的，只是用户当下提出来要解决而已，用户提出需求，一定要了解清楚需求的整个链路。你做的就是跟用户一起理解需求理清思路确定方案的过程。”
要习惯去问：“你要解决什么样的问题？目前业务流程是怎样的？要解决的问题处在流程中哪个环节？你想到的方案是什么？会有哪些影响？问题解决会有怎样的提升？”
很多时候，一个企业会使用多套系统，为了信息互通、效率最大化需要系统间整合以共同为企业服务，这类需求沟通的第一前提就是这几套系统在这个企业中的角色定位，清楚了定位，系统间的业务关系是什么，需要做什么就容易搞清楚。本末倒置的是不谈系统间关系，直接转化为能不能对接？这样的沟通会很累，也难让人回答。
很土的梳理，希望对看到的人能有帮助，祝大家Day day up！
