了解时，这种心态就会越强烈，更加担心自己“亏损”了；因此在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。
要有效地克服这个因素的困扰，核心的要点在于建立客户对开发团队的信任度，而建立信任度的要点有两个方面：一是需求人员必须提升自己的专业主义（关于这一点我将在后续的文章中说明）；二是需求人员要多站在用户的角度想问题，让用户感觉需求人员的目标是帮助自己解决问题，而非一味谋取利益。
（2）解决方案的选择权交给了不熟悉技术的客户
也就是用户经常会谈解决方案，甚至许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么（What），而不太关心用户提出需求的真正动机（Why）。但是这样就将解决方案的选择权交给了并不熟悉技术的客户代表，而客户代表选择的解决方案不是最合适的话，就必将引发后续的需求变更。
案例&场景：
在一次CRM软件开发的过程中……
负责输入客户信息的用户向开发人员提出：“你看这个界面，光电话就有快10个输入框，太麻烦了，每次按tab键都按酸了。我希望把他们合并成两个，一个为常用电话，一个为其他电话”。
“那有多个电话怎么办？”，开发人员回应道。
“其他电话的输入框可以设置为多行的、较宽的，这样我可以输入多个，中间用逗号分开它！”。
“好的，没问题” 。
……
当经理看到了这些客户信息之后，向开发人员提出：“我需要一个功能，输入任何电话号码，自动找出相应的客户。”
“啊……”
如果我们细究这个场景，分析一下负责输入客户信息的用户所提出的变更就会发现：“将10个电话输入框合并成两个”显然是解决方案，而真正的需求是“输入太麻烦了，每次按tab键都按酸了”。你或许就会想到如下所示的解决方案：
也就是说，默认情况上只显示左边的部分，当需要时点击“其它>>”按钮就可以将右边的不常用输入项显示出来。
总而言之，因为对于一个特定的问题可能的解决方案会有很多，因此用户可能在使用软件的过程中不断发现其他可选的、更合适的替代方案，从而导致了不必要的需求变更。而要缓解这一现象的关键就在于在需求捕获的过程中多问“为什么”。
项目经理：控制需求
当我们比较图1中第1幅和第2幅图时，就会发现项目经理在沟通的过程中会导致需求产生偏差。由于国内许多软件项目经理们通常是一身兼多职，项目管理、需求分析、架构设计一肩挑，因此在需求捕获的过程中，总会“及时”地在脑海里勾勒出技术框架和路线，然后尽可能地控制需求的范围。
就像这里，客户需要的可能是一个“秋千”或者是“上树工具”，但不管真正的需求是什么，第2幅图中的解决方案却都无法有效地满足。如果要做“秋千”，不应该被树干挡住；如果要做“上树工具”，木板的数量显然太少了。
究其原因不难发现，需求人员首先从项目经理的视角按工作量对需求进行了控制：将“三层”板的工作量减成“一层”板，如果不小心控制掉的是对业务很重要的东西，那么最终一定会以变更的形式“回报”给开发团队的。然后需求人员又从架构师的角度进行了“改良”：不稳定的“全挂在一个树枝上”改成“挂在两个树枝上”，结果根本无法使用。
因此具有多个角色的需求人员，必须在需求的过程中“戴正自己的帽子”，真正从理解业务的角度来捕获需求。
分析人员：技术加工
案例&场景：
分析员小张：“嘿，伙伴们！我有个提议，我们研究Hibernate已经有一
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
