- A+
写在前面的话
信息系统项目管理师高项考试的论文部分考验的是一个考生对于信息系统建设和管理的深度理解，希望大家备考切勿蜻蜓点水，应当静下心认真学习和思考。考试有应试方法和经验，但是考试的基础还是对知识的理解，仅凭借应试技巧，而缺乏深入学习，论文通过率不高的。我提供的论文是我参考范文，结合我自己的实际情况编写而成，去除了项目背景，增加了一些无关痛痒的小错误，只要认真学习，肯定能发现我埋的“小地雷”。
一、规划范围管理
规范范围管理是记录如何定义、确认、控制项目范围和产品范围，制定范围管理计划的过程。凡事预则立，不预则废。进行项目的范围管理也是如此。项目启动后不久，在了解项目初步范围的基础上，我就组织项目成员制定了一个大致的《项目管理计划》，然后和项目组一起，在《项目管理计划》的总体轮廓下，依据该项目的章程和项目的初步范围，参考海洋测绘相关标准，结合组织过程资产的文档模板，制定了《范围管理计划》（初稿）和《需求管理计划》（初稿），为范围管理的后续过程提供指南和依据。我们制定的《范围管理计划》的大致内容包括：如何制定项目范围说明书；如何根据范围说明书创建wbs；如何维护和批准wbs；如何确认和验收已完成的可交付成果；如何处理项目项目范围说明书的变更。《需求管理计划》包含了如何规划、跟踪各需求以及需求管理需要的资源、培训计划、项目干系人与需求管理的策略、判断项目范围与需求不一致的准则和纠正规程、需求跟踪结构、配置管理活动。
二、收集需求
在收集需求方面，我花了相当多的时间和精力；在调研需求的过程中，我们主要采用的是访谈、会议和原型展示相结合的需求调研方法。初期我们主要采用访谈和会议，我将分析人员分成几个小组，每组2-3人，分别派往与海事中心相关业务科室领导及一线工作人员、港口引航员、船员等进入深入交流，了解他们的工作过程、现存的痛点问题，以及他们对未来系统的期望等，每个地方驻点一周，每个地点驻点完成后要提交一份调研报告给我，每天早上所有系统分析人员要召开一次线上碰头会，总结和交流需求调研的情况，并形成会议纪要。第一轮调研工作完成后，我们形成了初步的需求文件和需求跟踪矩阵，然后我组织开发人员根据初步的需求文件利用Axure软件开发出简易的系统原型，再由分析人员到各单位向系统未来的使用人员进行演示，进行了第二轮的需求调研。客户在这一轮的需求调研中表现出了较高的积极性，提出了很多建设性的意见，我们汇总这些意见后对需求进一步修改和更新，形成了正式的需求文件和需求跟踪矩阵。需求跟踪矩阵包含以下内容:用户需求项标识（ur1.1）、用户需求项标题（船舶引航）、用户需求项更改标识（原始）、软件功能需求项标识（sr1.1）、软件功能需求项标题（船舶引航）、软件功能需求项更改标识（原始）、需求状态（已批准）、概要设计章节编号、详细设计章节编号、单元测试用例标识、集成测试用例标识、系统测试用例标识、对应代码等
三、定义范围
根据项目范围管理计划、项目章程、需求文件，我召开了项目成员会议，并邀请客户方的相关领导参加会议，对项目进行产品分析，对需求范围进行梳理研究，对项目范围进行定义，编写了项目范围说明书，并找建设方的项目经理和分管领导对《项目范围说明书》进行了签字确认，后续的变更就需要走变更流程才能对其进行修改了。同时我们也编制了一份《系统需求规格说明书》，作为项目组内部设计及后续开发、测试等的依据。在《项目范围说明书》中我们以客户能懂的语言描述了系统所要实现的功能、项目过程中需要提交的交付物、项目的验收标准、假设条件和制约因素、除外责任等。另外，我们对系统不实现哪些功能、不提交哪些交付物也进行了明确说明。如需求收集过程中，我们收集到了三维地图显示需求，但经过与客户方深入沟通后发现，实际业务中并不需要三维功能，而仅仅是一些领导喜欢三维酷炫的效果才会提出这样的需求，通过对成本、进度方面的考量，与客户方确认后，决定本次项目不开发三维功能
四、创建WBS
《项目范围说明书》得到用户确认后，我们进行了WBS分解。WBS的分解是一项非常重要的工作，好的WBS结构能使得原来看起来非常笼统、模糊的项目目标一下子清晰起来，使得项目管理有依据，项目团队的工作目标变清晰。由于WBS分解涉及到将要开展的具体工作，所以将来要做这些工作的项目成员最有发言权，我让小组的组长和骨干成员都参与到WBS的分解中。实践证明这样做既符合后续软硬件设计、编码、实施人员的实际水平，又能得到他们最大程度的认同。我们进行WBS分解时制定了如下原则：在各层次上都保证项目的完整性；一个工作单元只从属于一个上层工作单元；相同层次的工作包应有相同性质；工作单元应便于进行进度和成本的控制；工作包一般不大于80小时；采用滚动规划，不求一次把所有工作包都分解出来。据此我们的WBS分成四层，第一层是按照子系统划分的，包括6个子系统和项目管理；第二层是按定义需求、设计、编码、测试、验收等生命周期来划分的；第三层是对第二层的进一步细化，比如定义需求又分成需求调研、需求分析、需求定义和需求验证等；第四层是对第三层的进一步细分，比如需求调研又分成客户现场访谈、会议、建立原型等。对于WBS中工作单元的细节信息，我们在WBS字典中加以描述。WBS分解是一项很重要的工作，在这一过程中我们发现《项目范围说明书》中存在较多不明确的方面，通过WBS分解而得到明确。WBS分解工作完成后，项目范围基准就确定了。wbs分解为5层:第一层六个子系统和项目管理；第二层船舶导航分为路径规划、路径导航、航行监测；第三层航行监测分为障碍物监测、偏航监测、碰撞监测、水深监测；第四层偏航监测分为实时定位、路径检索、偏航算法；第五层实时定位分为AIS定位、GPS定位、北斗定位
五、确认范围
项目可交付成果、子功能被开发出来之后，我们项目组内部先对其进行评审和测试，通过后，把这些成果交付给用户，通过审查、产品审计、走查等方法，和用户一起按范围基准、质量标准等要求进行确认范围（即验收）。由于该项目范围广、功能点多，我们找客户进行局部确认范围的频次较高，在里程碑点一般举行较为正式的会议，非里程碑点一般通过当面交流的方式，虽然这样做增加了不少工作量，但对于最后一次性通过竣工验收非常有利。在确认范围时，对于局部确认范围，我们主要是邀请客户方、监理方参与评审和测试；对于全局确认范围，是由客户方邀请第三方（主要是相关领域专家）进行评审。在每个阶段结束时与相关干系人召开评审会，各方对本阶段的工作内容和可交付成果进行评审，对关键文档进行确认定版，评审过程的意见形成书面记录。
六、控制范围
控制范围就是监督项目的范围状态，管理范围变更的过程。通过偏差分析工具，始终对项目范围进行控制。根据需求文件、需求跟踪矩阵对项目范围进行监督和控制。该项目用户范围广、功能多的特点决定了该项目在开发过程中避免不了范围的变更，在项目一开始我就很清楚，如果不做好范围的控制，该项目很难在合同规定的时间内完成，预算也必然超支，所以项目一开始我就高度重视范围的控制工作。开始时我主要是在与客户签订的合同上下功能，将经过客户方确认的《项目范围说明书》作为合同的附件附上，同时在合同正文上明确范围变更的审批权限（即CCB由哪些人组成）和变更进行的流程；在项目进行过程中，果然有很多人提出这个那个新需求，要求添加进去，我让他们提交书面申请，说明经过批准之后才能实施，开始的时候很多人认为我们很难讲话，开始不配合工作，我拿出很多时间与他们沟通，说明这样做是为他们好。经过苦口婆心的说明，部分客户有所好转，但有部分客户很难讲话，我的工作一度陷入困境，这个时候我一方面对那些“刁难的人”采用刚性的合同来“说话”，但更多的还是用“柔性”的沟通来解决存在的问题，对变更提出者施加影响，要求变更提出者在会上说明变更必要性及变更方案，领导审核，确保实施的变更都是必要的。功夫不负有心人，到项目结束的时候，大家都理解了我的做法，觉得我做事“有章法”。
项目于2022年12月20日全部上线并顺利通过了用户的验收，在合同规定的日期前10天左右圆满完成了各项任务，至今运行状况良好，得到用户的一致好评。在本项目的范围管理中，我总结了如下几条经验：事先要有明确的计划作为指导；关于范围控制方面，一定要在项目正式开始前与用户就变更的审批权限和变更的流程达成一致意见，最好能写进合同中（或签订补充协议作为合同的一部分），在项目进行过程中一定要严格按照变更的规定流程进行，要死死的扛住，多用沟通来化解客户的不理解；必须在《项目范围说明书》上多花一些时间，比如，把范围确认（验收）的标准事前就在《项目范围说明书》中尽量说明清楚，并且经过客户确认，这样可以避免客户当事人（特别是政府部门的人）“不敢轻易签字”的问题；WBS的分解最好让执行候选工作任务的当事人参与，因为唯有参与，才有认同。
项目虽然取得了不错的成绩，但也存在需要改进的地方，如：对项目边界之外可能会有哪些工作描述得还是比较粗糙，如果能在《范围说明书》中对不应该包括在项目范围之内的工作描述得更细一点，就可以很轻松地排除客户的一些变更要求，避免一些无谓的争执；在范围确认环节，常常因为客户忙，不能及时参与而耽误了不少时间，对于这个问题，应该找客户方的领导，让领导清楚地知道，客户方的项目经理是需要投入很多时间在该项目上的，让客户方的项目经理专职（基本上很难）或将项目的工作纳入其主要（至少也是重要）工作事项和绩效考核中，这样项目经理才有时间和积极性参与到项目中。
牢记不足，吸取教训，相信通过不断的积累和不懈的努力，我的信息系统项目管理能力一定可以得到不断提高。
软考高项学习交流微信群
