项目周期也是半年左右，但是一个基本型号的打印机已经有二十年的历史。也就是说，现在的这款打印机是一个个小的项目的开发成果的累计。这时，该开发团队就需要很好的需求管理，而且需求管理已经不再局限在某个项目里。
市场的激烈竞争，企业自身的发展，我们看到一个产品的需求往往会非常多。如果全部实现，那将是一个“完美”的结果。时间和资源的现实面前，决策层需要进行选择：既要快速地将产品发布面世， 同时新的版本中也需要有足够地引起客户购买欲望的需求实现。
这里需要决策。孙子兵法中的“胜兵，先胜而后求战；败兵，先战而后求胜”早就阐述类似的道理：打胜仗的部队是在有胜算时之后才投入战斗，打败仗的部队先投入战斗，才寻求胜利的条件。需求工作的重要性是老生常谈的事情了，不是本文的重点。我们关注的是如何做出正确的决策而占得先机。
沙漏的上半部分强调的是在产品和项目的规划阶段，我们需要将做出正确的决策以满足现在市场的需要。这体现在收集和记录正确的需求；对需求的重要程度做出准确的刻画；基于成本和效益来规划产品的路线图，将需求的实现分配到各个的项目中。在需求明确的前提，项目经理就可以带领他的团队开展工作，这个阶段的重点就是如何保证需求在每一个研发的每个阶段都得到严格的满足和测试，而切实保证需求驱动开发和保证需求驱动测试，是研发团队将事情做正确的关键。
决策的重要基础是对需求的重要程度进行排序。但排序的基准在哪里，且基准也会随着个人的角度和时间的推移而变化？如果读者参与产品和系统规划的工作，尝试着回答下面的问题：所有来自A地区客户的紧急程度为高的且估算工作量在180 个人天以下的所有需求有哪些？他们现在的项目状态如何？这是一个问题的简单样本，问题的实质在于决策者可能需要从多个角度去分析需求，并需要在众多需求中找出最重要的或者是当前最感兴趣的需求的子集。在没有方法的指导和工具的支持下，这个工作在竞争越来越激烈的现在是越来越难了，因为决策者往往面对多个产品， 多个市场，多个竞争对手，当然还有时间和成本的压力。
“沙漏”的具体实践
沙漏虽然是个比喻，但实际上有很多公司都在实践这种思路。以Telelogic公司开发DOORS 这个产品为例，该产品的信息架构也呈沙漏的形状（为了展现的方便，图4 为一个卧倒的沙漏）。在沙漏的前半部分，需求的来源主要分三大块： 客户反馈（Customer Feedback）、市场行销部门反馈（Sales and Marketing Feedback） 和竞争对手分析（Competitive Analysis）。基于这些原始的需求信息，产品部门总结出DOORS 产品的用户需求，而后是分析得到功能规格来满足用户的需求，再分模块去详细设计。
重点解释一下在离散的原始需求和正式的用户需求之间所发生的整合的动作。正如上文提及的，我们不能期望客户的反馈是清晰的，是结构化的，但提交给开发部门的需求必须是清晰的、准确的、抽象的和可测试的。整合的动作就是进行信息的梳理和转换。
重要的是，开发部门使用工具将整合的过程和思路记录下来。常常在一个项目中听到这样的抱怨：客户（甲方）说不清楚原来提出的需求有没有在开发中得到体现，或者是直到见到产品了，才能确定需求是否体现，体现在哪里；而开发团队（ 乙方）会抱怨客户总是到项目后端变来变去，但能和客户“讨价还价”的依据又太少。在沙漏的模型中，最初的需求文档可以是图4中列出的，更可以是其他的贴近客户和市场的记录形式，如Email，会议记录等等。整合的过程中，我们需要将用户需求中的某条需求将和上游的来源文档中的需求描述部分联系起来，如利用工具建立类似超链接的li
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
