如今“数字化转型”在企业内部逐步深入，我们在与多家金融企业的科技负责人交流时，被问及次数最多的问题，是以下两个：
- “数字化转型”我们已进行多年，科技侧的转型成果如何衡量及呈现？
就以上两个问题，我们希望以提升研发效能为突破口，以“交付模式 规范化”，“关键能力 线上化”，“研发管理 数字化”，“决策制定 智能化”的“四化”建设为重要举措（图1），配合两个阶段的实施策略，为企业带来客观可量化的增长。近两年ThoughtWorks帮助多家企业定制并落地该方案，普遍带来了4个关键指标均提升20%+的效果（后文详细介绍）。
（图1：“四化”建设 提升企业研发效能）
一、规范化
交付模式规范化，强调建立可满足业务期望的交付模式及配套的相关机制。业务期望是多样化的，我们使用“业务期望多久上线”这个标准来做区分，建立多种交付模式。简单的说，一个需求来了，业务希望这个需求2周后上线，交付团队能清晰的知晓，如何让这个需求2周后上线（相关的流程，各角色职责，产出物标准等），同理，业务期望明天上线，交付团队也应知晓其方法，满足其期望。通过多种交付模式的建立及推广，来解决上文中提到的“问题2“双模”的研发交付模式，如何在我行大规模推广？”的问题。根据“业务期望多久上线”分类，一般分为4类：按小时发布（紧急发布），按天发布，按周发布，按月发布。每一个发布单元为一个版本，每一个版本匹配一种交付模式。注意：不建议按团队区分模式，在银行的交付环境下，1次发布通常会涉及多个团队，这样无形的就把交付模式变得复杂化，更何况团队该用哪种交付模式，也是一个难以定论的话题。可使用用户旅程的方法来梳理。交付模式最基本的是流程和任务，在流程下我们还期望区分实践（管理和技术两类）、平台等。流程是必须执行的，而实践是选择执行。例如“每日站会”是实践，团队根据自身的能力及特点选择执行，而“项目创建及审批”是流程，团队必须执行。多种交付模式对应多套流程及实践，下图是个总览，每个交付模式都应该有其自己的一套流程、实践，并且每个流程、实践，都需要有详细的解释说明（细节流程，任务、角色，产出物等）。
（图2：交付模式总览）
业务肯定都希望按天发布，但团队需要具备很高的能力，才能满足其要求。这里就要使用到“团队成熟度”来牵引团队提升能力，为团队能力定义成熟度标准（图3），并将成熟度与交付模式关联，例如“成熟度3级”的团队才能使用“按天发布”的交付模式，实现使用业务期望来持续牵引团队的能力提升，从而达到交付模式规模化落地的效果。
（图3：团队成熟度示例）
二、线上化
关键任务线上化，管理流程及需求的线上化这里不多赘述，一般线上化和规范化可以同步实施，这里单独拆出来的目的是强调使用线上化平台规模化的提升组织产品创设及技术能力。同时实现横纵两方面的打通及关联，横向实现从产品创设到投产运营评价的端到端流程打通，纵向实现从需求到代码的多维度关联。
- 各个产品间的打通，可以借鉴精益价值流的方法，把最小需求作为流动单元来梳理。
- 基于研发模式，做各种交付模式的定制化支撑，将规范化中的所有流程做到平台内，相关实践可用平台支撑，这样可以保证交付过程的精细化、差异化管控。
（图4：一站式综合管理平台）
建设产品创设模块（图5），支撑设计思维方法论，融合以用户为中心、快速验证的产品设计思想，赋能所有团队。
（图5：产品协同设计平台）
金融企业中有大量的研发外包，提升整体研发能力如果靠教练赋能或大规模培训，效果都很不理想，前者投入成本会非常大，后者成效有限。我们的建议是，用教练赋能的方式打造标杆团队，把技术能力“沉淀”在技术平台中，并根据交付模式，差异化技术能力，在全组织中推广平台（配合培训及适当教辅），从而达到全行技术能力的规模化提升（图6）。
（图6：提升平台技术能力，提升全行团队技术能力）
落地推广平台并不容易。可以将交付流程的核心审批移至平台，并“强制”该流程只能在平台中操作，来达到推广的目的，例如将需求受理，移交测试，上线申请等流程放在平台中操作。
三、数字化
研发管理数字化的前提是企业已有规范化的交付模式及线上化的管理平台。通过数字化来解决我们之前提到的“问题1，我们要用数字化的成效体现转型成果”。这个数字化的成效就是研发效能提升。当然研发效能的提升是结果，数字化的关键核心目的是做持续的过程改进，通过数据，来分析交付模式中的问题，持续改进交付模式，持续提升研发效能。规范化里的成熟度模型，是体现团队的能力，在成熟度模型中衡量的是团队的行为标准。我们还需建立研发效能度量指标体系，来管理团队交付，提升团队效能。如图7，是团队效能度量指标的示意，指标分为结果指标（核心指标）和过程指标，同时又分为质量与效率两个维度，指标需要覆盖交付全过程。前文中提到4个关键指标是：需求交付周期，需求吞吐量，生产问题密度，生产问题修复时长。当然每家企业可以定制自己的核心度量指标，核心度量指标一定要少，并且不要团队间横向比较，我们使用自己和自己比的提升百分比，来体现转型成果，并持续支撑提升。
（图7 团队效能度量指标）
端到端的过程改进，各个咨询企业都在喊，但真正的落地改进十分困难，原因有2点，1是这个改进需要有全局视角，要客观公正。2是改进是一把刀，是一个挑问题改问题的过程，团队抵触心理很强（一般哪有问题大家都知道，好解决早就解决了…）。所以这里的建议是
- 一定要建立独立团队，专职负责数据及过程改进（图8），来避免过程改进的快速夭折…这个团队有专职核心人员，以及专家组，领导组等兼职人员，例如成立EPG小组，EPG小组的人一定是组织内部的精兵强将。
- 通过数据客观反映问题并体现成果（图9），EPG的立场都是通过数据得到的，同时拿出解决方案并亲自带队落地。
- 建立相关机制，来保证EPG小组有“尚方宝剑”、“圣旨”、“黄马褂”，例如建立与最高层领导的单周汇报机制，在汇报中阐述成果，问题，解决方案，以及需要领导的支持，来达到全局改进的目的。（如果最高层领导不关注改进，那这事就不要干了。一般都会关注，因为这是转型成果的体现之一）。
（图8 EPG小组的核心职责）
（图9 数据驱动改进）
四、智能化
智能化在研发管理中的良好应用尚不多见，但这并不阻碍我们探索，智能化的初期是减少数据分析的成本。例如EPG每月会发一份数据报告，做这份报告需要1人2天的时间，我们通过智能化的模型建立，将这个报告中大部分的分析交给AI，这样的好处是可以将分析频率从每月提升到每周，甚至实时，及时的发现问题并立即改进，成本是最低的，从而减少改进成本，提升管理效能。
但不可否认，智能化研发管理的路还很长，探索智能化管理，不如探索智能化研发。四化建设是4个方面的举措，它们可以同时进行，也可以分阶段进行。这里给出我们最常用的两阶段落地策略（图10）。
我们把交付过程比喻成一个上下管道，管道中的宽窄不一代表各个部门的效能不同。需求是管道中的方块，从最上面流入，最下面流出，流出代表着上线。同时上线前有阀门，代表着上线审批及生产部署。
- 交付过程黑盒，不知道改进哪里，在管道流动中，只有改进最窄点，才能提升流速，反之改进其它点带来的都是内损和甩锅；
- 需求都是大块需求，流动中容易在管道中“卡住”，当然也许会卡在上线阀门，带来上线的风险；
- 上线后，大块的需求出了问题，难以定位，多人做的大需求，导致谁都不敢改，问题定位的时间长且复杂
阶段1：精细化研发管理，数据驱动改进文化的建立，通常6-12个月的改进时间。
- 可视化全过程：交付模式规范化，关键任务线上化，过程数据化；
- 数据驱动改进：成立EPG组织，找到瓶颈点，加以改进（可参考TOC约束理论）；
- 使用用户故事传递需求：需求拆分成小颗粒度，润滑交付过程，上线问题可快速定位。
在该阶段“上线流程和频率”暂时不会改进，金融行业质量风险不能妥协，上线前是最后的闸口，当我们技术能力与内建质量足够有信心后，再改变上线流程。以下是我们在几个企业中落地该方法得到的平均效能数据（图11），可以看到吞吐量、生产问题密度，生产问题修复时常数据显著提升，由于我们没改上线频率，所以交付周期提升并不明显。（在标杆团队中做了上线流程改造的试点）阶段2：数字化、智能化研发管理。通常12个月+的改进时间。
- 持续加强阶段1中的能力，尤其是技术能力与数据使用的能力，技术能力偏重于质量内建与持续发布，数据使用能力偏重于使用数据提升软件开发的可预测性。
- 改善发布流程，提升发布频率，在保证质量的前提下，做运维改进，更多的发布窗口，更智能化的上线流程，对能力强的团队提供绿色上线“通道” -成效：在吞吐量、生产问题密度、生产问题修复时常不下降的基础上，提升需求交付周期20%+。
“问题1：数字化转型”我们已进行多年，科技侧的转型成果如何衡量及呈现？”
“问题2：双模”的研发交付模式，如何在我行规模化落地？”
不要去硬套双模，以业务需求的发布频率，区分多种交付模式（随时、天、周、月），建立与之匹配的交付模式进行交付，达到满足业务发布期望的效果。在整体效能提升的实施过程中，我们可以通过“四化”来作为我们的建设举措，它们是：“交付模式 规范化”；“关键能力 线上化”；“研发管理 数字化”；“决策制定 智能化”。
最后，研发效能提升，是一个长期持续性工作，打好流程和数据的基础尤为重要，建立“使用数据管理过程，使用数据呈现结果”的文化。同时不要过度的依赖智能化，当我们还很难管理的时候，直接扔给AI管理是不合理的。希望本篇文章能对您有所启发，欢迎通过下图中邮箱地址与我们交流。
