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

日常业务支撑管理办法

第一章总则

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

质量，特制定本办法。

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

第二章各单元职责

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

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

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

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

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

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

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

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

第五条需求单元职责：

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

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

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

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

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

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

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

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

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

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

用户相关数据修改。

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

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

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

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

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

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

第四章版本控制

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

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

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

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

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

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

第五章流程管理

第九条需求申请

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

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

交分管领导审批；

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

交工单。

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

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

第十条需求澄清

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

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

性。

第十一条需求审批

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

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

责人。

第十三条需求分析

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

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

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

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

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

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

第十四条方案评估

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

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

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

第十五条工作量评估

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

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

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

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

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

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

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

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

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

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

第十六条版本排期

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

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

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

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

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

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

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

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

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

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

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

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

第十七条变更控制

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

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

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

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

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

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

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

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

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

批流程）：

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

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

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

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

期，如业务需求方案存在漏洞则对相应的开发功能进行暂停处理，需求

变更超过2次直接列入反向问责。

第十八条开发跟踪

项目管理负责人与合作厂商需求负责人沟通确认软件项目“预计启动时

间”及“预计上线时间”，合作厂商需求负责人将上线时间明确写入每周

跟踪表，每周五对各需求的上线时间进行跟踪评审。对于不能按时完成

的需求，合作厂商必须在原定上线时间前，及时向项目管理负责人沟通

解释，并向提交书面解释报告。

第十九条业务测试

需求开发完成后，项目管理负责人协调需求负责人进行业务验收测试，

并根据测试发现的问题，对具体问题进行优化调整，直至需求负责人最

终验证需求达到技术方案中的要求。

版本应经过完整的测试（含白盒、黑盒、覆盖、性能等测试），上线前需

提供一份完整的测试报告，并列明上线功能，以便后续跟踪。

第二十条质量控制

包括软件质量控制、过程质量控制以及用户体验控制：

（一）软件质量控制：需求负责人在完成业务测试后，对于上线后会影

响用户感知的需求，须协调质检小组负责人组织质量控制，以确保需求

上线后的用户感知。

（二）过程质量控制：严格把控业务支撑相关各个支撑环节，各环节应

提供对应的过程质量控制文档，包括需求规范文档，设计文档，测试用

例，测试报告。

（三）用户体验控制：拨测小组、体验小组分别通过定期拨测、定期提

供体验优化建议，以及时解决产品问题、优化产品质量，有效提升产品

用户体验。

第二十一条版本上线

版本分为三级进行管理，跟踪版本上线内容，避免版本混乱，同时版本

上线分级审批：

（一）一级版本（大版本）需分管领导审批

（二）二级版本（补丁）由室经理审批

（三）三级版本（小补丁）由项目经理审批

二级以上版本上线前，由产品室牵头组织产品上线评审会，对相关接口、

部件、模块、外围产品可能造成的影响需以预警的形式明确通知到各个

责任人。

版本割接时间需进行排期规划，串行处理，同时负责不同系统软硬件项

目的项目经理应加强沟通，避免不同厂商软硬件系统割接上线冲突导致

的问题。

由维护管理负责人组织版本割接上线：

（一）上线推迟管理

对于所有需求，原则上开发单元须严格管理把控业务上线的及时性，若

因为临时性原因导致的上线推迟情况，开发单元须提前通知相关需求负

责人、并抄送需求单元负责人。

（二）上线通知管理

对于上线即生效的业务，开发单元需在上线前1天通知需求单元具体的

上线内容（通知到各个单元的接口人），各单元接口人通知各需求负责人，

需求负责人提前做好信息流转报备工作；对于上线确认型的业务，测试

人员将测试结果反馈项目管理负责人和需求负责人，由需求负责人确认

测试通过后，做好信息流转报备工作。

（三）上线失败管理

对于上线即生效的业务，若上线失败，开发单元须在第一时间通知需求

负责人，同时开发单元和需求单元须尽快定位原因并明确重新上线的计

划。

第二十二条项目验收

需求分析负责人组织项目小组分版本进行项目验收，最终核定开发工作

量，并对事前和事后工作量进行对照和反向评价。项目小组成员包括项

目管理负责人、需求负责人、需求单元负责人、需求分析负责人。

工作量在30人天以上（含30人天）的项目，上线试运行满1个月后进

行验收；工作量在30人天以下的项目，割接上线后，可根据需求单元的

使用意见，适时进行验收。

第二十三条反向评价

为节约开发资源并有效控制版本风险，开发单元按月对需求单元进行需

求的反向评价，主要从需求变更、开发中需求取消、开发后不上线、上

线后不使用、上线后无价值等维度对需求进行反向评价。

（一）、门户相关需求，通过访问情况以及使用情况进行跟踪及评价；

（二）、后台功能相关需求通过操作使用情况及系统间调用情况跟踪评价。

第二十四条问责机制

版本启动后，业务方案变更，需重新排期，因此造成的需求进度延期、

功能范围增加、工作量增加等支撑风险由需求负责人负责，需求变更超

过2次直接列入反向问责；

因技术方案问题导致实现方式变化、投入产出比增大、上线后系统问题，

由需求分析负责人、项目管理负责人负责；

需求开发跟不上计划进度导致业务支撑延误，由需求分析负责人、项目

管理负责人负责；

需求割接失败及相关问题由维护管理负责人负责；

业务验证通过，而系统上线后出现系统问题，如果是测试与生产环节差

异，由测试经理负责，否则由业务负责人负责；

系统割接导致相关部件出现问题，由版本经理负责。

第二十五条详细日常业务支撑管理流程可参见附件五日常业务支撑管理流程图，其中每个流程环节的工单应在3个工作日内处理。

第六章考核管理

第二十六条按月对合作厂商实施考核管理，开发单元牵头组织各科室对合作厂商的服务情况进行考核评分。考核评分采用百分制, 考核指标包括业务

开发质量、进度、竞品对标以及综合奖惩等，各项考核评分应按照细则

分类和评分尺度，由各科室审核后，最终由开发单元汇总上报。其中各

单元须根据测试结果对合作厂商开发质量进行考核，对于需求单元发现

与业务需求不一致、但内部测试未发现的问题，由开发单元负责对合作

厂商进行考核，对于严重与业务需求相不符的功能业务单元有权提出考

核意见。详细考核细则参见附件四日常业务支撑考核实施表。

第二十七条考核过程中关键时间点如下：

（一）每月9日前（遇节假日顺延）需完成对合作厂商上个月的考核。

（二）每月10日前（遇节假日顺延）开发单元完成考核成绩的汇总。

（三）每月13日前（遇节假日顺延）开发单元协调厂商完成考核结果确认。

（四）每月15日前（遇节假日顺延）由领导签发考核结果。

（五）每月25日前合作厂商需向提交下月的工作计划，根据产品规划及业务现状进行评估，经双方确认后，30日前确定下月的工作计

划。

第二十八条合作厂商的各项工作目标、工作进度、考核结果等均通过上墙制度进行显性化管理。建立各项工作的通报制度，以督促合作厂商及时推进

各项工作。工作进度落后进度要求一周由开发单元负责人约谈合作厂商

负责人；进度落后二周由领导约谈合作厂商公司领导；落后进度三周将

发公函至合作厂商公司，并存档作为不良记录，该不良记录可作为今后

其他项目合作的评估依据。

第二十九条合作厂商对考核结果拥有申诉权。合作厂商在接到考核结果后若有异议需在考核申诉期限内向开发单元提出申诉申请，超过申诉期限视为

合作厂商同意考核结果。合作厂商考核申诉流程如下：

（一）合作厂商申诉时间为公布当月考核结果后3个工作日内。收到申诉后将组织复议，并将复议分数经合作厂商确认后作为最终考核

结果。

（二）数据核实后属于原因造成差异的，由对考核结果进行修订。

第七章结算管理

第三十条合作厂商必须满足如下条件才可进行结算：

（一）与公司签署了合作协议。

（二）不处于停止结算的违约期。

（三）不处于退出冻结期。

第三十一条合作厂商依据与公司签署的合作协议、每月考核评分表、开发单元提供的结算单进行结算。

第三十二条每月10日前结算上月的工作量，每季度的第1个月20日前完成上季度的服务费折算并申请付款。

第三十三条结算费用来自合作厂商每个季度日常业务支撑费用。结算金额计算方式为：每月开发结算总额A（结算工作量*人天单价），每月考核系数

为M（0.75至1.05，与当月考核成绩相对应），则当月实际结算金额=A*M。第三十四条有权对不符合逻辑或业务使用行为不合理等造成的不实数字进行稽核，被稽核的数据不参与合作厂商的支撑费用结算。的业务稽核规则可

根据业务情况适时进行调整。

第三十五条按照公司的计费、结算、稽核规则，每月13日发布上月的支撑费用结算单（含考核分值、结算金额）。若合作厂商对结算单有异议，可提起

核对申请，由统一组织和实施核对工作，并对核对进行全程监控和管理。第三十六条只受理当月发布的结算单的核对申请，合作厂商于每月15日前对发布的结算单进行确认，若未在规定时限内提出核对申请，则默认合作厂

商认可结算数据，不再受理该结算月份的核对申请。

第三十七条核对与结算付款相对独立。无论合作厂商是否申请核对，或者核对是否完成，结算付款工作均按规定的流程执行。核对不影响当季度的正

常结算，若产生差异，将以调账的方式解决。当季度产生的差异数据，

在后期结算数据中调账。

第三十八条合作厂商根据发布的结算单开具发票，并将发票送交。收取发票的截止时间为每个结算月17 日；对于17日后收到的发票将在下一结算月

份进行付款。

第三十九条根据结算单对合作厂商开具的发票进行核对，并依据结算单、开具的发票进行付款审批申请，经过审核后，在每个结算月20日前出具结算

付款审批单并提交公司财务部。由公司财务部根据结算单、结算付款审

批单（含发票）完成付款工作。

第八章附则

第四十条本管理办法由公司负责解释。

第四十一条本管理办法自颁布之日起执行。

附件

附件一：日常业务支撑需求申请表

日常业务支撑需求

申请表

附件二：软件开发功能点分析法FPA工作量评估模板

FPA工作量评估模板

附件三：软件开发阶段分析法工作量评估模板

分析法工作量评估

模板

附件四：日常业务支撑考核表

日常业务开发考核

实施细则

附件五：日常业务支撑管理流程图

附件五：手机动漫基地日常业务支撑管理流程图.jpg

1、需求提交子流程.jpg

2、需求变更子流程.jpg

3、进度变更子流程.jpg

4、验证上线子流程.jpg