论电子政务协同办公系统的需求管理和范围管理

论电子政务协同办公系统的需求管理和范围管理

摘要：笔者在2011年6-8月到某计算机公司进行下企业实践，参与了电子政务协同办公系统的项目管理设计，包括团队管理、需求分析和设计、系统集成、产品交付及本项目相关的各种沟通与协调。本项目的基本功能包括办公门户、收发文件、政务公开、事务协办、档案管理、车辆管理、会议管理、流程管理、组织结构管理、人员管理、短信发送、手机办公等功能模块。该项目具有需求提出层级多、行业特性强、业务流程复杂等特点，在项目研发和实施过程中，项目需求变更频繁，部分需求需要走一步看一步、同时经常出现“一句话”需求等。该文分析项目需求管理和范围管理的关联关系和相互作用，阐明需求开发对项目范围定义的重要性、工作分解结构粗细度将直接影响到本项目后续计划的执行乃至关系到项

目成败。最后对需求管理的一些实际问题进行了总结。

关键词：电子政务协同办公系统；需求管理；范围管理

中图分类号：tp391 文献标识码：a 文章编号：1009-3044（2013）04-0957-02

1 项目概况

电子政务协同办公系统是利用信息技术和网络技术，实现政府部门之间无纸化办公、透明化办公、规范化办公，提高政府部门之间办事效率，起到信息上传下达作用的一种计算机系统。笔者所在公司实施过多个政府部门的协同办公系统，该文以某一个地级市政府的协同办公系统（以下简称“本项目”）为例，该市为了更好地完

成电子政务协同办公系统的建设，由市政府秘书处负责总牵头，数字办负责具体的平台项目的承建，自2011年4月份开始进行招投标工作，2011年6月份正式中标，项目最终要建成全市统一的电子政务协同办公系统，功能包括办公门户、收发文件、政务公开、事务协办、档案管理、车辆管理、会议管理、流程管理、组织结构管理、人员管理、短信发送、手机办公（android和ios两个手机操作系统版本）等功能模块组成。

电子政务协同办公系统与企业的办公自动化协同系统实施项目不一样，其具有操作人员多层级不同、行业特性强、业务流程和协同要求复杂度高等特点，在本项目研发和实施过程中，项目范围和具体的业务实现需求变更频繁。同时电子政务协同办公系统项目实施没有标准规范，业务需求经常因人而异、因部门而异，因此业主（最终客户）与系统集成商之间的沟通有时会出现偏差。

根据目前国内已实施的许多电子政务协同办公系统项目的建设情况来看，无论是在项目规划、合同签订过程还是在具体的研发执行过程，对项目范围大都没有很非常明确和精准的圈定，经常是一句话需求，因此在项目合同签订后往往会叠加超乎合同范围的需求，同时也会经常因某些要求或事件需要临时增加需求进而影响到整个项目的范围界定，因此电子政务协同办公系统最终交付的成果往往是一个“四不像”，且整个项目实施过程复杂度高、周期长、成本增加，随着时间的推移、项目使用人员的更换需求和项目范围往往也会随之发生变化，如何控制好需求和项目范围是一个非常重

要的任务。

2 需求开发、需求管理和范围管理的区别与联系

范围管理对于信息化系统项目的成功实施有至关重要的作用，在项目管理体系中，项目范围与时间管理、质量管理、成本管理相互牵制和相互影响，项目范围的不确定性将直接影响到项目计划，也将致使整个项目的时间管理出现大范围波动、项目范围的不清晰将致使项目质量无法得到直接的控制最终导致项目交付成果与项目预期不一样、项目范围的经常变动对于项目研发和工程实施团队而言可能致使类似返工等现象进而直接影响到整个项目的投入因而使得项目的成本管理处于不可控状态。

需求开发指的是对客户提出来的初步需求或想法进行深入调研、沟通、了解并进行细化和设计的过程，目的是最终定义产品需求。需求管理则是为了确保参与需求相关干系方能够获得统一一致的需求理解，制定需求跟踪矩阵以对需求从产生到最终实现的全过程管理和跟踪，包括需求的变更和控制。范围管理则是一项管理性工作，目的在校验和检查项目管理过程中涉及范围的各种动作是否得到执行、是否包含了全部的工作，范围管理包括为成功完成本项目所需的范围计划编制、范围定义、创建工作分解结构、范围确认和范围控制共计五个过程。

本项目通过需求开发来获得客户最终需要的产品需求，并以此作为基础制定本项目的项目范围，同时进行项目范围管理。需求管理则是对已获得批准的项目需求进行全生命周期的管理，包括需求管

理定义、需求计划制定、需求管理流程、需求管理计划和需求实施建议等。对于项目的需求可以根据客户的紧急程度同时结合项目本身的特性等等情况分期或分步骤实现，而不管分多少期或分多少个阶段，一旦确定的需求则本期项目或本阶段项目的项目范围也就随之确定了。需求管理是针对已获得批准和确认的需求的管理和控制，包括变更控制，需求的变更会引起项目的范围的变更。

3 范围管理过程、方法和、工具及实施效果

通过前期的项目可行性分析、招投标等环节最终我司负责承建本项目。项目中标后签署合同时，大部分需求都比较笼统且泛泛而谈，双方在合同签订时对需求范围的界定缺乏严格的审核，在后面项目执行期间，用户总习惯于追求“大而全”的功能范围，以为“功能越多越好”。

例如，本项目中有一个功能模块叫“会议管理”，在需求中写明“乙方提供会议管理功能”就一句话，经过与市政府秘书处沟通确定该需求需要跟数字办进行调研和沟通，同时指定教育局作为试点单位提出项目建设需求，最终确定会议管理功能实现会议室名称管理、会议室使用管理两个大功能，其中会议室使用管理主要是会议使用者可以向会议管理中心申请并预占会议室，同时要求短信通知与会人员。但短信通知需要通信网络支持，合同签订时没有写明短信费用谁来出怎么出，最后考虑到成本的问题，经过艰辛的沟通最终确定采用邮件和oa界面提醒的方式进行会议通知。因而一句话需求在合同签署时一定要确定具体功能。

没有对具体的需求进行细化，项目范围就无法确定。例如，在合同中约定“乙方提供协同办公系统、移动办公系统的建设”，同时经常在合同上附上一个功能模块清单但没有具体的业务流程、业务要素和业务要求，这些需求在项目实施过程中经过调研后发现跟需求提出时的要求偏差很大。

综上，在该项目合同签订后的两个月内，我们需求人员负责对需求进行收集、分析和设计。本项目的使用部门涉及市政府、市委、人大、政协、市委下属部门（宣传部、纪委等）等单位和部门，根据不同单位和部门的需求，我们针对客户的实际工作时间和工作特性采用访谈、小组会议、问卷调查和原型法相互结合的方式对客户的需求进行收集。特别是访谈，我们采用了引导式的访谈模式来聚焦客户的需求，事先准备好提纲，采用开放式的沟通模式围绕提纲进行交流；而小组会议则也是以预先做好的界面原型为基础进行沟通，聚焦并细化需求，尽量避免模糊需求。需求收集完成之后，我们根据客户的需求进行分类整理，并形成需求跟踪矩阵同时制定需求管理计划。

收集各种需求后，项目组内部召集需求讨论会议进行细化，最终输出需求规格说明书，包括项目概述、项目目标、项目范围、项目的具体需求、项目的接口和边界、项目可交付成果、可验证成果和验证标准等内容。

需求内容基本确定之后，考虑到本项目跨越多个部门，我们采用谁提需求谁确认的原则，对于每一个需求点均与需求提出者进行确