背景：前一天，他们UX项目组与客户开了一个会议，评审他们已经完成的设计。 但是，客户对设计很不满意，但是他们自己又不能明确的说出他们想要的方案... UX的Lead就询问，项目面向的是什么样的用户群？项目主要希望达到什么商业目的和效果？等等...... 于是，与客户展开了痛苦而漫长的讨论，但是到最后，所有的问题又回到了原点..... 当UX leader再一次问出....项目面向的用户群是什么时，客户终于爆发了。 客户非常不高兴的问公司同事，他们是否听进去了他的话，他都已经反复回答了的问题，为什么还问？ 结果，项目组彻底无语.... 据说，这个项目已经换过几个lead了，但始终搞不定需求这一部分.
乍一看，整个过程中，UX组并没有什么不对，只是客户自己老是说不清楚，理不清什么是这个项目最总要和最关注的... 呵呵...
我的分析如下：
这是一个典型的欠教育的客户... 
很明显，这类客户不明白软件开发的流程，不知道我们为什么问那样的问题？不清楚他对问题的回答会对我们后期工作有什么影响？甚至，他认为他们没必要认真而全面的回答这些问题。 首先说明，我不是UX的人，后面说的内容如有不妥，敬请原谅。欢迎交流。 --joyyuan97
面对这种用户，我们首先要给他一个初步的软件需求调研过程的培训... 以确定，他知道我们再干什么，我们的工作是有意义的...
举例说明，如何培训客户： 拿一个网站项目做比喻
1. 我们应先告诉客户，我们需要确定商业目的和面向的用户。但是，我们需要解释给客户，我们为什么要先确定用户呢？
打一个比方，如果我们的网站是面向于年轻人的，那么，网站就应该够酷，够炫.... 甚至，可以做的像进入游戏界面一样... 呵呵..
而，如果网站是面向与老年人，那么网站就应该尽量简单，尽量减少不必要的干扰部分... 而且，网站字体应该尽量大些，以适应老人视力普遍低下的情况。
在解释完这些后，我们就可以询问客户，我们项目的目标客户群是什么？ 是否准确.....
2. 如同上面网站项目的例子，对于不同的目标客户，我们需要有一些设计准则。 那么，第二个步骤就是识别各目标用户的设计准则。也可以认为是Persona 分析。同样，我们在说完我们要做什么后，也要告诉客户，我们为什么要这么做？
之所以，我们要定义设计准则，一方面是为了设计时候，UX将以此为基准进行设计。另一方面是当对某部分提出多个方案时，我们将以基准为方案挑选标准，来决定最终方案。最后就是当进行设计评审时，我们会以此基准来验收设计。
3. 完成任务分析后，就可以开始具体的需求功能分析了。同样，我们需要告诉客户，我们将如何做功能相关的需求分析，以及为什么？
首先会让客户随意的提出他们认为应该实现的功能，业务目标，功能面向的人群等等。 如果是内部管理软件，则还需要需要客户谈他们的日常工作模式，业务上的约束，涉及人员的工作位置等与流程相关信息。 这一步需要强调，我们需要对需求项目进行分类整理，每个需求都应该有其重要程度，优先级和备注（成功标准等）。 而各需求属性的评判标准，则是根据前面分析出的商业价值和设计准则等来权衡的。 最后，对各需求项目进行分类总结，完成需求列表双方review，确认需求范围和要求。
4. 之后的步骤，做需求的人应该就都知道了... 呵呵，这里就不乱说了。不知道的人，随便找本需求方面的书看看。
5. 最后，就是需求签字了。说道需求签字，笔者就感觉特别有意思... 感觉对于需求签字，无论是软件开发者还是客户都对其有严重的误解。:-) 可能有些偏见....
作为软件开发人员，通常过于强调通过需求签字来约束客户不要变更需求。但是，当遇到强势客户的时候，你的这个签字又显的非常无力。而如果过于强调需求不可变更，我们又可能开发出一个并不实用的软件；我曾经见到过一个项目，项目经理为了防止客户变更需求，需求签字后项目组就回到公司闭门造车，不再与客户交流..... 最后的结果可想而知，当项目完成后，发现项目提供的流程根本不是客户日常流程方式，而且由于调研时候没有最高层领导参与，系统竟然没有提供最高层想要的统计对比部分... 狂倒....
而作为“聪明”的客户，他们又怕承担需求变更带来的负面效果，有时会遇到拖延签字的情况。或者签字者，并不是项目的真正负责人...
其实，上面的现象主要是因为大家对需求签字的意义和作用不清除而引起的。 我个人对需求签字的体会是：需求签字，是一个对我们需求阶段工作的一个双方互相肯定的行为，为什么只是客户签字承认我们需求内容，而不是我们共同签字呢？其实，不用把需求签字搞的那么严肃。呵呵... 对于需求签字，我们需要明确的告诉客户，需求一旦签字后，不代表需求不可变更，而是变更的代价将会远远高于我们的直觉感受。所以，当签字后我们需要变更需求，必须要对需求变更所带来的影响进行评估后，在予以考虑。如果需要变更引起较大的工作量，我们可以采取的措施是： 1. 将需求放在下一个迭代周期；2. 减少其他项目模块；3. 调整项目计划，推迟项目交付时间。 其实，我们向客户解释需求变更成本的方法很简单，我们可以举一个我们日常生活中，会遇到的问题就行了。比如：当我们装修房子的时候，也许，你一开始的时候说房间的墙壁颜色用白色就好，于是包工队就去买了白色染料；但是，周末你和你的家人去一个朋友家做客，看到他们的儿童房墙壁色非常温馨，于是你老婆和孩子就强烈要求，主卧室和儿童房要不同的色彩，装修一辈子也没有几次，所以你一定会希望是否能改一下。那么你的思考方式多半如下：
1. 提出你的方案
2. 询问包工队是否可行
2.1 如果包工队还没有开始做墙壁，那么我们只需要退掉一部分白色染料，购买一些彩色染料。 （由于是分次购买，且发生的退货行为，你最终购买染料的价格，将比你一次性购买染料的价格要多一些）
2.2 如果包工队已经开始做墙壁部分，我们就需要看是否做到主卧室和儿童房了？
如果没有开始主卧和儿童房，则处理结果如上。
如果已经做了主卧或儿童房或染料已经部分调配，则需要看如果我强行修改，损失有多大？ 包括材料和人工费..... 如果损失不大，那么也许你会强行修改；而如果损失超过了你的预期，你可能就会遗憾的放弃修改了。
其实软件中，对需求变更的管理也基本相似，只是稍微复杂一些，需要考虑关联需求等因素。首先，让客户明白我们的工作过程，让客户认可我们的分析不是敷衍，而是一种专业的行为就行了。 为什么同样的道理，同样的话，由我们说出来和由客户心目中的专家说出来不一样呢？呵呵.... 很多时候，是我们自己表现的太不专业了。专家，一般会现对客户进行一小段或几句话的方法培训，然后再诱导执行。而我们基本愣头青似的，上来就认为软件开发的方法是地球人都知道的事情，于是强迫客户按照我们的路子走，给客户的感觉是你们十分有攻击性。 我最赞成的观点是：如果一个项目经理批评一个跟他合作了三年的客户不懂软件的流程，那么，多半是这个项目经理没有对客户进行开发流程的教育。 如果第一个月甚至第一年，你说客户不懂软件的开发流程，还有情可原，如果三年后，你仍然说客户不懂软件流程，那么就是你的失职了... 呵呵... 客户不懂是正常的，而你是软件方面的专家，你为什么没教会他呢？ 当你给自己贴了一个专业的商标后，你就会发现软件其实并没有那么难，客户并没有那么可恶，他们更多时候会可爱的指出你疏忽的地方。
呵呵，以上是我跟同事聊天时，说道的内容。基本没怎么整理就写了出来。 而且，也没去找书看看，我这些歪理是否正确。如果不对，请指正... 我尽量修改正确，以免将来误人子弟。