日常业务支撑管理办法v3.4

日常业务支撑管理办法

第一章总则

第一条为规范公司（以下简称）日常业务支撑管理工作，适应项目开发和管理的需要，提高业务支撑管理水平，有效提升日常业务支撑工作的效率和

质量，特制定本办法。

第二条本办法适用于公司及下属各科室。

第二章各单元职责

第三条本办法中所称的开发单元，是指内负责具体IT系统开发的系统支撑室和产品管理室。所称的需求单元，是指内提出业务支撑开发需求的各科室。第四条开发单元职责：

（一）负责组织人员做好与合作厂商沟通协调工作。

（二）负责审核、审批需求分析报告。

（三）负责审核业务需求的技术可行性审核。

（四）负责组织人员做好软件需求、软件版本、系统上线跟踪协调工作。

（五）负责组织人员做好软件开发项目文档归档管理工作。

（六）负责组织人员对软件项目进行验收工作。

（七）负责对软件需求的结算工作量进行审核。

第五条需求单元职责：

（一）负责业务方案的策划。

（二）负责编写、审核、审批业务需求。

（三）负责审批业务测试及质量验证。

第三章需求分类与优先级级别

第六条业务支撑需求目前包括以下六类：

（一）业务需求：新增业务需求，需要新增系统功能。

（二）优化改进：优化现有系统功能、流程，改善现有系统功能。

（三）需求变更：对现有功能进行设计修改。

（四）配置修改：修改现网系统的配置参数，例如接入号、业务局数据。

（五）数据修改：现有业务数据展示修改，如内容、产品、订购关系、

用户相关数据修改。

（六）数据统计: 对现有业务从平台进行数据统计、提取。

第七条业务支撑需求的优先级别目前从高到低依次分为紧急、重要、日常三类。

具体的开发排期可按照优先级从高到低进行。影响用户感知急需进行修

改的需求，应立即修改，不能立即修改的应立即隐藏，并在1小时内完

成修改或隐藏。隐藏到后台的文字类的修改应在一天之内完成，涉及程

序修改的应按紧急补丁需求优先安排完成。

第四章版本控制

第八条日常业务支撑的开发版本控制按“红绿两区、高效并行、三天配置”的原则进行，版本管理可依据需求的性质进行分类管理：

红区：鉴权、计费、结算、能力部件等基础和关键功能需求纳入红区版

本进行开发，以确保系统质量、稳定性、可靠性。

绿区：前端门户、创新业务、独立交互模块等功能需求纳入绿区版本进

行开发，以快速迭代，提升支撑效率。

红区版本周期为5周，绿区版本周期为3周。

第五章流程管理

第九条需求申请

需求单元人员填写附件一日常业务支撑需求申请表，或通过电子工单流

系统提交支撑申请，提交至需求单元负责人审批。紧急需求需进一步提

交分管领导审批；

对于特别紧急需求，开发单元可先安排支撑，需求单元必须在上线前提

交工单。

对原有内容的微调可由需求负责人签字，直接提交至开发单元的需求分

析负责人，并由开发单元安排人员修改。

第十条需求澄清

为确保需求明确，需求单元人员提交需求前，必须先与开发单元的项目

管理负责人、厂商需求负责人进行需求澄清，明确需求并确认技术可行

性。

第十一条需求审批

需求单元负责人审阅软件需求申请表，审批通过后工单流转至开发单元。第十二条开发审批

开发单元负责人审阅软件需求申请表，并分派给具体负责的需求分析负

责人。

第十三条需求分析

需求分析负责人分析需求的技术可行性及其对系统架构的影响。如需求

对系统可能造成较大影响，由需求分析负责人协调并组织项目管理负责

人、业务负责人进行整体考虑和统筹设计，并就业务支撑方案达成一致。

涉及产品或系统演进规划、系统间联调、多部件协调开发的复杂需求由

跨部门技术专家组（由产品和系统规划、开发、网络及信息安全等相关

技术人员组成）组织需求分析和评审；

第十四条方案评估

项目管理负责人安排人员根据需求组织编写技术方案（UCD设计低保真、

需求功能规格说明书等）。方案设计完成后，组织需求单元人员进行方案

的评估和确认，并形成方案终稿冻结。

第十五条工作量评估

工作量评估应通过功能点分析法、开发阶段分析法等方法进行，以确保

开发工作量评估的客观、公正。

项目管理负责人组织工作量评估小组（项目管理负责人、需求负责人、

需求单元负责人、需求分析负责人、开发单元负责人、纪检负责人等）

进行开发工作量评估，具体操作如下：

（一）20人天以下的需求：由工作量评估小组评估并签字确认。

（二）21至70人天的需求：由工作量评估小组评估，并提请内部决策

会决策后，由需求单元分管领导签字确认。

（三）70人天以上的需求：由工作量评估小组评估，并提请厦门小组决

策会决策后，由省公司OA上发布决策会的会议纪要确认。

第十六条版本排期

各业务单元根据需求的优先级进行内部排序，并向开发单元提交待支撑

的需求内容。开发单元将待支撑的需求统一排序，未纳入开发版本或有

争议的部分需求请示领导决策。

（一）需求优先级按照需求来源（优先级顺序从高到低为：上级或兄弟单位督办需求、领导督办需求、一般需求）、需求紧急程度(从高到

低为：紧急、重要、一般)、需求前后端类型（影响用户感知的前

段需求优先支撑，后台管理相关需求开发之前可通过人工支撑）、

需求实现价值（需求的价值越高优先级越高）、需求滞留时间（滞

留时间越长优先越高）等五个维度进行综合考量。

（二）各需求单元按照五个维度对内部需求补充相关权值，由开发单元对需求统筹进行优先级排序。

（三）节假日类日常营销需求尤其是重要需求应日历化、模板化，避免经常出现紧急又重要的需求，打乱开发节奏。如确实需开发支撑，

应在开发版本启动前完成业务方案，否则必须提前明确预知开发单

元预留足够的开发工作量。

第十七条变更控制

包含版本上线进度、需求范围以及工作量的变更控制。

（一）版本启动开发后，新需求插入或需求变更时，引起的需求范围和

工作量的变更，根据需求对应的新增工作量进行分级把控、审批（由需

求负责人发起审批流程）：

5人天及以下需求由需求分析负责人负责签字；

6人天至20人天需开发单元负责人签字；

20天以上需分管领导签字。

（二）需求范围变更、开发进度延迟等原因导致的版本上线进度变更，

根据版本上线推迟工作日分级把控、审批（由开发厂商项目经理发起审

批流程）：

5个工作日及以下由需求分析负责人负责签字；

10个工作日及以下由开发单元负责人负责签字；

10个工作日以上由分管领导负责签字。

（三）为控制需求稳定性，版本开发或测试过程中变更的需求需重新排