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

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

文章插图
老读者应该都读过我半年前写过的一篇文章，风险和市场打架了怎么办，讨论的是有利益冲突的职能部门的协作方式。
其实，当时我还对另一个问题非常感兴趣，业务部门和技术部门，这组关系究竟应该如何协作。
市场和风险的关键点是利益冲突，而业务和技术的关键点是专业门槛高，但又互相依赖。
之所以对这个话题感兴趣，主要是我的前两个老东家正好选择了两种不同的模式，非常有意思，可以和大家聊一聊。
01前东家A，大型金融集团，他们对技术部门的定位就是：乙方。
开发流程非常规范，从提需求，到评审、排期、开发、交付，完全按照节奏来，部门领导聚在一起，一个季度开一次会，大家在一起排需求，排完定稿，想要中途插队，对不起，得通过总经理室批准。
这种模式的好处就是规范、严谨，因为排期长，逼迫业务想清楚再提需求，一定程度上也挡掉了很多拍脑袋的需求。
缺点就是周期长、不灵活，很多时候系统开发完成，可能项目已经黄了，已经结束了。
【 金融集团|业务部门和技术部门，究竟应该如何协作？】这种模式面对简单的业务模式没什么问题，比如只要搞清楚人工是怎么做的，程序按照人工的方式做出来就行了。
但是到了数据驱动的阶段，面对那些需求并不明确的、需要探索和创新的领域，就步履维艰了。

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

这些需要深度洞察客户需要大量数据驱动，需要业务和技术融合。
公司A做不到，作为内部员工，最大的体会就是，业务条线没有数据能力，没办法真正了解用户；技术条线有数据，但对业务不了解，不知道有什么用。
简而言之，A公司的模式就是业务提需求，技术做交付。
02前东家B，区域领先的金融集团，采用项目制模式，他们对技术的定位就不同了，技术部门时不时会牵头做一些项目，也就是科技引领，技术主导，业务支持。
为什么会形成这样的工作模式，根本原因就是大领导希望有一些外部变量能够对业务推进起到鲶鱼效应，而技术领导正好又比较积极。
这种模式的好处就是快速响应，高层牵头，很多事情当场拍板就能做了，效率很高。技术人员能从技术角度提出创新的想法，再也不是乙方了，翻身做主人了。
但这种模式的缺点也很明显，主要有两个：
1. 项目制重建设，轻运营其实很好理解，新建系统可以向上汇报，运营一个系统哪有新建一个系统让人感到血脉喷张呢？
项目制模式运行久了，作为内部员工，就会发现洋洋洒洒建一大堆的系统，要么没什么用，没业务在上面跑，要么明明可以一个系统搞定的问题，偏偏搞多个系统维护，费时费力。
2. 屁股方向不一致项目制除了技术上的问题外，更大的问题在于主导权的争夺，项目到底谁主导，听谁的，说不清楚。
我曾经有幸参与过类似项目，一开始我很迷茫，这么多老总的要求各不相同，有的总喜欢看表格，什么图都不要，而有的老总就是要看折线图、饼图，怎么办？
但时间长了，我发现，其实直属领导才是王道，业务部门领导的意见只能是参考，直属领导的意见是命令。
原因很简单，直属领导给我打绩效啊，业务部门不咸不淡的表扬又有什么用呢？
我这么想，业务部门同事自然也明白这其中的弯弯绕，随着项目的推进，每次开会，渐渐出现了业务谈业务的，技术谈技术的，大家鸡同鸭讲。
没办法，大家的屁股没动，自然说不到一块去。
两种模式各有弊端，而且还都不小，那究竟技术和业务之间应该怎么协作？
03最近在听华为数据转型课程的时候，受到一定启发。
华为提出了业务IT一体化模式，就是把技术能力建在业务上，由业务主管担任责任人，业务人员和技术人员一起成立数字化团队，技术人员不再是单独的一个部门，而是成为具体业务部门的一部分，形成长期固定的组织形式。
我一听，就感觉非常有意思，这种模式有两个非常明显的好处：