提升业务响应力：践与行｜商业洞见

金融企业转型的三个挑战

从2009年到现在，我们在包括国有商业银行、股份制银行等传统金融企业里做敏捷转型咨询时，为了提升业务响应力，发现他们常常面临一些相似的挑战。

挑战1：业务侧敏捷的滞后

业务部门花好几个月、甚至半年的时间讨论业需求，整理出完备的SRS（软件需求规格说明书），通常是一份厚重的文档，而此时业务部门发现预算所能支撑的软件开发和测试时间已然不多，因此要求开发团队在三个月内开发完成，估计只有一个月用来测试，然后就要上线。更麻烦的是，在开发过程中业务人员发现用户需求在最近已经发生更改，他们必须修改需求规格说明书，而且还非常频繁，开发团队开始抱怨压力太大，测试团队更是热锅上的蚂蚁。

这个场景表现出的一些特征如下：

• 需求分析过程非常长，常常是好几个月
• 需求池（产品待办事项列表）常常处于干枯状态，或者是井喷填满
• 开发和测试团队抱怨时间不够
• 开发过程中大量需求变更带来很多浪费
• 发布时间一拖再拖

这个场景中，突出的问题是超长业务决策时间压缩开发测试时间，需求变更成本高。

深入分析来看，是传统金融企业业务侧缺乏一套行之有效的方法用以提升投资决策效率，从而快速将市场需要转化为业务需求，让交付团队开发并及时上线。除此之外，业务人员缺少用户价值驱动的理念和方法，常常凭个人一厢情愿和拍脑袋规划需求，缺失了用户研究和运营数据分析环节，导致浪费。

我们咨询过的传统银行，有几款产品，做了很多功能，但是仅仅百分之几的功能被用户使用，很多功能用户从来没有用过，造成大量浪费，业务人员还要在从来没有使用过的功能上再增加新功能，犹如火上浇油。

在敏捷的浪潮下，交付侧已经有很好的方法论支撑，无论是流程还是技术实践，都可以快速响应，比如Scrum这样的敏捷方法，持续集成和持续交付这样的技术实践。

如何从业务侧改进，做到精益产品开发，快速应对市场变化是一大挑战。

挑战2：项目驱动交付的掣肘

业务侧以项目为中心立项，立项过程需要层层审批，特别是预算部分。有时立项没有及时审批通过，导致隶属于它的需要快速实现的高价值需求被延误，无法及时抓住对应用户。更糟糕的是，产品团队被打散，多个项目并行开发，没有统一的优先级，不能聚焦在高价值功能点上，等开发团队反应过来时，这个需求已经失去价值，无需再开发，延误了商机。

这个场景中，暴露的是关于项目立项的问题。常见的做法是，业务侧根据需求立项，导致项目多如山，每个交付团队同时承担多个项目开发，其后果是：

1. 超负荷
2. 流动性差
3. 交付慢

每个立项还要经过层层漫长审批，特别是预算部分非常敏感。为了减少审批次数，在立项之初，项目管理人员期望把项目范围扩大，使得预算同时变大。当业务人员看到预算增大，把该有的不该有的功能都添加到交付范围内，结果导致交付更慢。更可怕的是，很多功能并没有业务价值。

我们正在负责一个大型全球跨国银行的IT研发中心，常见一个团队十来个人，同步并行的项目有三到四个，两三个人负责一个项目。在开发过程中，交付团队将注意力集中在按时交付项目划定的范围，跟业务部门分离，沟通方式局限于文档和电话，对于业务变更需求抱怨颇多。

以项目为中心交付时，如何优化治理结构和既定流程，为第二个典型挑战。

挑战3：唯“快”不破与核心安全求稳

企业在提升业务响应力过程中，受到互联网行业的冲击和影响，觉得敏捷是一颗银弹，对于后台核心业务开发也花了大量时间来尝试敏捷方式运作。然而核心系统业务需求趋于常规化和周期化，比如存款、利息重新计算等，比较稳定、可预测；其次，因为是核心业务，影响范围深而广，上线前的回归测试周期长，需要特别谨慎不能有任何失误，业务部门求稳胜过高响应力。最后发现应用敏捷方式来提升业务响应力效果并不理想。

这里暴露的问题是没有区别对待不同业务，进而采用不同开发模式。面对移动互联网的迅猛发展及互联网金融的竞争，传统金融企业纷纷提出“移动优先”、“数字优先”等IT战略，以提高响应力和适应性。对于金融行业的新兴业务或者前端系统，比如手机银行、自助服务以及渠道拓展、互联网平台接入等业务，需要对终端用户的需求快速响应，才能扩大用户群体，迅速占领市场。

然而对于金融IT传统的后台核心业务系统，却表现出如下一些特点：

• 安全性要求极高：国家各种法律法规对于金融系统安全性有严格要求；
• 稳定性要求极高：必须保证7X24X365的可用性;
• 需求变更频率不高：比如银行中的存款、清算、结算等核心IT系统；
• 受限于以上要求，功能常常是集中交付，而非迭代交付。

我们在咨询过程中客户会经常询问一个问题，“我的产品或者项目适合采用敏捷开发吗？”，如上所述的两种业务模式应该如何处理？是应该不加区分全部采用敏捷开发模式吗？这就是在传统金融企业产品研发过程中面临的“快”与“慢”并存之挑战。

以上提到的传统金融企业具备如下一些特点，决定了其业务响应力提升面临上述挑战，要想让“大象灵活的可以跳舞”，实属不易。传统金融企业特点如下：

• 组织机构庞大，交付团队动辄上万人
• 组织结构复杂，管理效率低下
• 产品创新、投资决策流程复杂且低效，很难快速响应市场需求
• 跨部门协作比较困难，业务、开发、测试、运维分离，“顽固”的职能划分，而且团队物理分散在不同地域
• 拉通业务端敏捷阻力大，业务人员的意识转变慢
• 企业IT表现出“慢”、“贵”、“难”等特点

正因为“大象”的特点，要提升其业务响应力困难重重，但并不是没有解决方法。

应对之策

策略1：价值驱动决策撬动业务敏捷

图1: EDGE（价值驱动产品组合管理）提升业务侧响应力

前面谈到，业务侧人员在面对敏捷的交付团队时，如何让自己变得更敏捷？其本质上是如何让业务和产品管理人员聚焦于价值，通过价值驱动决策，快速决定应该投资哪些产品功能，并创建产品待办事项列表用于交付团队开发。

EDGE是ThoughtWorks提出的一套基于组织的愿景和目标进行投资分配和监控的决策系统，立足于寻求企业投资组合管理价值最大化。它使得企业可以快速响应市场机遇，有效的将组织的战略目标与执行能力紧密的联系在一起。通过明确商业愿景、制定产品策略、专题分析和组合管理、制定最小可行产品、精益交付以及持续衡量价值来提升业务响应力。

实施策略和步骤

第一步：对业务管理机制达成共识

给业务人员、业务部门领导和业务线高层宣讲整个EDGE的业务管理机制，并达成共识。

第二步：通过精益价值树规划战略

业务人员邀请业务部门领导和业务线高层，建立精益价值树，从组织层面全局思考业务线商业愿景、目标、机会点以及行动方案。这部分非常重要，笔者在咨询过程中听到过业务人员经常猜测领导的想法，领导的话有时也被曲解，双方并没有以用户为中心。要想让业务部门从高到低所有人就战略达成一致，应当遵循精益价值树，如图2：

图2: EDGE（价值驱动产品组合管理）价值树

需要着重指出的是，精益价值树不是一成不变的。通常采用每季度组织工作坊的方式，根据市场运营的价值反馈对精益价值树进行评审，调整商业目标和后续投资。

第三步：采用可视化方法建立投资组合待办事项列表

将精益价值树中每个目标的愿景、核心价值和机会点可视化，并且对每个专题方案进行分析，输出投资组合待办事项列表，示例如下图3。

图3: 某银行专题分析示例

第四步：建立PVR（Periodic Value Review）评审与决策机制，审核及调整投资组合待办事项列表。

PVR会议由产品经理或产品负责人召集，邀请管理层、相关业务人员、市场、运营和技术专家共同参与，需要做如下事宜：

回顾近期发布专题的用户反馈、运营数据，决策后续演进措施，包括是否需要调整产品策略 产品经理讲解近期新的专题分析，共同讨论决策专题优先级 审视和更新持续三个版本的滚动规划 建议每月至少一次

第五步：通过MVP和滚动版本计划实现产品设计

滚动的版本计划将最高优先级的专题拆分为故事，分别规划到可以交付的版本中，形成持续几个迭代的滚动规划。

到此，就可以将待办事项列表中的用户故事交给交付团队开始迭代开发，进入传统的敏捷交付流程。

策略2：以产品为中心的交付

为了进一步明确这两者的区别，特对比如下：以项目为中心，其核心是以需求立项，带来的主要问题是项目周期长、需求力度大、反馈周期长、多并发项目、团队无节奏，直接结果是无法快速交付对终端用户有价值的产品；相比之下以产品为中心的交付，统筹所有需求、需求力度更小、采用持续滚动计划、团队节奏感更强，从而使得所有成员关注最有价值的高优先功能，持续交付价值。

企业创造产品的目的就是要解决用户或企业自身所面临的问题，因此以产品为中心也就是以解决问题为中心；相反，以项目为中心则是以计划、预算和职能为中心。

图4: 项目为中心交付流程 vs 产品为中心的交付流程

产品为中心的团队组建

虽然提到要“围绕产品组建跨职能团队”，但是传统金融行业的组织结构是典型的职能矩阵式， 业务部门通常在总部，开发、测试、运维部门分离，物理地理位置上也分离，很难做到理想的敏捷团队同地共置，即使是把开发和测试放在一起，也不容易；再加上外包团队，分布式团队更复杂。如何快速解决这种复杂的分布式团队的敏捷协作问题，各大银行纷纷借鉴学习了ThoughtWorks的Always-on工作模式来构建高效的分布式虚拟团队。

图5：Always-on可以帮助分布在不同地点的团队成员虚拟的面对面沟通，及时解决问题。敏捷12条原则中第四条“敏捷在整个项目开发期间，业务人员和开发人员一起工作”，这种Always-on的模式，就是为了实现这个原则。

策略3：差异化交付模式应对“快”与“慢”

差异化交付模式，是一个能够很好应对传统金融行业在“快”与“慢”的挑战下落地敏捷的一个可选方式。所谓“快”，就是变化快，需要快速响应，及时调整；所谓“慢”就是在已经非常熟悉的领域，可预测性强，需求变化慢。下面详细介绍如何使用这种模式实施交付。

差异化交付模式

差异化的交付模式如下图。模式1进行很多内部迭代，上线之前专门有个Launching阶段，与各个依赖之间进行联调测试，以免出现上线前的集成风险。模式 2结合了LSM（Lean Startup Methodology）以及Scrum，对于一个产品的研发包含：产品的Vision设置、概念剖析、MVP发布以及后续的持续迭代交付阶段。

图6: 差异化交付模式

模式1：长迭代与版本火车

不需要频繁的上线发布，而更强调稳定性。因此在每一个版本周期内以小瀑布方式完成计划、设计、开发和测试，并准备发布。开发过程以2到4周为迭代，可以在每个迭代结束时给业务和产品负责人做一次演示，尽早获得反馈；也可以更好的支持敏捷团队尽早开始联调测试。每年固定4或6个版本火车，各产品的版本节奏基于版本火车时间点对齐，利于进行跨产品间集成的协调和共同上线。某国际银行的Core Banking核心后台业务，也希望进行敏捷转型，选择了适合的模式1。

图7:版本火车

模式2：在进入迭代开发之后，就是传统的Scrum流程，迭代开发、持续交付。

差异化互相依赖的协作模式

作为前台系统，经常要与核心中后台系统做对接，差异化的两种模式进度如何匹配？具体实施方式如下：

• 前后台Scrum团队密切合作，建立Scrum of Scrums机制，定期沟通，互相协调配合，提前规划好依赖日历，明确好先后顺序，并且避免两边需求偏离太远；
• 从项目第一天开始进行系统集成，及时发现问题；
• 有时候后台资源不足，这时候采用Mock服务的方式，先保证前台的功能满足业务需求，而后根据中间层的Contract ，作为接口需求，与后台系统集成；
• 在上线前，后台会有长期的System Test、UAT 时间，这时候前台的开发计划尽量匹配后台的 ST 进行测试，以免出现上线前的集成风险。

图8:差异化交付协作方式

应对之策纵观

所有应对之策结合使用，其全局效果如下：

图9:应对之策全景图

写在最后

诚然，以上应对之策其实施流程不可谓不简单明了。然而，我们发现在过去几年的咨询过程中，企业高层在推动时却面临重重困难、层层阻挠。其本质原因在于，企业在变革过程中，推动变革的中坚力量是中层管理者，大量中间层管理者在企业响应力的提升以及责任承担方面起着举足轻重的作用。

如何撬动中层，确保以上策略落地。从组织级角度，需要提升其敏捷适应性领导力。Jim Highsmith作为敏捷宣言签署人之一提出的“适应性领导力模型”[1]，要求管理者专注于如下行动：

• 提升价值交付速度
• 充满激情地改进质量
• 少做：精益思考，交付客户必需的功能和稳定的产品，少即是多
• 融入员工并持续激励他们

其核心思维转变如下：

• 适应：从“完美计划以预防变化”转变为“接受变化”是不可避免的，唯一可控的是如何适应变化，拥抱变化
• 探索：从传统的“计划并执行”模式，转变为设定愿景并持续探索，敢于挑战未知世界，从探索中学习并不断演进解决方案
• 引导：从传统的“命令进而控制”思维转变为融入员工，引导建立自组织、自我约束的团队
• 驾驭矛盾：从面临抉择时做“A或B”的选择、择其一个则牺牲其二，转变为处理好矛盾统一体，兼顾“A与B”创造性地提出新的更优解决方案

在合理采用以上策略之后，企业在不断敏捷化的道路上还将面临规模化的挑战。规模化并不是简单的从两三个小团队转到几百个团队的敏捷运作，其范畴更宽，囊括了整个企业的所有职能，包括财务预算、人力资源规划、安全与合规等，其终极目标是打造一个“持续创新的、高适应力、高绩效”的精益企业。