编辑导语：工作中，难免遇到业务和技术冲突的情况。遇到这种情况，项目应该如何进行呢？笔者用自己前东家的两种模式举例，分析了业务技术一体化可能存在的问题和适用模式。有相关困惑的小伙伴不妨来看看，说不定方法也适合你。

老读者应该都读过我半年前写过的一篇文章，风险和市场打架了怎么办，讨论的是有利益冲突的职能部门的协作方式。

其实，当时我还对另一个问题非常感兴趣，业务部门和技术部门，这组关系究竟应该如何协作。

市场和风险的关键点是利益冲突，而业务和技术的关键点是专业门槛高，但又互相依赖。

之所以对这个话题感兴趣，主要是我的前两个老东家正好选择了两种不同的模式，非常有意思，可以和大家聊一聊。

01

前东家A，大型金融集团，他们对技术部门的定位就是：乙方。

开发流程非常规范，从提需求，到评审、排期、开发、交付，完全按照节奏来，部门领导聚在一起，一个季度开一次会，大家在一起排需求，排完定稿，想要中途插队，对不起，得通过总经理室批准。

这种模式的好处就是规范、严谨，因为排期长，逼迫业务想清楚再提需求，一定程度上也挡掉了很多拍脑袋的需求。

缺点就是周期长、不灵活，很多时候系统开发完成，可能项目已经黄了，已经结束了。

这种模式面对简单的业务模式没什么问题，比如只要搞清楚人工是怎么做的，程序按照人工的方式做出来就行了。

但是到了数据驱动的阶段，面对那些需求并不明确的、需要探索和创新的领域，就步履维艰了。

• 比如产品的定价究竟定多少？
• 线上流程怎么设计？
• 哪一步跳出率高哪一步跳出率低？
• 哪些人会跳出而哪些人会坚持到底。

这些需要深度洞察客户需要大量数据驱动，需要业务和技术融合。

公司A做不到，作为内部员工，最大的体会就是，业务条线没有数据能力，没办法真正了解用户；技术条线有数据，但对业务不了解，不知道有什么用。

简而言之，A公司的模式就是业务提需求，技术做交付。

02

前东家B，区域领先的金融集团，采用项目制模式，他们对技术的定位就不同了，技术部门时不时会牵头做一些项目，也就是科技引领，技术主导，业务支持。

为什么会形成这样的工作模式，根本原因就是大领导希望有一些外部变量能够对业务推进起到鲶鱼效应，而技术领导正好又比较积极。

这种模式的好处就是快速响应，高层牵头，很多事情当场拍板就能做了，效率很高。技术人员能从技术角度提出创新的想法，再也不是乙方了，翻身做主人了。

但这种模式的缺点也很明显，主要有两个：

1. 项目制重建设，轻运营

其实很好理解，新建系统可以向上汇报，运营一个系统哪有新建一个系统让人感到血脉喷张呢？

项目制模式运行久了，作为内部员工，就会发现洋洋洒洒建一大堆的系统，要么没什么用，没业务在上面跑，要么明明可以一个系统搞定的问题，偏偏搞多个系统维护，费时费力。

2. 屁股方向不一致

项目制除了技术上的问题外，更大的问题在于主导权的争夺，项目到底谁主导，听谁的，说不清楚。

我曾经有幸参与过类似项目，一开始我很迷茫，这么多老总的要求各不相同，有的总喜欢看表格，什么图都不要，而有的老总就是要看折线图、饼图，怎么办？

但时间长了，我发现，其实直属领导才是王道，业务部门领导的意见只能是参考，直属领导的意见是命令。

原因很简单，直属领导给我打绩效啊，业务部门不咸不淡的表扬又有什么用呢？

我这么想，业务部门同事自然也明白这其中的弯弯绕，随着项目的推进，每次开会，渐渐出现了业务谈业务的，技术谈技术的，大家鸡同鸭讲。

没办法，大家的屁股没动，自然说不到一块去。

两种模式各有弊端，而且还都不小，那究竟技术和业务之间应该怎么协作？

03

最近在听华为数据转型课程的时候，受到一定启发。

华为提出了业务IT一体化模式，就是把技术能力建在业务上，由业务主管担任责任人，业务人员和技术人员一起成立数字化团队，技术人员不再是单独的一个部门，而是成为具体业务部门的一部分，形成长期固定的组织形式。

我一听，就感觉非常有意思，这种模式有两个非常明显的好处：

1. 打破部门壁垒，效率更高

技术和业务两个部门，难免会出现将部门利益凌驾于公司利益之上的选择。

举个例子，业务部门年底冲一把业绩，提一些上线只用一两周次的临时需求，或者需求明明没想清楚，但就是要提。

原因很简单，技术资源是公司公共资源，我不抢就被别的部门抢了，我抢到了，不管上了之后到底怎么样，总比什么都不做强吧。

于是就给技术部门非常多的压力以达到自己的目的。

再举个例子，技术部门不甘心做乙方，肯定会想方设法包装自己。

业务部门的需求可能通过现有的平台，简简单单就完成了，但是技术部门不会这么想，技术部门一看自己年度工作没什么亮点，就要把一个小小的需求，以各种奇奇怪怪的名称打造新的所谓一站式解决方案，美其名曰，为了长远业务发展。

事实上，谁都知道，肉眼可见的未来业务没办法达到技术预估的量，那些所谓的场景根本碰不到。

平时公司肯定会从需求评审、后评估机制来解决这种问题，但治标不治本，除了增加一大堆莫名其妙的制度，别的一点用都没有。

说到底，有的项目是立竿见影，有些东西没办法很快看到成果，僵化的制度就有点刻舟求剑，没什么用。

但随着业务技术一体化，就能从更高的层次，解决这些问题。

打绩效的老总是同一个人，大家都是一个方向，各自的小算盘也该收一收了，很多没意义的事情也就没必要折腾了。

2. 数据能力将成为业务的核心生产力

长期的融合最明显的好处就是，技术人员懂业务痛点，业务人员懂技术流程，技术开发过程中，很清楚业务的目的、方向，中间不需要反复确认、了解，而业务人员也不会提出超出技术能力范围的无理需求。

数据和业务的融合，更关键的是，给传统的业务运行模式中，将数据长在业务部门内部，这样，技术就再也不是乙方，也不是费用部门。

我们常常说，数据是新时代的石油，只有和业务紧密的结合的数据才是真正的生产要素，才能驱动业务。

业务技术一体化在我看来是解决这个问题最好的办法，类似“支部建在连上”这一伟大创举。

04

最后简单聊聊业务技术一体化可能存在的问题。

我们要清楚地明白，在解决一个复杂问题的过程中，是不可能有一个方案解决所有问题的，业务技术一体化是有优势的，但肯定不会完全没有缺点。

回想下我公司A那种建设模式的问题，职能部门各司其职，没办法起到1+1>2的效果。

业务技术一体化什么后果？

自己的事情自己都能搞定，那不是部门壁垒更深了吗？

在技术上的体现就是重复建设。业务和技术都是一个部门了，很容易自产自销，既不愿意有求于别人，也不愿意把自己的分享出去，大家各扫门前雪，烟囱林立。

这又是另一个话题，如何沉淀各个条线通用能力，也就是这几年很火的中台概念，中台的出现，就是各个部门烟囱太高，壁垒太深，必须把通用的能力沉淀下来，再赋能前端。

当然了，中台说到底也不是万能的，中台的价值如何评估？中台过重，如何灵活支持前端业务的开展，等等。

问题就是这样一环扣这一环，所以很多事情只有开始，没有终点，只有不断摸索前进。

今天就分享到这里了，希望对大家有所启发。

本文由 @一丁 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议