需求分析中的注意点

在做项目时，经常会碰到这样的事情：客户向我们反映在和你们的工程师谈论需求时，他们总是满口答应没问题。可是，当他们做好以后，拿过来一看，根本就不是这么回事。而开发人员也在诉苦：用户什么都不懂，而且他们的需求老是变动，时间又这么紧,你让我们怎么办？
我觉得如果开发人员在做需求分析时，需要注意下面几点：
一、掌握相关的行业知识，会前做好充分准备
通常会面前的问题列表准备时间要远远多于会面的时间。通常客户在连续和你交谈2个小时之后，就会失去热情和耐心，这是大部分人的共同特点。所以充分的准备工作很重要。如果你去客户那捕获需求，通常客户会说，我需要做一个什么样的系统，然后我可以用它来做这个，那个，还有那个……，然后就不知道该说什么了。这 时，你一定要拿出事先准备的问题列表，针对每个大的功能的每一个功能点进行提问，一个都不能放过。对非功能的需求也同样不能放过，如客户需要的系统至少连 续运行多少小时不出问题，系统在若干数量的访问者访问时的响应时间范围等。如果你在会面前没有对客户提供的资料，表格等进行全面研究，对客户需求就不可能调查全面，你可能需要反复去约见他，这样你会给客户留下工作效率低的印象，他对你会逐渐的感到厌烦，对你未来的工作表现会失去信心。
在和客户沟通之前，最好了解一下相关的行业知识。有一个项目管理人员说：行业知识可有可无，作为需求人员，最重要的是和客户沟通。最好把客户讲的东西都记下来。然后，由项目组决定后，再把意见反馈给用户。这种沟通方式，既不能有效的发现问题，也容易延误项目时间。
二、重在沟通


沟通的方式可以是访谈和调研、会议、电话、电子邮件、小组讨论、模拟演示等不同形式。我的意见是最好是与客户面对面的沟通。金庸武侠小说中的高手过招，都是面带微笑，不露声色，比拼的是内力。面对面的沟通，就是比拼内力。所以，一定要把准备工作都做好了。
沟通其实也是在相互妥协。对用户合理的要求，要尽量满足。用户的一些不合理的要求，要想办法避免。要委婉地提醒用户，如果这样做，可能要增加项目时间，或者对运行环境有更高的要求等等。沟通一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。如果是比较正式的沟通，还需要将会议记录以邮件的形式发给双方相关主要人员确认，抄送会议中的其他相关人员。
沟通中须注意下面几个问题：
1、让客户打开话匣子
对客户进行提问，引导客户说出他们的需求，是非常关键的，这里面的学问也是很大的。有一些人通常会问这样的问题：“你们的工作流程是什么样的?”，这种问题是非常经典的无效问题。当你向客户提出问题的时候，你可以先进行换位思考，如果有人问你这个问题你该怎么回答呢?是不是很好回答呢?如果连你也觉得这个问题并不好回答时，就需要考虑换个问法了。通常人们在谈论自己很熟悉的东西时，都会有说不完的话，对于客户自己每天做的工作，他为什么没办法对你谈呢?问恰当的问题，问能让客户打开话匣子的问题，你就胜利了。这时你会面前的准备工作就显得尤为重要了，你要针对他们要做的软件的功能，一部分一部分的问，不能着急，要深入，并细致，对于他们如何处理这些事情的操 作习惯等都要重视，因为要改变他们的习惯，让他们适应你的软件的一种新的操作方法通常是会降低客户满意度的，甚至他们会要求你进行修改。对于你对某些功能的猜想和假设，也一定要问客户，是不是根本就不需要，客户有时会碍于情面不好意思说出你的想法是没有必要的或是错误的，这时你一定要足够敏感，并勇于否定自己，这样会减少不必要的开发工作，也会给客户留下你很尊重事实的良好印象。
2、搞清能正确回答问题的人
不同的问题需要问不同的人，需求中有很多是细小的操作级别的问题，也有很多是关乎全局的问题，这就要求一定要搞清楚什么问题去问什么人。很多捕获需求的人员抱怨说，“客户答不上这些问题，他们自己都不知道要怎么做”，如果你碰到了这种事情，就要反省一下，你问对人了吗?客户中有一些是大干部，有些是中层管理人员，还有操作人员。对于操作细节上的问题，一定要去问那些负责操作的人员，他们会更清楚每个步骤需要怎么去操作，如果你去问大干部这些问题，你通常会被搪塞，或者以工作太忙，还有其他得事等原因被打发掉。对于关乎全局的问题，操作级别的人员给出的答案通常是不权威的，即便他们回答了你，你也一定要去大干部那里确认一下，再开始开发工作，否则你会后悔的。
3、千万不要浪费客户的时间
和客户面谈时特别要注意一点，就是千万不能浪费客户的时间，让他觉得非常无聊，这是捕获需求最大的忌讳。一旦你犯了这样的错误，你再想约见他就难了，他很可能不愿意再和你会面了。尤其是企业中的领导，他们通常是日理万机，因此要格外珍惜会面的时间。这也是很多作需求的人员常常抱怨的问题，“客户经常没时间见我，我有什么办法”，如果你遇到了这类问题，你一定要反省一下自己，是不是曾经犯过这样的错误，下次一定不要再犯了。
三、深究细节
不要等到项目做好后，才让客户发现问题。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，在客户看来当然需要更改，但这种更改却被我们看成了需求的更改。既然是需求的更改，那么就需要增加项目 成本(资源)或延长项目时间。我看过一篇文章,说要要想项目成功，就得和用户建立亲密的伙伴关系。可是，这种以需求的更改为理由让用户从口袋里掏钱,亲兄 弟也不干阿。所以，需求分析不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。需求是最重要的工作，也是最麻烦的。 客户是不懂需求的，他们的脑海里面没有这个概念， 他们只希望你做出能用的系统 ，用着顺手就好。
四、充分利用需求确认会议
需求确认会议通常由全体涉众(利益相关人)参加，这可是个确认需求的难得的机会，大家能聚在一起，这样的机会其实很难得，所以一定要珍惜。在这种会议上，一定要先针对全局性的问题(与大家都相关的问题)进行交流，千万不要针对部分人感兴趣的问题讨论个没完没了，那样的话，不感兴趣的人会走 开的，那样你再想征求与他们相关问题的意见时就找不到人了。对于只跟个别部门或人员有关系的问题你可以单独找时间根他们讨论。


五、发挥原型的效力
了解需求后及时做出demo让客户确认，确认后要签字。这一点非常重要，很多时候我们了解了需求就闷头开发，等开发完毕后，却不是客户想要的东西，造成巨大浪费；签字是为了让客户认真对待这个demo。demo能用就好，不要过多追求。程序员往往追求完美，想一下子把工作做到位；而最有效率的方法是尽快看到结果 然后再慢慢完善。在项目初期需求会经常改变，这样的目的也是避免把过多时间耗在无用的需求上。demo对于提高客户对软件的认知程度有很好的效果，他能使客户对软件有一个直观的认识，面对原型，他们可以更好地提出他们的想法和意见，尤其对那些对软件缺乏认识的客户。对原型的修改，再确认，最后得到稳定的原型，这些工作会让需求更稳定，减少很多实施工作中的反复修改工作或者返工。
六、注意挖掘不能拿到台面上讲的非功能性潜在需求
我们在软件开发验收过程中得到很多的经验教训，最常见的问题是在开发过程中没有抓住客户的关键负责人或重要领导的意图，没有了解客户看重的是什么。而等到 开发团队提出要验收的时候，客户又总是觉得这也不满意那也不满意，总之是不愿意验收