编辑导语：在工作中，难免会遇到业务和技术上的冲突。在这种情况下，项目应该如何进行？作者以前雇主的两个模型为例，分析了商业技术集成可能存在的问题和适用的模型。有困惑的朋友不妨看看，也许方法也适合你。
老读者应该看过我半年前写的一篇文章，风险和市场打起来怎么办，讨论有利益冲突的职能部门合作模式。
其实当时我对另一个问题很感兴趣，就是业务部门和技术部门应该如何配合。
而市场风险的关键点是利益冲突，而业务和技术的关键点是专业门槛高，但它们是相互依存的。
之所以对这个话题感兴趣，是因为我以前的两个前雇主只是选择了两种不同的模式，非常有意思，可以和大家聊聊。
# 01
前业主A，大型金融集团，他们对技术部的定位是：乙方
开发过程非常规范，从需求提出到审核、调度、开发、交付，都按照节奏进行。部门领导每季度开一次会。大家一起整理需求，完成最终稿。如果你想中途插队，对不起，你必须得到总经理办公室的批准。
这种模式的优点是规范严谨。由于时间表很长，这迫使企业思考清楚，然后提出需求。在一定程度上也阻挡了很多拍脑袋的需求。
缺点是周期长，不灵活。在许多情况下，当系统开发完成时，项目可能已经变黄并结束。
面对简单的商业模式，这种模式没有问题。比如，只要我们知道如何手工做，程序就可以手工完成。
但到了数据驱动阶段，将很难面对那些需求不明确、需要探索创新的领域。
*例如，产品的价格是多少？
*如何设计在线流程？
*哪个步骤的跳出率高，哪个步骤的跳出率低？
*谁会跳出来，谁会坚持下去。
这些需要深度洞察的客户需要大量的数据驱动、业务和技术集成。
A公司做不到。作为内部员工，最大的体验就是业务线没有数据能力，无法真正理解用户。技术线有数据，但不了解业务，不知道有什么用。
简而言之，A公司的模式是业务提需求，技术做交付.
# 02
原业主B是区域领先的金融集团，采用的是项目化模式，他们对技术的定位不同。技术部不时会牵头做一些项目，就是技术引领、技术引领、业务支撑。
这种工作模式的根本原因是大领导希望一些外部变量能对业务提升起到鲶鱼效应，而技术型领导只是更积极而已。
这种模式的优势是反应快，领导水平高，很多事情都可以在现场高效完成。技术人员可以从技术角度提出创新的想法。他们不再是乙方，而是翻身做主人。
但是，这种模式的缺点也很明显，主要有两个：
## 1\.项目体系重建设，轻运营。
其实很容易理解。新系统可以向上报告。一个新系统在运行一个系统的时候怎么会让人觉得血腥？
项目模式已经运行了很长时间，作为内部员工，你会发现构建很多系统是没有用的，也没有业务在上面运行，或者在明确一个系统可以解决的情况下，维护多个系统是费时费力的。
## 2\.对接方向不一致。
除了技术问题，项目体系更大的问题在于对主导权的争夺。目前还不清楚谁将领导这个项目，谁将听取它的意见。
我曾经有幸参与过类似的项目。起初，我很困惑。所以很多老板有不同的要求。有些人总是喜欢看表格，不想要任何图片，而有些人只想看折线图和饼图。我该怎么办？
但是时间长了我发现，其实直接领导才是王道，业务部门领导的意见只能作为参考，而直接领导的意见就是命令。
原因很简单。T
我是这么想的，业务部门的同事自然明白其中的波折。随着项目的推进，每次会议，业务谈业务，技术谈技术，大家都如鱼得水。
没办法，大家的屁股都没动，所以自然就不能一起去了。
两种模式都有各自的缺点，而且都不小。那么技术和商业应该如何合作呢？
## 03
最近听了华为的数据转型课程，很有启发。
华为提出了业务IT一体化模式，就是把技术能力建在业务上，由业务主管担任责任人，业务人员和技术人员一起成立数字化团队，技术人员不再是单独的一个部门，而是成为具体业务部门的一部分，形成长期固定的组织形式
一听就觉得很有意思。这种模式有两个明显的优势：
## 1\.打破部门壁垒，提高效率。
而技术和业务部门，难免会将部门的利益凌驾于公司的利益之上。
比如年底业务部门赶去演出，提了一些只需要一两个星期就能上线的临时需求，或者需求没有想清楚，只是需要提一下。
原因很简单。技术资源是公司的公共资源。如果我不抢他们，我会被其他部门抢走。我抓住了他们。不管我得到它们后会发生什么，总比没有好。
于是就给技术部门非常多的压力以达到自己的目的。
再举个例子，技术部门不甘心做乙方，肯定会想方设法包装自己。
业务部门的需求可能通过现有的平台，简简单单就完成了，但是技术部门不会这么想，技术部门一看自己年度工作没什么亮点，就要把一个小小的需求，以各种奇奇怪怪的名称打造新的所谓一站式解决方案，美其名曰，为了长远业务发展。
事实上，谁都知道，肉眼可见的未来业务没办法达到技术预估的量，那些所谓的场景根本碰不到。
平时公司肯定会从需求评审、后评估机制来解决这种问题，但治标不治本，除了增加一大堆莫名其妙的制度，别的一点用都没有。
说到底，有的项目是立竿见影，有些东西没办法很快看到成果，僵化的制度就有点刻舟求剑，没什么用。
但随着业务技术一体化，就能从更高的层次，解决这些问题。
打绩效的老总是同一个人，大家都是一个方向，各自的小算盘也该收一收了，很多没意义的事情也就没必要折腾了。
## 2\. 数据能力将成为业务的核心生产力
长期的融合最明显的好处就是，技术人员懂业务痛点，业务人员懂技术流程，技术开发过程中，很清楚业务的目的、方向，中间不需要反复确认、了解，而业务人员也不会提出超出技术能力范围的无理需求。
数据和业务的融合，更关键的是，给传统的业务运行模式中，将数据长在业务部门内部，这样，技术就再也不是乙方，也不是费用部门。
我们常常说，数据是新时代的石油，只有和业务紧密的结合的数据才是真正的生产要素，才能驱动业务。
业务技术一体化在我看来是解决这个问题最好的办法，类似“支部建在连上”这一伟大创举。
## 04
最后简单聊聊业务技术一体化可能存在的问题。
我们要清楚地明白，在解决一个复杂问题的过程中，是不可能有一个方案解决所有问题的，业务技术一体化是有优势的，但肯定不会完全没有缺点。
回想下我公司A那种建设模式的问题，职能部门各司其职，没办法起到1+1>2的效果。
业务技术一体化什么后果？
自己的事情自己都能搞定，那不是部门壁垒更深了吗？
在技术上的体现就是重复建设。业务和技术都是一个部门了，很容易自产自销，既不愿意有求于别人，也不愿意把自己的分享出去，大家各扫门前雪，烟囱林立。
这又是另一个话题，如何沉淀各个条线通用能力，也就是这几年很火的中台概念，中台的出现，就是各个部门烟囱太高，壁垒太深，必须把通用的能力沉淀下来，再赋能前端。
当然了，中台说到底也不是万能的，中台的价值如何评估？中台过重，如何灵活支持前端业务的开展，等等。
问题就是这样一环扣这一环，所以 很多事情只有开始，没有终点，只有不断摸索前进。
今天就这里了，希望对大家有所启发。
本文由 @一丁 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
