金融企业转型的三个挑战

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

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

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

需求分析过程非常长，常常是好几个月

需求池（产品待办事项列表）常常处于干枯状态，或者是井喷填满

开发和测试团队抱怨时间不够

开发过程中大量需求变更带来很多浪费

发布时间一拖再拖

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

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

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

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

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

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

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

超负荷

流动性差

交付慢

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

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

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

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

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

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

安全性要求极高：国家各种法律法规对于金融系统安全性有严格要求；

稳定性要求极高：必须保证7X24X365的可用性;

需求变更频率不高：比如银行中的存款、清算、结算等核心IT系统；

受限于以上要求，功能常常是集中交付，而非迭代交付。