会员登录
会员注册
由于是新产品，在组织内部，开发团队通常找不到足够的帮助。而要从外界获得，又受到时间、经费和职责等因素的限制。在这种情况下，学习竞争对手的产品是一个很有效的方法。开发团队可以从研究和剖析类似产品着手，例如，如果要开发一个电子邮件客户端软件，那么，Outlook和Foxmail就是很好的学习对象。亲身的去使用和体验这些软件，仔细阅读它们的用户手册、在线帮助，甚至联系它们的客户服务。而且，这项工作应该让整个团队一起参与，增强每个团队成员对产品的理解和感性认识，当然，参与的程度和时机可以有所不同。
面对有限的需求来源，引入资深用户是另一个解决方法。所谓资深用户，他们可能很熟悉同类产品的使用，或者了解用户通常需要些什么。比如开发个人理财软件，那么一个理财顾问，或者一个理财高手就是很合适的资深用户。对于面向群体用户的产品，特别是那些大众消费类软件，这些资深用户事实上并不如想象中那么难获得。个人关系是主要的获取途径。为了减少个人偏好的影响，应该尽可能多引入几个资深用户。对于某些产品，比如前面提到的电子邮件客户端软件，似乎团队成员中就可以找到资深用户。但在团队内部发展资深用户并不值得鼓励。其中的原因在“CPD陷阱”一节中会解释。
三、模糊的需求界定在一个新产品开发项目中，某项需求是否需要、它的优先级如何、某项功能或者要求究竟如何表述，这些界定问题由于没有一个确定的用户或者客户说“要还是不要，好还是不好，急还是不急”而会变得模糊不清。
这种模糊的需求界定也发生在开发团队内部。每一个成员都可以声称“用户要这个功能”，或者“用户根本不可能那样操作”。需求的界定常常成为“公说公有理，婆说婆有理”的争论。
在现实世界里，开发团队往往处于一个尴尬的境地。他们通常被认为有义务制定出需求规格，并对此负责，却没有被赋予对需求规格最后“拍板”的权力。在这种情况下，开发团队以及开发团队的领导要明确自身的立场，并将相关的责权利落实到纸面上。
在技术层面上，解决“模糊的需求界定”问题的一个方法就是采用原型。利用原型来讨论，利用原型来证明观点，这比“空对空”的争论要有效得多。拓展出去讲，在界定需求的时候，尽量用事实和数据来支持观点，避免“可能怎样怎样”的猜想，如果不能肯定，就落实到概率上，这样可以通过风险分析的技术手段来帮助决策。
四、CPD陷阱CPD是PMT的一个词汇，意即“无谓的创造-追求完美-自我否定”。团队成员过多涉足需求的开发(即使可能存在进度上的压力，项目的初始阶段也几乎总是一段美好的时光。进入一个新鲜而陌生的领域，团队的每个人都容易发现一片崭新的世界，每个人都能够为新产品添加一系列“激动人心”的特性。但这些特性是否合适、是否有必要却往往被“激动”淹没了。追求完美是计算机技术人员一个很普遍的特征，这一特征会促使这些无谓的创造继续下去，直到大家觉得“这个产品做得再好也不过如此”，于是，自我否定就会接踵而来。