们的客户服务。而且，这项工作应该让整个团队一起参与，增强每个团队成员对产品的理解和感性认识，当然，参与的程度和时机可以有所不同。
面对有限的需求来源，引入资深用户是另一个解决方法。所谓资深用户，他们可能很熟悉同类产品的使用，或者了解用户通常需要些什么。比如开发个人理财软件，那么一个理财顾问，或者一个理财高手就是很合适的资深用户。对于面向群体用户的产品，特别是那些大众消费类软件，这些资深用户事实上并不如想象中那么难获得。个人关系是主要的获取途径。为了减少个人偏好的影响，应该尽可能多引入几个资深用户。对于某些产品，比如前面提到的电子邮件客户端软件，似乎团队成员中就可以找到资深用户。但在团队内部发展资深用户并不值得鼓励。其中的原因在“CPD陷阱”一节中会解释。
三. 模糊的需求界定
在一个新产品开发项目中，某项需求是否需要、它的优先级如何、某项功能或者要求究竟如何表述，这些界定问题由于没有一个确定的用户或者客户说“要还是不要，好还是不好，急还是不急”而会变得模糊不清。
这种模糊的需求界定也发生在开发团队内部。每一个成员都可以声称“用户要这个功能”，或者“用户根本不可能那样操作”。需求的界定常常成为“公说公有理，婆说婆有理”的争论。
在现实世界里，开发团队往往处于一个尴尬的境地。他们通常被认为有义务制定出需求规格，并对此负责，却没有被赋予对需求规格最后“拍板”的权力。在这种情况下，开发团队以及开发团队的领导要明确自身的立场，并将相关的责权利落实到纸面上。
在技术层面上，解决“模糊的需求界定”问题的一个方法就是采用原型。利用原型来讨论，利用原型来证明观点，这比“空对空”的争论要有效得多。拓展出去讲，在界定需求的时候，尽量用事实和数据来支持观点，避免“可能怎样怎样”的猜想，如果不能肯定，就落实到概率上，这样可以通过风险分析的技术手段来帮助决策。
四. CPD陷阱
CPD是PMT的一个词汇，意即“无谓的创造－追求完美－自我否定”。团队成员过多涉足需求的开发（即使可能存在进度上的压力，项目的初始阶段也几乎总是一段美好的时光。进入一个新鲜而陌生的领域，团队的每个人都容易发现一片崭新的世界，每个人都能够为新产品添加一系列“激动人心”的特性。但这些特性是否合适、是否有必要却往往被“激动”淹没了。追求完美是计算机技术人员一个很普遍的特征，这一特征会促使这些无谓的创造继续下去，直到大家觉得“这个产品做得再好也不过如此”，于是，自我否定就会接踵而来。
为了防止陷入CPD陷阱，开发团队只需要个别人参与新产品的需求开发，而其他人则可以以已开发的需求作为进一步讨论的基础。这或许限制了团队的创造性，但却是更高效率的。产品开发不同于研究。产品开发更多的是需要一种“收敛”，从“想法”到“产品”的“收敛”。如果你发现这种做法埋没了团队中太多富有创造精神的成员，但你要检讨团队的成员结构，或者你现在的团队适合研究而非产品开发。
五. NV陷阱
NV是PMT的另一个词汇，意即“下一版本”。在功能性需求上，CPD陷阱是常见的。而对于非功能性需求，比如产品性能上，NV陷阱是很容易陷入的。陷入NV陷阱后，往往到时候产品的质量会大打折扣，甚至“拿不出手”。另外，不完整的需求也容易导致错误的设计，这种架构上的缺陷实际上很难在“下一版本”轻易的改变。
除了主观上对非功能性需求的不重视，陷入NV陷阱的原因常常还有迫于时间压力，或者毫无来由的乐观。开发人员常常认为他们在以后的同样长的时间里可以完成多得多的事情，而且这些事情通常是现在不大愿意做的事情。
“这个版本的确不够稳定，下个版本再说吧”，这是经常可以听到的说法。为了防止陷入NV陷阱，非功能性需求从一开始就要被提出来，并受到应有的重视。如果这些非功能性需求是确实需要的，就应该被写入需求规格书，并在产品开发过程中接受实现状况的检查。
有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱是新产品开发项目中常见的四大问题。除此以外，新产品开发项目中也存在其他的一些特殊问题，比如在需求的跟踪管理上，新产品开发项目就与其他类型的项目有不同的地方。PMT将继续这方面的研究和实践，并期待和广大读者的交流。