造价师/评估师培训:010-82146681

联盟会员/机构评定:010-82146682

业务合作咨询:010-82586972

E-mail:bscea@bscea.org

 

优秀实践案例

优秀实践案例(2023)丨建立研发度量体系 提高银行科技管理水平—北京科信深度科技有限公司

点击:时间:2024-10-24
一、案例概况
  (一)案例背景
  A银行是一家全国性股份制商业银行,随着业务的不断发展,信息科技领域的人员数量也在快速地增长。
  截止2022年,信息科技领域的软件研发人员规模已达到在6000人左右,占总员工数的比例为10%左右。2018年以前,开发资源主要是通过框架协议的形式进行外部采购。随着科技战略的调整,A银行不断增加自有研发人员数量,截止2022年,自有人员的占比已超过50%。
  信息科技部在全国有多个研发中心,日常运行维护的软件系统超过400个。
  信息科技领域的人员规模大、软件产品多,且面临来自不同领域的“期望”。
  一方面,业务团队受到外部的监管越来越严格,同业竞争也越来越激烈,不断要求信息科技团队提升响应业务需求的速度、质量。
  另一方面,内部管理部门要求信息科技部门能够“物有所值”、“避免浪费”。
  内部的相关方总结为:每年的科技投入持续快速增长,而业务需求的响应速度依然太慢。
  (二)面临的问题
  A银行信息科技领域的主要工作产出物有两种:一是项目,一般是建立新的软件系统,或是原系统的大规模升级改造;二是任务,一般是对原有系统的零星需求开发、解决问题。
  项目的数量占比全部开发工作产出物数量虽然只有20%左右,但是金额占比则在50%左右。任务的数量较多,每个具体任务的金额大小不一。
  2018年以前对这两种产出物的管理模式, A银行长期被如下问题困扰:
    1、对于项目,需要在立项前估算出合理的工期、工作量、费用。其中的工作量、费用主要基于专家经验进行测算与评审,缺乏系统、科学的方法,评估结果的合理性、公允性时常受到质疑。
    2、对于任务,一是制定年度的人力资源外包预算时,缺乏有效的预算依据。二是每个季度都需要向外包合作伙伴付款,付款的依据主要是依据外包伙伴的“考勤”。每笔支出的费用难以对应产出物的价值。这种方式一直被计财部门质疑,认为并不是真正的“权责发生制”。
而信息科技内部直观的感觉是“忙闲不一”。不同软件系统的人员(包括自有与外包)工作饱和度不一样,例如:某些大项目已经投产,但是使用的人力资源并没有相应减少。而进行任务开发的部门则一直在强调资源紧张,一直在加班加点。对于这个“感觉”,缺乏相应的数据要素来说明。 
无论是对于项目还是任务,管理层与开发团队,均无法得知做类似的项目,在业界内公允的工作效率、工作量应该是多少?
经过对同业调查与了解,A银行的领导层认识到问题的根源在于无法对“产出物”的规模进行量化管理,期望在内部建立起信息科技的量化管理体系,解决面临的问题。即:一切依靠数据说话。
二、实施过程
  2018 年,由A银行信息科技团队的PMO部门牵头,引入我司作为咨询方,成立了研发度量体系建设项目组(以下简称项目组),开展体系建设工作。
  (一)确定目标
      度量体系主要包括 “人员”、“流程”、“技术”、“应用”四个层面,其框架见图1。
图1 度量体系框架图
      针对A银行的现状,项目组确定的初步目标如下:
      一是人员,初步建立具备功能点计数能力与实践经验的专业估算及审核团队。
      二是流程,初步建立规模/工作量/成本的量化评估体系,包括但不限于管理办法、过程规范、估算模板、知识库等。同时拉动上下游相关活动(如商务谈判、招投标、需求分析)的改进与优化。
      三是技术,引入功能点分析(FPA)方法并适度优化,建立基于功能点规模进行工作量/成本估算方法,为后续科学地制定项目预算、任务量化结算管理奠定坚实基础。
      四是实践,确定科学的系统分类及各类产品生产率基线,建立典型功能点字典库。
在试点阶段的“技术层面”,项目组选择了4个主要产品对度量方法进行试用。以验证方法的有效性、可靠性,并了解整个体系建设的实施难度及应用成本。
  (二)工作计划
    项目组为了实现计划的目标,制定了详尽的工作计划。计划的主要内容如下表:
  (三)现状评估
    首先,项目组对A银行的现有“估算能力”进行评估,为了保证对应用能力进行全面评价,采用“估算方法应用能力评估模型”,从人员(含资源、能力)、流程(包含制度化、稳定性、持续改进)、技术(包含方法及工具)、实践(包含输入、运用、输出)等多个维度,全面了解A银行当前估算方法应用水平,从而提出恰当的改进建议。
    估算方法应用能力评价模型分为4个级别,简要描述如下:
    1级(初步建立):已开展部分实践,尚未形成制度化流程。
    2级(已管理):初步建立相关流程,可以采用一致的方法进行软件估算或测量。
    3级(已稳定):建立了稳定的流程,可以获得可靠的规模数据并用于管理决策,初步形成管理闭环。
    4级(自适应):制度化地运用数据对相关流程、方法进行分析并持续改进。
    采用此模型可以定期对组织相关能力进行评价,以了解本组织能力短板、改进情况、改进目标以及与同业优秀实践的差距。
    2018年,A银行的评价结果如下:
  (四)定义问题与制定方案
    经过调研,梳理出人员、流程、技术、实践方面存在的主要问题是:
    1. 人员方面的主要问题
    (1)组织资源的问题:相关管理及专业资源不足,制约了成本度量水平的进一步提升。
    (2)基本能力的问题:一是对基于国标的功能点分析方法不了解,二是尚不具备功能点计数、审核的专业团队,三是相关人员缺乏必要的系统培训及指导。
针对上述问题,项目组制定的解决方案如下:
汇集组织资源:组建并培养A银行的内部功能点小组,负责方法的维护、争议仲裁以及数据分析与持续改进。引入独立的第三方进行审核。
提高基本能力:对软件功能点计数及审核相关人员开展相关培训及认证,保证方法的一致性。对于常见的共性问题写入指南及相关文档,在后续培训中强调,持续赋能。
    2. 流程方面的主要的问题
    (1)制度化的问题:在软件研发成本度量领域,缺乏细致的管理办法、规程及配套制度,难以保证相关流程有效落地。
    (2)稳定性的问题:审核流程需进一步明确及规范化。
    (3)持续改进问题:关键数据(实际工作量耗时)没有收集,历史数据没有整理,尚未有效应用数据,尚未利用数据对方法进行定量分析并改进。
    针对上述问题,项目组制定的解决方案如下:
    加强制度化:建立相应的软件研发成本度量管理办法、规程;在当前管理办法、规程、流程的基础上引入新的软件成本度量方法。
    提高稳定性:建立功能点计数-审核机制,并形成管理闭环。
    着力持续改进:收集开发工作的实际工时数据;利用数据进行相应的度量分析,测算一些关键指标(例如:生产率、缺陷密度等),对管理办法、规程、成本度量方法、关键指标进行持续改进。
   3. 技术方面的主要的问题
    (1)方法的问题:方法不符合国家标准,难以实现一致性。
    (2)工具的问题:模板不符合国家标准; 没有收集记录工作量、工期的实际数据。
  针对上述问题,项目组制定的解决方案如下:
    在方法上,引入基于国家标准的快速功能点方法;引入最新的行业基准数据。加强部分场景计数规则优化,进一步保证方法的客观性和一致性。结合行业数据,引入需求蔓延因子,提升早期估算准确性,并逐步开展针对变更的度量与分析。
    在工具方面,统一估算模板,结合后续应用流程,可将基本的功能点清单维护(计数/确认/审核/变更/归档)、比对、快速估算等功能在项目管理平台中逐步实现。
   4. 实践方面的主要的问题
    (1)输入的问题:需求文档水平参差不齐,需要进行较多需求澄清才可以准确估算。
    (2)运用的问题:相关人员缺乏系统的方法培训及指导,部分评估结果质量不佳,存在较大的审计隐患。
    (3)过程及数据资产的问题:没有有效利用过程资产及数据,尚未形成“度量文化”。
    (4)输出的问题:估算准确性难以验证,不客观。
    针对上述问题,项目组制定的解决方案如下:
    对于输入问题,使用功能点方法辅助进行需求分析,进一步提高需求文档的质量;优化相关模板及规范,对需求的粒度提出更为明确的要求,同时更有利于功能点计数。
    对于运用问题,形成稳定的功能点计数及审核队伍,并利用试点推广及外部审核机会加深相关人员对方法的理解。
    对于过程及数据资产问题,明确数据的后续采集、审核、入库策略;选择试点系统,收集数据进行分析并形成基线;定期对数据进行分析并更新相关基线及算法模型;逐步积累估算偏差数据及需求稳定性数据,并用于持续改进。
    对于输出问题,通过交叉验证方式检验并优化相关模型,逐步提升估算能力及准确程度。
  (五)实证结果
    在9个月的实践后,项目组对相关的度量数据及衍生数据进行了分析。
    其一,产出物(任务和项目)的规模与实际工作量之间的相关性系数大于0.8。此数据说明:基于功能点分析度量出的产出物规模与A银行的实际工作量有较强的相关性。可以进行下一步的生产率测算、估算模型建立等工作。
    其二,在可靠的数据基础上,咨询团队对生产率数据进行计算与分析,其离散程度也在理想的范围内(小于30%)。
  (六)全面建设
    在取得良好验证效果后,2020年初,A银行的高层领导决定在信息科技领域内部全面推广功能规模度量方法,并以此建立起研发度量管理体系。
    体系建设主要分为4个层面:
      1、人员
      对信息科技团队进行“软件工程造价师”认证培训,全面覆盖规划、需求、研发、测试、项目管理等团队。并确定由信息科技的规划团队( 80 人)负责项目和任务的功能规模度量,即:功能点分析与计数,外部专家对度量结果进行审核。
      2、方法
      应用前期的实践数据,建立了基于功能点规模的工作量估算、结算模型,即“方程法”计算模型。
      3、流程
      对于项目,在项目立项前,开发团队基于经验法对工作量估算;规划团队基于方程法进行工作量测算。
      PMO将两方的结果进行交叉验证。如果两者的偏差超出合理范围,则进行根因分析,发现问题并提出解决方案,最后形成双方均认可的结果。
      对于任务,在任务进入业务验收测试后,规划团队基于方程法进行工作量的核算。相关方在付款前,对核算结果与外包伙伴的实际考勤数据进行交叉验证。
      4、应用与工具
      PMO定期分析组织以及各系统的相关数据,了解规模度量方法的掌握水平及组织研发效能,针对数据分析中发现的主要问题给出改进方案。
    经过努力,功能规模度量以及工作量的估算、审核,相关数据分析活动均实现了信息化,融入到统一的IT项目管理平台中。 
三、实施成效
  经过五年多的推广应用和持续改进,A银行已建立起了比较成熟的研发度量管理体系。
  2023年6月,相关方使用 “能力评价模型”对A银行的进行了定期的评价,最后计算得出的“分值”,属于业界P75水平。
  取得的主要成效如下:
    1、人员层面 
    经过多期培训,A银行已有300多人掌握了功能点分析方法并通过软件工程造价师认证考试。核心计数团队的功能点计数偏差率已由2020年初的平均15%以上降低到 5%左右。
    2、方法层面
    在逐步深化应用标准方法的同时,也积极开展规则定制活动,不断提高方法的适用范围,目前行内80%的需求均可以采用量化方法进行规模、工作量评估。
    3、流程层面
    已基本建立起完整的分析、澄清、审核、后评价流程,能完全保证高质量的输出。
    4、应用层面 
    通过长期实践,作为输入的需求文档质量有了明显的提升,输出的规模度量、工作量评估结果,基本可以控制在10%以内。
    已形成完善的过程及数据资产,并制度化地应用于相关改进活动。通过定期的数据分析和晾晒,提升了研发效能的可视化水平。
四、客户评价
    信息科技部领导评价:建立的研发度量体系,一是对于业务团队可以给出明确、量化的预期,二是很好地解答了计财部门对“物有所值”的质疑,极大地推进了我行的信息科技工作,从而为业务工作提供了更好的保障。
    相关的度量数据已成为A银行重要的生产要素。
相关新闻
 
关闭

入会申请/机构评定:010-82146682


培训报名/续证补考:010-82146681

返回顶部