市场和研发的平衡
    在很多上了一定规模的公司中，有两个团队是一定存在且非常重要的：市场部和研发部。市场团队主要和“人”打交道，进行市场的调研和需求的获取，这处在图2中沙漏的上半部分。在沙漏的下半部分是工程领域，也就是开发队伍工作的领域。对开发人员来说，他们很少有机会真正地面对客户，他们工作的基础就是需求。对一个项目或产品的成功， 这两个团队必须紧密合作，扮演好自己的角色。一旦此间的平衡被打破，团队就会遇到麻烦。很多公司里市场部门“坐大”，为了赢得客户的定单，或不深入理解客户的要求，或是直接“指示”研发部门按照自己对系统实现的理解进行开发。这都违反了上文中提及的需求捕获的关键原则。当另一方面，我也遇到这样一些公司，它们是由研发起家， 整个研发部门在公司中占有比较多的“话语权”。会有这样的开发经理或人员，可能是出于追求技术领先或完美的热情， 在满足用户需求的同时，也会增加设计/ 实现其他“多余”的功能点。这些功能点其实是“无源之水”，并没有实际的市场和用户需求与之相对应。

    需求将市场部和研发部紧密地联系起来，让两者之间的有效连接并维护平衡的角色就是团队中的需求专家。市场部和直接的用户，以及相关系统的投资方、监管方、维护方等等进行交流，我们不能保证他们能够提供准确的清晰的需求描述，因为他们只是在提出他们的问题和对结果的期望，而且要求我们的客户去学习什么是好的需求和如何提需求是不现实的。现实的是团队中有这么一些人，熟悉领域且受到过需求管理方面的指导和培训，他们知道应该怎么去收集、分析和总结需求。例如在西门子， 负责捕获客户需求的工作主要由市场部人员去做，但并不是直接将这些需求转给开发部。有一个需求管理小组，隶属于研发中心，主要职责则相当于市场部和开发部的一个接口。需求工程师对从市场部那里获取的零散和庞大的需求文档进行整理和分类，然后提交给开发部。开发人员不需要和市场部争论哪些事情做得到还是做不到，而是由需求工程师来做。（具体参见《探索需求管理的三步曲》——《程序员》2005年9月刊） 这是一个很好的做法，需求工程师可以是一个职位，也可以是一个角色。单独的职位可能在小的团队中不太实际，但拥有这个角色的人自己必须很清楚自己的位置：是处在市场和研发中间，需要维护好平衡，做好接口的工作。

    产品线需求 vs 具体项目需求
    研发团队的项目性质很大程度上决定了需求管理做到的深度和广度。有项目经理问，我的项目周期常常只有几个月半年的，还需要做需求管理吗？诚然，若是一些没有专注业务领域的团队，他们项目的时间短，而且没有类似的后续项目，可以不必在需求管理上面投入太多的资源。而另一方面，如果这个项目是一个产品发展的某一个阶段，我们就要重新审视这个问题。就如一个做打印机的日本公司在上海的研发团队，他们的项目周期也是半年左右，但是一个基本型号的打印机已经有二十年的历史。也就是说，现在的这款打印机是一个个小的项目的开发成果的累计。这时，该开发团队就需要很好的需求管理，而且需求管理已经不再局限在某个项目里。

    市场的激烈竞争，企业自身的发展，我们看到一个产品的需求往往会非常多。如果全部实现，那将是一个“完美”的结果。时间和资源的现实面前，决策层需要进行选择：既要快速地将产品发布面世， 同时新的版本中也需要有足够地引起客户购买欲望的需求实现。

    这里需要决策。孙子兵法中的“胜兵，先胜而后求战；败兵，先战而后求胜”早就阐述类似的道理：打胜仗的部队是在有胜算时之后才投入战斗，打败仗的部队先投入战斗，才寻求胜利的条件。需求工作的重要性是老生常谈的事情了，不是本文的重点。我们关注的是如何做出正确的决策而占得先机。

    沙漏的上半部分强调的是在产品和项目的规划阶段，我们需要将做出正确的决策以满足现在市场的需要。这体现在收集和记录正确的需求；对需求的重要程度做出准确的刻画；基于成本和效益来规划产品的路线图，将需求的实现分配到各个的项目中。在需求明确的前提，项目经理就可以带领他的团队开展工作，这个阶段的重点就是如何保证需求在每一个研发的每个阶段都得到严格的满足和测试，而切实保证需求驱动开发和保证需求驱动测试，是研发团队将事情做正确的关键。

    决策的重要基础是对需求的重要程度进行排序。但排序的基准在哪里，且基准也会随着个人的角度和时间的推移而变化？如果读者参与产品和系统规划的工作，尝试着回答下面的问题：所有来自A地区客户的紧急程度为高的且估算工作量在180 个人天以下的所有需求有哪些？他们现在的项目状态如何？这是一个问题的简单样本，问题的实质在于决策者可能需要从多个角度去分析需求，并需要在众多需求中找出最重要的或者是当前最感兴趣的需求的子集。在没有方法的指导和工具的支持下，这个工作在竞争越来越激烈的现在是越来越难了，因为决策者往往面对多个产品， 多个市场，多个竞争对手，当然还有时间和成本的压力。