论信息系统项目管理师需求（范围）管理

项目需求与范围的区别和联系

项目范围（Project-scope）包括项目的最终产品或服务以及实现改产品或服务所需的各项具体工作。从这个意义上讲就是项目应该做什么，不应该做什么，以及如何做。也就是说，项目范围事实包括2个方面的内容：项目需求和项目过程．项目需求确定做什么．项目过程确定如何做．

项目范围管理也就是对项目应该做什么和怎么做做出相应的定义和控制．事实上就是对需求的管理和项目过程的管理．

摘要：

通常大型信息系统开发项目都具有相当的难度和复杂性，含糊的需求和频繁变更让经常会使项目进度多拖延、成本超支、偏离既定目标，严重时会导致项目的失败，因此，加强项目需求管理尤为重要。2010年4月至10月，我参加了某集团企业协同办公管理系统项目的开发，并担任的该项目的项目经理。项目的总体目标是建立一个兼具企业门户、公文管理、工作流、知识管理、移动办公的办公平台，共分为10个子系统，分别为：企业门户、个人办公、信息发布、收发文管理、规章制度、日常事务、工作流管理、文档管理、移动办公和基础平台。本文以该项目为例，结合作者实践，探讨了信息系统项目中的需求管理问题，分别论述了需求管理计划编制、需求控制和跟踪、需求变更管理等过程作为需求管理手段的应用，列举了一些有效的工具和技术的使用；最后，谈一些自己的体会和经验总结。

正文：

通常大型信息系统开发项目都具有相当的难度和复杂性，含糊的需求和频繁变更会使项目进度多拖延、成本超支、偏离既定目标，严重时会导致项目的失败，一个项目的成功得益于有效的需求管理机制，这在本人所主持的某集团企业协同办公管理系统项目实施过程中得到了充分验证。

2010年4月至10月，我参加了某集团企业协同办公管理系统项目的开发，并担任的该项目的项目经理。项目目标是建立一个兼具企业门户、公文管理、工作流管理、知识管理、移动办公的协同办公平台，整体提升企业办公服务水平和工作效率。系统采用B\S架构，核心技术框架根据微软的.NET分层体系结构实现，共分为10个子系统，分别为：办公门户、工作助手、信息发布、收发文管理、规章制度、日常事务、工作流管理、文档管理、移动办公和基础平台。

该项目是一个综合性的系统工程项目，该集团企业包括总部、6个大区公司及其下属的地方公司，在管理模式上存在较大差异，信息化程度参差不齐，各个地区工作流程也不一致，业务需求很难统一;协同办公是公司新的业务领域，我方领导也希望将本项目作为公司业务延伸拓展的一个新的窗口；从技术角度将，涉及移动办公、电子签章、工作流、全文检索、备份归档、无线通信等相关技术；人力资源方面，需要不同专业技术的人员配合，可能会存在多部门之间的协作。由此可见，该项目组织构成复杂、干系人面广人多、业务需求很难统一，而且涉及新的业务领域，公司在协同办公方面也缺乏积累，工作面临很大挑战。因此，在该项目中，我充分重视了项目需求管理，通过制定合理的需求管理计划，做好需求的跟踪和控制，提高领导和项目干系人的参与热情等方法，有条不紊地完成了该项目。具体来说：

首先，制定合理的需求管理计划，为项目团队如何管理项目需求提供的指导。我们参考了CMMI和组织过程资产的基本内容，并结合项目的各方面实际情况，确定了需求管理的组织方针、需求管理跟踪的方法、工具和时间、业务培训计划、如何进行需求验证和变更控制以及制定需求跟踪矩阵。我们确定采用微软的团队资源管理器（TFS）实现对需求和文档的管理，并在需求、需求分析、设计、代码等各个阶段打基线，通过TFS实现对各种变更的管理，做到有效可控；规定在打每个基线之前召开评审会，邀请所有项目干系人代表参与评审，做到每个阶段的成果都能符合项目干系人的要求。我们还指定了需求管理的总负责人，统一进行需求的管理。

由于该集团企业下属部门众多而且分布各地，业务需求有一些差异，业务领域一般比较广泛和复杂，在需求获取定义的方法上，我们采用了专家法。邀请专家时要尽量能够代表各个地区、部门、组织机构以及各个业务技术领域，这样既可以帮助我们短期内熟悉相关业务，也便于收集和统一来自各个方面的需求，为日后需求的确认铺平道路。

再次，项目评审是确保项目需求能得到很好跟踪和控制的有效措施。在项目进度计划中我们确定了需求分析、系统设计、系统测试、系统上线等几个重要里程碑。在这些里程碑结束后，我们将邀请相关项目干系人参与项目的评审工作。目的是为了防止需求偏差、遗漏，和收集新的需求，使跟踪工作贯穿于项目的始终，以确保项目需求的正确性和可接受性。每一次的项目评审都给我们带来了很多很好的建议，让我们充分发现了我们系统的不足之处，发现了许多业务上的偏差。当然也有许多项目干系人提出了系统易用性上的建议。会后，我们按照项目范围变更计划和客户方、业务专家一起对这些建议作了逐一评估，将那些有益的建议包含进项目范围管理计划中。

此外，再好的计划也不可能做到一成不变，因此变更是不要避免的，关键问题是如何对变更如何进行有效的控制。本项目的复杂程度高、涉及面较广、实施周期长，在实施过程中，由于用户方需求的变更，或由于各方交流的失误等，曾经导致了部分项目内容的变更。当有变更要求提出的时候，作为项目经理，我都会召集项目团队相关人员，进行协商讨论和工作安排，对变更因素进行分析、快速决策。由于本项目需求变化不断调整，我们建立了良好的变更流程：填制申请单、团队相关人员讨论、提交CCB给出最终确认、实施和验证变更、通知干系人。在变更管理时要做好版本控制，我们通过使用TFS进行文档的检入、检出、打标签等操作，每次修改后TFS根据事先定义好的规则自动生产版本号，可以方便的跟踪每个需求变动的历史，当需要恢复早期很有价值。

最后，领导的重视和项目干系人的参与是这次项目成功的关键。项目正式启动之初，在双方领导的通力配合下，我们召集了全行主要干系人参与的项目启动会，并邀请客户高层在会议上讲话，提升大家对这个项目重要性的认识。在这次会议上，我作为项目经理向各项目干系人，就项目的主要目标、需求范围、需求调研计划、沟通方式作了详细介绍。希望各项目干系人能够积极配合我们的工作，同时我们也将尽量满足他们的要求。在项目进行过程中许多干系人都给我提出了很多很好的建议，同时我们也采取了电话、E-mail、QQ群等多种沟通方式收集他们的需求。这个项目的成功是全体项目干系人的成功，是全体项目干系人共同努力的结果。

由于我们在项目进行的最初期阶段就引入了项目需求管理理念和方法，项目顺利完成，客户很满意，也为今后公司类似项目积累了经验，得到了公司管理层的高度评价，这归功于整个团队的配合。但是回顾起来，也有一些不足的地方：项目可行性研究做的不够充分，没有充分考虑到各个地区信息化程度的差异，造成到目前为止，少数单位由于网络方面的原因，只能通过拨号来使用本系统，使用效果打了一些折扣。我们也采取了一些补救的措施，如尽量减小页面大小，优化系统响应时间原因等，一定程度上改善使用效果，通过和用户的悉心沟通，最终得到了用户的认可。

总之，项目的管理方式多种多样，因人而异、因项目规模而异，管理方式不是一成不变的。适合自己的管理模式才是最好的模式，这些都有待于我们进一步研究、探索、实践和总结。