整理：需求管理相关方法论、工具、流程

新产品开发项目中的需求问题

新产品开发项目中典型的四大问题，分别是：有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱。
有限的需求来源
解决办法：

1. 学习竞争对手的产品是一个很有效的方法。
• 让整个团队一起参与，增强每个团队成员对产品的理解和感性认识
• 当然，参与的程度和时机可以有所不同。
2. 面对有限的需求来源，引入资深用户是另一个解决方法。
• 但在团队内部发展资深用户并不值得鼓励。

模糊的需求界定
需求的界定常常成为“公说公有理，婆说婆有理”的争论。
解决办法：

1. 管理上：开发团队以及开发团队的领导要明确自身的立场，并将相关的责（对需求规格负责么？）权（对需求拍板么？）利（需求管理的方法选择权？）落实到纸面上。
2. 技术上，采用原型。通过风险分析的技术手段来帮助决策。

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

解决办法：

1. 开发团队只需要个别人参与新产品的需求开发，而其他人则可以以已开发的需求作为进一步讨论的基础。

这或许限制了团队的创造性，但 却是更高效率的。产品开发不同于研究。产品开发更多的是需要一种“收敛”，从“想法”到“产品”的“收敛”。如果你发现这种做法埋没了团队中太多富有创造 精神的成员，但你要检讨团队的成员结构，或者你现在的团队适合研究而非产品开发。

（回想当年自己团队创业时候的过度讨论，虽然直觉上感觉不对，为避免无谓的争论浪费时间，最后自己主动退出深度参与讨论，仅仅基于已经提出来的需求进一步细化、梳理，但是拿不出科学的说法来证明这种退让是效率上有益的，而不是所谓的义气之争。相见恨晚矣！然整个生涯看，亡羊补牢矣！）

NV陷阱
NV是PMT的另一个词汇，意即“下一版本”。在功能性需求上，CPD陷阱是常见的。而对于非功能性需求，比如产品性能上，NV陷阱是很容易陷入的。陷入NV陷阱后，往往到时候产品的质量会大打折扣，甚至“拿不出手”。另外，不完整的需求也容易导致错误的设计，这种架构上的缺陷实际上很难在“下一版本”轻易的改变。
开发人员常常认为他们在以后的同样长的时间里可以完成多得多的事情，而且这些事情通常是现在不大愿意做的事情。

解决办法：

1. 非功能性需求从一开始就要被提出来，并受到应有的重视。
• 写入需求规格书
• 在产品开发过程中接受实现状况的检查。

企业和商业软件项目需求管理的不同

• 企业软件项目的关键在于需求管理和流程建模，
• 算法和基本功能以及BUG什么的，那是作为商业软件开发的组件保证的

对客户的需求进行分级管理，简单地说，把需求分成五级：

1. urgent(必须立刻优先实现)，
2. necessary(必须实现,但不一定马上进行)，
3. needed(需要的，不过没有也还凑合)，
4. better(现在似乎也可以，但可以更好一点)，
5. useful（总会有用的）

一个需求等级的确认需要两个过程，

1. 首先从正面论证它是不是必须的，是不是好得多；
2. 然后从反面论证，不要是不是可以回避的，天会不会塌下来？
   

显然，无论客户是如何那般的行业专家，他的需求只能是平均地分配在这五个级别，否则就说明他不是专家，（呵呵，也算是个逻辑陷阱），在实现时，当然就挑urgent&necessary来实现，其余的，升级再说了。


用JIRA、CVS、XPlanner、WIKI来进行项目管理