金融集团|业务部门和技术部门，究竟应该如何协作？( 二 ) 资源位|部门|各部门|app|产品

1. 打破部门壁垒，效率更高技术和业务两个部门，难免会出现将部门利益凌驾于公司利益之上的选择。
举个例子，业务部门年底冲一把业绩，提一些上线只用一两周次的临时需求，或者需求明明没想清楚，但就是要提。
原因很简单，技术资源是公司公共资源，我不抢就被别的部门抢了，我抢到了，不管上了之后到底怎么样，总比什么都不做强吧。
于是就给技术部门非常多的压力以达到自己的目的。
再举个例子，技术部门不甘心做乙方，肯定会想方设法包装自己。
业务部门的需求可能通过现有的平台，简简单单就完成了，但是技术部门不会这么想，技术部门一看自己年度工作没什么亮点，就要把一个小小的需求，以各种奇奇怪怪的名称打造新的所谓一站式解决方案，美其名曰，为了长远业务发展。
事实上，谁都知道，肉眼可见的未来业务没办法达到技术预估的量，那些所谓的场景根本碰不到。
平时公司肯定会从需求评审、后评估机制来解决这种问题，但治标不治本，除了增加一大堆莫名其妙的制度，别的一点用都没有。
说到底，有的项目是立竿见影，有些东西没办法很快看到成果，僵化的制度就有点刻舟求剑，没什么用。
但随着业务技术一体化，就能从更高的层次，解决这些问题。
打绩效的老总是同一个人，大家都是一个方向，各自的小算盘也该收一收了，很多没意义的事情也就没必要折腾了。
2. 数据能力将成为业务的核心生产力长期的融合最明显的好处就是，技术人员懂业务痛点，业务人员懂技术流程，技术开发过程中，很清楚业务的目的、方向，中间不需要反复确认、了解，而业务人员也不会提出超出技术能力范围的无理需求。
数据和业务的融合，更关键的是，给传统的业务运行模式中，将数据长在业务部门内部，这样，技术就再也不是乙方，也不是费用部门。
我们常常说，数据是新时代的石油，只有和业务紧密的结合的数据才是真正的生产要素，才能驱动业务。
业务技术一体化在我看来是解决这个问题最好的办法，类似“支部建在连上”这一伟大创举。
04最后简单聊聊业务技术一体化可能存在的问题。
我们要清楚地明白，在解决一个复杂问题的过程中，是不可能有一个方案解决所有问题的，业务技术一体化是有优势的，但肯定不会完全没有缺点。
回想下我公司A那种建设模式的问题，职能部门各司其职，没办法起到1+1>2的效果。
业务技术一体化什么后果？
自己的事情自己都能搞定，那不是部门壁垒更深了吗？
在技术上的体现就是重复建设。业务和技术都是一个部门了，很容易自产自销，既不愿意有求于别人，也不愿意把自己的分享出去，大家各扫门前雪，烟囱林立。
这又是另一个话题，如何沉淀各个条线通用能力，也就是这几年很火的中台概念，中台的出现，就是各个部门烟囱太高，壁垒太深，必须把通用的能力沉淀下来，再赋能前端。
当然了，中台说到底也不是万能的，中台的价值如何评估？中台过重，如何灵活支持前端业务的开展，等等。
问题就是这样一环扣这一环，所以很多事情只有开始，没有终点，只有不断摸索前进。
今天就这里了，希望对大家有所启发。
本文由 @一丁原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议