日常业务支撑管理办法v34.docx

日常业务支撑管理办法文件状态：[]草稿[]正在修改文件标识：CM-A&C Base-DailySoftwareRequireManagement-022文件密级：中当前版本：3.4[V]正式发布文档名称：日常业务支撑管理办法撰稿人：张金林、李晓耕、徐文敏参与讨论人员：熊亿民、李晓耕、张金林、徐文敏等完成日期：2012-9-20第一章 总则第一条 为规范公司（以下简称）日常业务支撑管理工作，适应项目开发和管理 的需要，提高业务支撑管理水平，有效提升日常业务支撑工作的效率和 质量，特制定本办法第二条 本办法适用于公司及下属各科室第二章 各单元职责第三条 本办法中所称的开发单元，是指内负责具体 IT 系统开发的系统支撑室和 产品管理室所称的需求单元，是指内提出业务支撑开发需求的各科室第四条 开发单元职责：（一） 负责组织人员做好与合作厂商沟通协调工作二） 负责审核、审批需求分析报告三） 负责审核业务需求的技术可行性审核四） 负责组织人员做好软件需求、软件版本、系统上线跟踪协调工作五） 负责组织人员做好软件开发项目文档归档管理工作六） 负责组织人员对软件项目进行验收工作七） 负责对软件需求的结算工作量进行审核。

第五条 需求单元职责：（一） 负责业务方案的策划二） 负责编写、审核、审批业务需求三） 负责审批业务测试及质量验证第三章 需求分类与优先级级别第六条 业务支撑需求目前包括以下六类：（一） 业务需求：新增业务需求，需要新增系统功能二） 优化改进：优化现有系统功能、流程，改善现有系统功能三） 需求变更：对现有功能进行设计修改四） 配置修改：修改现网系统的配置参数，例如接入号、业务局数据五） 数据修改：现有业务数据展示修改，如内容、产品、订购关系、用户相关数据修改六） 数据统计: 对现有业务从平台进行数据统计、提取第七条 业务支撑需求的优先级别目前从高到低依次分为紧急、重要、日常三类具体的开发排期可按照优先级从高到低进行影响用户感知急需进行修改的需求，应立即修改，不能立即修改的应立即隐藏，并在 1 小时内完 成修改或隐藏隐藏到后台的文字类的修改应在一天之内完成，涉及程 序修改的应按紧急补丁需求优先安排完成第四章 版本控制第八条 日常业务支撑的开发版本控制按 “红绿两区、高效并行、三天配置”的原则进行，版本管理可依据需求的性质进行分类管理： 红区：鉴权、计费、结算、能力部件等基础和关键功能需求纳入红区版 本进行开发，以确保系统质量、稳定性、可靠性。

绿区：前端门户、创新业务、独立交互模块等功能需求纳入绿区版本进 行开发，以快速迭代，提升支撑效率红区版本周期为 5 周，绿区版本周期为 3 周第五章 流程管理第九条 需求申请需求单元人员填写附件一日常业务支撑需求申请表，或通过电子工单流系统提交支撑申请，提交至需求单元负责人审批紧急需求需进一步提 交分管领导审批；对于特别紧急需求，开发单元可先安排支撑，需求单元必须在上线前提 交工单对原有内容的微调可由需求负责人签字，直接提交至开发单元的需求分 析负责人，并由开发单元安排人员修改第十条 需求澄清为确保需求明确，需求单元人员提交需求前，必须先与开发单元的项目 管理负责人、厂商需求负责人进行需求澄清，明确需求并确认技术可行 性第十一条 需求审批需求单元负责人审阅软件需求申请表，审批通过后工单流转至开发单元第十二条 开发审批开发单元负责人审阅软件需求申请表，并分派给具体负责的需求分析负 责人第十三条 需求分析需求分析负责人分析需求的技术可行性及其对系统架构的影响如需求对系统可能造成较大影响，由需求分析负责人协调并组织项目管理负责人、业务负责人进行整体考虑和统筹设计，并就业务支撑方案达成一致涉及产品或系统演进规划、系统间联调、多部件协调开发的复杂需求由跨部门技术专家组（由产品和系统规划、开发、网络及信息安全等相关 技术人员组成）组织需求分析和评审；第十四条 方案评估项目管理负责人安排人员根据需求组织编写技术方案（UCD设计低保真、需求功能规格说明书等）。

方案设计完成后，组织需求单元人员进行方案 的评估和确认，并形成方案终稿冻结第十五条 工作量评估工作量评估应通过功能点分析法、开发阶段分析法等方法进行，以确保 开发工作量评估的客观、公正项目管理负责人组织工作量评估小组（项目管理负责人、需求负责人、 需求单元负责人、需求分析负责人、开发单元负责人、纪检负责人等） 进行开发工作量评估，具体操作如下：（一） 20 人天以下的需求：由工作量评估小组评估并签字确认二） 21 至 70 人天的需求：由工作量评估小组评估，并提请内部决策 会决策后，由需求单元分管领导签字确认三） 70 人天以上的需求：由工作量评估小组评估，并提请厦门小组决策会决策后，由省公司0A上发布决策会的会议纪要确认第十六条 版本排期各业务单元根据需求的优先级进行内部排序，并向开发单元提交待支撑 的需求内容开发单元将待支撑的需求统一排序，未纳入开发版本或有 争议的部分需求请示领导决策一） 需求优先级按照需求来源（优先级顺序从高到低为：上级或兄弟 单位督办需求、领导督办需求、一般需求）、需求紧急程度（从高到 低为：紧急、重要、一般） 、需求前后端类型（影响用户感知的前 段需求优先支撑，后台管理相关需求开发之前可通过人工支撑）、 需求实现价值（需求的价值越高优先级越高）、需求滞留时间（滞 留时间越长优先越高）等五个维度进行综合考量。

二） 各需求单元按照五个维度对内部需求补充相关权值，由开发单元 对需求统筹进行优先级排序三） 节假日类日常营销需求尤其是重要需求应日历化、模板化，避免 经常出现紧急又重要的需求，打乱开发节奏如确实需开发支撑， 应在开发版本启动前完成业务方案，否则必须提前明确预知开发单 元预留足够的开发工作量第十七条 变更控制包含版本上线进度、需求范围以及工作量的变更控制一）版本启动开发后，新需求插入或需求变更时，引起的需求范围和 工作量的变更，根据需求对应的新增工作量进行分级把控、审批（由需 求负责人发起审批流程）：5 人天及以下需求由需求分析负责人负责签字；6 人天至 20 人天需开发单元负责人签字；20 天以上需分管领导签字二）需求范围变更、开发进度延迟等原因导致的版本上线进度变更， 根据版本上线推迟工作日分级把控、审批（由开发厂商项目经理发起审 批流程）：5 个工作日及以下由需求分析负责人负责签字；10 个工作日及以下由开发单元负责人负责签字；10 个工作日以上由分管领导负责签字三）为控制需求稳定性，版本开发或测试过程中变更的需求需重新排 期，如业务需求方案存在漏洞则对相应的开发功能进行暂停处理，需求 变更超过2 次直接列入反向问责。

第十八条 开发跟踪项目管理负责人与合作厂商需求负责人沟通确认软件项目“预计启动时间”及“预计上线时间”，合作厂商需求负责人将上线时间明确写入每周跟踪表，每周五对各需求的上线时间进行跟踪评审对于不能按时完成的需求，合作厂商必须在原定上线时间前，及时向项目管理负责人沟通 解释，并向提交书面解释报告第十九条 业务测试需求开发完成后，项目管理负责人协调需求负责人进行业务验收测试，并根据测试发现的问题，对具体问题进行优化调整，直至需求负责人最 终验证需求达到技术方案中的要求版本应经过完整的测试（含白盒、黑盒、覆盖、性能等测试），上线前需 提供一份完整的测试报告，并列明上线功能，以便后续跟踪第二十条 质量控制包括软件质量控制、过程质量控制以及用户体验控制：（一）软件质量控制：需求负责人在完成业务测试后，对于上线后会影响用户感知的需求，须协调质检小组负责人组织质量控制，以确保需求 上线后的用户感知二）过程质量控制：严格把控业务支撑相关各个支撑环节，各环节应提供对应的过程质量控制文档，包括需求规范文档，设计文档，测试用 例，测试报告三）用户体验控制：拨测小组、体验小组分别通过定期拨测、定期提 供体验优化建议，以及时解决产品问题、优化产品质量，有效提升产品 用户体验。

第二十一条 版本上线版本分为三级进行管理，跟踪版本上线内容，避免版本混乱，同时版本 上线分级审批：（一）一级版本（大版本）需分管领导审批（二）二级版本（补丁）由室经理审批（三）三级版本（小补丁）由项目经理审批 二级以上版本上线前，由产品室牵头组织产品上线评审会，对相关接口、 部件、模块、外围产品可能造成的影响需以预警的形式明确通知到各个 责任人版本割接时间需进行排期规划，串行处理，同时负责不同系统软硬件项 目的项目经理应加强沟通，避免不同厂商软硬件系统割接上线冲突导致 的问题由维护管理负责人组织版本割接上线：（一） 上线推迟管理 对于所有需求，原则上开发单元须严格管理把控业务上线的及时性，若 因为临时性原因导致的上线推迟情况，开发单元须提前通知相关需求负 责人、并抄送需求单元负责人二） 上线通知管理 对于上线即生效的业务，开发单元需在上线前1 天通知需求单元具体的 上线内容（通知到各个单元的接口人），各单元接口人通知各需求负责人， 需求负责人提前做好信息流转报备工作；对于上线确认型的业务，测试 人员将测试结果反馈项目管理负责人和需求负责人，由需求负责人确认 测试通过后，做好信息流转报备工作。

三） 上线失败管理 对于上线即生效的业务，若上线失败，开发单元须在第一时间通知需求 负责人，同时开发单元和需求单元须尽快定位原因并明确重新上线的计 划第二十二条 项目验收需求分析负责人组织项目小组分版本进行项目验收，最终核定开发工作 量，并对事前和事后工作量进行对照和反向评价项目小组成员包括项 目管理负责人、需求负责人、需求单元负责人、需求分析负责人工作量在30 人天以上（含30 人天）的项目，上线试运行满1个月后进 行验收；工作量在30 人天以下的项目，割接上线后，可根据需求单元的使用意见，适时进行验收第二十三条 反向评价为节约开发资源并有效控制版本风险，开发单元按月对需求单元进行需求的反向评价，主要从需求变更、开发中需求取消、开发后不上线、上 线后不使用、上线后无价值等维度对需求进行反向评价一）、门户相关需求，通过访问情况以及使用情况进行跟踪及评价；（二）、后台功能相关需求通过操作使用情况及系统间调用情况跟踪评 价第二十四条问责机制版本启动后，业务方案变更，需重新排期，因此造成的需求进度延期、功能范围增加、工作量增加等支撑风险由需求负责人负责，需求变更超 过2 次直接列入反向问责；因技术方案问题导致实现方式变化、投入产出比增大、上线后系统问题， 由需求分析负责人、项目管理负责人负责；需求开发跟不上计划进度导致业务支撑延误，由需求分析负责人、项目 管理负责人负责； 需求割接失败及相关问题由维护管理负责人负责；业务验证通过，而系统上线后出现系统问题，如果是测试与生产环节差异，由测试经理负责，否则由业务负责人负责； 系统割接导致相关部件出现问题，由版本经理负责。

第二十五条详细日常业务支撑管理流程可参见附件五日常业务支撑管理流程图，其中每个流程环节的工单应在 3 个工作日内处理第六章 考核管理第二十六条按月对合作厂商实施考核管理，开发单元牵头组织各科室对合作厂商的服务情况进行考核评分考核评分采用百分制 , 考核指标包。