银行科技业务需求管理办法-2023

XX银行业务需求管理办法第一章总则为加强XX银行（后简称为我行）业务需求管理，明确我行需求管理范围和规范，明确需求从提出到交付各环节参与者及其职责，提高需求管理效率，降低风险，实现需求高质高效交付目标，制定本办法。本办法仅适用于被定义为业务需求的管理，问题、事件、服务、数据查询等管理不适用。本办法仅适用于对总行各部门提出的业务需求的管理。分行需求需提交给归属的总行业务部门，由总行业务部门判断是否提出。本办法仅适用于提交到金融科技部项目管理室且被受理的业务需求的管理。本办法与软件开发过程管理办法紧密结合，相辅相成。业务需求管理应当遵循科学合理、规范高效、权责清晰的原则。需求管理的目的主要包括以下几点：（一）需求来源可控，通过需求收集、整合、拆分机制，控制需求数量、提高需求质量；（二）确保需求目标完整、可行，业务价值目标统一；（三）通过对需求的分析、定义和跟踪，提高需求交付速率及交付成功率；（四）有效管理和控制需求的变更，减低需求风险；（五）确保需求管理过程合规、可追溯；（五）为需求各环节参与人提供明确、一致的需求信息，促进需求协同。第二章概念定义本办法所称业务需求管理，是指对业务需求进行收集、整理、分析、定义、跟踪、变更等一系列管理活动的总称。本办法所称业务需求，是指总行各部门为实现需求目标，指派需求提出人描述需求背景、需求内容、需求目标、目标价值分析、风险分析、需求紧迫程度分析、需求重要程度分析及需要满足的技术、商务要求。其中，若无技术、商务要求，无需描述。业务需求需以正式文档形式出现。参考《XX银行业务需求申请单》模板。技术要求，是指需求对改造系统性能、安全性、可扩展行等指标的要求。商务要求，是指因当前人力资源池、自主研发资源不足时，需要通过商务采购，对被采购方要求、可接受的费用预算、交付要求等说明等。本办法所称业务需求牵头机构，是指业务需求提出部门，作为业务需求确认、验证唯一责任方。本办法所称业务需求统筹管理机构，是指金融科技部项目管理室（以下简称项目管理室），作为需求统筹管理唯一责任方。本办法所称业务需求实施机构，是指金融科技部开发中、数据中心、运维中心，作为需求实施、交付工作唯一责任方。本办法所称业务需求池，是指金融科技部负责统一收集业务预提需求进入业务需求池，入池需按照提交先后顺序组织初步分析。本办法所称开发待办清单，是指已经明确的需求明细，业务需求实施机构应按照优先级、入单日期先后顺序明确进度计划并按计划开展。第三章组织职责业务需求管理组织架构分三级：业务需求牵头机构、业务需求统筹管理机构、业务需求实施机构。业务需求牵头机构职责如下：指派一名需求提出人，作为业务需求确认、验证、验收工作唯一责任人。负责提供预提需求申请单，与需求实施机构对需求申请内容沟通达成一致意见，根据沟通结果完善业务需求申请单，并取得本部门总经理、涉及会签部门总经理、本部门主管行长审批确认。若业务需求涉及多个部门，牵头机构负责协调业务资源。提交确认的业务需求申请单。负责审核业务需求实施机构提交的技术评估表。重点确认技术实施方案、交付计划是否满足预期。负责组织业务测试，按照《XX银行软件开发过程办理办法》中业务测试管理要求完成测试工作。组织生产验证，提供生产验证报告并由本部门总经理确认。需求按照《XX业务需求管理办法》要求开展需求相关工作。业务需求统筹管理机构职责如下：负责制定XX业务需求管理办法，并持续改进。提供业务需求管理过程需交付的文档模板。统一收集、过滤、拆分、整合全行业务需求。负责业务需求实施机构分发。负责优先级制定和维护。作为业务需求牵头机构、业务需求实施机构的联络员，确保需求从提出到交付全流程的信息同步，促进需求分析、确认、评估、审核进程。负责需求管理重点里程碑进展跟踪：完成技术评估日期、开始开发日期、送测日期、计划投产日期。负责组织需求管理重点环节评审：技术评估、投产方案。负责业务需求版本管理。负责业务需求变更管理。业务需求实施机构职责如下：指派一名开发负责人，作为需求开发过程唯一负责人。若需求涉及多个系统，开发负责人负责协调资源完成需求分析、评估、开发、交付工作。负责与需求提出人一起完成业务需求确认。在提交前分析涉及系统、预估工作量、预计费用、预计开始开发日期、是否需要申请追加资源等。负责需求具体技术评估，并负责解释评估内容。负责需求开发、出厂测试、解决测试问题、解决投产后问题。负责组织业务验收测试，审核测试结果，判断是否符合投产要求。负责编制需求投产方案，并负责解释方案内容。负责投产实施。需求按照《XX业务需求管理办法》要求开展需求相关工作。及时提示超期问题，寻求解决方案。或调整计划，或追加资源。第四章业务需求管理事项及流程业务需求管理主要包含4项事宜：业务需求采集管理、业务需求变更管理、业务需求里程碑评审、业务需求过程管理、业务需求文档管理。业务需求采集管理：需求池管理维护（含需求分类、优先级规划）、开发待办列表维护（契合优先级的序列）。业务需求变更管理：对进入到开发待办列表的需求进行变更管理。包含不限于更新基线、变更记录、组织评审、变更信息同步。业务需求里程碑评审：技术评估评审、投产方案评审。业务需求过程管理：重点关注开发待办列表中计划与实际完成情况。业务需求文档管理：制定并维护需求过程文档模板，制定文档编制标准，文档版本控制要求，文档留存可追溯机制。业务需求管理流程按顺序主要包含11个阶段：需求预受理、需求分发、需求分析、需求确认、需求受理、技术评估、需求评审、需求开发、业务验收、投产上线、生产验证。需求预受理：采集、过滤业务需求，形成业务需求池。需求分发：按照需求入池时间顺序分发业务需求实施机构。需求分析：需求背景、内容、目标、重要程度、紧急程度、优先级、交付计划、目标价值、预估工作量、预算费用、人力资源情况等信息对齐环节。需求确认：业务需求牵头部门根据需求分析结果完善业务需求审批单，形成终版获取部门总经理、会签部门总经理、部门主管行长审批通过意见后提交至业务需求统筹管理机构作为需求基线。需求受理：需求基线确认后，正式受理需求，需求进入待开发清单。技术评估：对已确认的需求进行详细的技术评估。明确涉及系统、开发负责人、开发方式、开发工作量、交付计划等，形成技术评估表。若涉及多个系统，由开发负责人协调统一整理。需求评审：对技术评估表内容进行评审确认。需求开发：根据评估结果开展开发工作，要求参见《软件开发过程管理办法》。业务验收：业务需求牵头部门指派测试人员进行验收测试，测试通过后方可安排投产。测试管理要求参见《软件开发过程管理办法》。投产上线：准备投产方案，投产方案评审，投产实施。若涉及多个系统，由开发负责人协调统一整理投产方案。生产验证：投产后，业务需求牵头部门负责人指派人员进行生产验证，判断交付结果是否符合预期。第五章业务需求采集管理需求池数据来源如下：（一）每季度统一收集：每季度统一收集各业务部门计划下一季度期待交付的需求，整理形成预受理清单。常规情况下，本季度仅对预受理需求进行分析确认工作。规划为紧急的需求汇总由提出部门负责人、科技负责人、需求归属中心负责人决策实施方案。（二）临时需求：当季提出期望当季完成的，需经提出部门负责人、科技负责人、需求归属中心负责人共同决策是否必要本季度完成，若是，则加入当季待开发清单，按非常紧急需求制定方案。业务需求分类如下：业务需求根据两个维度进行分类：按申请部门、按需求内容。（一）按申请部门可以分为金融科技部需求和其他业务部门需求。金融科技部需求：内部提出的系统优化、性能优化、软件升级、为解决生产识别的可能在未来影响业务开展的涉及代码变更的问题的需求等。（二）根据需求内容可分为业务拓展、业务减缩、优化改造、产品维护、利率调整、监管合规、风险控制、数据赋能、缺陷修复、客户体验、需求变更。业务拓展：已有系统中没有此功能，需要在原有基础上新增功能。业务减缩：停用已有系统某已有功能。优化改造：因组织架构、制度规范、业务处理流程等发生变化，需要对现有系统的某些功能进行优化改造。产品维护：新建产品、已有产品规则变更、已有产品停用等。包含普通存款产品、特色产品、贷款产品。利率调整：OM系统未推广或未涵盖产品利率、挂牌利率等需要系统后台操作的需求。监管合规：为满足监管要求、审计要求、人行合规要求等对系统进行优化改造的需求。风险控制：反洗钱、黑名单、限额、司法查冻扣、其他为实现控制金融风险为目标而提出的需求。数据赋能：新增报表、报表优化、停用报表等常规、通用报表维护。（不包含一次性数据查询）缺陷修复：生产运维中经常引发事件的共性问题、开发测试中发现的系统缺陷，且，需要通过代码修改（生产版本变更）的系统问题及缺陷。一般由金融科技部提出，此类问题的管理原则谁发现谁提出谁测试。客户体验：对客渠道界面优化。（手机银行客户端、门户网站、智能柜台、ATM等）需求变更：已提出未投产需求实施过程中进行需求调整，但调整内容的变动会引起成本增长过大、或引起工作量大幅度增长，实际能够交付日期与初始预期差距较大、或对现有业务影响较大、或可能存在风险，合规等问题。此时，需要重新提交需求申请，重新分析评估。业务需求分级如下：业务需求根据三个维度划分等级：紧急程度、重要程度、开发工时。其中，紧急程度、重要程度影响优先级排序。（一）根据紧急程度可分为紧急、一般紧急、非紧急。紧急：紧迫程度为高，业务期望的投产时间有实际的必要性，且按常规资源分配和进度安排无法按时投产，必须通过领导特批增加资源或调整已排期需求开发顺序，可能涉及部分流程进行加急处理，才能满足上线要求的需求。一般紧急：紧迫程度为中，业务期望的投产时间有实际的必要性，且按常规资源分配和进度安排可以按时投产，且不可受紧急需求排期影响。非紧急：紧迫程度为低，需求提出方认可当前的排期计划，若有紧急需求需要调整排期中需求，优先对此类需求进行调整。但，调整后的排期计划必须与提出方达成一致。（二）根据重要程度可分为非常重要、重要、一般。（三）根据评估开发工时可以分为大型需求、中型需求、小型需求。（每日工时按8小时计）大型需求：评估开发工时大于720小时。中型需求：评估开发工时大于240小时，小于等于720小时。小型需求：评估开发工时小于等于240小时。紧急的需求必须是重要的。需求优先级可分为：高、中、低。（一）需求实施序列默认按高、中、低排序，各级按受理日期先后排序；（二）根据需求的重要程度和紧急程度，优先级按照以下规则划分：优先级紧急程度紧急（高）一般紧急（中）非紧急（低）重要程度非常重要（高）高高中重要（中）高中中一般（低）中中低第六章业务需求变更管理本制度所称变更管理，目的是控制需求变化引起的开发过程与需求初始目标不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。建立需求基准版本和需求控制版本文档。对已经确认并纳入基线管理的需求进行变更时，需求申请部门应向项目管理室提交业务需求申请表，并在表中注明类型为“需求变更”，该表需经过需求申请部门负责人签字确认，如需求变更引起了较大费用成本的增加，则需要再次发起需求审批。项目管理室收到需求变更申请后，协调开发或大数据中心及相关业务部门开展需求变更的影响分析和实施工作。变更影响分析和变更实施的具体要求参照软件过程管理相关办法执行。第八章业务需求过程管理跟踪开发待办清单，及时关注已超期需求，排查超期原因，向需求过程干系人同步超期情况，组织相关人员解决超期问题，记录过程问题。跟踪开发在途清单送测计划，及时关注已超期需求，排查超期原因，向需求过程干系人同步超期情况，组织相关人员解决超期问题，记录过程问题。跟踪已交付需求清单，跟踪业务测试进展。跟踪已投产需求清单，跟踪业务生产验证结果。第九章业务文档管理需求文档清单：被确认的《业务需求申请单》、《需求技术评估表》、《出厂测试记录》、《业务测试材料》、《投产上线方案》、《生产验证记录》、《详细/接口设计》、被确认的《需求变更申请单》。《业务需求申请单》要求各项内容描述清晰、无二义性；目标完整、无遗漏；目标明确，不模糊；各项内容描述正确，无逻辑错误；业务闭环、目标可验证。《详细/接口设计》仅认定为需求类项目时收集。《需求变更申请单》仅需求实施过程中发生需求变更时收集。需求文档需按照金融科技部项目管理室提供模板进行编制。审核通过的需求文档由金融科技部项目管理室留存，以留存文档为需求过程管理依据。已被收录的需求文档若需调整，需走变更流程，未进行变更流程的认定无效。对于不符合需求文档要求的，各审核节点人员应予退回并督促整改，文档提交人应及时整改文档内容并提交审核。所有的需求文档都要进行版本控制，文档要包含文档类型、名称、创建者、创建时间、修改者、修改时间、版本号、评审人员等信息。第十章监督改进机制本办法施行后，每半年通过调查问卷的形式向半年内参与过业务需求流程的人员收集改进意见。分析意见