沙漏之喻
软件工程——其实是人们希望从工程领域中学习经验、借鉴理论来帮助解决在复杂系统和软件开发中遇到的问题。然而，随着软件工程的实践，越来越多的人认识到软件的生产和造桥铺路等工程项目的最大不同就是在于开发过程中人的灵活性和创造性。现在软件工程的发展趋势也重视和体现到这一点，既需要包含和鼓励个体的灵活和创造，但同时也希望从工程的角度对活动进行规范，对创造的过程和结果进行很好的保存和展现。产品/ 项目研发中的需求活动贯穿整个生命周期，前期的市场部门的灵活沟通，广泛收集的活动到后期研发团队紧扣需求、巧妙分析、严格设计的过程不仅反映了工程的力量，也体现了“艺术”的技巧。但如何将客户的凌乱的需求和最后的严谨的解决方案联系起来，如何将人的活动和工程的工作平衡起来， 如何在更高的层次分析和分配需求都是系统工程的重点，也是实际工作的难点。
上大学时非常喜欢哲学课，它能一个简单的问题通过辩证复杂化，可把一个复杂的问题通过统一简单化。这篇文章无意哗众取宠地追求哲学上的高度， 只是想通过以沙漏为模型，以需求为主线，除去细枝末节，更深刻地来认识此间的概念和问题。随着讨论的展开，我们可以看到需求活动的沙漏之喻是如何帮助解答实际工作中的困惑和问题。
从“问题”到“答案”
沙漏是一种古代的计时工具，以它的式样来刻画需求的过程显得非常恰当。图1中沙漏的上端对应需求捕获的过程，沙漏的下面是需求开发找到答案的过程。在需求捕获的过程中，我们需要尽可能的扩展我们的思路，争取能收集所有可能对最后系统或产品产生影响的信息。然而，当沙漏的口开得很大的时候，收集的信息是高度分散的、凌乱的和非结构化的，有些需要还可能是互相矛盾和冲突的。因此，我们需要沙漏的筛选：对要求解决的问题进行梳理，对系统的范围做出决定，选择那些合适的，现实的需求，需求就得到了精炼。这时候问题陈述就是对系统要解决问题的陈述，而不是所有问题的陈述。通过这样一个漏斗的过程，漏下来的需求就是我们系统要满足的需求，这个时候的需求是一个正式的结构化的信息以交付给开发团队。在这个基础上，就可以设计解决方案。
怎么来做需求精炼和筛选，下文会有更详细地讨论。在这里，我想要谈的是区分问题领域和解决方案领域，这也是Jeremy Dick 给我们的忠告之一。经常遇到这样的情形，客户抱怨花了钱没有得到有用的产品，而开发团队也会觉得很郁闷因为拥有这么多而好的功能的系统客户却不懂得“欣赏”，不愿接受。有用和既多且好的功能，这看似统一的表述在这里却成了矛盾。什么对客户来说是有用的？其实很简单，能帮助他解决问题是有用的。而那些拥有很多强大功能的系统和产品如果做不到这一点，矛盾就不可避免。很多团队负责需求收集的人员有着很强的技术背景，习惯将思考的出发点放在系统应该有什么样的功能， 怎么实现这些功能。也就是说，他们往往在没有深入理解客户问题的情况下直接进入解决方案，而不是首先定义独立于解决方案的全面而真实需求集合。
那么，如何有效地区分问题领域和解决方案领域呢？其实，从需求的原始陈述开始，到最后的系统实现，整个过程是连续的：体现了从问题到解决方案的持续演化；同时也是离散的，各个阶段的需求信息之间应有明显的差异。最关键的区分在涉众需求和系统需求之间。涉众需求描述相关涉众、用户的想要解决的问题，期望达到的效果；而系统功能需求则是刻画为了要解决提出的问题，相关的产品和系统应该具有怎样的功能。通过下表的对比，我们可以清楚地看到两者之间的差别，特别是在最后一项，两者在文字描述的差异上更显示出立足点的不同。
由此可知，我们只有在充分理解用户想解决的问题的基础上，
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
