近些年，随着组织对敏捷的追求，许多银行IT部门开始尝试产品化，希望利用产品研发的方式，提升内部效率，结果是：玩不转！因而本文将剖析其中的问题，供内部决策者参考。

敏捷产品化一到银行及各种金融机构，各种问题就粗来了：

有PMO小伙伴问：加兴老师，你觉得敏捷真的适合银行吗？

有开发组长在培训课堂上问：我们的系统就只有一两个业务人员用，它也适合做用户画像和产品化吗？

有资深一点的部门经理开始质疑：我们银行的产品在业务，比如说XX贷，说白了，银行的产品就是钱，我们开发部门的产品，就那么几个，网银算一个，App也算一个，我们的系统都是为这些产品服务的。

这话说得很对！

一、手段不是目的，没效率就解决效率

首先来看一下咨询公司敏捷产品化方法论的来源：互联网产品的迭代式开发模式。

这意味着，首先，它得是一个产品，其次，才谈得上用什么方法论来优化开发效率。

于是又有了一些不甘就如此的思想者，苦苦思索，在IT内部寻找“产品”，解决“是一个产品”的问题，拿了手段，忘了目的。然后完全忘了要提升效率这档子事。

在这里我要大喊一声：手段不是目的！没效率就要解决没效率的问题！手段用错，更没效率！

有一些小伙伴就很清醒，我们问：DevOps的行业标准，你们怎么看，达到了几级？

对方回答说：那个标准的高级别，其实是参考互联网公司，不适合我们。

基础级别，可以作为一些通用方法、技术趋势，借鉴一下。越到高级别，由于行业不同、经营运作的本质都不一样，可借鉴和可操作性就越差。

回到前面的一系列问题，产品研发的本质，就是前期高投入，后期规模化销售获得边际收益。

首先，这个系统在商业模式上就是scale得通的，有海量用户在使用它，而不是我们拿人家产品的研发方式，去解决我们只有一两个人用的系统怎么去scale的问题。

产品研发的过程，是高度集成的，过程紧凑、资源集中、决策延迟、减少质量损失。因为这些部分处理不好，就会给上市时间、上市产品质量、客户满意度带来巨大损失。报废一件实验室试验品/生产线上几百个零件 vs. 召回几千几万件已销售产品，哪个损失大？

所以，丰田可以在生产线上出现未解决问题时，任何一个人可以拉动警示铃，让全员停下来解决。而这些到了客户的真实现场，客户只问一句：谁敢在项目有障碍时停下来？一屋子人，没一个人敢说“停下来”。

因为非产品场景下，不停下来，没有几千几万个成品损失，停下来，延误的是几十个关联项目的工期！这种链锁效应谁能承担？

单个缺陷往后渗透，确实会影响波及数个项目的质量，但具体问题具体解决，缺陷是如何引起的？业务缺陷？设计缺陷？编码缺陷？

软件开发内部，接近3/4的效率问题，都是技术、业务性问题，而不是方法论问题。

我随便讲个真实的故事：

Think big：你欠缺业务知识，依赖业务人员。你的“产品化”业务接口人也不那么懂业务，他要问他的业务领导。业务领导太忙了，没空管你这档子事，然后，你的产品Backlog都梳理不完整。怎么Think BIG？

Start small：你没有分析能力，找不到重点，挖掘不到问题背后的原因。然后，到处都是“高优先级”，拖延了人家业务部门正常的项目流程，态度恭敬地回复你：你的方法好复杂哦。怎么Start SMALL？

Move fast：写不出高质量代码……重编码轻测试的软件架构……搞不来自动化测试……缺乏测试有效性……一群人累死了都……还在这里干“快速研发模式”……

因而，不能简单地通过方法论来解决效率问题。你的手段，不能偏离你的目的。

二、强化业务技术能力，你才有效率

我们在组织展开一线调研，大量的团队反馈的关键词就是：业务不熟。

有的说，我们这里新人太多了，业务不熟，所以开发进展很慢。

有的说，一个问题，我们需要业务人员给我们解释、澄清，我们才能确定技术上有没有问题，所以解决问题的过程特别长。

有的说，我们这里人员流动率太高了，不懂我们的业务，所以做得很慢。有的说，一直忙着做项目，业务知识没有沉淀，新人来了不知道该问谁，没有文档，看代码，代码太多，简单的工作也帮不上忙，一个系统谁做的就一直做下去，其它人也做不了，最后这个人走了，其它人遇到新的功能就只能再做一遍，代码看不懂，维护不了。

还有的说，我们这里测试换了一拔又一拔，每次交接版本，都要开发人员给测试讲一遍业务，因为业务理解不深，测试经常啥问题也测不出来。

还有的公司的开发，由于不懂客户的业务又不敢问，经常自我沉思到半夜，四处求助。

业务型系统关键的效率影响因素是什么呢？就是业务知识。换句话说，这个领域的“熟练工”，就是最有效率的。

“因为你是这方面的专家所以可以做这个产品”，竟然成了一种稀缺。可见这个世界有多荒唐。不专业，也能做产品，这才该是大家懂得起的道理。