需求分析其实是两个动作：了解需求，分析需求。那么这次要讲的就是如何了解需求。

    需求在我们的日常工作中其实有两个来源：别人告诉你的和自己找的。今天讲沟通，因此侧重点在讲别人告诉你的。其实做需求分析我觉得和传统意义上的工程师是不一样的，它不仅仅需要分析能力，也需要非常强的沟通能力。在大多数情况下，我们遇到的需求都是别人提出来的，是和对方的工作或者业务相关的，因此业务方在这个需求上是最有发言权的。所以听对方说是最直接，最高效的途径。当然每个需求分析师都了解这点，这都不知道不用混了。那么我要重点讲的就是怎么让他们讲出他们想的。

    看一些沟通的书会发现，里面经常会提到“说的不是想的东西”。为什么会这样呢？书上说信息传递分为以下几步：脑子想的－》表达的－》听到的－》理解的。也就是说信息从它脑子到你的脑子，可能发生了转换。这是在沟通中最容易犯的错误，或者说是发生的问题。如果不能解决这个问题，那么就是不能做正确的事，那么后面你做的越正确，离目标就越远了。那么怎么解决这个问题呢，我的经验总结一下，有以下几点：

第一：要有准备。其实一般我们在接手需求之前，都会有个书面的东西提上来。当然这个东西可能很简单。但是不要小看这个东西，因为这个可能才是用户经过深思熟虑的东西，毕竟写下来的东西要比口头说的慎重。那么上次说了那么多要准备为什么要准备，就是准备这个东西，看了它的需求，了解了系统，那么这个时候你应该在你的脑子里面有了一个大致的设计了，这个时候和用户在交流中你就可以判断：如果和你想的基本一致，那么相当于两次校验，基本上可以确定用户要表达的或者它想要的就是这个东西；如果和你想的大相径庭，那么就要去考虑，是它上次说的不对，还是这次说的不对，或者你想的有问题，最麻烦的就是需求真的变了，这个后面还会说，因为既然现在会变，就说明它的需求根本就不确定，这种情况怎么处理，后面会讲到。

第二：有做好充分沟通必须的“前戏”。先说一些无关紧要的话，放松一下情绪。紧张是很容易忘的，大家应该都遇到过嘴边有话说不出来的情况，怎么想都想不起来，这种一般都会在放松之后重新又想起来。

第三：学会提问的技巧。简单的说就是正面提问和反面提问。其实做需求有时候需要很罗嗦，罗嗦的目的不是因为自己不明白，也不是为了把对方搞晕。罗嗦就是为了证明对方不晕。比如你先证明的提问，问她这样有什么好处，目的是什么。然后反过来问她，如果不做有什么坏处。对于需求来说后面才是最重要的，也就是说你需要搞清楚“不做有什么坏处”。因为所有的需求都是需要成本的，你不做如果对它没有坏处的话，那么做了肯定对自己或者自己的部门有坏处。

第四点我觉得就是要和客户搞好关系，这方面何必是大师。其实这个和第二点有相似的地方，熟了，你可以更加深入的了解他的工作，甚至他的生活，比如你熟悉的某个mm天天加班，但是其实完全可以通过改进系统提高效率，但是她不知道要提需求，那么一个好的做法就被埋没了。同样你在拒绝她的时候更加容易让对方接受，毕竟大家熟么，不至于让对方觉得你是耍官腔，故意不做。可以大大的减少这种误会。

第五：你应该觉得自己是个专家。这点在很多新人身上尤其突出，不自信。客户说什么就是什么。可能和我们客户第一的价值观有关系。尊重专业。在业务上她是专家，这点我们从不否认，但是现在你们谈的是如何做一个系统，她是在系统上工作。你要听取她的建议，但是这永远只是建议，否则全都听客户的还要你干吗？当然这里不是说你是专家了就nb了，就不掉用户了，不是这样的。你应该是以一个咨询师的身份出现在她的面前，让她觉得你是可以信赖的，你是来真正给他解决问题的，这样她自然会对你说的话坚信不移，沟通就不会总停留在讨价还价的事情上。当然要做到让对方信任，提高自己的功力是必修课。这是没有捷径可以走的。

前面三点是战术性的，讲的是交流过程中具体怎么做，而后面两点则是慢工，需要积累的。

从整个了解需求的过程上讲，一般是这样几步：了解需求，形成文档，文档确认。这是大家都知道的，但是我还是建议采用迭代的方式，当然这样需要很多时间，对客户的素质也有很高的要求，就当是个理想吧。了解了用户要什么，那么下次我们要讲的就是如何抽象，如何分解，如何找到用户真正想要的东西。请看下集《分析》。