技术管理进阶——技术总监的第一要务

技术总监的角色不仅限于技术管理,更需要具备全局视野和业务理解。本文通过实例阐述了技术总监如何从产品矩阵、业务主线、营收模块等角度建立对业务的深刻认知,并在技术决策中平衡投入与产出,确保技术服务于业务目标。重点讨论了如何通过建立主线、评估模块重要性和影响业务规模的方法,来指导技术团队的工作方向和资源分配。
摘要由CSDN通过智能技术生成

之前完成了一个基础生存指南系列:

新晋总监生存指南开篇之总监二三事

新晋总监生存指南二——建立指标

新晋总监生存指南三——OKR实践

新晋总监生存指南四——项目执行指南

新晋总监生存指南五——人才运营机制

新晋总监生存指南终章——构建团队信息通道

上述是偏中层管理软实力方面的要求,(个人认为)是基本的生存必要技能,能“活下去”,但是想“活得好”甚至“发家致富”还是远远不足的,因为还完全没涉及到业务呢!

一般情况下,技术管理想要出色,必须贴近业务,用技术的手段解决业务的问题。技术是工具,业务才是核心(有些场景可能不是),只想搞管理或者只想研究技术皆有风险

一、技术总监该做什么

前面的章节简单探讨过leader由于安全感(焦虑感)抢下面小伙伴活干的问题,这是一种卡位、上下锁死,是对信息量的不负责,也是对下面下伙伴的不负责,属于偏内卷的做法。

于是一个问题,技术总监到底该做什么呢?这里以一个故事展开。

之前一个产品同学跑来跟我们说需要采购一套供应链系统,以满足某方面的需求,而他十分迫切,希望我们尽快进行评估。

产研是天生的“敌人”,这类采购行为,当然是直接叫停(玩笑罢了),取而代之的是几个问题:

1)供应链系统是我们产品矩阵(框架)中的什么角色;

2)供应链系统是不是我们的核心依赖项;

3)其他类似的公司,供应链系统是否采购,是什么样的状态;

4)更成熟的公司是如何做的;

于是产品同学便去调研了......

这里大概得出了技术总监的一个重要差异化:要有大局观。

大leader需要跳出技术框架,部分进入产品(业务)框架,对每一部分要有自己足够的认知,也要知道这个部分对于全局是什么角色。

因为一般来说,各个小leader只会关注到自己的模块,大leader才有这个信息量以及时间(毕竟不写代码,不跟太多细碎的项目)将这些模块串联,如果没有关注全局的人,就会出现灰色地带区域无人管理的情况。

d1fa276cb45e98ff020c0ee60dd9f5e0.png

对于成本,大家都会避免负责,趋利避害是天性嘛。

二、全局角度下的模块重要度

之前有幸完整的见证了一块产品的诞生,甚至第一版的需求是我写的:

afb72d59d7894150964c19486be60e3e.png

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

c07f26afcfc1e6c53e37932e34cddb45.png

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

1)设计基础的交互模型,采用Hybrid模式,andriod硬件;

2)业务模块是常规需求分下去做就行;

3)试纸检测一块实现难度非常高便需要亲自切入了;

首先,这里涉及了试纸盒如何设计才能侧面帮助准确率提高,还要设计通用的产品盒,以帮助后续硬件能售卖其他产品,这里需要解除很多“专家”,也需要解除很多模具厂商,来回拉扯,加之这里涉及到专利和有效性,关乎成败,还只能技术负责人切入了。

在这个基础上:

1)产品同学如果想把业务模块外包,你会认为后续迭代较多,并且需要和我们的产品矩阵结合拒绝;

2)产品如果建议直接在机器上使用原生开发,这样体验更好,但是你可以以机器投放出去基本完蛋为由拒绝;

3)产品如果想把光学检测部分外包出去,这里反而是值得思考的,一般的技术是不具备这个专业性的,但是这里无论从专利还是壁垒来说都是对公司极其重要的模块,这个时候可以建议最好招人做或者合作的模式;

4)其他部分,比如机器外形设计、广告商页面等,其实都可以外包,因为不涉及主干路径;

这里还仅仅是初期某一条业务线研发时期技术模块的思考,如果这类业务线开展10条以上,模块复用、数据流转,什么业务线重要,哪条业务线不重要,技术要有更多的判断,如果判断失准,就很可能耗时费力了,所以:

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

那么什么重要,什么不重要的依据到底是什么?

三、建立主线

技术总监的第一要务是建立产品(业务)主线,不管你以什么方式,以你认为自洽的逻辑将产品线串起来,最好有完善的数据流向支撑串联逻辑,比如比较流行的人货场:

56aa170d0b7621f1405d3e97f9896174.png

PS:图都是知乎上截的

先拆分业务(产品)模块,再思考技术模块,做到一定映射关系,而我这边也喜欢采用三层框架做分解。之前看了刘润的一篇文章,里面大概有几句话:

企业的唯一目标是创造顾客,创造(独特、品质)价值+(尽量)传递价值;

创造价值=做产品(服务);

传递价值=做营销+做渠道=提高触达;

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

2e2004014565889d470ebbac6556eac9.png

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

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

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

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

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

PS:这不废话吗,肯定都重要啊!

以世面上的直播平台为例,可能是这样的:

97d09ac3c760d907069ea5fb598dc984.png

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

四、简单打样:营收线分解

PS:这部分完全是个人认知,大家读读就好。

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

1)公司的营收基本盘是什么;

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

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

4)什么是货币体系,他是如何崩毁的;

......

首先回答一个问题,什么是营收框架?

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

消费方决定了产品的需求(量),提供方决定了一种产品的供给(量);营收框架中有许多角色参与其中,核心就是买卖方。

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

事实上平台一般不提供内容服务,比如直播平台的服务是主播提供的,教育平台的服务是“教师”提供的,这些角色提供内容服务的时候,用户消费平台提供的产品对服务提供者进行奖励(现金、流量、荣誉),平台通过消费模块使用的“权益”(特效、身份感)对用户进行奖励。

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

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

第三个问题是,平台如何影响规模?

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

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

所以无论什么公司,做活动(撒币)变向降低产品价格,就是最好的手段,通过提高服务”有效价值“的手段来增加消费量,从而增加总体消费额(另外,平台提供了”营销事件“,也可以触发需求量提升,比如传统节日、520节点是一致的)。

在这种一步步发问中,将产品的所有收入手段做分类,比如会员、折扣、游戏折扣......

如此一来,便对这个模块有了较为清晰的认知了。

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

然后实际情况可能稍显复杂......

五、结语

技术总监生存指南是中层管理的门槛,是入场券的标准;了解业务、深入业务、融合技术与业务才是进阶之道。

全面的了解业务,也是中层管理的第一要务!后续文章,我们来探讨技术如何切入业务,一起奔小康,希望此文对大家有帮助。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值