需求分析时的用户心理

在和用户谈需求时，以下用户的反应都是正常的。

1. 用户不知道他到底要一个什么样的系统，要靠开发人员同不同层次的用户谈了以后才知道用户的需求。

在项目刚开始，首先接触的人是用户高层领导。他经常讲，我们上这个系统的目标是什么，我们为什么要上这个系统，我们要达到什么样的一个层次。这是用户的业务目标和范围。

之后接触到的是用户中层领导。他会讲，我们的业务是什么，我们怎么工作，我们的工作流程是什么。这是用户业务流程。

开发人员开始整理这些信息，把软件功能点找出来，确定软件如何完成用户的工作。这是软件功能需求。

按照功能需求做出来的软件可以用了吗？不一定，因为这些功能如果没有方便用户操作和使用，用户还是不满意，所以还需要考虑软件的特性。特性比如，我们开发的软件能够自动检测用户输入的文字错别字。如果有这样的特性，用户会觉得惊喜。

2. 用户看到了一个现有系统，觉得很不错（注意这仅仅是他的感觉“不错”），界面漂亮，功能强大。用户就认为自己需要一个类似的系统。如果开发人员按照现有软件开发自己的软件，是注定要失败的。因为有些功能不需要做了，有些功能需要却没做。

3. 用户在表达自己的想法时，很多时候是凭感觉讲的，但是感觉是最不准确的，比如不错，什么算不错，不错到什么地步才算不错。感觉是会变的，今天用户要做这个功能，明天说不定他就忘记了这个功能。用户这次要这个功能，下次他忘记了又把系统改回去了。

4. 用户的高层领导，心态很高，期望很高，要求质量很高，最好一次就讲清楚需求而不麻烦，最好把全部工作打包能交给系统处理。

用户的中层领导，常为甲方项目负责人，希望项目能够不出错，早点把项目交差了最好。

用户的系统操作人通常会觉得做需求烦，老来问他们这些问题，不是已经说清楚了吗？

5. 用户在需求研讨会上一开始就谈文档格式，数据类型。这时不能让用户滔滔不绝地讲下去，而是要将谈论内容引向分析工作流程，并且要和用户强调流程分析的重要性。

6. 需求研讨会上，最好别让五个以上的用户开讨论会。用户懂业务，他们思路清晰，讲话飞快，你才听完某甲讲完，正在想着怎么写下来。某乙马上接过话题，滔滔不绝地讲，这样你在某甲的思路就被打断了，某乙的话也没记住。你就变成了一个脑子听五张嘴巴不停地讲。会议结束后，估计你的大脑都是晕的。

注意的以下几点：

1. 要树立让用户配合的信心

无论什么样的用户，上至博士生导师，政府厅长，企业老总，下至商店小老板，单位小领导，还有一些单位里的老油条。在和这些人打交道的时候，要注意自己的专业性，还要注意自己的通用性。当开需求调研会时，你只有十分钟的时间来把这些人吸引住。这些人在社会上混了这么多年，什么世面都见过了。你在向他们介绍最开始的系统时，一定要专业，但是要通俗易懂。如果讲得不好，就会被被这些人看低了，你以后和他们做需求，他们就能指着你，喷着你，心里看不起你。这样你的工作就没法开展下去。

2. 用户不懂，培训他们，注意培训的力度和高度

用户高层领导想听什么话，用户中层领导想听什么话，用户操作人员想听什么话，一定要搞清楚，了解他们当前最关心的是什么。只有抓住了他们最关心的地方，你才能和他们交流。尤其对用户领导层，一定要让他们树立起项目开发的概念。要让他们听懂，为什么需求重要，为什么要做流程分析。只要他们听懂了，你的工作就好开展下去。用户领导是不会接受你教他的，即使你说的事情已经说到了心动处，因为他觉得没面子，不接受。要换一种方式方法让他知道，开发方应该怎么做。

3. 吵架是中国人撕破面子的事情

吵架是交流中的冲突。

有些人怕吵架，在有冲突可能性的时候，闷声不出气。这样给用户的感觉是，你软弱。

如果和用户吵架了，那是你没有控制好自己的情绪，没有掌握好讲话的分寸。吵架了要找自己的原因，分析自己的不足，不能一味怪用户，如果一味把所有的责任推到用户身上，那么你不会有进步。

其实掌握好吵架的度，注意讲话的语气，讲话的语言，讲话的环境，吵架也不难。

吵完架以后，要注意修补你和对方的关系，而且还要注意修复你和吵架旁观者的关系。