项目管理中的需求管理和范围管理

论项目管理中的范围管理摘要：从业的这些年里，经历过软件研发、研发管理、集成项目实施和实施管理。经历的大大小小的项目，有非常成功的，也有不怎么顺利的甚至失败的。项目的失败可能是有各种名样的原因导致的，但是否实施了有效的范围管理却是关键因素，本文论述我在多年工作中对项目范围管理的一些认识，希望与大家分享。关键词：项目管理范围管理需求2008年我从研发部门调入实施部门负责实施项目管理工作，这之后整整一年时间，一直在努力完成一个投入不断增加、迟迟无法完成验收的项目。推动验收的过程非常艰难，因为项目合同范围签得很虚很空，而项目过程中也没有签署相应的范围说明书及需求说明书，因此跟客户的每一次沟通在项目是否完成建设目标上都难以达成一致，双方对需求范围的理解和界定也无法达成一致。每一次沟通，都会在原有的遗留问题或需求列表中多出新的内容来，项目组一直在不断地投入，期望最终客户能够满意，但是事实是随着系统的不断调整，客户方和项目组已经没有人能真正说清楚，这样的情况使得验收推动更加困难。其实相信大家在项目管理的经历中，大多有过类似的经历：一个项目做了很久，感觉总是做不完，就像一个“无底洞”。客户总是有新的需求要集成商做，就像客户在“漫天要价”，而系统集成公司则总是疲于应付，从而带来项目周期拖长、项目成本超出预算、客户满意度降低、公司信誉受损等一系列后果，甚至还可能导致项目失败。实际上，造成上述问题的根本原因，就是因为项目没有执行有效的范围管理，即项目中没有就哪些该做，哪些不该做，做到什么程度等与客户达成一致。信息系统集成项目特点之一是实施的周期长、对业务的依赖性强，特别是一些跨业务的项目，要完全把客户的全业务流程稳定下来，并通过系统实现，是需要较长的时间来巩固的，因此在项目实施过程中常常出现需求不稳定、需求变更，项目范围失控的现象，如果在此问题上没有一个“度”的控制，那么项目的范围将失去可控性，随之而来的是项目风险和成本的失败，最终导致项目的严重滞后甚至是失败。那么什么是项目范围管理？信息系统集成项目又如何才能做好范围管理呢？项目是为完成产品或服务所做的一次性努力，因此系统集成项目范围的概念包含两方面，一个是产品范围，即产品或服务所包含的特征或功能，另一个是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。而范围界定的关键是明确的需求，需求是整个软件产品链的源头，需求工作的优劣将直接影响到产品的设计、生产、销售和维护的全过程。一、 需求分析需求是整个软件产品链的源头，需求工作的优劣将直接影响到产品的设计、生产、销售和维护的全过程。在以往建设失败的系统集成项目中，80%是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，客户不习惯或不愿意去用集成商的新系统。在软件开发过程中需求的变化是永恒的，需求不可能是完备的，造成需求变化的原因有很多。比如：随着项目的进展，开发方和客户方对需求的了解越来越深入；原先的需求文档可能存在这样或那样的错误和不足，因此要变更需求；由于市场和业务发生了变化，原先的需求文档可能跟不上当前市场的要求，因此要变更需求等等。需求的变更不一定是坏事，常常提出需求变更的动机是好的,目的是希望产品更加符合用户的需求。但是需求变更意味着要调整资源、重新分配任务、修改前期工作成果等，这将为项目的正常进展带来影响，项目延期或成本投入的增加等，解决这个问题最好的办法是事先将需求分析工作尽量做完备，即在需求分析上遵循一定的方法步骤，在需求管理上遵循一定的策略。需求分析的过程包括了需求开发和需求管理两个部分。需求开发指的是从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，这几个阶段的活动可以是相互独立和反复的，不一定非要遵循线性的顺序。需求管理则是与需求直接相关的活动，即软件项目开发过程中控制和维持需求约定的活动，主要包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。需求开发和传统的产业相比，由于软件项目的需求具有模糊性、不确定性、变化性和主观性的特点，它不像生产汽车、电脑硬件的需求，是有形的、客观的、可描述的、可检测的，同时由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响，造成了软件需求分析是软件项目开发中的确是很难把握的问题。因此做好需求的开发需要遵循一定的步骤和方法，无序的工作是无法获得良好的结果的。基于这一点，我认为以业务为中心进行访谈、分析、引导、确认，需求过程项目组应该将各项工作做细，寻求客户的配合和理解，最终达成对需求成果的一致认可。首先调研主要以访谈的方式进行，正式访谈前应该制定需求调研计划，明确各项访谈、整理等工作的具体时间、地点、调研内容及建议参与的人员，调研计划提前发给客户，以便客户提前就访谈内容做准备，也便于客户方项目管理人员协调相关业务人员参与调研。调研内容应该以业务为中心展开，通常的可以包括业务现状和相关IT系统建设现状、在建系统使用的组织及人员包括相应的使用权限设定、各项具体业务流程以及客户对业务工作改进的意愿及对系统建设期望、具体的系统功能需求、对系统性能、交互体验方面的需求等。调研中需要注意的几点：■参与调研的业务人员要尽量保证是相关业务流程环节的使用人员或业务决策人员，这能保证需求与实际业务的符合度和一致性，不至于在系统开发完成后发现与实际业务是不符的；■调研访谈要有详细的访谈记录，对于访谈过程中双方确认的内容或决议，要通过面方式比如会议纪要、备忘录、邮件等及时提交客户方业务人员确认，以保证项目组与客户方对需求理解的一致性；■这个阶段的调研采用相对紧凑的节奏，访谈结束当天就需要及时进行调研成果的整理分析，考虑系统对需求实现的可行性，从而及时发现调研中遗漏或不明确的项、以及关键技术难点等，以便在下次访谈时及时跟进，保证需求的完整性；■这个阶段的访谈、需求整理分析可以反复多次，以达到需求尽可能的详细和完备。阶段性访谈调研结束后，项目进行需求详细分析阶段，这个阶段项目组在前一阶访谈调研结果的基础上，分析抽象出系统功能需求，同时考虑操作界面、性能等非功能性需求；需求分析采用业务到系统到数据的整理分析过程，保证系统与业务的符合度。对操作流程及交互需求，可以通过开发系统原型来实现。需求详细分析形成需求规格说明书和系统原型，这部分工作完成后可以再次安排调研，这个阶段的调研重点是跟客户确认需求及系统实现与业务的符合度，往往在这个阶段业务和项目组的分歧会表现得更明显。因此可以在该阶段尽量协调业务决策人员参与，以保证分歧的高效解决和确认。对于系统无法实现的需求，应该尽可能采用引导的方式与客户沟通。由于各种各样的原因，在企业的经营管理中总会有一些具有自己特色的东西，但是，企业难于在短时间改变现有的做法，这就需要软件的灵活性和实施的变通。当然，应该尽可能地使企业的行为合符有关的法规和惯例，这是最好的结果。但是最好的软件也不是万能的，不可能百分之百地解决客户地所有问题。在项目的实施过程中，应该实事求是地、明确地告诉用户那些是软件做不到的。如果一味只想把企业原本正确的业务流程转变成本公司软件所规定的业务流程，结果造成双方僵持。当然更不能一味要求降低客户需求，而是应该在满足客户影响业务的主要需求基础上，合理地降低的客户需求。这就需要通过变通的方法或解决方案引导客户放弃或改变实现，只有获得客户在需求上一致的认知，才能有效降低需求变化带来的风险。需求管理的策略有效的需求控制必须遵循一定的管理策略：需求一定要与投入有必然的联系。在项目启动的初期，实施方和客户方就应该明确达成一致，需求发生变化，项目投入也要随之改变，客户方应该为变更需求付钱。需求的变更要经过出资者的认可。需求的变更将引起投入的变化，需求的变化也可能引发运行系统的不稳定、业务流程的改变等，出资者必须认可由需求变化导致的投入及风险，这样出资方才能够慎重地对待需求的变更，而不至使需求变更变得随意。所有需求变更均应该纳入需求控制审批流程，即使很小的需求。通常项目组不应该随时或随意地响应客户的需求，尤其是一些很小的很容易实现的需求。我认为正确的方法应该是固定的接口人收集需求，定项目组定期评估分析，并且跟客户方确认审批后才能进行开发。随意的需求变更必然导致系统开发的重复投入和系统的不稳定。精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细，越能避免需求的渐变，但是尽可能完备的需求，能够帮助有效控制需求的变化。注意沟通的技巧。不要直接拒绝客户的需求，客户提出需求必然是有原因的，项目组应该站在业务的角度去分析需求的变化，挖掘客户真正想要达到的目的，然后提出解决方案。良好的沟通技巧及主动工作，能够帮助双方诉求和项目目标的一致。二、 范围管理那么如何才能做好项目的范围管理呢？做好项目范围管理的基础是一个科学的范围管理流程，这个在项目管理协会(PMI)的项目管理知识体系指南(PMBOK)中已经给出了严格的定义，其中包括范围规划、范围定义、范围确认和范围变更。没有一个科学的方法论进行指导，要对整个项目范围有一个严格的控制将会是一个很困难的过程，而按照PMBOK规定的几个流程，我们发现可以轻易地将项目的范围管理起来。通过范围管理的启动过程确定项目的范围框架，范围规划确定项目的范围管理计划，范围定义制定详细的项目范围说明书，为将来的项目决策提供依据，而项目核实和项目控制过程保证了范围管理能够如期地实施。通过这样的一个科学管理流程就保证了范围管理能够真正地有效落实。编制范围计划具体的说，范围说明是在项目参与人之间确认或建立了一个项目范围的共识，作为未来项目决策的文档基准。范围说明中至少要说明项目论证、项目产品、项目可交付成果和项目目标。范围管理计划是描述对项目范围如何进行管理、项目范围怎样变化才能与项目要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估。范围管理计划还应该包括对变化范围怎样确定以及对变化应归为哪一类等问题的清楚描述。范围分解完成项目是一个复杂的过程，计划明确了，还应采取分解的手段把主要的可交付成果分成更容易管理的单元才能一目了然，最终得出项目的工作分解结构(WBS)。比较常用的方式是以项目进度为依据划分WBS,第一层是大的项目成果框架，每层下面再把工作分解，这种方式的优点是结合进度划分，直观、时间感强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。2.2.3范围变更管理一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的，因此对变更的管理是项目经理必备的素质之一。变更并不可怕，糟糕的是缺乏规范的变更管理过程。范围变更的原因是多方面的，项目经理在管理过程中必须通过监督绩效报告、当前进展情况等来分析和预测可能出现的范围变更，在发生变更时遵循规范的变更程序来管理变更。科学