需求分析中应该注意的问题（作者谈需求的功力可见一斑）

by webwlanin技术,项目管理

在做项目时，经常会碰到这样的事情.
客户向我们反映在和你们的工程师谈论需求时，他们总是满口答应没问题。可是，当他们做好以后，拿过来一看，根本就不是这么回事。而开发人员也在诉苦：用户什么都不懂，而且他们的需求老是变动，时间又这么紧,你让我们怎么办？
我觉得如果开发人员在做需求分析时,如果注意以下几点,也许可以避免被动的局面. 

1、掌握相关的行业知识
在和客户沟通之前，最好了解一下相关的行业知识。
有一个项目管理人员说：行业知识可有可无，作为需求人员，最重要的是和客户沟通。最好把客户讲的东西都记下来。然后，由项目组决定后，再把意见反馈给用户。这种沟通方式，既不能有效的发现问题，也容易延误项目时间。
案例：
小A某名牌大学毕业，公司为了锻炼他，特意安排他和一个比较重要的客户进行一次沟通。小A和客户电话联系，商定了见面的时间和地点。西装革履的小A提前十 分钟来到了见面的地点。一番客套之后，小A和客户就开始进入话题。客户开始谈他的需求，从项目背景到项目目的，从业务流程到相关部门和人员。客户兴致勃勃 地说着，小A手忙脚乱的记着。客户停下来，问小A你觉得我的观点有什么需要补充吗？小A老实地回答说，我对业务还不是很熟悉。客户一下兴致全无，对小A 说，等你对业务熟悉了，再来找我把。

2、重在沟通
沟通的方式可以是访谈和调研、会议、电话、电子邮件、小组讨论、模拟演示等不同形式。我的意见是最好是与客户面对面的沟通。金庸武侠小说中的高手过招，都是面带微笑，不露声色，比拼的是内力。面对面的沟通，就是比拼内力。所以，一定要把准备工作都做好了。
沟通其实也是在相互妥协。对用户合理的要求，要尽量满足。用户的一些不合理的要求，要想办法避免。要委婉地提醒用户，如果这样做，可能要增加项目时间，或者对运行环境有更高的要求。
沟通一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。

3、深究细节
不要等到项目做好后，才让客户发现问题。
客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终 出来的系统是很难完全符合客户的业务流程的.这时，在客户看来当然需要更改.但这种更改却被我们看成了需求的更改。既然是需求的更改,那么就需要增加项目 成本(资源)或延长项目时间。我看过一篇文章,说要要想项目成功,就得和用户建立亲密的伙伴关系.可是,这种以需求的更改为理由让用户从口袋里掏钱,亲兄 弟也不干阿.
所以,需求分析不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。

需求是最重要的工作，也是最麻烦的。 客户是不懂需求的，他们的脑海里面没有这个概念， 他们只希望你做出能用的系统 ，用着顺手就好
我认为做需求有几个地方是比较关键的
1.人际交往能力 。这是最根本的 不用多说
2.了解需求后及时做出demo让客户确认，确认后要签字。这一点非常重要，很多时候我们了解了需求就闷头开发，等开发完毕后，却不是客户想要的东西，造成巨大浪费；签字是为了让客户认真对待这个demo
3.能用就好，不要过多追求。程序员往往追求完美，想一下子把工作做到位；而最有效率的方法是尽快看到结果 然后再慢慢完善。在项目初期需求会经常改变，这样的目的也是避免把过多时间耗在无用的需求上。

做过软件的人都听过这样的抱怨：需求变化太快，软件系统经常要修改，都连续加班几个星期了……

通常面对这样的问题，要如何解决呢?

首先，问题的根源是：需求不断变化。

很多人都有这样的经历，在捕获需求时，根据客户的阐述，做了记录，然后开发出了软件，客户却说很多地方不符合他们的意思，又要求修改。

我们分析一下捕获需求过程中存在的问题。

客户很可能对软件方面的知识知之甚少，他并不知道你需要知道什么。

比如说，一个业务流程，从业务逻辑到能转化成软件实现很可能会有问题。这就是所说的信息化过程中需要进行的业务改造，因为能输入计算机，并输出结果的一 定是能进行形式化处理的内容，这也是很多企业员工抵制信息化的原因之一，因为信息化会导致人的因素会被相对削弱，他们的工作过程也会完全被透明化。

这样，我们就一定要让客户知道你要知道的是什么。如何做到呢?

对于产品类的项目，你的客户不是一个，那么就要广泛的去征求意见，需求调查问卷通常对全面了解客户需求有一定的作用。

对于特定客户，需要和他们直接沟通交流。

和客户交流要注意方式方法，不能盲目约见，下面是一些行之有效的方法。

一、 会面前做充分的准备

通常会面前的问题列表准备时间要远远多于会面的时间。通常客户在连续和你交谈2个小时之后，就会失去热情和耐心，这是大部分人的共同特点。所以充分的准备工作很重要。

如果你去客户那捕获需求，通常客户会说，我需要做一个什么样的系统，然后我可以用它来做这个，那个，还有那个……，然后就不知道该说什么了。这 时，你一定要拿出事先准备的问题列表，针对每个大的功能的每一个功能点进行提问，一个都不能放过。对非功能的需求也同样不能放过，如客户需要的系统至少连 续运行多少小时不出问题，系统在若干数量的访问者访问时的响应时间范围等。

如果你在会面前没有对客户提供的资料，表格等进行全面研究，对客户需求就不可能调查全面，你可能需要反复去约见他，这样你会给客户留下工作效率低的印象，他对你会逐渐的感到厌烦，对你未来的工作表现会失去信心。

二、让客户打开话匣子

对客户进行提问，引导客户说出他们的需求，是非常关键的，这里面的学问也是很大的。

有一些人通常会问这样的问题：“你们的工作流程是什么样的?”，这种问题是非常经典的无效问题。

当你向客户提出问题的时候，你可以先进行换位思考，如果有人问你这个问题你该怎么回答呢?是不是很好回答呢?如果连你也觉得这个问题并不好回答时，就需要考虑换个问法了。

通常人们在谈论自己很熟悉的东西时，都会有说不完的话，对于客户自己每天做的工作，他为什么没办法对你谈呢?

问恰当的问题，问能让客户打开话匣子的问题，你就胜利了。

这时你会面前的准备工作就显得尤为重要了，你要针对他们要做的软件的功能，一部分一部分的问，不能着急，要深入，并细致，对于他们如何处理这些事情的操 作习惯等都要重视，因为要改变他们的习惯，让他们适应你的软件的一种新的操作方法通常是会降低客户满意度的，甚至他们会要求你进行修改。

对于你对某些功能的猜想和假设，也一定要问客户，是不是根本就不需要，客户有时会碍于情面不好意思说出你的想法是没有必要的或是错误的，这时你一定要足够敏感，并勇于否定自己，这样会减少不必要的开发工作，也会给客户留下你很尊重事实的良好印象。

三、千万不要浪费客户的时间

和客户面谈时特别要注意一点，就是千万不能浪费客户的时间，让他觉得非常无聊，这是捕获需求最大的忌讳。

一旦你犯了这样的错误，你再想约见他就难了，他很可能不愿意再和你会面了。尤其是企业中的领导，他们通常是日理万机，能抽出时间和你会面，你应该感到很荣幸，因此要格外珍惜会面的时间。

这也是很多作需求的人员常常抱怨的问题，“客户经常没时间见我，我有什么办法”，如果你遇到了这类问题，你一定要反省一下自己，是不是曾经犯过这样的错误，下次一定不要再犯了。

四、搞清能正确回答问题的人

不同的问题需要问不同的人，需求中有很多是细小的操作级别的问题，也有很多是关乎全局的问题，这就要求一定要搞清楚什么问题去问什么人。

很多捕获需求的人员抱怨说，“客户答不上这些问题，他们自己都不知道要怎么做”，如果你碰到了这种事情，就要反省一下，你问对人了吗?

客户中有一些是大干部，有些是中层管理人员，还有操作人员。对于操作细节上的问题，一定要去问那些负责操作的人员，他们会更清楚每个步骤需要怎么去操作，如果你去问大干部这些问题，你通常会被搪塞，或者以工作太忙，还有其他得事等原因被打发掉。

对于关乎全局的问题，操作级别的人员给出的答案通常是不权威的，即便他们回答了你，你也一定要去大干部那里确认一下，再开始开发工作，否则你会后悔的。

五、发挥原型的效力

原型对于提高客户对软件的认知程度有很好的效果，他能使客户对软件有一个直观的认识，面对原型，他们可以更好地提出他们的想法和意见，尤其对那些对软件缺乏认识的客户。

对原型的修改，再确认，最后得到稳定的原型，这些工作会让需求更稳定，减少很多实施工作中的反复修改工作或者返工。

六、充分利用需求确认会议

需求确认会议通常由全体涉众(利益相关人)参加，这可是个确认需求的难得的机会，大家能聚在一起，这样的机会其实很难得，所以一定要珍惜。

在这种会议上，一定要先针对全局性的问题(与大家都相关的问题)进行交流，千万不要针对部分人感兴趣的问题讨论个没完没了，那样的话，不感兴趣的人会走 开的，那样你再想征求与他们相关问题的意见时就找不到人了。对于只跟个别部门或人员有关系的问题你可以单独找时间根他们讨论。