南非标准银行访谈： 银行如何实现双速IT转型

南非规模最大、历史最悠久的金融服务机构—— 南非标准银行（Standard Bank）近年来面临来自新兴互联网金融公司的严峻挑战。在为客户提供创新产品和具有吸引力的体验的同时，互联网金融公司的运营成本也远远低于传统银行。“我们相信，传统银行不是投资开发的技术有问题，而是流程没有到位，未能从新技术中获得充分的效益。”标准银行首席技术官兼集团技术部门负责人Mike Murphy 回忆说。

最终，这家历史长达155 年的银行踏上了持续多年的数字化转型征程。其核心是向敏捷软件开发模式转型，即注重快速的产品迭代、测试和学习方式，以及部门之间的密切协作。在与麦肯锡公司的Sven Blumberg 和Christian Stüer 的对话中，Murphy 讲述了金融机构对互联网渠道日益增长的需求和倚重，以及标准银行为长期业务转型、收入增长所采用的新技术和业务策略。

多数跨国银行都在推行不同形式的数字化或移动战略，为什么这一转型如此关键？

Mike Murphy：我们现在所面对的千禧一代年轻消费者对新技术非常在行，对互联网的世界也非常习惯。这一现象在新兴市场尤其明显：那里90%的消费者年龄在30 岁以下。以非洲为例，19 岁以下的人口占总人口近一半，大多数年轻人有手机。银行一直以来都在寻求“可靠”的数字化银行解决方案，而现在这样的方案已经成为现实。我们看到，银行已经通过数字化创新获得了差异化优势，现在客户单击鼠标就可以进行贷款申请和查看账户信息。数字化转型也有利于定制化产品的推行以满足客户个性需求。在各式各样的服务中，移动技术的发展速度尤其惊人，没有哪家银行愿意在这方面落后。

在推动数字化和移动创新中，IT 部门扮演着何种角色？

Mike Murphy：多数银行在客户体验方面根本无法和纯互联网金融公司竞争。但这并非由于银行没有做过尝试，更多的只是因为慢了一拍。在帮助企业快速应对市场方面，IT 部门有着举足轻重的作用，但前提是IT 部门不再仅仅是个传统的执行者。我们再来看纯互联网金融公司，其IT 部门更多的是作为业务部门和用户群体的合作伙伴，共同合作推出新的应用软件。在纯互联网金融公司，软件开发和交付的自动化水平也更高，IT 开发人员在获得授权后可以快速响应不断变化的客户需求和想法，而不是每个开发决策都要得到相关许可。总体而言，它们更多地采用敏捷软件开发模式。

南非标准银行是怎么决定向敏捷软件开发转型的？

Mike Murphy：我们的应用开发和维护（ADM）部门一直采用传统的软件开发模式，包括瀑布模式，但这样的模式速度较慢。我们了解到美国硅谷等先进地区的做法，也和银行同业甚至其他行业的高管做过交流。我们希望自己的性能和成本也能达到类似的先进水平。于是，我们详细研究了纯互联网金融公司采用的敏捷软件开发模式，并仔细权衡了利弊，结合自身的特殊需求，对行业的最佳做法进行了适当调整。我们一开始主要采取敏捷开发模式来开发移动应用软件和网络银行软件，因为业务部门对此特别感兴趣。而现在，我们的IT 部门已把敏捷开发模式推广到多数ADM 部门，覆盖了15 个产品管理团队，包括150 名全职员工。我们的目标是到2016 年底，让整个ADM 部门全部采用敏捷开发模式。

标准银行的软件开发流程发生了哪些变化？

Mike Murphy：总体而言，标准银行比以往更加注重协作和同一地点办公。每个产品管理团队都有专职的产品负责人、开发人员和测试人员，而且他们都坐在一起。根据产品需求，任何产品团队都可能一起工作。这样一来，如果新的应用软件需要与现有软件实现兼容，团队成员可以坐在一起，拿出一套同步开发的方案。我们向业务部门和IT 部门的负责人强调这种协同发展和联合解决问题的理念。这样，我们就可以准确掌握业务部门的软件应用或服务功能需求，调动所有部门进行开发工作并有效追踪责任。我们就原型设计安排了多次讨论，这样业务部门和技术部门可以修正各自的想法，一边测试软件，一边不断地明确需求。在开始编写代码之前，我们还会邀请客户参与进来。通过网络论坛和社交媒体互动而非正式的公关部门，我们与客户建立了非正式的关系。如果客户建议增加一项新功能，我们会与其分享设计初稿并征求意见。我们的测试人员也充分参与到产品开发的全过程而非最后阶段，因此他们对软件功能的理解比以前深刻得多。测试人员的工作不仅仅是标注错误，更重要的是寻求新的问题解决方案。现在，我们采用自动化测试手段，加快了以往需要大量人工的流程。

标准银行是如何接受这一新的开发模式的？

Mike Murphy：这正是最大的挑战之一。在标准银行，很多人已经习惯了传统的工作方式，不希望改变惯常的工作流程，把事情做完就万事大吉。我们把敏捷开发模式作为整个ADM 部门工作的重中之重，迫使员工走出自己的惯常套路。我们把产品管理团队召集起来开大会，解释变革背后的逻辑，并设定了明确的提升目标。我们还通过正式的制度设计强化了这些信息，比如把相关团队的成员集中到同一办公地点，以便更好地进行协作。我们给团队自主权，他们有权决定日常工作的开展方式，但我们同时要求他们定期开会，让所有人了解项目的最新进展，为每个敏捷迭代设定开发周期要求，并定期进行项目回顾，以讨论下一个敏捷迭代时团队可以有哪些不同的改进。员工们普遍认可了这种相对松散和灵活的工作机制。

标准银行的人才管理工作发生了哪些变化？

Mike Murphy：成本压力确实制约了我们可以招聘的岗位类型和员工数量。因此，我们把重点放在培养现有员工的敏捷开发技术和工作原则上。我们采用“传帮带”的方式，即参加培训、研讨会或实地访问了美国硅谷公司的员工，要把学到的知识和心得正式传授给团队其他人。每名团队成员都要接受连续数天的敏捷软件开发培训，我们还配备了专职的敏捷开发技能教练，不断深入产品部门传授技能，进行经验回顾，并就团队如何改进做法提出建议。最重要的是，我们在应用软件开发部门内部设立了多个与开发质量有直接利益关系的团队或者团体，比如iOS 团队、云技术团队等，他们每两周左右集合一次，以鼓励知识交流。这种制度对于确保跨团队和跨职能沟通十分有益。

所有这些变革落地时的效果如何？

Mike Murphy：业务部门和IT 部门之间的互动方式发生了重大变化。例如：在向敏捷开发模式转型之前，我们用了2500 页文档来对所开发的一个桌面应用进行解释。许多页的需求信息都是重复的，即便如此，仍然有很多开发人员难以理解其效果应该是怎样的。而现在开发桌面应用时，我们会参考IT 部门、业务部门、用户界面专家和终端用户共同开发的一些经典案例。业务部门感到更有掌控力，IT 部门也不再像以往那样被动地执行。事实上在这种模式下，IT 部门也感到获得了更多的授权。团队可以每个月开发新的在线功能，并且由于系统早就考虑了客户的反馈意见，返工量也随之大幅下降。在采用敏捷开发模式前，标准银行的开发人员可能会在一款新应用中发现上千个缺陷，测试故障率高达38%；而在实现敏捷开发模式后，软件缺陷降到100 个左右，测试故障率则大幅降至3%。开发流程的总体效率大大提高了，部门内部和部门之间也有了更多的信任。以前，有的基本的测试可能需要运行两次，第一次由开发人员进行，再加上把关复核的二次测试；而现在，测试人员可以立即接受开发人员的测试结果，接着进行后续更为复杂的测试。

在推行这些变革的过程中你们面临哪些挑战，又是如何应对的？

Mike Murphy：我无法过分强调打破部门隔阂和迫使员工走出既有模式的重要性和挑战，特别是对银行这类成熟行业中的成熟机构而言。想要采取敏捷开发模式是一回事，获得业务部门的高度认可完全是另外一回事。我们在早先有过教训。由于相关业务部门的负责人对需要从日常IT 运营和支持工作中抽调时间和资源感到不适应，我们曾经不得不中断了最初的一批开发转型试点项目。

从理论上来说，业务部门的负责人能够理解敏捷开发模式的潜在效益。但当我们向转型迈出第一步时，他们才意识到转型的牵涉面有多大，于是不愿意为创新牺牲稳定性。

我们明白，业务部门需要很快就能看到实实在在的效益。为了使各部门之间形成共识，我们创建了新的沟通渠道—— 内部通讯、网页、定期全体大会等，以展示在敏捷产品开发和交付模式下已经取得的成功和面临的挑战。这样的沟通鼓舞了团队的士气，维持了变革的积极氛围。现在，我们的各业务部门都有了支持敏捷开发模式的“骨干人员”。同时，我们对行业活动的参与也有助于团队成员理解标准银行与同业相比在数字化转型中取得的进展。事实上在很多方面我们都遥遥领先，这一现状也十分鼓舞人心。

其他公司可以从标准银行的成功转型中吸取哪些经验？

Mike Murphy：我们的第一批试点就产生了显著的效益—— 劳动生产力率提高了50%，单位成本下降了70%。但是不可否认，我们仍然处于转型的初期，面临着诸多挑战：如何把敏捷开发模式拓展到ADM 部门之外、如何保证我们的IT 架构、基础设施和运营模式紧跟数字化发展的最新动态，这都需要思想观念和组织规划的重大转变。比如，如何把八十多人的技术团队拆分成多个关注特定应用功能或客户体验的子团队，以及如何从业务部门选择专职的产品负责人。考虑到不同团队选择的工作方式不同，我们正在学习如何在尊重各团队自主性和接受不同产品团队质量差异之间进行权衡。在所有的变革领域，我们也面临着长期的挑战—— 如何把变革坚持到底。

对我们而言，或者说对任何向敏捷开发模式转型的公司而言，最重要的事情就是牢记转型绝不应该仅仅着眼于降低成本。转型关乎优化企业的运作方式，以及为客户提供最优质的服务—— 无论他们选择何种渠道与我们进行沟通和互动。