浅谈需求驱动的项目管理

 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)的核心就在于需求，而不是任务。

　　需求的开发

　　首先要需求条目化。而不是放在一个大Word文档中。条目化之后，我们就可以给每个需求设置属性，通过这些属性来决定需求实现的顺序，工期，查看当前的状态等等。包括里程碑的制定，都要针对具体的需求项。 同时为了处理变更，我们还要记录需求之间的依赖关系以及追踪需求与后续的开发工件（如计划、任务、测试用例、实现代码等）的关系。这些关系又称之为“需求 追踪矩阵”。 一旦需求发生变化，影响面很广，要评估与实施需求变更，首先要确认需求变化带来的冲击面。这个工作就要依赖于“需求追踪矩阵”体系。这也是我们为什么要把需求条目化的一个重要原因。

　　条目化的需求，用MS Word难以管理，一般需要存放在数据库中。

　　但条目化不能解决一个古老的问题，即如何能把需求描述清楚。需求必须要写的清晰明确，完整，确保开发人员不需要为一个模糊的需求做决定，尤其是不要自行发挥。我推荐使用wiki来描述需求的细节，加上UI prototype，形象的描述需求。wiki最大的好处在于协同修改很方便。

　　另外一些实践能够帮助需求开发工程师提高需求编写质量：

　　记录每条需求的原因。有研究成果表明，通过记录每条需求的原因（即为什么要实现这个功能），可以删除多达半数的所谓“需求”。虽然在记录工作上投入了一定的工作量，但是有效地避免了为那些不必要的需求所要完成的后续工作，可以显著地降低系统规模、缩短系统开发周期，正所谓“事半功倍”。
　　尽可能考虑采用适当形式化的方法。由于自然语言存在歧义，一个二义性的描述因此可能导致对于同一个需求的不同解释，而采用形式化表示方法编写需求能够更加准确地在用户和开发团队间进行沟通。常用的形式化需求表示方法包括：实体关系图、数据字典、数据流程图、USE CASE等。当然还是 UI prototype最直接，简单，有效。
　　使用专业的工具编写需求，管理需求。这类工具由于没有成熟的理论指导，客户的要求各有不同，市场上相应的工具不多。汉星天公司一直致力于这方面的研究，推出了相应的需求描述，需求变更管理的解决方案；并在中国上百家大企业得到非常好的效果。

用户需求 vs. 软件需求

　　需求，谁来写呢？我们先看看两个定义需求的名词：

　　用户需求 - 用户对于其需要解决的问题以及期待的软件能力的描述。通常以用户的语言描述，用作开发团队与用户就系统如何解决问题进行沟通的桥梁。
　　软件需求 - 建立在用户需求之上，以开发团队所能理解的方式描述系统所应具有的功能，是开发团队进行设计和实现的依据。

　　我了解的一般的客户，写个word文档，发封email，或打个电话，就把需求甩给开发团队了。能写一个结构完整、内容严谨需求的客户很少。在美国，基本上用户会写需求，RFP（Request for Proposal）。国内有时候项目经理或做需求分析的工程师会帮助用户整理用户需求。用户需求比较粗。有了用户需求之后，再对其细化，写出软件需求。对于应用系统来说，软件需求写好了，开发的工作就简单多了。

　　这两种需求分别记录。里程碑一般以用户需求为目标。用户需要关联到多个软件需求上。

　　项目规划和进度监控

　　将需求作为项目规划和实施的目标，这是RDPM的核心。一切以需求为中心。

　　通过小版本发布逐步实现需求

　　在项目计划和进度控制方面，我们采用迭代的方法。

　　将项目目标分解为较小的、易于管理的子目标，这对于减少项目失败风险很有帮助。项目目标分解可以从各个角度进行，采用小版本发布分阶段实现项目需求是目前越来越被认同的一种。尤其是现在流行的敏捷开发方法，更是提倡迭代开发。有个普遍的误解就是以为敏捷开发方法只适用于小规模的开发团队，其实对大的团队一样适用。大的开发团队 可以按照实现不同的模块分成很多小的项目小组，给个项目小组其实就是一个小团队。一般5、6个人最为合适，团队合作和沟通成本之间有一个很好的平衡。

　　小版本发布是针对以前瀑布式开发的缺点而提出的开发方式。在以前的模式中，项目往往经过一个漫长的需求开发、设计、编码和测试阶段后才能够与客户见面，而客户在这个时间段上进入了“盲区”，直到开发团队“隆重推出”开发成果。而恰恰这个时候是项目风险最大的时候，由于在过程中缺乏交流机会，客户往往会发现这个产品与他们想象的很不一样，因此很有可能导致项目拖延或者失败。

　　小版本发布则不同，它将系统的实现分解为多个连续的版本，每一个都实现一部分的系统功能。当每个小版本结束后，都会邀请客户评估这一版本实现的状况，并且根据用户反馈制定和调整下一个小版本的目标。这样做的好处是显而易见的：客户越早看到产品，就能越早发现与开发团队间就用户需求方面的理解差异， 尽早调整需求，从而避免了在项目后期调整需求带来的巨额代价。另一个潜在的好处是，这一部分产品功能经过验收后就有可能投入使用，从而尽早为用户提供价值。 当然，小版本发布会不可避免地面临较多的需求变更请求，因此需要仔细的管理需求变更。

　　以需求实现为单位规划项目实施

　　小版本发布需要为每个版本制定实施目标，确定在本次版本中需要实现的功能以及计划修改的以前版本的缺陷。而用户需求是功能的表达方式，因此使用用户需求作为小版本是顺理成章的。当然根据粒度不同，也可以使用软件需求做为小版本发布的内容。

　　在定下版本计划的目标后，就需要规划实施。不过由于用户需求描述的是客户的业务和对系统的期望，因此直接采用用户需求作为开发任务安排的起点并不合适。从用户需求导出的软件需求则是以开发团队能够理解的语言和结构描述的，很适合作为安排需求实现的基础。需求追踪矩阵可以帮助我们找到版本目标中的那些用户需求相关的软件需求，项目经理则为找到的这些软件需求的实现制定开发任务，从而形成开发任务集的主线，再辅以集成测试和缺陷追踪，就形成了完整的开发计划。这样的分解方式自然而且清晰，易于上手。

　　项目的进度监控

　　前文说到用户需求是客户与开发团队间的契约，因此用户需求自然成为客户参与项目时候关心的重点。但是，在实际项目过程中，当客户真正参与项目、试图了解项目进展状况时，却发现除了用户文档外，再也找不到这些需求的影子，取而代之的是一堆花花绿绿的项目任务进展报告、甘特图、统计报告等。这些报表也许准确地反映了现在项目中任务的分布和实现状况，但是与用户关心的需求实现状态没有什么直接联系，因而与缺少了共同的语言。

　　这个问题来源于传统项目管理过程中以任务为中心的理念和实践。在这种理念下，项目被认为是一个任务的集合，主要的工作就是任务的分解（WBS： Work Breakdown Structure）、分派、实现和审核。在一个项目组内部，这的确是工作的主要内容。但是，现代的软件开发过程都强调用户的参与，项目进展仅仅以任务为视角展现就不是很合适了。对于客户而言，他们所熟悉的问题描述，即用户需求，已经被分解成几十甚至上百个大大小小的任务，再难看出它们之间的联系，客户自然会感到迷茫，更别说从中看出需求实现的状态了。

　　而RDPM中提供的是需求实现状态图，需求变化趋势，需求数量完成率，需求规模完成率，工时消耗率等指标。这些指标对于客户来说更有意义。

　　需求的变更

　　“需求变更”是业界公认的项目管理重大挑战，尤其是项目后期产生的需求变更，对项目的影响是非常大的。但是，需求开发不可能做到完美无瑕，而且随着客户对项目和系统的了解，很有可能提出新的需求或者对原有的需
求作出修正。因此，需求的变化是不可避免的。

　　对于如何应对需求变更，主要的思路有两条：首先是从源头做起，提高需求质量，减少变更的可能性，这个在前文已经提过，不再赘述；另一个就是建立流程严格控制需求变更。

　　做任何变更之前，我们都要考虑后果(consequence)。由于需求在开发中所处的中心地位，一旦需求发生变化，影响面是很广的。我们通过建立需求追踪矩阵，来分析需求的冲击面，即一个需求如果变更，将导致哪些其他的需求，测试用例、设计、编码进行变更。这个客观的信息将为项目经理提供一个做出合理判断的有力依据。

　　有效管理需求变更有几个需要特别注意的环节：

　　1. 建立正式的申请和处理流程

　　虽然众多项目管理人员对于变更可能带来的巨大影响有深刻的理解，但令人不解的是我们常常看到这些变更的提出、讨论和执行却常常停留在口头上。这样做有两个弊端：首先是时间一长，无论是当事人还是开发团队的其它成员都说不清楚变更是因何发生以及结果怎么样了。显然，这对于提高项目管理质量、改进开发过程是很不利的。其次是由于缺乏形式上的约束和对变更冲击的定量化分析，变更会被非常随意地提出、或被草率地执行，大大影响了项目的进展和开发质量。因此建立一个正式的变更处理流程并真正得以实施非常重要。

　　2. 定量化的变更冲击分析

　　变更作为一个计划外的风险因素对项目肯定存在冲击，只是大小的差别。因此，如果能够定量化地评估变更带来的影响就能帮助开发团队作出正确的应对决策。这就是变更管理中的冲击分析环节。上面谈到了，分析的基础是追踪矩阵，它记录了项目管理要素之间的联系关系。从这些关联关系中我们可以找到每一个潜在会受到影响的要素，评估对其的影响，从而组合出变更对整个项目可能造成的冲击。

　　从上面的例子可以看到，即使是加了一个看似与其他关系不大的需求，也会造成一系列的潜在影响，更不用说是在需求众多、关系复杂的大型应用系统开发项目中了。

　　3. 组成变更控制管理委员（CCB）

　　作为变更管理的一个核心控制环节，变更控制委员会（简称CCB）起决策和管理作用。它通常由客户代表和开发团队代表共同组成，负责评估变更冲击以及 决定是否要实施这样的变更。这种综合了需求方（客户）和开发方（开发团队）力量的委员会能够较好地权衡变更代价，从而减少了单方面考虑变更所带来的不利影响。

　　4. 不要忽视变更执行的管理

　　在实践中很多开发团队虽然组成了CCB并有一定的处理流程，却往往忽视了对于变更执行的管理。而变更实施的好坏、完整性对于项目本身的影响同样是巨大的。在这方面，根据冲击分析和变更评审的结果，建立一个变更任务列表并且追踪它的执行是一个很好的实践。

　　总结

　　软件项目与传统的工程项目有着很大的不同，这种不同导致描述需求的方式，实现需求，进行项目计划、监控项目进度的方式都有很大的不同。由于这种不同，传统的基于任务的项目管理方法对于应用类的软件项目并不适用。这里我们提出以需求为中心的软件项目管理。 通过提高需求描述的质量、采用小版本发布策略、将用户需求作为小版本的目标来组织和计划项目开发、积极应对需求变更、提供以用户需求为中心的项目进展视图，从而和客户一起来保证项目的成功。