软件需求最佳实践阅读笔记04
项目相关败因分析4
一、 客户的需求放大
曾经看过一个漫画，客户向项目经理描述要做一秋千，项目经理向需求分析员描述自己的理解的用户描述，然后需求分析员进行设计。开发人员对需求分析员的设计进行实现。可是到了最后成了一个四不像，这其中的原因固然是因为沟通是真的缘故，但是对于失真的原因，也有待于分析。
- 客户的需求放大
通过比较客户的描述喝醉后的结果时，我们就会发现用户在描述自己的需求时做了许多“添砖加瓦”的事。“用户要么不会说，要么就会添油加醋”的现象，这在平时的实践中屡见不鲜。这其中至少有两方面的原因：
1） 客户希望支付的成本尽可能少，获得的效益尽可能多。这种思维对于任何一个客户、任何一个人而言都是本能反应。而当用户对开发成本越不了解时，这种心态就会越强烈，更加担心自己“亏损了”；因此在需求协商时就会采取尽可能增加功能的方法来降低“亏损”的风险。要解决该问题并不是一件容易的事，一方面需要提升软件估算实践的有效性，另一方面则需要产业成熟度的提高。
2） 解决方案的选择权交给了不熟悉技术的客户，许多需求团队在进行需求捕获活动时，经常预期用户能够直接告诉他们要做什么，而不太关心用户提出需求的真正动机。但是这样就将解决方案的选择权交给了并不熟悉技术的客户代表，而一旦客户代表选择的解决方案不是最合适的，就必须引发后续的需求变更。
2. 项目经理的需求控制
通过看到的漫画，我们可以发现项目经理在与客户沟通的过程中会对客户的描述进行自己的控制。这是因为在国内，大部分的项目经理都是从技术人员晋升来的，他们本身就有很强的技术。另外还可能身兼多职，项目管理、需求分析、架构设计一肩挑。因此在需求捕获的过程中，总会“及时”地在脑海里勾勒出技术框架和路线，然后尽可能地控制需求的范围。但实际上，有些需求“表面上”是控制下去了，但却在后面以“需求变更”的形式全回来了。
实际上，作者的体会是需求分析人员是有必要对需求进行有效分析的，问题出在控制的策略和方向上。从前面的描述中不难看出，项目经理经常会从技术的角度来对需求进行控制，这样就可能造成无法形成对需求的有效理解。另外，在技术分析的时候，尽量不能通过技术进行分析。需求分析的本质在于业务分析。
