业务与系统的傲慢与偏见

在 IT 行业随波逐流了多年以后，我发现了一个共性的问题，那就是无论是在传统行业还是互联网行业，无论是做那种业务的公司，那么对于做业务的人和做系统研发的人来说，他们之间就会存在巨大的鸿沟，有的时候大到难以互相理解。因为本人现在在金融科技领域，所以试图从这个行业来进行解释。

对于业务人员，常见疑问：

1. 需要这么长时间的开发？我需要一个月之后上线，给你加人行不行？
2. 业务系统都已经在线上运行了，为什么还需要投入研发？
3. 为什么有些大到不可思议的改动很快就可以实现，而有些很小的改动却需要很长时间？
4. “系统什么都能做”到底是不是忽悠？

对于开发人员，常见疑问：

1. 为什么需求老是变化？
2. 为什么不找到一个最好的产品 / 模式，这样系统只用开发一次就行？
3. 为什么系统优化这么重要的事情，都没有人关注？

这种鸿沟无论是从认知层面还是从沟通层面都有体现，以至于他们之间的矛盾长期不可调和，那么这到底是怎么回事呢，又是怎么解决呢？且看下图：

这个图中蓝色的线表示需求的数量，绿色的线表示 IT 产出量，它描述了一个核心的矛盾，那就是业务诉求的变化剧烈程度远远超过 IT 产出能力的变化程度。而 IT 产出能力的提升有其自身的变化规律，可以描述为：

1、在短期内，IT 产出能力无法大幅提升，也就是说它有个“上限”。

IT 类型的工作有一个特点，那就是短期之内不容易被替换，这种特点可以用另外一种工作来类比，那就是绘画。对于一副画到一半的半成品，如果换一个人来继续画，那么要么就是画出来的画严重偏离了原作者的意图，要么就是需要比原作者更长的时间来完成。研发类的工作有类似的规律，一个设计都是有很多的意图或者潜在的设计思路在其中的，换了一个人很难快速以及完整的理解这些意图和思路，以至于时间反而会花的更加长。

还可以引用另外一个段子，说一个女人花九个月就可以生一个孩子，那么加大人力投入，九个女人是不是能够在一个月就生出一个孩子？这种荒谬的想法却被换了一种形式在 IT 行业经常发生，例如常见的人月算法，一项 1 个人月的事情，是否可以用 5 个人在 6 天完成？很遗憾的是大部分情况是不行的，因为可以这样计算的前提是系统的细分模块互相之间关联度很小，可以“并行开发”，但是细分到一定层次就不能再细分了，就像怀孕只能由一个女人来完成一样，这个事情不能接力了。短期之内加人的结果就是投入产出严重不成正比，整体上影响其他项目的进度。

2、IT 产出能力也有一个“下限”，即使没有业务需求，研发也需要持续投入。

这是怎么回事呢？IT 系统的这个特征也可以用另外一个东西来类比，那就是汽车。汽车买完了之后不是说就可以一直开下去，它每年是要进行维护的，换个机油，换个滤芯，喷个漆打个蜡什么的，只不过 IT 系统的维护需要更加频繁。常见的情况有：

• 依赖的第三方系统升级
• 配合安全部门、合规部门、数据统计部门、财务部门进行系统、数据改造
• 现有系统组件被检测出安全漏洞
• 基础网络设施变化
• 数据量累积定期迁移
• 系统在大促期间的扩容和缩容
• 升级的客诉工单的处理

而通常这些变化和业务本身并没有直接关系，但是又不能不投入，用一句俗话来说，管生不管养是不行的，对于 C 端的业务来说，一个业务系统一旦上线并正常开展了业务，那么把业务和系统下掉就是一个漫长的过程，而无论它上面的业务是否发展的很好。当业务发展不好的系统越来越多的时候 IT 能力将会严重受制于这个“下限”，可以说是积重难返，应对业务变化的能力越来越小，速度越来越慢，整体效率越来越低。

这些特征应该可以解答上面提到的一些问题。对于系统改动大小的问题，对于业务人员来说一般难以辨别什么改动算是大的改动，什么改动算是小的改动，因为有时候觉得很难的不可思议的改动居然很快就改了，而一些看起来很小的改动却被告知需要很长时间，这个问题其实也可以用盖房子进行类比，开始的诉求是一个人居住，所以盖了一间平房，然而过了五年因为人丁兴旺，需要盖一个楼房，但是平房的地基不深，无法承载一个楼房的重量，必须重新从打地基开始建起。对于不懂建筑的人来说，很难判断什么情况需要重新打地基，什么情况不需要，就像不了解系统的人看系统一样，很难判断什么是巨大的改动，什么是很小的改动。

而对于 IT 系统能力的问题，可以说，IT 系统的能力非常强大。从大的时间跨度来讲，信息技术已经对人类生活产生了翻天覆地的变化，而且这种变化还在无时无刻的进行之中；从小的范围来讲，余额宝这些宝宝类产品已经把人们的消费理财观念和习惯提升了一个档次；从一个公司的业务的角度来讲，IT 能力还有巨大的潜力可以挖掘。这通常会给人一种错觉，认为技术什么都能实现，那么真的是这样的吗？其实不然，可以分两个层面来说：

• 原理上无法实现的东西不能实现。例如开发一个可以准确预测股市走向的系统，一个可以在短时间内破解高强度加密信息的系统。
• 原理上能实现的都能实现，但是通常会有人力物力财力的投入作为前提条件。然而业务人员一般只是喜欢听肯定的结论，忽视或者不愿意提起隐含的前提，使得实际操作上来说不可实现。即使强行推进，也会很容易陷入无休无止的成本泥潭，进入一种进退两难的境况，同时也错失了业务发展的良好时机。

所以，“技术什么都能实现”要么是业务人员的一厢情愿，要么是技术人员刚拿完奖金的酒后豪言壮语，再要么是一个无知少年对技术的盲目崇拜。

反过来看，对于技术人员来说，业务也是难以理解的，最大的问题恐怕就是：

需求为什么老是变化？

今天提的需求，过两个星期就变了，旧的项目刚做完又要开始新的模式的新项目…为什么不能稳定呢？解释这个问题其实也是很简单，因为业务系统是人们真实的生产生活的映射，交易类系统是人们现实交易在计算机上的一种表示，所以系统的复杂性来源于业务的复杂性，业务复杂系统就复杂，业务简单系统就简单，业务变化快系统就变化快，业务变化慢系统就变化慢。

对于互联网金融交易系统来说，业务系统复杂性取决于金融业务的复杂性，其他行业也适用于这个结论。举个例子，资管机构在控制资金端流动性风险的时候，通常会采用很多控制策略，例如每个月固定时间开放一天（月固定定开）、每个月开放一天（月开）、每个月相对某天开放（月对开）、每日开放、每周开放等，对于研发人员来说眼花缭乱毫无头绪，系统设计的模式根本赶不上变化，隔三差五需要修改，但是对于业务人员来说，都很简单啊，控制流动性嘛。所以对业务本质理解的深入程度直接决定了对系统进行架构的优良程度。

另外一个问题，为什么不能找到一个收益最高的产品，一直卖就好了？就像华为苹果小米的手机，长期卖的很好，为什么不能采用这样的模式呢，系统也可以少开发几套？这个问题其实也是好解释，那就是实物商品的好坏很好判断，但是金融产品的好坏是很难判断的，而且实物商品品质很稳定，但是金融产品的“品质”却很不稳定。所以无法找到一个“好”的金融产品并且一直卖下去。

还有，研发人员会对系统优化有持续的热情，但是对系统优化的强调却基本得不到业务人员的认同，这是为什么？很简单，角度不一样，业务关注的是交易的交易量，收入，业务的利润等，系统优化是什么，具体能够对业务指标提升多少呢？如果无法明确，那么还是算了吧。那么这种说法到底有没有道理呢，其实是不矛盾的，业务人员关注的是短期目标，研发人员关注的是长期目标，只是通常需要在这些目标之间进行权衡。系统优化对业务的提升通常是缓慢温和的，但是长期来讲是巨大和根本的，行业领先的金融机构例如招商银行，二十年来一直在系统方面大力投入，积累起来的综合实力已经使其远远领先于其他金融机构，并且竞争壁垒极高，难以复制。

综上所述，业务人员和研发人员的分歧往往来源于自己的认知领域的不同，对于同一件事情在不同的角度观察的不同，对于短期目标和长期目标的认知不同。但是 IT 产出能力与业务需求的变化之间的矛盾却是一个长期和固有的矛盾，这个矛盾恐怕不能消除，但是可以不断的缓解：

1 提升 IT 产能

通过多种方式可以将 IT 提升业务的“上限”持续提升，例如：

• 增加人员 。当然远水不解近渴，加人可以在中长期提升产能，但是短期不能。
• 增加时间 。对于大部分互联网公司来说，这点上面已经做得“很好了”，但是这种方式最严重的问题就是不可持续，而且有天花板，就是到了一定程度再怎么增加时间也不能继续提升产能。
• 优化流程 。同样几件事情，如果换一种方式做就会更加高效，举个例子，研发和测试的边界点，在目前的实践中普遍采用了研发面对面交付测试的模式，虽然对研发带来更多的工作量，但是整体效率却提升了。
• 优化架构 。同样一个目标，如果换一种实现方式或者思路，就能更快更好的完成，例如非业务功能尽量中台化，可以称之为“拿来主义”，使用第三方提供的公用平台可以加快系统建设速度。
• 需求排序和分期 。在短期产能无法快速提升以及架构无法短期优化的情况之下，怎么缓解需求矛盾呢，这个时候就需要仔细评估需求的投入产出比，或者依据项目的重要程度进行一定的排序了，实际情况是每个项目都很重要，每个项目都很紧急，但是再紧急也需要排序，从中找到当下最需要做的事情，这个当然是需要业务人员和研发人员密切配合才能进行。

2 降低系统维护难度

其实是降低 IT 产能的“下限”，使得最低投入越来越小，例如：

• 业务下线 。通常一个业务上线了之后会运行很长的时间，出于合法合规的要求，一般的业务一旦有了存量，那么除非用户主动同意，否则是无法对用户进行清仓的，从而导致即使业务发展较差甚至亏损也不能将业务下线。这个情况直接导致各种各样的系统一直存续，按照上面的分析，IT 能力的下限将会变得很高，也就是固定投入将会是长期和持续的，所以需要把业务下线也作为一个重要的事项来推进，简单来说，业务人员不能只是关注上线一个又一个的业务，也需要关注下线一个又一个的业务。下线的过程仍然是需要业务、运营、系统研发各方的密切配合，其结果将有效降低固定 IT 投入，同时还能提升 IT 能力上限。
• 系统优化 。俗话说，磨刀不误砍柴工，系统优化和升级是个长期和不断需要进行的事项，因为它会长期和有效的提升 IT 产能，这个是业务人员通常会忽视的事情。拿跑步来说，穿一双不太舒服的鞋子一样能够跑，那么是否需要换一双好点的鞋子？这个问题，通常在短期很难看到效果，长期来讲会得到很好的收益，但是业务人员通常迫于眼前的压力，会选择不是很好的方案，并在压力解除的时候也不会主动推动系统优化。

简单来说，业务人员和技术人员需要真正深入的互相理解和互相配合才能解决效率问题，因为从业务盈利的目标上来讲，两者是密不可分的。

本文转载自公众号京东数科技术说（ID：JDDTechTalk）。

原文链接：

https://mp.weixin.qq.com/s/M76sUGmbMhc6whnh7dWyZQ