如何和业务方建立良好的合作关系

原创不易，求分享、求一键三连

前段时间有个粉丝问了一个问题：

小钗，我去年刚被提拔成了技术负责人，机会来之不易，所以业务方的很多需求我们都会尽量满足，但需求是无止境的，最终业务方对技术部的评价依旧很低，我们应该如何建立与业务方的良性合作机会呢？

很好的问题，该同学表面在问技术部如何让业务团队满意，他的解法是尽量满足业务团队的需求，但结果却不太好，这里的原因是选择权问题：

面对业务方压力，很多同学往往选择“我必须做”、“我没办法不做”、“我没有选择”的思维而最终丧失选择权；没有选择就没有重点，没有重点便不能集中资源，最后什么都没有做好。

另一方面，你不选择业务方就会帮你做选择，但他选择的未必是你擅长的，最终结果依旧是什么都做不好，如果甘心将自己做工具人，那当然没人对工具在意啊。

所以，该同学的根本的问题在问如何提升技术部在公司的地位、技术团队在团队真正的价值是什么。

就这几年我的认知来说，核心在有选择，路径是如何有选择，重点其实就一句话：对业务有足够的了解

谁了解得多，谁对细节有掌握，谁就对那件事情有话语权

HowTo

技术同学首先要摆正自己的位置：

1. 技术是核心资源，这个时候业务方会求着技术干活，我们只需要决定投资谁就行；
2. 业务是爸爸，这个时候技术是辅助角色，那我们首先要选择最强业务线做投资，还得投入少量资源给其他有潜力的业务线；

而无论是成为核心还是辅助爸爸，都有个前提是：了解业务，这需要技术团队有几个足够深入业务的人，我们为他取了一个名字叫：业务架构师。

业务架构师，事实上就是要从技术领域转到产品、业务领域，这有一定要求，首先你得在技术领域做到至少是自己的上限，确实找不到什么增长点了才去做；

如果专业领域本身能再进一步，并且兴趣点就在这里，还真没必要做这个事；其次是你至少有一些天赋，想接触下业务，要有兴趣。

真实情况下也是很多总监及以上会开始接触业务，技术+管理毕竟没有技术+业务+管理来得香。

其次是时机点，成长也是有成本的，让技术总监去负责某条业务、产品线事实上是有很高的试错成本，能不能拿到这种成长资源去吃这个经验包，也是要考虑的。

强行转可能需要降维，不是所有人能承担，资金上不划算嘛

比如，我就是负责技术团队的同时，又恬不知耻的要了某块产品线，虽然恬不知耻，但还是立了军令状。

这里要注意的是，管理团队和把自己作为一个产品设计者是两回事，比如之前管客服团队，可能只是招个客服leader，做代理即可。

这里的区别是，下场去把脚打湿，甚至把头发打湿，淹不死就行。不懂的就把头放低，初期承认不丢人，中后期还不懂就别折腾了...

最后具体到怎么做，就千人千面了，举个例子。

案例·建立主线

业务架构师的第一要务是建立产品（业务）主线，不管你以什么方式，以你认为自洽的逻辑将产品线串起来，最好有完善的数据流向支撑串联逻辑，比如比较流行的人货场：

PS：图都是知乎上截的

先拆分业务（产品）模块，再思考技术模块，做到一定映射关系，这样方便了解全面。

我这边喜欢采用三层框架做分解，之前看了刘润的一篇文章，里面大概有几句话：

企业的唯一目标是创造顾客，创造（独特、品质）价值+（尽量）传递价值； 创造价值=做产品（服务）； 传递价值=做营销+做渠道=提高触达；

于是可以把产品分为三层框架：

之前我问了老板一个问题：如果微信九宫格给我们开放入口，是不是就成功了？

这里的问题的本质其实是，是不是产品流量足够大就算成功。

老板想了想说了下，流量这么大，你也承接不了啊。

这里的逻辑相当于你在村里开了一个小餐馆，突然给你挪到火车站，就算流量大，你这个小餐馆也服务不了，这里除了菜品好不好吃，还涉及到整个后厨的供应链管理，整个餐馆的服务（人员服务，菜品服务），整个销售揽客策略等......

所以初期，基础服务非常重要，其次流量很重要，再次营销策略很重要。

PS：这不废话吗，肯定都重要啊！

以市面上的直播平台为例，可能是这样的：

不论是人货场还是三大框架，或者其他什么模式，只要能用一条线一个数据流将现有的产品主线串起来都可以，然后再以你的逻辑判断其中每个产品模块在产品大蓝图中是什么角色，未来产品蓝图演化过程中应该是什么位置即可。

案例细化·营收框架

PS：这部分完全是初学者认知，大家笑一笑就好

形成系统性的思维后，需要对某条线建立足够的认知，比如深入营收模块，便至少需要回答以下问题：

1）公司的营收基本盘是什么；

2）既然营收活动可以刺激消费，那么他是怎么做到的，具体到一个周期几个营收活动可以利益最大化；

3）某些对营收有关系的模块要下线，这些模块属于哪部分，为什么下线为什么做不起来；

4）什么是货币体系，他是如何崩毁的；

......

这里稍微深入一点，首先回答一个问题，什么是营收框架？

营收框架其实是平台各个产品的市场集，是所有消费产品或者服务的提供方（卖方）和消费方（买方）组成的群体

消费方决定了产品的需求（量），提供方决定了一种产品的供给（量）；

营收框架中有许多角色参与其中，核心就是买卖方。

第二个问题是营收框架如何运行的？

事实上平台一般不提供内容服务，比如直播平台的服务是主播提供的，教育平台的服务是教师提供的；

这些角色提供内容服务的时候，用户消费平台提供的产品对服务提供者进行奖励（现金、流量、荣誉），平台通过消费模块使用的权益（特效、身份感）对用户进行奖励。

简单来说就是，平台与卖方提供服务、用户消费服务，三方都获得奖励，这个就是营收框架运行的方式，——花钱大家都开心

作为平台方，非常关心整个营收的规模，所以平台需要使用各种方法，让这个营收盘子越做越大，需求量变大或者效率变高（卖方产出变高）都是可行的方向。

第三个问题是，平台如何影响规模？

流量不是这里考虑的范畴，关于营收框架运行效率如何提高，这里首先要思考另一个问题：

单一产品营收规模=产品价格*产品销量

所以无论什么公司，做活动（撒币）变向降低产品价格，就是最好的手段，通过提高服务有效价值的手段来增加消费量，从而增加总体消费额；

另外，平台提供了营销事件，也可以触发需求量提升，比如传统节日、520节点是一致的。

在这种一步步发问中，将产品的所有收入手段做分类，比如会员、折扣、游戏折扣...如此一来，便对这个模块有了较为清晰的认知了。

理想情况下，产品（业务）认知建立结束，便可以同步执行技术相关的建设，设计基本盘，设计营销活动，什么服务需要组合，折扣怎么设计，全局货币体系如何设计，便可以娓娓道来。

案例细化·打破界限

之前有幸完整的见证了一块产品的诞生，当时为了更进一步参与甚至部分需求都是我写的：

首先这是一个软硬件结合的项目，其次其中有一个尿检试纸光学检测问题，单从研发阶段可以划分为：

技术层面这里做三个工作：

1. 设计基础的交互模型，采用Hybrid模式，andriod硬件；
2. 业务模块是常规需求分下去做就行；
3. 试纸检测一块实现难度非常高便需要亲自切入了；

首先，这里涉及了试纸盒如何设计才能侧面帮助准确率提高；还要设计通用的产品盒，以帮助后续硬件能售卖其他产品；这个过程需要接触很多领域“专家”，也需要接触很多模具厂商，是一个很好的突破边界的案例。

在这个基础上技术负责人要思考：

1. 如果资源不足，需要做模块外包，哪部分自研，哪部分外包，要有全局考虑；
2. 硬件部分是采用原生开发还是Hybrid形式，其中的考虑点是体验、机器投放后维护成本的平衡；

技术Leader需要给出什么该自己做，什么可以不做（外包）的判断，并且有理有据，需要尽可能的站在全局考虑某一模块的投入度。

那么什么重要，什么不重要的依据到底是什么，依据就是技术在全局业务的参与度，和对应模块技术侧的专业性判断。

结语

更好合作关系的前提是技术人对业务有基本认知，这也是程序员一个常见的问题：

只关注技术，不关注业务

但了解业务、深入业务、融合技术与业务才是真正进阶之道。

在某个场景下，技术同学能为业务提供中肯的建议，专业的判断，那么良性的合作关系自然就产生了。

走管理线的技术同学一定要有深入业务的觉悟，只是做工具人当舔狗是没有价值的，业务行就辅助，业务不行就取代，有此格局，何愁合作不成？

好了，今天的分享就到这，喜欢的同学可以四连支持