业务需求管理规范v1009.docx
- 文档编号:16827616
- 上传时间:2023-07-17
- 格式:DOCX
- 页数:13
- 大小:78.83KB
业务需求管理规范v1009.docx
《业务需求管理规范v1009.docx》由会员分享,可在线阅读,更多相关《业务需求管理规范v1009.docx(13页珍藏版)》请在冰点文库上搜索。
业务需求管理规范v1009
公司业务需求管理规范v1
版本说明:
v1.0
1.总则
1.1.概述
为了加强公司业务需求全流程管理,提升项目管理水平,规范业务新增、变更、下线流程,特修订本管理办法。
本办法由省公司市场经营部牵头负责管理,当流程发生重大变更时应根据需要及时进行修订并通知相关人员。
本管理办法规定的公司业务需求管理规范,从2012年09月1日起试行。
本管理办法中所定义的单位或部门说明如下:
1、技术部门:
业务支撑系统部、网管中心。
2、业务部门:
市场经营部、数据部、中心、集团客户部、省级集团客户服务中心、客户服务部、省客户服务中心、终端运营中心。
3、地市公司为公司九地市分公司。
1.2.适用范围
本管理办法适用于公司业务支撑系统(包括BOSS系统、经分系统、客服系统、网上营业厅系统等电子渠道支撑系统、业务支撑系统部维护开发管理的增值系统),以及部分涉及业务功能承载的网管系统。
1.3.主要内容
本办法主要包括需求规范、开发规范、测试/上线规范、推广应用规范四个部分,各部分内容如下:
1.需求规范。
主要对需求定义、需求部门、需求角色、需求分类、需求管控原则、需求模板等内容进行规范。
2.开发规范。
主要对接口管理机制、支撑响应机制、过程沟通机制、RDMP管理机制四个方面进行规范。
3.测试/上线规范。
主要对测试管理、上线管理和信息采编进行规范。
4.推广应用规范。
主要对应用评估分析、问题反馈机制进行规范。
2.需求规范
2.1.需求定义
需求主要是指省公司业务部门、业务支撑系统部内部以及地市公司所提出的涉及业务新增、变更和优化(系统BUG)的开发需求,业务部门提交的所有需求须严格按照所制定的业务需求模板提交。
2.2.需求特征定义
将需求特征可以细分为三个类型:
新增、变更/优化、系统BUG。
1、新增:
新开发业务或功能,如省内携号业务的开发。
2、变更/优化:
对原有业务规定、系统功能等进行调整、优化等;
3、系统BUG:
开发遗漏或错误导致的业务功能优化需求。
2.3.需求等级定义
按照需求的重要程度分为重要和普通。
业支部根据需求的重要程度和需求到达时间先后顺序安排开发,重要需求开发优先级高于普通需求,个别插队需求(各个业务部门提出要求)优先级高于重要需求。
暂定每月每个部门开发优先级调整次数不超过本部门需求总量的10%。
2.4.需求部门
市场经营部、数据部、中心、集团客户部、省级集团客户服务中心、客户服务部、省客户服务中心、终端运营中心。
2.5.人员角色
1.需求接口人。
每个业务部门的需求发起均归口管理,每类需求指定1人为需求接口人,负责统一把关并递交需求,以及对口与开发部门之间的总体沟通(但不负责具体开发需求的沟通),具体人员如下:
各部门各类需求接口人
序号
需求大类
需求小类
市场经营部
集团客户部
数据部
客户服务部
省客服中心
中心
终端运营中心
业支部
1
业务类
基础语音
陈家忠
原鸿
陈银铃
郑秋平
张磊135********
-
-
-
2
集团信息化产品
-
-
-
3
数信业务
-
-
-
4
服务
-
-
-
5
营销类
营销类
陈超
原鸿
吴敏
郑秋平
-
章静
-
6
渠道类
渠道管理
-
-
-
-
-
-
-
7
渠道运营
-
-
-
-
-
-
-
8
经分类
经营管理
陈琰
许星
许炜
郑秋平
-
葛丽萍
-
9
系统类
系统类
-
-
-
-
-
-
马建
2.需求项目经理。
每个具体业务的负责人,负责提出具体的需求并与开发人员沟通。
3.支撑接口人。
开发部门每份需求须明确支撑总接口人,负责对口管理与业务部门之间的总体沟通(但不负责具体开发需求的沟通)。
4.支撑项目经理。
每个具体业务的支撑负责人,负责具体的需求功能点的开发支撑管理。
2.6.需求提交形式及频次
1、形式:
对于新增类的需求和大的变更都需要以业务支撑联系单的形式递交开发部门,其它小的不涉及业务规则的变更需求和系统BUG可直接通过RDMP和BOMC单提交。
2、频次:
原则上每类业务每周提交需求不超过1次,需求由需求总接口人每周汇总后提交。
2.7.需求分类
分为五大类业务需求,具体包括:
基础业务类(基础语音类、集团信息化产品类、数信业务类、服务类)、营销类、渠道类(渠道管理类、电子渠道运营类)、经分类(经营管理、服务管理、增值业务营销类、渠道终端、品牌营销、集团客户管理类)、系统类,具体定义如下:
1.1、基础业务类-基础语音类:
主要指大众市场业务类需求,包括套餐、账祥单、发票、服务密码等等基础业务,以及面向大众市场推广的业务如积分等等。
1.2、基础业务类-集团信息化产品类:
主要指集团市场业务类需求,包括集团基础业务、集团信息化业务等。
1.3、基础业务类-数信业务类:
主要指数据业务产品类需求。
1.4、基础业务类-服务类:
主要指客户服务类需求,如担保开机等等。
2.1、营销类:
指各业务部门根据市场营销需求提出的营销支撑需求,其中营销管理平台及营销方案由市场部统一管理运营,各业务部门负责应用。
3.1、渠道类-渠道管理类:
指BOP系统和电子渠道中对于渠道系统架构调整、渠道管理规范调整、新增渠道建设开发、新增渠道涉及的功能开发等;
3.2、渠道类-电子渠道运营类:
指对于涉及到电子渠道界面及流程的优化、电子渠道框架自身的优化,电子渠道内不涉及到业务规范的交互流程和界面优化。
4.1、经分类-经营管理:
涉及公司运营、劳动竞赛、经营考核、细分市场等运营管理类指标、即席查询、报表需求;
4.2、经分类-服务管理:
涉及客户接触、客户满意度、客户信用评分等服务类指标、即席查询、报表需求;
4.3、经分类-增值业务营销类:
涉及增值业务产品及VGOP平台的经分类需求;
4.4、经分类-渠道终端:
涉及各渠道、终端运营的经分类需求;
4.5、经分类-品牌营销:
涉及三大品牌客户规模、消费等经分指标、报表类需求;
4.6、经分类-集团客户管理类:
涉及集团客户、集团产品类的经分类需求;
5.1、系统类:
指非业务类的系统功能类需求,如新开发系统、系统升级等。
2.8.需求统筹管理原则
根据2.7中业务需求的分类原则,各类需求均须由专门部门专人归口管理,并根据固定的模版填写需求内容并发文。
各类需求管控原则如下:
1、基础业务类(基础语音类、集团信息化产品类、数信业务类、服务类)按照以下原则进行管理:
:
(1)各业务负责部门根据业务属性归口管理所负责业务的需求发起,对于涉及多个业务交叉的情况下,业务牵头部门需做好与其它部门的沟通协调,业务规则需经相关部门会签。
举例:
多号通业务的牵头部门是数据部,则数据部须负责多号通业务的总体业务规则,同时需要和市场部沟通号源管理、账目项管理、资费设计等问题,需求也须经市场部会签。
(2)市场部负责基础语音业务,集客部负责集团信息化产品,数据部负责其他数信业务产品(需求由中心负责管理),客服部负责服务类产品。
(3)对于涉及资费、营销案规则类需求,须由市场部统一管理并提交需求。
(4)对于涉及到电子渠道(网营、短营、24H营业厅、掌营、人工台及IVR)承载的新增/修改的需求,均需做好和电子渠道负责部门(省客服中心)的沟通并按照电子渠道需求模版填写需求内容,需求文件必须经其会签(系统已经实现电子渠道类的需求,各个开发环节均有短信通知客服中心人员),以确保各渠道的信息一致性。
2.营销类:
(1)各业务负责部门各自负责各部门的营销类支撑需求,独立发送;若涉及到批量开通/修改业务、新增/调整业务提醒信息、客户交互信息等,均需由客户服务部和省客服中心审核会签,以确保服务规范性。
(2)对于涉及营销管理平台的支撑需求,包括营销服务管控流程变更、接触渠道变更等,须由市场部、客服部、客服中心共同把关后,由市场部统一提交需求。
(3)对于大市场统筹的大型营销主题活动支撑需求,如两节促销、IPhone4S应对等需求,须由市场部审核后各业务负责部门提交需求。
3.渠道类:
渠道管理类和电子渠道运营类
总体原则:
市场部负责渠道管理类需求,省客服中心负责电子渠道运营类需求。
4.经分类:
、
(1)经分类主要包括经营管理、服务管理、增值业务营销类、渠道终端、品牌营销、集团客户管理类等六大类的需求,各业务负责部门根据自身经营分析需求负责业务需求的发起。
(2)对于涉及经分系统菜单路径修改、角色及权限管理办法调整需求,以及大型经营考核需求,如劳动竞赛、年度KPI考核等需求,须由市场部统一管理、提交需求。
(3)对于涉及客户特征标签库变更、客户信息前台界面展现、客户清单下载类等涉及客户视图和客户信息安全类应用,需由市场部审核后,由业务负责部门提交需求。
5.系统BUG类
系统BUG类需求由业支部自行管理。
注:
不在上述管控范围内的,各部门根据业务类型自行管理,以上管控原则将不定期补充、修订。
2.9.需求统一模板定义
为规范化各类需求发起,提升开发效率,各类业务需求都需制定统一的模板,后续需求提交时均需按照统一模板编写。
目前制定的需求统一模版包括主要包括以下几类:
《新业务需求模板V2.0》、《业务需求变更模板v2.0》、渠道类-电子渠道运营类(《短信营业厅业务新增需求模板v1》、《网站、终端及掌厅业务新增需求模版v1》、《IVR语音流程规范-流程图_开关类业务模版v1》)、经分类模版《经分需求模板v1》,具体见《附件二:
业务需求模版》。
2.10.需求版本管理
1、业务部门须做好所负责业务的管理办法的实时更新,每月更新到语音规范中,做好业务版本的管理;
2、业务需求提出时,均需明确原业务规则和新业务规则的不同点。
3、支撑部门须做好系统版本的管理控制。
3.开发规范
3.1.接口管理机制
1、每一份需求(业务联系单/RDMP/BOMC),均由业务接口人统一发送,每一个需求功能点须明确重要程度和业务项目经理以便开发人员与其确认(对于同一业务的不同功能点,原则上需归口一个业务项目经理管理,避免开发人员多头沟通);每一份需求(业务联系单/RDMP/BOMC),由支撑接口人统一分配给各个的支撑项目经理。
2、对于同一业务在不同渠道的开发情况,原则上需归口同一个支撑项目经理管理,避免业务人员多头沟通。
3.2.支撑响应机制
1、对于重要的业务需求,要求开发部门在收到需求文后的2个工作日内响应并在4个工作日安排开发计划;
2、对于普通的业务需求,要求开发部门在收到需求文后的4个工作内响应并在8个工作日安排开发计划;
3、对于特别紧急的需求,可以通过邮件方式先行沟通,但必须抄送部门领导知悉。
4、对于包含内容过多的开发需求,原则上允许适当延长明确开发计划,但须支撑项目经理事先和业务项目经理沟通。
3.3.过程沟通机制
1、需求确认机制
为了提升开发人员对需求理解的准确性,必须做好两个关键环节的沟通:
(1)开发人员编写“业务需求说明书”后,需和业务项目经理确认后定稿;
(2)开发人员编写“产品需求说明书”后,若产需实现功能点和业务需求说明书存在差异的地方,须将修改内容和业务项目经理确认后定稿。
开发人员和业务人员通过电话/邮件等方式沟通,产品需求说明书作为后续考核开发准确性的依据。
2、沟通频次和沟通形式。
(1)业务部门和开发部门通过电话/邮件的形式实时进行开发过程存在问题的沟通;
(2)每周五上午由开发部门按照《附件三:
开发需求反馈模板》反馈开发进度,并发送到业务接口人,由业务接口人通知到具体的业务项目经理(注:
RDMP系统完善且系统速度提升后,通过RDMP展现各功能点开发进度);
(3)如有无法沟通和协调的事宜,每月最后一周星期五上午,由业务部门或开发部门牵召集业务需求沟通会,对涉及的问题进行现场沟通解决(沟通要点周四上午明确并随会议通知发出,各相关部门提前评估待讨论内容以便提升会议效率)。
3.4.RDMP管理机制
1、支撑部门在RDMP平台上录入开发需求时,对于分批上线的功能(上线时间不同)、不同渠道(分成各个不同渠道支撑需求)须分解成不同的软件需求,便于业务部门跟踪。
2、对于已经接受到需求函但是来不及安排开发的,须录入RDMP平台,需求状态为“需求已接受但未安排”的状态,表示业支部门已经收到需求,但是还未安排给具体的支撑人员。
3、RDMP增加优化需求提交功能,供省客服中心和九地市公司提出的业务优化需求建议,提交专业部门(市场、数据、集客、服务),省公司专业部门负责审核并可以在RDMP上直接提交生成一张RDMP优化需求工单。
注:
此类需求以零星优化为主,对于改动较大、或则省公司已统筹安排的,将通过正式的需求文件发送,不通过这种便捷方式提交
4.测试/上线规范
4.1.测试管理
1、测试要求
(1)所有需求在上线之前,需经过集成商测试、业支部测试、地市或省公司业务部门测试,避免因测试不到位出现问题;
(2)所有需求上线前(除了上线即生效的业务,如账单等业务)均需经过业务项目经理确认后才能上线,测试阶段业务不推送到生产环境(目前所有业务均是上线并发布到生产环环境,存在较大风险),且只有测试号码能够使用新功能,测试通过后由需求发起人进行确认后上线发布。
2、测试标准
(1)对于上线即开通的业务,须有开发人员项目经理确认后方可上线,且需安排地市及时的进行测试,并请省公司需求提出人进行测试结果确认。
(2)对于非上线即开通的业务,都需要经过业务经理确认才可上线;
(3)对于部分未涉及到业务调整和与客户感知无关的优化需求可由业支部负责业务测试。
(4)在电子渠道上线的产品及服务电子渠道业务上线前增加预发布测试环节,由客服中心组建测试团队配合业务需求部门进行电子渠道平台的业务测试,在客户化体验测试通过后方可上线。
3、测试考核
(1)业支部须根据测试结果对开发商开发质量进行考核
(2)对于业务部门发现与业务需求不一致、但内部测试未发现的问题,由支撑部门负责对集成商进行考核,对于严重与业务需求相不符的功能业务部门有权提出考核意见。
4、测试通知
所有项目的测试公告均须发送到测试人员和需求项目经理、需求接口人,以便需求项目经理跟踪测试情况。
4.2.上线管理
1、业务上线推迟管理
对于所有需求,原则上开发部门须严格管理把控业务上线的及时性,若因为临时性原因导致的上线推迟情况,支撑部门须提前1天通知业务项目经理、并抄送业务项目经理主管;若项目推迟超过1个月的,支撑部门须通过正式文件回函通知业务部门。
2、业务上线通知管理
对于上线即生效的业务,开发部门需在上线前1天通知业务部门具体的上线内容(通知到各个部门的需求接口人),各个部门的需求接口人通知各业务项目经理,业务项目经理提前做好信息流转报备工作;对于上线确认型的业务,测试人员将测试结果反馈开发项目经理和业务项目经理,由业务项目经理确认测试通过后,做好信息流转报备工作。
3、业务上线失败管理
对于上线即生效的业务,若上线失败,业支部须在第一时间通知业务部门需求负责人,由业务部门需求负责人通知客服中心下线相关知识库采编内容;对于上线确认型的业务,上线内容由需求负责人测试确认通过后上线。
同时,业务部门和开发部门须尽快定位原因并明确重新上线的计划。
4.3.信息采编
1、对于上线即生效的业务,业支部门需在上线前1天通知业务部门具体的上线内容,业务部门须在第一时间通过信息流转告知省客服中心,并同步通知地市信息采编人员;若上线失败,业支部须第一时间通知业务部门需求负责人,由业务部门需求负责人通知客服中心下线相关知识库采编内容;对于上线确认型的业务,上线内容由需求负责人测试确认通过后,发送到信息流转邮箱通知省客服中心采编。
2、省公司与地市公司各业务部门需求总牵头人须按周、按月将上线知识点汇编发布,并更新业务规范,其中,按周以邮件方式通知全省业管人员,按月以BOP公告方式通知全省业管人员。
5.推广应用规范
5.1.应用评估分析
所有新增业务,业务部门定期跟踪评估应用情况,避免开发资源浪费等情况的出现。
5.2.问题反馈机制
暂无
6.业务需求管理总体流程图
以下流程图为业务新增/变更需求的流程图,系统优化需求不包含在内,具体流程环节补充说明如下:
1、需求提出阶段
(1)地市公司项目经理:
地市公司根据省公司制定的需求反馈模版,每周上报新增/变更需求,其中业务类需求统一汇总到地市业管处,营销类需求分别由地市项目经理汇总到省公司接口的项目经理处。
(2)省公司项目经理:
省公司项目经理负责汇总本专业新增/变更的需求,反馈到需求接口人处。
(3)省公司需求接口人:
负责定期提交业务新增/变更需求。
2、需求开发阶段
业务需求说明书和产品需求说明书必须由需求项目经理、开发项目经理和开发商三方确认后方可安排开发。
3、需求测试阶段
(1)对于非上线即开通的业务,所有上线发布均需业务人员确认测试通过后方可上线。
(这个功能开发中,功能上线后即按照这一模式管理)
(2)对于上线即开通的业务,业支部须提前通知地市/省公司业务部门上线后安排测试。
4、需求上线阶段
(1)所有需求上线后,需求项目经理需要对上线的软件进行评分。
(2)对于设计到业务操作类的上线需求,业支部须在上线时同步提供业务操作手册。
(3)所有新开发的业务需求,业支部须建立上线初期(7天内)建立应急保障机制,快速响应解决因开发错误但测试未发现等原因造成的故障,由开发人员安排,无需通过正常工单核查原因。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 业务 需求 管理 规范 v1009
![提示](https://static.bingdoc.com/images/bang_tan.gif)