原创不易，求分享、求一键三连
两个故事
技术的价值？
大家不要看我很乐观，其实去年考核拿了个C：
那时候一颗疑惑的种子也种下了，一直在问自己一个问题：
技术团队对于公司的价值是什么？
跟外包团队有什么差别？
技术是个成本部门，并没有自己的产品，也不带流水！
这也是很多技术总监会面临的一个问题：
多数时间去写代码了，行业知识这种枯燥的东西他们怎么可能太了解呢？
谁了解的多，谁对细节有掌握，谁就对那件事情有话语权
技术是个通用技术，只要技术好在哪里都能待，所以丢掉技术无异于自绝后路。
而事实上技术负责人写代码带来的帮助微乎其微，于是技术负责人就会陷入一种死循环，甚至会有些自责：
就是自己不给力，就是因为自己做的不够好，才导致了团队在公司中话语权不够；但你让他不要写代码那也是「万万不能的」
我认真去观察了下，看看不同团队技术话语权问题，竟然发现外包团队的技术话语权最高？这尼玛真的气人！
然后我又去研究了下，哪个CTO是公司决策层的核心？额，有点不好看呢...
看了《经济学原理》后，我「感觉」真实世界运行的「另一个」底层逻辑是资本流动，做为一个负责人，你了解公司资金流吗，你了解为什么要收购一个公司吗，你看得懂财务报表吗？
是的，这些都是非本专业的，我们除了技术，其实对其他所知甚少，而高管会议时，你说的性能优化、模块重用、效率提升天老爷才感兴趣呢？
甚至个别同事连研发和IT都分不清，这是痛苦的地方，说不清楚说不明白啊，让你问业务点问题都不知道说什么。
当然，话不可绝对，这个也许只是圈子问题...
兜底
前面的章节简单探讨过leader由于安全感、焦虑感抢下面小伙伴活干的问题，这是一种卡位、上下锁死，是对信息量的不负责，也是对下面下伙伴的不负责，属于偏内卷的做法。
于是我们提出了五维能力模型和Leader的五件事回答这个问题：
但是，方法论太虚，我们举一个例子说明总监以上该做什么：
之前一个产品同学跑来跟我们说需要采购一套供应链系统，以满足某方面的需求，而他十分迫切，希望我们尽快进行评估。
产研是天生的「敌人」，这类采购行为，当然是直接叫停（玩笑罢了），取而代之的是几个问题：
1）供应链系统是我们产品矩阵（框架）中的什么角色；
2）供应链系统是不是我们的核心依赖项；
3）其他类似的公司，供应链系统是否采购，是什么样的状态；
4）更成熟的公司是如何做的；
于是产品同学便去调研了......
这里大概得出了技术总监的一个重要差异化：
要有大局观，要有成本意识
大leader需要跳出技术框架，部分进入产品（业务）框架，对每一部分要有自己足够的认知，也要知道这个部分对于全局是什么角色。
因为一般来说，各个小leader只会关注到自己的模块，大leader才有这个信息量以及时间（毕竟不写代码，不跟太多细碎的项目）将这些模块串联，如果没有关注全局的人，就会出现灰色地带区域无人管理的情况。
所以技术Leader可以成为团队兜底的存在，但他为什么能兜这个底，除了兜底这种保下限的事情，还有没有什么可以弯道超车的事？
业务端的技术创新
什么是业务架构师
所谓业务架构师即⼀个优秀的技术站在业务⻆度思考问题，扮演部分产品、运营⻆⾊，然后形成⼩团队，站在⼯程效率⻆度与产品业务⽅⼀起解决实际问题，拥抱变化也控制变化。
说白了就是——结合业务做技术创新...
业务是信息输入是底色，技术是创新能力，底色+能力=创新的可能
从个人发展来说，大概是这样的：
1）更大的认知
比如，之前管50人团队，我现在能管500人团队。
2）更多的认知
比如，之前做了两年开发，又去做了两年产品，再去做了两年语文老师。
3）1+1>2的认知
比如，两个相关联的领域，先做了两年技术，升职做了架构师，甚至需要负责某个产品的设计。
这里比较晦涩，再举个不恰当的例子是，学了九阳神功，后面又学了九阴真经，最后达到了1+1>2的效果，Hybrid架构就是这类产物。
业务工程师便是要融合业务与技术两个领域，设计出更好的结果，这里的输入是业务及技术知识，产出可以是产品、服务、合作流程、合作机制等。
大公司有明显的「边界」，很难允许技术去做产品决策，但是前端做点后端的工作，做点Native的工作，这个限制没那么严格，毕竟有fullstack的说法嘛。
2W1H
业务架构师，事实上就是要从技术领域转到产品领域，这有一定要求，首先你得在技术领域做到至少是「自己的上限」，确实找不到什么增长点了才去做；
如果专业领域本身能再进一步，并且兴趣点就在这里，还真没必要做这个事；其次是你至少有一些「天赋」，想接触下业务，要有兴趣。
真实情况下也是很多总监及以上会开始接触业务，技术+管理毕竟没有技术+业务+管理来得香。
其次是时机点，成长也是有成本的，让技术总监去负责某条业务、产品线事实上是有很高的试错成本，能不能拿到这种成长资源去吃这个经验包，也是要考虑的。
强行转可能需要降维，不是所有人能承担，资金上不划算嘛
比如，我这里就是负责技术团队的同时，又恬不知耻的要了某块产品线，虽然恬不知耻，但还是立了军令状。
这里要注意的是，管理团队和把自己作为一个产品设计者是两回事，比如之前管客服团队，可能只是招个客服leader，做代理即可。
这里的区别是，下场去把脚打湿，甚至把头发打湿，淹不死就行。不懂的就把头放低，初期承认不丢人，中后期还不懂就别折腾了...
最后具体到怎么做，就千人千面了，这里举个例子。
案例·建立主线
业务架构师的第一要务是建立产品（业务）主线，不管你以什么方式，以你认为自洽的逻辑将产品线串起来，最好有完善的数据流向支撑串联逻辑，比如比较流行的人货场：
PS：图都是知乎上截的
先拆分业务（产品）模块，再思考技术模块，做到一定映射关系，这样方便了解全面。
我这边喜欢采用三层框架做分解，之前看了刘润的一篇文章，里面大概有几句话：
企业的唯一目标是创造顾客，创造（独特、品质）价值+（尽量）传递价值；
创造价值=做产品（服务）；
传递价值=做营销+做渠道=提高触达；
于是可以把产品分为三层框架：
之前我问了老板一个问题：如果微信九宫格给我们开放入口，是不是就成功了？
这里的问题的本质其实是，是不是产品流量足够大就算成功。
老板想了想说了下，流量这么大，你也承接不了啊。
这里的逻辑相当于你在村里开了一个小餐馆，突然给你挪到火车站，就算流量大，你这个小餐馆也服务不了，这里除了菜品好不好吃，还涉及到整个后厨的供应链管理，整个餐馆的服务（人员服务，菜品服务），整个销售揽客策略等......
所以初期，基础服务非常重要，其次流量很重要，再次营销策略很重要。
PS：这不废话吗，肯定都重要啊！
以世面上的直播平台为例，可能是这样的：
不论是人货场还是三大框架，或者其他什么模式，只要能用一条线一个数据流将现有的产品主线串起来都可以，然后再以你的逻辑判断其中每个产品模块在产品大蓝图中是什么角色，未来产品蓝图演化过程中应该是什么位置即可。
案例细化·营收框架
PS：这部分完全是初学者认知，大家笑一笑就好
形成系统性的思维后，需要对某条线建立足够的认知，比如深入营收模块，便至少需要回答以下问题：
1）公司的营收基本盘是什么；
2）既然营收活动可以刺激消费，那么他是怎么做到的，具体到一个周期几个营收活动可以利益最大化；
3）某些对营收有关系的模块要下线，这些模块属于哪部分，为什么下线为什么做不起来；
4）什么是货币体系，他是如何崩毁的；
......
这里稍微深入一点，首先回答一个问题，「什么是营收框架」？
营收框架其实是平台各个产品的市场集，是「所有消费产品或者服务」的「提供方」（卖方）和「消费方」（买方）组成的群体
消费方决定了产品的需求（量），提供方决定了一种产品的供给（量）；
营收框架中有许多角色参与其中，核心就是买卖方。
第二个问题是「营收框架如何运行的」？
事实上平台一般不提供内容服务，比如直播平台的服务是主播提供的，教育平台的服务是「教师」提供的；
这些角色提供内容服务的时候，用户消费平台提供的产品对服务提供者进行奖励（现金、流量、荣誉），平台通过消费模块使用的「权益」（特效、身份感）对用户进行奖励。
简单来说就是，平台与卖方提供服务、用户消费服务，三方都获得奖励，这个就是营收框架运行的方式，——「花钱大家都开心」
作为平台方，非常关心整个营收的规模，所以平台需要使用各种方法，让这个「营收盘子」越做越大，需求量变大或者效率变高（卖方产出变高）都是可行的方向。
第三个问题是，「平台如何影响规模」？
流量不是这里考虑的范畴，关于营收框架运行效率如何提高，这里首先要思考另一个问题：
单一产品营收规模=产品价格*产品销量
所以无论什么公司，做活动（撒币）变向降低产品价格，就是最好的手段，通过提高服务「有效价值」的手段来增加消费量，从而增加总体消费额；
另外，平台提供了「营销事件」，也可以触发需求量提升，比如传统节日、520节点是一致的。
在这种一步步发问中，将产品的所有收入手段做分类，比如会员、折扣、游戏折扣...如此一来，便对这个模块有了较为清晰的认知了。
理想情况下，产品（业务）认知建立结束，便可以同步执行技术相关的建设，设计基本盘，设计营销活动，什么服务需要组合，折扣怎么设计，全局货币体系如何设计，便可以娓娓道来。
然后实际情况可能稍显复杂......
结语
成为总监是获取某些信息的入场券；
了解业务、深入业务、融合技术与业务才是进阶之道。
全面的了解业务，也是中层管理的第一要务！
好了，今天的分享就到这，希望对各位有用。「原创不易，多多分享」
