需求在软件项⽬中扮演着及其重要的⾓⾊。不管哪种类型的项⽬，⽆论是新产品开发，还是外包项⽬，开发队伍都⾯临着普遍存在的需求问题，⽐如如何获取有效的需求、如何处理需求的变更等等。这些问题有其共性的⼀⾯，也有和项⽬类型相关的⼀⾯。本⽂着重讨论了在新产品开发项⽬中的⼀些需求问题，以及避免和解决这些问题的建议。

⼀. 概述

在开始进⼀步讨论之前，我们先明确⼏个概念。

⾸先，本⽂是从开发团队，或者说项⽬组的⾓度来看需求问题。所谓开发团队，通常包括了程序员、测试员和其他⼀些项⽬成员，如配置管理员和软件架构师，以及基层的管理⼈员，⽐如项⽬经理。类⽐于传统企业，开发团队相当于企业的⽣产车间。但是，在⼤多数的软件组织中，开发团队除了担当“⽣产”任务以外，往往也是需求获取的主体；在某些较为正规的组织中，也许会有市场部门给出⼀些需求，但这些市场数据和有限的调研结果通常是远远不够形成需求规格书的。

其次，何谓“新产品开发项⽬”。简单⽽⾔，在本⽂中，新产品开发指开发团队需要从⽆到有将⼀个想法（idea）转化为产品（product）。新产品开发不同于产品升级，开发团队没有⼀个已存在的基础；新产品开发不同于开发⼀个实验型的作品或者演⽰、原型之类的东西，开发团队最终的产出必须是产品，在功能、性能、可⽤性等⽅⾯都有⽐较⾼的要求和期望；新产品开发不同于承接⼀个软件开发项⽬，也不同于为明确指定的⽤户或者客户定制产品，开发团队最终⾯对的是⼴泛的市场，是⼀个由众多独⽴的最终⽤户（同时也是客户）组成的群体。新产品开发项⽬更加不同于维护型的，或者其他类型的项⽬。

第三，本⽂所讨论的需求基于需求的传统定义，即软件需求指⽤户对软件产品明确的和期望的要求。这些要求直接影响了⽤户对此产品的满意程度，或者更直接的说，影响了⽤户的购买决定以及对产品和开发商喜好的判断。对于开发团队⽽⾔，在实际⼯作中，需求问题往往和设计问题，特别是⾼层（High level）的设计纠缠在⼀起，很难有明确的界限划分。但在本⽂中，需求问题不涉及与具体实现相关的问题，⽐如技术选型，⼈机界⾯。

概括⽽⾔，在⼀个新产品开发项⽬中，开发团队⾯临的需求问题涉及到需求的获取、分析和管理。本⽂的余下部分将重点讨论新产品开发项⽬中典型的四⼤问题，分别是：有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱。

⼆. 有限的需求来源

新产品的想法可能来⾃⽼板的拍脑袋，也可能来⾃市场部的报告，或者也可能来⾃研究部门的某个创意；但不管怎样，可以肯定的是，没有⼈具备⾜够的信息来准确的描绘出未来的产品（⽽且通常这个未来也不会很远）是什么样⼦。如果项⽬组成员恰好属于这个产品的⽤户，⽐如这个产品是⼀个字处理软件，或者仅仅是搭上⼀点关系，⽐如这个产品是⼀个个⼈理财软件，那获取需求的任务就更加理所当然的落在了开发团队⾝上。

表⾯上看，由开发团队⾃⼰定义需求会使得需求相对稳定，对开发团队是有利的。但事实上，开发团队会⾯临不少棘⼿的问题，最直接最明显的，就是需求的来源受限。开发团队最需要的就是明确的（也是稳定的）需求，⽽现在，要开发团队⾃⼰去获得，⽽且获取需求的来源⼜很有限。

由于是新产品，在组织内部，开发团队通常找不到⾜够的帮助。⽽要从外界获得，⼜受到时间、经费和职责等因素的限制。在这种情况下，学习竞争对⼿的产品是⼀个很有效的⽅法。开发团队可以从研究和剖析类似产品着⼿，例如，如果要开发⼀个电⼦邮件客户端软件，那么，Outlook和Foxmail就是很好的学习对象。亲⾝的去使⽤和体验这些软件，仔细阅读它们的⽤户⼿册、在线帮助，甚⾄联系它们的客户服务。⽽且，这项⼯作应该让整个团队⼀起参与，增强每个团队成员对产品的理解和感性认识，当然，参与的程度和时机可以有所不同。

⾯对有限的需求来源，引⼊资深⽤户是另⼀个解决⽅法。所谓资深⽤户，他们可能很熟悉同类产品的使⽤，或者了解⽤户通常需要些什么。⽐如开发个⼈理财软件，那么⼀个理财顾问，或者⼀个理财⾼⼿就是很合适的资深⽤户。对于⾯向群体⽤户的产品，特别是那些⼤众消费类软件，这些资深⽤户事实上并不如想象中那么难获得。个⼈关系是主要的获取途径。为了减少个⼈偏好的影响，应该尽可能多引⼊⼏个资深⽤户。对于某些产品，⽐如前⾯提到的电⼦邮件客户端软件，似乎团队成员中就可以找到资深⽤户。但在团队内部发展资深⽤户并不值得⿎励。其中的原因在“CPD陷阱”⼀节中会解释。

三. 模糊的需求界定

在⼀个新产品开发项⽬中，某项需求是否需要、它的优先级如何、某项功能或者要求究竟如何表述，这些界定问题由于没有⼀个确定的⽤户或者客户说“要还是不要，好还是不好，急还是不急”⽽会变得模糊不清。

这种模糊的需求界定也发⽣在开发团队内部。每⼀个成员都可以声称“⽤户要这个功能”，或者“⽤户根本不可能那样操作”。需求的界定常常成为“公说公有理，婆说婆有理”的争论。

在现实世界⾥，开发团队往往处于⼀个尴尬的境地。他们通常被认为有义务制定出需求规格，并对此负责，却没有被赋予对需求规格最后“拍板”的权⼒。在这种情况下，开发团队以及开发团队的领导要明确⾃⾝的⽴场，并将相关的责权利落实到纸⾯上。

在技术层⾯上，解决“模糊的需求界定”问题的⼀个⽅法就是采⽤原型。利⽤原型来讨论，利⽤原型来证明观点，这⽐“空对空”的争论要有效得多。拓展出去讲，在界定需求的时候，尽量⽤事实和数据来⽀持观点，避免“可能怎样怎样”的猜想，如果不能肯定，就落实到概率上，这样可以通过风险分析的技术⼿段来帮助决策。

四. CPD陷阱

CPD是PMT的⼀个词汇，意即“⽆谓的创造－追求完美－⾃我否定”。团队成员过多涉⾜需求的开发（即使可能存在进度上的压⼒，项⽬的初始阶段也⼏乎总是⼀段美好的时光。进⼊⼀个新鲜⽽陌⽣的领域，团队的每个⼈都容易发现⼀⽚崭新的世界，每个⼈都能够为新产品添加⼀系列“激动⼈⼼”的特性。但这些特性是否合适、是否有必要却往往被“激动”淹没了。追求完美是计算机技术⼈员⼀个很普遍的特征，这⼀特征会促使这些⽆谓的创造继续下去，直到⼤家觉得“这个产品做得再好也不过如此”，于是，⾃我否定就会接踵⽽来。

为了防⽌陷⼊CPD陷阱，开发团队只需要个别⼈参与新产品的需求开发，⽽其他⼈则可以以已开发的需求作为进⼀步讨论的基础。这或许限制了团队的创造性，但却是更⾼效率的。产品开发不同于研究。产品开发更多的是需要⼀种“收敛”，从“想法”到“产品”的“收敛”。如果你发现这种做法埋没了团队中太多富有创造精神的成员，但你要检讨团队的成员结构，或者你现在的团队适合研究⽽⾮产品开发。

五. NV陷阱

NV是PMT的另⼀个词汇，意即“下⼀版本”。在功能性需求上，CPD陷阱是常见的。⽽对于⾮功能性需求，⽐如产品性能

上，NV陷阱是很容易陷⼊的。陷⼊NV陷阱后，往往到时候产品的质量会⼤打折扣，甚⾄“拿不出⼿”。另外，不完整的需求也容易导致错误的设计，这种架构上的缺陷实际上很难在“下⼀版本”轻易的改变。

除了主观上对⾮功能性需求的不重视，陷⼊NV陷阱的原因常常还有迫于时间压⼒，或者毫⽆来由的乐观。开发⼈员常常认为他们在以后的同样长的时间⾥可以完成多得多的事情，⽽且这些事情通常是现在不⼤愿意做的事情。

“这个版本的确不够稳定，下个版本再说吧”，这是经常可以听到的说法。为了防⽌陷⼊NV陷阱，⾮功能性需求从⼀开始就要被提出来，并受到应有的重视。如果这些⾮功能性需求是确实需要的，就应该被写⼊需求规格书，并在产品开发过程中接受实现状况的检查。

有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱是新产品开发项⽬中常见的四⼤问题。除此以外，新产品开发项⽬中也存在其他的⼀些特殊问题，⽐如在需求的跟踪管理上，新产品开发项⽬就与其他类型的项⽬有不同的地⽅。PMT将继续这⽅⾯的研究和实践，并期待和⼴⼤读者的交流。

• 上一篇：CMMI需求开发指南
• 下一篇：IT需求管理办法