IT行业自上个世纪70年代蓬勃发展，直到现在，如何管理好软件项目还一直是大家讨论的话题。这是因为软件项目失败的太多，比如项目彻底被取消、项目的工期拖延等等。

　　中国目前很多软件开发团队的实际情况来看，从某种程度上来说，错误的使用和依赖两个软件来管理项目是项目失败的一个重要理由。这两个软件是Microsoft Project和Microsoft Word。 像钉钉子，总是用一把斧子。

　　工程项目 vs. 软件项目

　　Microsoft Project本身是一个不错的项目管理工具，能够做任务分配，Petri-NET， Gannt图，资源使用分析等等。但是，Project是用来管理工程项目的，如造房子，修大桥等等。这些工程类的项目一般使用以任务驱动的管理方法。而软件项目和传统的工程项目有本质的差别，那是任务的不确定性。举个例子，目前房地产很火，造什么样的房子，只要资金到位，都能保质保量的造好。造10层楼，1层用多少人天，每天做什么，很容易计划，分配任务，人力资源。而且需求是不会变的。没见过造房子，盖了3层之后改主意了，拆了重新盖。

　　而软件大大不同了，需求的变化是不可避免的，而且凡是做过项目的人都知道，需求的变化实际上还挺频繁。这样一来，很容易造成计划赶不上变化，用Project定义任务，计划工期通常要耗费项目经理大量的时间，而且没有意义。

　　有人问，为什么需求不能固定下来呢？定下来不许变。通常工程师会问这样的问题。如果他变成了客户，他可能不会问这个问题了。需求总是会变的。第一：出钱的总是有更多的话语权（当然改需求是要应该付费的）；第二：市场的情况在变，比如竞争对手突然发布了一个新的产品功能， 那我们也必须做出应对，这要变更需求；第三：写需求的不是神仙，人都或犯错误的，犯错误允许改正（但犯错误要有惩罚，是需求变更是要付费的）。 因此传统的纯瀑布式的开发方式已经成为历史了，愈来愈多的开发团队采用极限编程，迭代的开发，来应付需求的变更。

　　那么软件项目的这种特点，需要与之相应的项目管理工具。用斧子钉钉子的做法有点不合时宜了。

　　和传统项目还有一个很大的不同，当工程项目拖后了工期，可以多加人手，把工期赶回来。而软件不这么简单了，新来的人要熟悉项目的内容要花时间，工期很难完全赶上。很多IT的老总们体会不到这个问题，总以为多加人手，加班能搞定。真正的有效的项目管理是要靠一个有效的管理体系来支撑的。

　　需求的描述

　　软件项目有很多不同类型。目前我们所说的软件项目，多数指的是应用类(Application)的软件项目，而不是系统类(System)的项目，如数据库，文件系统，开发工具。系统类的软件项目和应用类的项目有很大的不同。系统类的项目花很长时间研究体系架构（Architecture），设计系统的框架，模块之间的关系等等。而应用类的软件基本上会用现成的框架，如J2EE， 或Microsoft的平台等等，主要精力放在需求的实现上。中国目前的应用系统多数是为客户做定制开发的项目，比如各大企业、政府、机构、国防等做的系统，也有一些做产品的，如中小企业的财务系统，通用办公软件等等。 针对应用类的项目，我们看看使用Word写这类的需求有什么问题，为什么有问题。

　　一般用Word来写需要，隐含了一个想法，是一上来把需求都写好，定下来，然后给开发部门去实现。一般Word文档写的需求很庞大。 而对于应用系统的开发， 我建议使用迭代的方法开发。上面提到了，瀑布式的开发已经成为了历史。需求一次性写好，很难。软件是慢慢成长起来的（见Microsoft Secrets），一个milestone一个milestone的发展。象小孩子长大一样，中间可能会走弯路、错路，需要我们不短的调整、指引，后他/她才能成才。你很难一开始给他/她描绘一个一生的所有的详细场景，让他/她按照你的蓝图走（工程项目才能做到这样）。

　　我们建议先想好我们会有几个milestone，每个milestone发布哪些功能。然后描述需求，框架性的需求要先确定好， 然后先写近要实现的功能的需求说明。后面的需求 和开发可以并行了。这样我们的产品可以比较快的面世，客户会及时的给出反馈。从而减小项目的风险。这里建议写需求的时候，用UI Prototype，User Scenario方法，让用户越早看到实际使用界面和使用方法越好。

　　目前我们很多项目的需求是用Microsoft Word写的，动辄几十页，上百页。这样的大文档，除了上面讲到的项目管理方法上的问题，还存在下面的问题：

　　规模巨大，不方便查阅。一个中小型应用系统的需求文档可多达数百页甚至更多。即使使用分卷也不方便查阅.

　　　不利于更新。需求文档是一个活的文档，不断的增长，更新是难免的。在Word中做了更新，即使用修订模式，也不容易看出更改的部分。这样导致开发和功能设计两个环节沟通不畅。通常变成需求只有第一个版本，以后的变更发个邮件或口头说一下了。

　　　不利于多人同时、协同修改。

　　　需求没有条目化，Word文档中通常只是描述功能，但实际上我们还要把需求分成一项一项，设置每个需求的优先级，难易程度，功能点（function point），在哪个发布中应该做完，需求来源等等。这种类似数据库的特性，在Word难以体现。

　　　不利于建立需求与其它开发控制元素的关系。这可能对写需求的业务人员体会不到，但对于项目经理，实现这些需求的人员来说是非常重要的。在开发过程中用户需求与软件需求的关系、软件需求与开发任务的关系、测试用例与需求之间的关系等，对于需求变更控制、质量控制都是非常重要的参考信息。一体化的需求文档（如MS Word）很难做到这一点。

　　以需求驱动的项目管理(RDPM)

　　针对应用软件的项目，汉星天公司提出与传统的基于任务的项目管理方法不同的，以需求为中心的软件项目管理方法。在管理中，Microsoft Project和Word的使用处于次要地位。

　　用户的需求是软件开发的源泉和归宿。需求代表了用户期待解决的问题，而软件项目开发的所有活动都是为此目标服务的。在众多的软件开发实施案例中，当项目一 旦开始，对于用户而言项目像进入了隧道的列车：他们再难看到自己需求的实现状况，虽然有众多的形形色色的项目进展报表，却很难回答一个很简单的问题：我的那些需求究竟实现的怎样？ RDPM(Requirement Driven Project Management)的核心在于需求，而不是任务。