第15章组织保障组织保障是确保项目顺利进行的后台支持体系就像一场精彩演出背后的舞台管理、道具准备和应急措施。本章围绕信息和文档管理、配置管理、变更管理三个方面详细介绍了如何为项目提供稳固的组织保障。15.1 信息和文档管理信息和文档是项目的“记忆”和“资产”管理好它们能让项目有据可查、有序推进。15.1.1 信息和文档1. 信息系统信息信息系统中的信息按用途可分为四类用户信息个人或组织的基本信息、账号信息、信用信息、行为数据等。业务信息按行业划分如金融、能源、交通或按业务特点细分研发、生产、维护。经营管理信息市场营销、财务、并购、产品、运营等管理视角的信息。系统运行信息网络和信息系统运维数据如配置信息、监测数据、备份数据、日志、安全漏洞等。2. 信息系统文档文档是项目的书面记录对于信息系统开发项目文档一般分为三类开发文档描述开发过程本身如可行性研究报告、需求规格说明、设计规格说明、开发计划、测试计划、质量保证计划等。产品文档描述开发过程的产物如培训手册、用户指南、软件支持手册、产品手册等。管理文档记录项目管理信息如进度变更记录、软件变更记录、团队职责、项目计划、阶段报告、配置管理计划等。文档的质量分为4级1级最低限度文档适合单人自用程序包含程序清单、开发记录、测试数据、程序简介。2级内部文档用于专用程序在1级基础上增加程序清单内的足够注释。3级工作文档适合多人联合开发或可被其他单位使用的程序。4级正式文档适合正式发行、普遍使用的软件需遵守GB/T8567规范。15.1.2 信息文档管理规则和方法1. 信息文档编制规范规范化管理体现在四个方面文档书写规范统一符号、图标含义、注释格式注明书写人和日期等。图表编号规则采用分类结构编号便于查找。例如按生命周期阶段、文档、内容、序号进行编号如图15-1。文档目录编写标准包含文档编号、名称、格式、份数、存储地点、存档时间、保管人等。文档管理制度建立规范包括借阅登记、权限控制等。2. 信息文档定级保护根据信息受影响的对象和程度进行定级保护影响对象个人、法人和其他组织的合法权益和经济利益社会秩序、公共利益国家安全。影响程度无影响、一般损害、严重损害、特别严重损害。基于此结合业务特点制定分级标准对文件的编制、审批、存储、分发、使用、变更、销毁等提出管理要求。特别要注意客户要求和合同要求密级文档需保密和权限管理。签字确认的文档应与电子文档对应电子文档设为只读。项目人员须谨慎处理信息资产防止泄露、丢失或被盗。3. 信息文档配置管理配置管理通过技术或行政手段管理配置项及其相互关系建立配置管理数据库CMDB并维护其准确性支持问题分析、变更影响度分析等。变更有主动变更提高收益和被动变更应对变化。变更管理是对变更从提出到完成的整个过程的管理。形象解释信息和文档管理就像项目的“图书馆”所有书籍信息和手稿文档都要分类编号、妥善保管并有严格的借阅制度。15.2 配置管理配置管理是在项目整个生命周期中维持配置的完整性和可跟踪性确保变更受控。它就像项目的“版本控制系统”记录每个组件的演变历史。15.2.1 基本概念1. 配置项CI配置项是作为单一实体进行管理的硬件、软件或文档集合。典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、设备型号等。配置项分为基线配置项如设计文档、源代码和非基线配置项如各类计划、报告。权限管理原则基线配置项对开发人员只读非基线配置项向项目经理、CCB及相关人员开放。2. 配置项状态配置项有三种状态草稿刚建立版本号格式为0.YZYZ从01~99。正式通过评审版本号格式为X.YX主版本19Y次版本09。修改正在修改版本号格式为X.YZZ递增修改完重新评审后变为正式版本号更新为X.YZ归零。状态变化流程如图15-2草稿→正式→修改→正式。3. 配置项版本号草稿0.YZYZ随修改递增。正式X.Y首次正式为1.0。小升级可增加附件版本附件版本累积到一定程度增加Y大升级直接增加X。修改X.YZZ递增修改完成重新评审后Z置0X.Y按规则增加。4. 配置项版本管理版本管理涉及配置标识、控制、审计、发布等记录配置项的演变过程。5. 配置基线基线是经过正式评审和批准的规格说明或产品作为后续开发的基础只有通过变更控制才能修改。基线对应一个特定的版本是进一步开发和修改的基准点。基线的主要属性包括名称、标识符、版本、日期等。6. 配置管理数据库CMDBCMDB是包含每个配置项及相互关系信息的数据库存储的信息包括与配置项有关的变更请求配置项变更轨迹特定的设备和软件计划升级、替换或弃用的配置项与配置项有关的变更和问题来自特定供应商的配置项受问题影响的配置项事件、问题、已知错误、变更、发布及员工、供应商、业务部门信息配置项的财务信息供应商、购买费用、日期7. 配置库配置库用于存放配置项并记录相关信息分为三种类型开发库动态库开发人员个人工作区保存当前正在开发的配置实体由开发人员自行控制无需严格配置控制。受控库主库包含当前基线及对基线的变更受完全配置管理。开发阶段工作结束时存入。产品库静态库存放已发布使用的基线产品完成系统测试后存入等待交付。建库模式有两种按配置项类型建库适用于通用软件开发有利于统一管理和控制但可能造成目录结构复杂。按开发任务建库适用于专业软件开发配置灵活适合线性开发模式。15.2.2 角色与职责配置管理涉及以下角色配置控制委员会CCB负责制定配置管理策略、审批计划、设置基线、批准变更、监督实施、接收验证结果等。配置管理负责人配置经理负责整个项目生命周期的配置活动包括计划、识别、控制、审计、回顾、改进审批CMDB结构变更指派审计员等。配置管理员负责具体实施如建立维护配置管理系统和库、配置项识别、基线管理、版本控制、配置状态报告、审计、发布交付。配置项负责人确保所负责配置项的准确真实记录变更、维护关系、调查审计差异、遵从过程、参与评估。15.2.3 目标与方针管理目标所有配置项能被识别和记录维护配置项记录的完整性为其他管理过程提供准确信息核实配置记录的正确性汇报配置项当前和历史状态确保配置项有效控制和管理对于软件开发项目还包括制定配置管理计划、识别需控制的产品、制定控制策略、使用工具确保基线状态及时了解等。管理方针定义配置管理过程制定相关制度明确角色责任提供培训项目成员严格按照过程执行配置管理需资金和管理支持在项目生命周期中系统性控制基于项目类型定义覆盖范围定期开展配置审计关键成功因素记录所有配置项、分类、编号、定期审计、有负责人、关注变化、定期回顾、与其他管理关联15.2.4 管理活动1. 制订配置管理计划计划需经CCB审批内容应包括目标和范围、主要活动识别、控制、状态报告、审计、回顾改进、角色责任、规范和流程、进度安排、接口控制、人员团队、信息系统规划CMDB、受控环境、工具、日常事务、基线发布和里程碑、工作量与资源计划。2. 配置项识别识别需要受控的配置项为每个分配唯一标识号定义重要特征确定所有者明确进入条件和时间建立基线维护文档与产品版本的关系。标识通常包含字符、拷贝号/序列号、版本号。3. 配置项控制即变更控制包括变更申请填写变更申请表说明变更内容、原因、影响、实施方案、工作量等提交CCB。变更评估CCB评估变更对项目的影响、必要性、范围、可行性、工作量。通告评估结果将批准/否决/推迟决定通知相关干系人。变更实施项目经理组织修改记录变更信息。变更验证与确认测试或验证变更结果提交CCB确认。变更的发布配置管理员将变更后的配置项纳入基线通知相关人员。基于配置库的变更控制通过检出/检入机制解决并发修改冲突如图15-3。程序员从受控库检出代码锁定修改后检入解锁确保同一时间只有一人修改。4. 配置状态报告记录和报告配置项的当前状况包括每个受控配置项的标识和状态、每个变更申请的状态、每个基线的当前和过去版本、其他活动记录。就像给动态演化的配置项拍“照片”。5. 配置审计审计分为功能配置审计和物理配置审计功能配置审计验证配置项的实际功效是否与需求一致如开发是否完成、性能特征是否达标、支持文档是否完整。物理配置审计验证配置项的物理存在是否与预期一致如要交付的配置项是否存在、是否包含所有必需项目。审计应定期进行或在重要事件后如新库建立、重大变更前后、发布前、灾难恢复后、发现未授权配置后。审计发现不一致时需由负责人调查后再更新CMDB。6. 配置管理回顾与改进定期回顾配置管理活动发现问题和改进点。包括准备回顾会议、召开会议听取汇报、制订改进计划、协调落实改进。形象解释配置管理就像管理一个大型仓库每个物品配置项都有编号、状态和版本有专门的保管员配置管理员进出库要登记定期盘点审计如果发现问题要追溯并改进。15.3 变更管理变更是项目中不可避免的变更管理就是规范地处理变更确保项目基准与实际执行一致最大程度满足需求、提升价值。15.3.1 基本概念1. 项目变更的含义变更是指在项目实施过程中对功能、性能、架构、技术指标、集成方法、进度等方面做出的改变。变更管理的实质是不断调整项目努力方向和资源配置以提升项目价值。2. 变更产生的原因常见原因有产品范围或项目范围定义的过失或疏忽增值变更应对风险的紧急计划或回避计划项目执行与基准不一致带来的被动调整外部事件3. 变更分类根据性质可分为重大变更、重要变更、一般变更不同审批权限根据迫切性可分为紧急变更、非紧急变更根据行业特征还可分如弱电工程中的产品范围变更、环境变更、设计变更等。4. 变更管理原则基准管理基准是变更的依据变更后要重新确定基准。变更控制流程化所有变更遵循统一流程。明确组织分工评估、评审、执行职能要清晰。与干系人充分沟通征求重要干系人意见。变更的及时性宜早不宜晚只做必须变更的。评估变更的可能影响包括对客户可视和内部工作的影响。妥善保存变更相关文档确保完整、及时、准确可用配置管理工具。5. 变更管理与相关活动的关系与项目整合管理变更管理是整体变更控制的一部分贯穿始终。变更请求可能影响范围、基准等需综合评审考虑对整体目标的影响。与配置管理变更管理包含部分配置管理活动如配置项识别、状态记录、配置确认与审计。配置管理计划规定哪些组件受控变更请求需经变更控制。15.3.2 角色与职责变更控制委员会CCB决策机构负责审查、评价、批准、推迟或否决变更通知结果接收验证结果。变更管理负责人变更经理负责整个变更过程方案的结果监控过程协调资源确定类型组织计划管理日程回顾关闭承担相应责任。变更请求者提出变更需求记录并提交请求单初步评估风险和影响。变更实施者按照批准计划实施变更记录过程验证确认。变更顾问委员会在紧急变更时可行使审批权定期听取汇报提出改进建议。15.3.3 工作程序变更申请及时以书面形式提出记录变更内容、原因、初步方案等。对变更的初审确认变更必要性格式校验确保信息充分达成共识。变更方案论证技术评估和经济社会效益评估将需求转化为资源需求。大型变更可召开论证会议。变更审查项目所有者如CCB根据申请和评估方案决定是否变更。专业评审和经济评审可分开客户意见应核心。发出通知并实施基准调整资源到位明确交付日期等通知相关人员。实施监控项目经理负责监控变更实施确保整体受控CCB监控里程碑等。效果评估根据基准评估变更目的是否达成分析差距并解决。变更收尾确认变更后的项目纳入正常轨道按新基准监控。15.3.4 变更控制1. 变更申请的控制严格控制变更申请的提交确保覆盖所有变更操作不能绕过。同时要根据变更影响提高流程效率。2. 变更内容的控制进度变更控制判断当前状态影响因素查明变化管理实际变化。成本变更控制影响因素确保变更同意管理实际变更监控偏差记录偏差防止未批准变更通知干系人控制超支。合同变更控制规定合同修改过程与整体变更控制结合。3. 变更类型的控制标准变更低风险、预先授权可无需额外授权但创建或修改时需全面评估。正常变更常规风险按标准工作程序管理可自动化提高效率。紧急变更需快速响应精简流程临时调整决策权限事后补充测试和调整。4. 变更输入输出的控制输入控制基准、计划、文件、绩效报告、变更请求和方案等。输出控制批准的变更请求、更新的基准和文件、变更后绩效报告、经验教训等。15.3.5 版本发布和回退计划对于信息系统开发变更往往涉及版本发布需制定应急回退方案。版本发布前准备工作回退分析备份存储过程、函数等数据备份配置数据备份在线生产平台接口、应用、工作流明确启动回退的触发条件说明回退机制职责通知部门、确定关联系统、回退时间点评估风险评审检查单回退步骤通知用户系统开始回退通知各关联系统版本回退回退存储过程等数据对象回退配置数据回退应用程序、接口程序、工作流等回退完成通知周边系统测试确保系统正常运行通知用户回退完成项目需分析回退原因完善回退管理。形象解释变更管理就像给飞机调整航线必须经过申请、评估、批准然后重新设定航线基准并随时监控飞行状态。如果调整失败还要有备降机场回退计划确保安全。