如果时间退回到十多年以前,新兴互联网公司的技术人员几乎都是从「业务开发」开始自己的职业生涯的。然而到了今天,不知道你有没有发现,业务开发和纯技术的开发已经有了明显的分野。
最开始,互联网业务的出现,让人们第一次从用户需求和用户体验的角度来设计产品。正是这种与传统生意的不同,造就了很多互联网早期的传奇故事。而互联网公司的技术人员,作为这些用户产品的真正实现者,他们的目标就是用技术来解决产品实现问题。也就是说,代码是直接服务于产品需求的(典型的业务开发)。在这个过程中,技术人员逢山开路,遇水架桥,遇到什么样的技术问题就解决什么样的技术问题。遇到存储问题,他们就调试和扩容数据库;遇到系统问题,他们就升级系统软件,做基本的运维工作;遇到架构问题,他们就设计技术架构,直接支撑业务。总之,对业务逻辑的开发和对技术问题的解决,这两件事是很难分开的。
正是在这样的业务驱动的过程中,丰富的公用组件、技术体系或框架被设计出来,并逐渐从业务中抽离。搜索引擎产品,将信息检索(Information Retrieval)技术的工程化推向了前所未有的高度;社交网络对于信息流的需求,催生了基于写扩散和读扩散的整套信息流分发的技术架构(也包括存储架构);随着移动互联网的兴起,前后端分离的技术比以往走得更远,同时也出现了众多以客户端边缘计算为核心的专业编程技术。
在这样的大背景下,绝大多数能从业务中剥离的技术,都已经形成了开源项目。从MVC基础编程框架,到各种分布式数据库技术,到微服务调用和异步消息队列,再到大数据处理的整个技术栈,开源世界已经应有尽有,且不止一种选择。如今,新成立的创业公司,面对新的业务需求,技术人员在技术选型上的空间已经相当丰富,基本可以像搭积木一样把产品搭建出来。技术人员可以把更多精力放在业务开发上,从而大大提高了产品迭代的效率。但是,随着业务的做大,技术团队肯定也会不断碰到一些「纯技术问题」的困扰,需要对某些底层技术架构更专业的人员才能解决。于是,有一定规模的公司,或者基于开源项目进行二次开发,或者自研自己的底层架构,希望在长远的业务竞争中跑得更持久。
为了下文讨论清晰,我们将这些负责开发和维护底层技术架构的技术人员,称为「专业技术开发」人员;而将主要精力放在业务逻辑开发上的技术人员,称为「业务开发」人员。
在有些时候,「业务开发」和「专业技术开发」之间的区分并不是那么明显,特别是在一些初创的公司内部。这两类技术人员,他们都需要和业务人员(产品经理、运营人员、市场人员等)打交道。毕竟,所有的技术需求,源头都是来源于业务层面,两者只是「度」上的区别。对于一些刚进入职场的技术同学来说,他们甚至很难意识到自己的工作到底属于哪一类。但是,无论如何,你需要审视一下自己当前的工作,并结合自己的技术特点,看一下到底偏向哪一个方面。这关系到长远的规划。
我们先看一下对这两种开发人员各自的要求是怎样的。
先说「专业技术开发」,技术上的要求主要在于深度上,要能层层进阶,逐步逼近技术的本质。不同的阶段就犹如孤独求败的三柄长剑。
第一柄剑,乃是利剑,「凌厉刚猛,无坚不摧」。就好比一个初入职场,踌躇满志的年轻人,浑身充满斗志且技术精湛。他面对再复杂的系统,都能像一柄「利剑」一样,刺开迷雾,抽丝剥茧,深入到背后的原理。仅仅「会用」,远不是他的目标。
第二柄剑,是重剑,所谓「重剑无锋,大巧不工」。就好比一个资深的架构师,不仅深谙现有系统和框架的特性,也同样知晓它们的优点和缺陷,更能够凭借一己之力设计出更好的系统。种种繁复的技术细节,都是表象;再庞大的系统,也尽在掌握之中。花哨的技巧,早就不是他追求的目标。
第三柄剑,却是一柄木剑。到了这个阶段,已经达到了「不滞于物,草木竹石均可为剑」的状态。在他眼里,众多不同的上层技术,不同的开发语言,不同的技术栈,在底层都能看到相同的技术本质。本来繁杂的各路技术思想逐步归一,并对它们之间可能产生的融合与变化了然于胸。
再看一下「业务开发」人员。他们的工作不像前一种那么单纯,而是需要面对整个世界的复杂度。对这一类技术人员的要求,除了技术本身之外,还需看重两点:一个是要有业务Sense;另一个是要对业务数据敏感。
所谓业务Sense,又要从两方面来看:用户价值和商业价值。首先,他应该对创造更好的用户体验兴趣浓厚,他能够从用户的视角看待问题,有一定的「共情」能力。他应该对于产品所带来的用户价值有自己的判断,而不仅仅是被动接收产品经理的需求。其次,他应该对商业模式有一定的认识。他知道以LTV(用户的终身价值)和CAC(用户获取成本)为基础的产品标尺;他能认识到,一个好的产品必须在市场、产品、渠道、模型这四者之间达到契合。
所谓业务数据敏感,首先,他应该很明确地了解到业务的数据目标是什么,并能够清醒地意识到这个目标是整个团队的事情,而不仅仅是产品经理或运营人员的KPI。其次,他应该知道这个业务目标如何拆解到技术层面,能意识到技术事项和数据指标之间的逻辑关系。更进一步,他可能还需要对事物之间真实的因果关系有一定的分析能力,能够推断出哪一些产品或技术的改动可能对数据指标产生影响,并能够对如何通过AB实验来探索改进产品有系统的思维方法;他对于数据敏感,知道所维护的产品在AARRR整个用户生命周期(拉新、激活、留存、推荐、变现)上的特点,并能推断出哪些行为可能会对各个漏斗的转化率产生影响。
有些读者会说,这看起来更像是对业务人员的要求,而不是对技术人员的要求。但「业务开发」人员的工作,每天都与业务紧密相关,所以业务人员的思维方式他也需要有所了解。当然,最后还有最重要的一项要求——技术本身。一位「业务开发」人员,他应该知道什么样的产品方案适合用怎样的技术方案来支撑,这是最基本的要求。除此之外,他还应该提前做好技术布局,为业务的未来发展扫清障碍;同时,他能清醒地计算ROI(投入产出比),用较小的技术投入换取最大的业务价值。没错,「业务开发」最终就是这样,领着程序员的工资,操着CEO的心。
总之,对比一下「专业技术开发」和「业务开发」:前一种是专才,追求大道至简;后一种是全才,讲究学识渊博,包罗万象。
社会分工本质上是生产力发展的结果。就像我们在前面分析的一样,「专业技术开发」和「业务开发」这两种技术人员,是从互联网业务的不断繁荣中逐渐分化出来的。首先,分化意味着专业化;但在某种程度上说,也意味着「无趣」。早期初创企业中那种“光着膀子听着歌,一边盯着用户反馈,一边直接修改线上产品”的粗放的快乐时刻,现在的技术人员很难体会到了。粗放的做法被专业化的方案所替代,技术的「上古田园时期」已经一去不复返了。
专业化分工对于技术人员的成长所带来的影响是深远的。我们就来看一下这两种技术人员在成长过程中各自可能碰到的困境。对于两者来说,这些困境有些相同,有些不同。
首先第一点,他们都会遭遇到成长的边际效用递减法则。边际效用递减法则,本来是一个经济学概念,通俗地解释就是,对于同样的一件事情,开始投入的时候,收益值很高,越到后来,同样的投入量能换取的收益值就越少。大到国家和企业,小到一个团队和个人,这个原则都适用。
具体到技术人员的成长上来说,对于「业务开发」,最开始进入一个业务领域的时候,也是成长最快的时候。他通常要在短时间内掌握很多专业的「领域知识」,这个过程就好像一块干海绵一下子吸满了水。等到他能够娴熟地驾驭这些「领域知识」之后,业务逻辑的开发就变成了枯燥的、重复性的工作。而对于「专业技术开发」来说,这个过程发生在技术深度的拓展上。一个技术精湛的、像一柄「利剑」一样的技术同学,他能够在短时间内摸清一个底层架构的百分之八十,这个过程也是他最有收获的过程。但当他能够应付大部分技术需求的时候,变化也变得越来越少,他会感觉到翻来覆去还是那么些东西;而在技术深度上要想再深入一层,也是千难万难。
第二点是业务价值和技术亮点的冲突。对于「业务开发」来说,技术亮点通常很难提炼。他每天可能会花费90%的时间都在做业务逻辑的开发,但「业务逻辑开发」这件事情本身却不一定能体现出技术亮点。他需要不断地去概括、去抽象,去挖掘业务背后更深层的技术问题。而对于「专业技术开发」来说,则经常面临重复造轮子的风险。由于底层架构的复用性通常都比较强,他需要考虑所造的「轮子」对于业务的独特价值到底是什么,到底有没有必要性,到底是不是技术的自high。
最后,「业务开发」会更多地受到业务兴衰的影响。业务经常面临着试错风险,业务由盛转衰,或者自始至终就没有成功过,不管哪一种情况,最后的结果都是大部分写过的代码被抛到一边,一切从头开始。「专业技术开发」当然也会受到影响,但影响程度会小一点。
随着业务的繁荣和技术的发展,整个知识库变得愈发庞大了,而人的精力有限。既关注技术,又关注业务,经常让人力不从心。所以需要寻找平衡点。
这个平衡点,对于不同的人不一样,对于不同的具体职位,也不一样。
这就好比金庸小说中逍遥派里的人物,苏星河除了跟无崖子学武功之外,还学琴、学弈、学书法、学绘画,结果耽误了武学,最后败给了丁春秋。而另一个武学人物——黄药师,就平衡地很好,不但奇门遁甲、琴棋书画、天文地理都有涉猎,而且武功卓绝,属于宗师的级别,还能自创出「落英神剑掌」之类的武功来。当然,金庸小说中也有成功的「专才」,比如乔峰,比如郭靖,都堪称「战神」级别。
所以说,每个人都有适合自己的策略。有些人喜欢心无旁骛,持续钻研,始终如一;有些人则比较爱折腾,喜欢经常换个领域,比如专业技术干久了,就换到业务方向尝试,或者反过来。
不过有一个现实的情况可能需要考虑,对于「专业技术开发」和「业务开发」,社会的职位需求量肯定是后者比前者多得多。这个也很好理解,业务是公司的核心,业务也发展变化更快。所以通常情况下,技术人员比较理想的状态是「一专多能」。首先能够精通某一个专业领域的技术(由于精力有限,能够精通一个专业领域已经非常不错了),比如搜索技术,比如推荐技术,比如分布式架构,然后还能对业务有所了解,能够从业务的视角去思考问题。
在「专业技术开发」和「业务开发」两者之中,不存在哪个更好、哪个更坏的问题;如何把握两者之间的「度」和平衡点,也没有一个绝对的答案。但不管是偏向哪一个方向,重要的是搞清自己当前的现状和未来的定位,以及从「现在」到「未来」的路线是什么。
平衡点对每个人都不一样,而且对同一个人的不同时期来说,也是一个动态的平衡。持续关注新的领域,给自己找到下个阶段应该了解和深入研究的领域(技术领域或业务领域),才是不断成长的关键。在不断成长的动态的过程中,你才有机会总结出一套结构化的思维方式,甚至逐渐走出常规,开拓不一样的人生。
总之,时间有限,不要浪费太多。因为,青春很快就会逝去。
(正文完)
欢迎关注我的个人微博: 微博上搜索我的名字「 张铁蕾 」,与我互动 。
原文 https://mp.weixin.qq.com/s/OUdH5RxiRyvcrFrbLOprjQ
如何写好业务代码? 在前端工作中有很多业务性代码,如果书写不规范,那么对后期的维护将是非常致命的。业务场景:后端数据库中经常会一个字段具备几个不同的状态
考虑到所有主要加密货币的增长,以及区块链周围隐藏的令人钦佩的特性,一些公司正在考虑将区块链技术集成到他们的业务中,并且这已经不是什么新闻了,区块链技术就被认为只是比特币的公共交易账本
一直都是写关于技术的一些东西,从来没想过我会写一篇与技术没什么关系的文章,因为在之前的我看来,这种文章完全就是假大空
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!