一个好的技术头狼是怎样的?

简介: 一个好的技术头狼是怎样的?

本文来源:支付宝体验科技


  基本模式


蚂蚁集团芝麻企业信用作为一个 tob 业务,在每个方向上设定合适的技术头狼非常重要,头狼作为业务战场的一号位,总结下来需要做以下几件事情:

  • 了解业务背景、行业以及战场
  • 与业务充分沟通,并理解业务背后的思路
  • 人力盘点,对战场人力划分
  • 整体的技术架构设计
  • 多方协作问题处理
  • 业务数据的思考
  • 推进业务优化升级

以上 7 点是个相对通用的方法论,不论什么业务,其实都可以往里带入,以下根据具体案例,分节详细讨论这 7 点。


  流程细节


了解业务背景


这一句虽然简单,但对于一个业务技术来说要求其实很高,尤其是 toB 相关的业务。c 端业务本身自己可作为用户带入产品,去体验,到那时 b 端业务就需要更多的行业经验才能支撑。简单来说,如果我们在做的是一款充话费的产品,那么我们核心思考的就是如何降低用户的操作成本,人机交互是否足够流畅,这时候表单的自动填入,帮助用户选取最佳的优惠方案,甚至自动充值这种降低用户操作量的产品需求就会逐步出来。


但是对于 b 端产品来说,往往很难直接带入,拿企业主服务来说,企业主核心需要的是什么,这个需要长期去了解,或者亲身体验才会更有体感,否则做出来的产品就没有吸引力。比如从企业主角度来说最总要的是找钱 - 找人 - 找市场,有了基础的判断,整体产品思路就会相对清晰,tob 类业务重点就是解决这 3 类问题信贷服务(找钱)- 人才/技术服务(找人)- 行业服务(找市场),剩下的就是考虑我们业务是哪个方向,如何和企业主诉求匹配的问题了。


业务和产品策略沟通


这一步实际上是第一步的一个补充,只有有足够的行业思考或者产品思考,你和业务的沟通才是对等的,当两个人聊一件看似相关,但实际根本不同的一件事情的时候,只会产出无效的结论。所以先多看看业务文档和规划,理清楚里面的逻辑,并基于业务方向,思考如何产品化落地的基础思路。然后与业务和产品一起,来一场(或多场)激烈的讨论,思路就会清晰很多。比如今年业务思路是提升用户时长还是提升收入,亦或者是留存,这时候从方向上来说一定有一个核心的 kpi,也就是主要矛盾和次要矛盾,优先解决主要矛盾,然后逐步解决次要矛盾,复杂事物的多个矛盾实际上就是业务上拆分的多个战场。


技术架构


作为技术同学,首先需要有一个全局的技术架构图,从底层依赖,到服务设计,再到产品展现,需要明确每个技术方向针对这个战场需要提供的核心服务,从角色上更像是一个解决方案架构师,不仅仅需要了解自己的那部分,还要对全链路的技术有一定的了解。先看下下面这张架构图(来自百度)

这张图针对银行业务进行了 4 层划分,相对清晰的讲明了一个银行业务中的核心系统能力以及相互的依赖关系,通过类似的架构图,能够更好的让其他人了解这个方向业务的技术策略,对于每一个点上来说,也更容易找到自己在战场中的定位。


人才盘点


对于业务战场来说,都不太可能是一个人就能落地的,这里面就涉及了前端、后端、算法、数据、BI 等各种各样角色的配合,如何让这么多角色有序的配合起来,就需要做很多事情。有了上面提到的技术架构图,这时候首先需要将整个战场做一个更细的方向划分,每个方向指定一个核心同学负责,并一起梳理策略节奏和核心结果,这样在做事之前就会有一个清晰的大图去定义每个人的事情。然后从业务落地角度来说,也需要头狼有一定的协调规划能力,保持战场中需求有条不紊的落地,拿一个需求来举例,业务想要对外提供一项服务,这时候业务和产品第一个想到的肯定是技术头狼这个角色,会先和头狼做简单的背景沟通,头狼需要有一定的全局判断力,这个需求涉及哪些改动,方案是否合理,需要上下游哪些角色配合,是否有跨团队合作,是否有技术风险,这些问题头狼需要有一个大致的结论。这样在推动整条链路从brd -> prd -> 系分这个阶段才能有效的结合起来,才会更加顺畅,提升整体落地效率。


多方协作


很少有业务可以实现一个自己的闭环,其中都会涉及和其他 bu 的跨部门合作,这时候作为一号位就需要能够快速理清楚和对方合作中,对方提供的核心功能是什么,我们如何对接,对接流程是什么样的,整体对接方案是否安全合规等问题。在对接过程中也需要定期 check 整体进度,以及协调解决过程中遇到的各种问题。


数据


只有从数据中才能快速找到各种问题的答案,所以需要定义清楚当前战场的数据指标是什么,然后再往下拆分 3 层,每层指标都应该有明确的定义,并形成数据大盘,这样一方面可以为业务和产品提供有力的数据支撑,同时也能够更好的让自己对这个战场有明确的判断。如何获取有价值的信息,就需要找到一个合适的时间周期,定期对大盘数据进行分析,并阶段性复盘,这样会逐步提高自身的数据敏锐度,同时进一步加深对这个方向业务的理解。


业务推进


业务需要技术方案落地,同时技术也可以对业务有一定的推进,但这一切一定是依赖对业务的整体判断才能有效产出。只有对行业有清晰的认知,才能在行业做出技术创新,从而产生新的业务模式变更。技术始终需要解决的一件事情就是降本增效,一方面技术创新可以降低研发成本,加速产品上线,另一方面,技术创新可以为业务带来新的模式。拿企业信用业务来举例,前几年主要以企业风管 SaaS 能力为主,对接方有国企,有政府机构,有商业公司,对接成本普遍几个月,这时候核心问题无非是如何帮助这类型企业快速实现风管能力落地,从这个角度出发,之前做的风管业务组建云平台就可以有效解决对接成本问题,由之前的接口接入-isv实现交互层-功能内嵌 简化为云组件接入一步,但这并不意味着某个技术方向可以长期稳定的迭代下去,只有和业务匹配的技术才能够发挥最大价值。随着业务的不断发展,新的技术和能力可以更加有效的帮助业务落地,这也是技术在业务领域的价值。


  落地保障


为了能够协助业务达成最终目标,就需要有一定的保障机制,在这里主要可以分为以下几点

  • 业务大盘建设

针对业务进行标准化的大盘建设,梳理出来核心链路,并对核心链路进行高保。

  • 定期同步机制

这块主要是按实际情况,初期可以单周,长期可以考虑双周沟通,针对目前战场,需要关注核心技术能力进展是否顺利,有哪些卡点。作为一号位,这些卡点需要高优协调解决,从更全面的角度去看整体的技术规划落地情况。

  • 业务反馈机制

事物是不断变化的,业务虽然会定一个阶段的目标,但在具体实施的过程中,会有一些优先级或者短期方向的调整,这时候就需要能够理解业务变化的本质,并对整体技术方向做一次梳理,看哪些内容是需要调整的,及时做出调整,才能够更好的和业务打好配合。具体时间可以双周/单周形式,和业务有一个短时间的例会,会上可以同步当前进展以及从技术侧看到的一些数据问题,以及和业务分析业务侧现阶段是否达成目标,如果目标未达成,主要是哪些原因影响,及时对有问题的点进行调整。


  总结


以上只是一个粗略的总结,每个方向都可以展开一篇完整的文章,简单来说,技术一号位不仅要懂业务,也需要梳理出业务迫切需要的是什么,为最终的业务目标服务。


相关文章
|
28天前
|
SQL 自然语言处理 Rust
东白随记系列技术博客文章
东白随记系列技术博客文章
28 0
|
4月前
|
Serverless C语言
执指之剑 一针见血(指针初识)
执指之剑 一针见血(指针初识)
21 3
|
11月前
拿捏链表(二)-------反转链表
拿捏链表(二)-------反转链表
40 0
237. 删除链表中的节点【我亦无他唯手熟尔】
237. 删除链表中的节点【我亦无他唯手熟尔】
49 0
用试题这把“剑“帮你破除指针与数组之间的那些猫腻
用试题这把“剑“帮你破除指针与数组之间的那些猫腻
61 0
|
人工智能 算法 C++
每日算法系列【LeetCode 354】俄罗斯套娃信封问题
每日算法系列【LeetCode 354】俄罗斯套娃信封问题
|
JavaScript 前端开发
迷失中的this指向,看完这篇就会了
this是一个比较迷惑人的东西,尽管你对this有很多的了解,但是面试题里面考察this指向,总会让你有种猜谜的感觉,知道一些,但是还是会出错,或许你猜对了,但是又好像解释不太清楚。
迷失中的this指向,看完这篇就会了
|
前端开发 JavaScript
#yyds干货盘点# 前端歌谣的刷题之路-第四十九题-头部插入数据
#yyds干货盘点# 前端歌谣的刷题之路-第四十九题-头部插入数据
56 0
#yyds干货盘点# 前端歌谣的刷题之路-第四十九题-头部插入数据
|
移动开发 JavaScript 安全
前端百题斩【025】——原来跨域也是可以进行分类的
前端百题斩【025】——原来跨域也是可以进行分类的
前端百题斩【025】——原来跨域也是可以进行分类的
|
前端开发 JavaScript
前端百题斩【019】——数组中方法原理早知道
前端百题斩【019】——数组中方法原理早知道
前端百题斩【019】——数组中方法原理早知道