在IT行业随波逐流了多年以后,我发现了一个共性的问题,那就是无论是在传统行业还是互联网行业,无论是做那种业务的公司,那么对于做业务的人和做系统研发的人来说,他们之间就会存在巨大的鸿沟,有的时候大到难以互相理解。因为本人现在在金融科技领域,所以试图从这个行业来进行解释。
这种鸿沟无论是从认知层面还是从沟通层面都有体现,以至于他们之间的矛盾长期不可调和,那么这到底是怎么回事呢,又是怎么解决呢?且看下图:
这个图中蓝色的线表示需求的数量,绿色的线表示IT产出量,它描述了一个核心的矛盾,那就是业务诉求的变化剧烈程度远远超过IT产出能力的变化程度。而IT产出能力的提升有其自身的变化规律,可以描述为:
1、在短期内,IT产出能力无法大幅提升,也就是说它有个“上限”。
IT类型的工作有一个特点,那就是短期之内不容易被替换,这种特点可以用另外一种工作来类比,那就是绘画。对于一副画到一半的半成品,如果换一个人来继续画,那么要么就是画出来的画严重偏离了原作者的意图,要么就是需要比原作者更长的时间来完成。研发类的工作有类似的规律,一个设计都是有很多的意图或者潜在的设计思路在其中的,换了一个人很难快速以及完整的理解这些意图和思路,以至于时间反而会花的更加长。
还可以引用另外一个段子,说一个女人花九个月就可以生一个孩子,那么加大人力投入,九个女人是不是能够在一个月就生出一个孩子?这种荒谬的想法却被换了一种形式在IT行业经常发生,例如常见的人月算法,一项1个人月的事情,是否可以用5个人在6天完成?很遗憾的是大部分情况是不行的,因为可以这样计算的前提是系统的细分模块互相之间关联度很小,可以“并行开发”,但是细分到一定层次就不能再细分了,就像怀孕只能由一个女人来完成一样,这个事情不能接力了。短期之内加人的结果就是投入产出严重不成正比,整体上影响其他项目的进度。
2、IT产出能力也有一个“下限”,即使没有业务需求,研发也需要持续投入。
这是怎么回事呢?IT系统的这个特征也可以用另外一个东西来类比,那就是汽车。汽车买完了之后不是说就可以一直开下去,它每年是要进行维护的,换个机油,换个滤芯,喷个漆打个蜡什么的,只不过IT系统的维护需要更加频繁。常见的情况有:
而通常这些变化和业务本身并没有直接关系,但是又不能不投入,用一句俗话来说,管生不管养是不行的,对于C端的业务来说,一个业务系统一旦上线并正常开展了业务,那么把业务和系统下掉就是一个漫长的过程,而无论它上面的业务是否发展的很好。当业务发展不好的系统越来越多的时候IT能力将会严重受制于这个“下限”,可以说是积重难返,应对业务变化的能力越来越小,速度越来越慢,整体效率越来越低。
这些特征应该可以解答上面提到的一些问题。对于系统改动大小的问题,对于业务人员来说一般难以辨别什么改动算是大的改动,什么改动算是小的改动,因为有时候觉得很难的不可思议的改动居然很快就改了,而一些看起来很小的改动却被告知需要很长时间,这个问题其实也可以用盖房子进行类比,开始的诉求是一个人居住,所以盖了一间平房,然而过了五年因为人丁兴旺,需要盖一个楼房,但是平房的地基不深,无法承载一个楼房的重量,必须重新从打地基开始建起。对于不懂建筑的人来说,很难判断什么情况需要重新打地基,什么情况不需要,就像不了解系统的人看系统一样,很难判断什么是巨大的改动,什么是很小的改动。
而对于IT系统能力的问题,可以说,IT系统的能力非常强大。从大的时间跨度来讲,信息技术已经对人类生活产生了翻天覆地的变化,而且这种变化还在无时无刻的进行之中;从小的范围来讲,余额宝这些宝宝类产品已经把人们的消费理财观念和习惯提升了一个档次;从一个公司的业务的角度来讲,IT能力还有巨大的潜力可以挖掘。这通常会给人一种错觉,认为技术什么都能实现,那么真的是这样的吗?其实不然,可以分两个层面来说:
所以,“技术什么都能实现”要么是业务人员的一厢情愿,要么是技术人员刚拿完奖金的酒后豪言壮语,再要么是一个无知少年对技术的盲目崇拜。
反过来看,对于技术人员来说,业务也是难以理解的,最大的问题恐怕就是:
需求为什么老是变化?
今天提的需求,过两个星期就变了,旧的项目刚做完又要开始新的模式的新项目…为什么不能稳定呢?解释这个问题其实也是很简单,因为业务系统是人们真实的生产生活的映射,交易类系统是人们现实交易在计算机上的一种表示,所以系统的复杂性来源于业务的复杂性,业务复杂系统就复杂,业务简单系统就简单,业务变化快系统就变化快,业务变化慢系统就变化慢。
对于互联网金融交易系统来说,业务系统复杂性取决于金融业务的复杂性,其他行业也适用于这个结论。举个例子,资管机构在控制资金端流动性风险的时候,通常会采用很多控制策略,例如每个月固定时间开放一天(月固定定开)、每个月开放一天(月开)、每个月相对某天开放(月对开)、每日开放、每周开放等,对于研发人员来说眼花缭乱毫无头绪,系统设计的模式根本赶不上变化,隔三差五需要修改,但是对于业务人员来说,都很简单啊,控制流动性嘛。所以对业务本质理解的深入程度直接决定了对系统进行架构的优良程度。
另外一个问题,为什么不能找到一个收益最高的产品,一直卖就好了?就像华为苹果小米的手机,长期卖的很好,为什么不能采用这样的模式呢,系统也可以少开发几套?这个问题其实也是好解释,那就是实物商品的好坏很好判断,但是金融产品的好坏是很难判断的,而且实物商品品质很稳定,但是金融产品的“品质”却很不稳定。所以无法找到一个“好”的金融产品并且一直卖下去。
还有,研发人员会对系统优化有持续的热情,但是对系统优化的强调却基本得不到业务人员的认同,这是为什么?很简单,角度不一样,业务关注的是交易的交易量,收入,业务的利润等,系统优化是什么,具体能够对业务指标提升多少呢?如果无法明确,那么还是算了吧。那么这种说法到底有没有道理呢,其实是不矛盾的,业务人员关注的是短期目标,研发人员关注的是长期目标,只是通常需要在这些目标之间进行权衡。系统优化对业务的提升通常是缓慢温和的,但是长期来讲是巨大和根本的,行业领先的金融机构例如招商银行,二十年来一直在系统方面大力投入,积累起来的综合实力已经使其远远领先于其他金融机构,并且竞争壁垒极高,难以复制。
综上所述,业务人员和研发人员的分歧往往来源于自己的认知领域的不同,对于同一件事情在不同的角度观察的不同,对于短期目标和长期目标的认知不同。但是IT产出能力与业务需求的变化之间的矛盾却是一个长期和固有的矛盾,这个矛盾恐怕不能消除,但是可以不断的缓解:
通过多种方式可以将IT提升业务的“上限”持续提升,例如:
其实是降低IT产能的“下限”,使得最低投入越来越小,例如:
简单来说,业务人员和技术人员需要真正深入的互相理解和互相配合才能解决效率问题,因为从业务盈利的目标上来讲,两者是密不可分的。
领取专属 10元无门槛券
私享最新 技术干货