Open lcxfs1991 opened 2 years ago
原文链接
李成熙,腾讯文档前端Leader,负责DOC业务前端研发。2014年度毕业加入腾讯AlloyTeam,先后负责过QQ群、花样直播、腾讯文档等项目。2018年加入腾讯云云开发团队。2019年加入Shopee金融前端团队任一线前端Leader。专注于性能优化、工程化和小程序服务。微博 | 知乎 | Github
这是一篇由内部分享转成的文章。因为最近有一些新的感悟,因此加入了一些新的内容。为什么还是想将一次分享铸成这篇文章呢?因为在日常工作中,还是能感受到很多同事一心只扑在技术上,对业务、对产品的关注过少,更有甚者是不想做业务需求,只求做艰涩的技术需求。
这并不是一个技术人正确的产品观。错误的产品观,会让技术人在技术上只求深入,不问业务,业务与技术的脱轨会让钻研的技术前功尽弃,也会让业务发展停滞。在商业公司里面从事技术,离不开商业世界基本的运行逻辑:收入 - 成本 = 利润。技术人就是要做功能将收入做得多多的,成本降得低低的,获得利润。当然你可以选择自己干,像两位马爸爸一样当创始人;或者做开源,像Vue、Redis、Nnginx 等开源应用的作者那样既做开源又做商业。只有通过技术手段获得利润,并且利润可持续,我们作为技术人的职业生涯才是可持续的。君不见,Webpack的作者由于拿不到足够的赞助又去上班了。连自己都养不活,更不要说烧些钱去探索星辰大海了。
那怎么样才是技术人良好的产品观,以及可以怎么树立呢?接下来我从四个常见的反面的思维为阐述。
在日常闲聊中,还是有很多同事对自己的产品数据不甚清楚,尤其许多前端的同事。可能后台经常要为机器发愁,生怕服务撑不起用户的并发,所以会经常问产品相关的产品数据。但前端的同事总觉得将页面切完接口调完就完事儿了。许多新的前端同事可能没想到,其实我们的HTML页面、其它静态资源部署,都是要考虑流量问题。一旦用户量很大,还需要要求云服务商给我们的服务、静态资源扩容。
下面列举了一些技术人最关注的数据。这些数据跟我们日常工作都是最息息相关的。有经验的技术人一般都会有所了解,新同事可能并不熟悉,本文只是做一个全面的列举,有兴趣可以专门学习,每一种类都有比较深的学问。
接下来我会列举一些跟产品更紧密关联的数据种类,这些连许多工程师都会忽略其重要性。一般来说,这类数据可以分为行为数据与业务数据。关注这些产品的数据有什么意义呢?
一般来说,产品都会告知开发人员,尤其是前端或客户端帮忙做以上行为数据的一些埋点,再将数据导入数据仓库进行清洗后再加以分析。开发人员往往做完埋点就觉得工作完成了,在此也是希望开发人员可以要求产品人员提供相关功能、运营活动的行为指标,来看到自己做的功能是否受到用户青睐、运营活动是否带来用户的增长或留存。如果数据好当然可喜可贺,如果不好也没关系,可以用于复盘,为下一个爆款的功能和活动打好基础。至于如何做好埋点、如何分析复盘,这将是一个非常庞大的议题,但是有了以上数据埋点与指标的基本概念,才能做好复盘。
除了前端和客户端经常关心的行为数据,还有后台和数据同事经常打交道的业务数据。不同细分领域关注的业务数据可能不太一样,初创公司可能更关注用户规模,而电商金额公司则更看着实实在在的金额。以下列举一些常见的业务数据指标和比较关注这些指标的细分领域:
这些业务相关的数据,即使平时没有关注,如果你有投资科技领域的股票,这些数据相信也是经常见诸于财报,这些数据对这些公司的股价有实质性的影响。既然你用“真金白银”投资科技股会关注这些指标,而你“肉身”投资到某个业务,何不也多多关注这些业务的核心指标呢——这毕竟关乎你的前途和钱途。
这是一个典型的需求工具人思维。“产品说啥,我就干啥”;“为什么产品说这么干,背后的产品逻辑是啥,我不清楚”。抱有这种心态的技术人,很难真正投入到产品的研发中,往往敷衍了事,也无法将根据产品的特性与逻辑提供最适合的技术手段进行支持。更正确的想法应该是:让产品因你存在而大不同!让“技术”和“业务”互相成就彼此,共同成长。业务发展倒逼技术改进,技术改进成就业务,相佐相成。
那要怎么样才可以践行这样的理念呢?可以尝试以下的几条:
这也是一种常见的思维误区,只管自己的一亩三分地,总觉得多干一点自己就吃亏了。只关注自己“端”的技术,会导致:
没法从宏观、全链路的技术角度,去设计技术方案,做出用户体验最好的功能。 一个典型的反面案例,导出导入任务用户等待时间长,容易超时,最差劲的做法就是前端只管将页面和提示做好,后台只将导入导出接口写好,两边的衔接、中间通路的超时配置、用户体验完全忽略,很典型的只关注单点技术产生的问题。
解决问题慢或者无法解决。 有不少的技术疑难杂症会出在前后台交叉的领域。如果不能从全局出去,想办法,建立更好的日志监控、设计更好的工具用以快速定位并解决问题,问题则会迟迟得不到解决影响更广泛的用户。而且最后很可能沦落到互相推诿责任。
在这些年的研发过程中,认识到许多优秀的技术前辈、老板,他们的技术视野都是非常广阔的,他们一般都是先从某项技术专精起家,有机会涉猎其它领域的技术并通过快速学习的能力掌握,这样他们才具备统领涵盖多项技术的跨技术团队的能力。另外我觉得有一点尤为重要,即较为复杂、牵涉各端的需求,最好都由一位对各项技术都有所了解的技术同事作为技术Owner,总领各方的整体的技术方案更为妥当,并且这位技术人也需要对产品特性逻辑比较清楚,才能领导设计出符合产品与用户要求的技术方案并将其落地。
为了更好地论证这个思想是偏见,有必要先定义一下通用技术与领域技术。这里的通用是指编程语言、数据结构、算法、设计模式等通用的计算机知识,如果是前端工程师可能会扩展到浏览器、V8等的一些相关知识。而业务领域技术,则专指该业务领域特别所需而其它业务领域可能不太需要的技术,比如直播行业需要直播录播、视频编解码等相关知识和技术;金融行业需要学习相应的股票、债券等知识,在国内券商甚至需要考证券从业人员资格证书;支付行业需要学习央行相关的法律规定还有支付的相关模型(读了内网的跨境金融技术深深感叹)还有各种数据库和各种锁保证交易和金额的一致性等等。
刚入行的年轻技术人总是希望学习更多的通用技术知识,但对业务领域的知识则表示抗拒,还发出灵魂一问:学了这些我到别的公司能用上嘛?我的回答是:有的用得上,有的用不上。比如视频技术,如果不在直播行业打工了,去长视频混口饭吃是绝对没问题的,但你说一旦跳槽到金融行业则完全用不上了。
有这样的想法很正常嘛,年轻的小伙未来的路还很长,可以尝试更多自己的兴趣,有很多转变赛道的机会,但你有没有想过,如果你成为某个业务领域的技术专家,这个支付模型整个公司只有几个人懂,核心视频编解码优化技术只有你能消化得了,办公文档的标准你了如指掌,你何愁不会成为业务的骨干与带头人呢?通用技术习得的人非常多,可替代性也比较强,但业务领域的技术知识,则还是需要沉浸在业务中,多年的摸爬滚打才能积累起来。通用技术与领域技术并不是互斥的,在修炼通用技术的同时,何不把自己所在业务所需要的业务领域技术与知识也一同学习,来个齐头并进呢?而且我相信,随着信息技术从消费互联网走向工业互联网,从新经济走向传统行业,我们所需要学习的业务知识、领域技术将会越来越多。而这类知识技术也将是技术人延长我们职业寿命非常重要的一环。
文章写得比较曲折,并没有直接陈述什么才是正确的技术人产品观,而是通过四个大家常见的一些误区或者偏见,逐一阐述和批判从而得到个人认为比较正确的产品观。以上均为经验心得,如有冒犯或谬误,恳请原谅或斧正,也欢迎大家留言进行讨论。
原文链接
这是一篇由内部分享转成的文章。因为最近有一些新的感悟,因此加入了一些新的内容。为什么还是想将一次分享铸成这篇文章呢?因为在日常工作中,还是能感受到很多同事一心只扑在技术上,对业务、对产品的关注过少,更有甚者是不想做业务需求,只求做艰涩的技术需求。
这并不是一个技术人正确的产品观。错误的产品观,会让技术人在技术上只求深入,不问业务,业务与技术的脱轨会让钻研的技术前功尽弃,也会让业务发展停滞。在商业公司里面从事技术,离不开商业世界基本的运行逻辑:收入 - 成本 = 利润。技术人就是要做功能将收入做得多多的,成本降得低低的,获得利润。当然你可以选择自己干,像两位马爸爸一样当创始人;或者做开源,像Vue、Redis、Nnginx 等开源应用的作者那样既做开源又做商业。只有通过技术手段获得利润,并且利润可持续,我们作为技术人的职业生涯才是可持续的。君不见,Webpack的作者由于拿不到足够的赞助又去上班了。连自己都养不活,更不要说烧些钱去探索星辰大海了。
那怎么样才是技术人良好的产品观,以及可以怎么树立呢?接下来我从四个常见的反面的思维为阐述。
产品的数据是多少,我不知道
在日常闲聊中,还是有很多同事对自己的产品数据不甚清楚,尤其许多前端的同事。可能后台经常要为机器发愁,生怕服务撑不起用户的并发,所以会经常问产品相关的产品数据。但前端的同事总觉得将页面切完接口调完就完事儿了。许多新的前端同事可能没想到,其实我们的HTML页面、其它静态资源部署,都是要考虑流量问题。一旦用户量很大,还需要要求云服务商给我们的服务、静态资源扩容。
下面列举了一些技术人最关注的数据。这些数据跟我们日常工作都是最息息相关的。有经验的技术人一般都会有所了解,新同事可能并不熟悉,本文只是做一个全面的列举,有兴趣可以专门学习,每一种类都有比较深的学问。
接下来我会列举一些跟产品更紧密关联的数据种类,这些连许多工程师都会忽略其重要性。一般来说,这类数据可以分为行为数据与业务数据。关注这些产品的数据有什么意义呢?
行为数据
一般来说,产品都会告知开发人员,尤其是前端或客户端帮忙做以上行为数据的一些埋点,再将数据导入数据仓库进行清洗后再加以分析。开发人员往往做完埋点就觉得工作完成了,在此也是希望开发人员可以要求产品人员提供相关功能、运营活动的行为指标,来看到自己做的功能是否受到用户青睐、运营活动是否带来用户的增长或留存。如果数据好当然可喜可贺,如果不好也没关系,可以用于复盘,为下一个爆款的功能和活动打好基础。至于如何做好埋点、如何分析复盘,这将是一个非常庞大的议题,但是有了以上数据埋点与指标的基本概念,才能做好复盘。
业务数据
除了前端和客户端经常关心的行为数据,还有后台和数据同事经常打交道的业务数据。不同细分领域关注的业务数据可能不太一样,初创公司可能更关注用户规模,而电商金额公司则更看着实实在在的金额。以下列举一些常见的业务数据指标和比较关注这些指标的细分领域:
这些业务相关的数据,即使平时没有关注,如果你有投资科技领域的股票,这些数据相信也是经常见诸于财报,这些数据对这些公司的股价有实质性的影响。既然你用“真金白银”投资科技股会关注这些指标,而你“肉身”投资到某个业务,何不也多多关注这些业务的核心指标呢——这毕竟关乎你的前途和钱途。
我是一个没得感情的需求机器
这是一个典型的需求工具人思维。“产品说啥,我就干啥”;“为什么产品说这么干,背后的产品逻辑是啥,我不清楚”。抱有这种心态的技术人,很难真正投入到产品的研发中,往往敷衍了事,也无法将根据产品的特性与逻辑提供最适合的技术手段进行支持。更正确的想法应该是:让产品因你存在而大不同!让“技术”和“业务”互相成就彼此,共同成长。业务发展倒逼技术改进,技术改进成就业务,相佐相成。
那要怎么样才可以践行这样的理念呢?可以尝试以下的几条:
那是后台/客户端的事,与我无关
这也是一种常见的思维误区,只管自己的一亩三分地,总觉得多干一点自己就吃亏了。只关注自己“端”的技术,会导致:
没法从宏观、全链路的技术角度,去设计技术方案,做出用户体验最好的功能。 一个典型的反面案例,导出导入任务用户等待时间长,容易超时,最差劲的做法就是前端只管将页面和提示做好,后台只将导入导出接口写好,两边的衔接、中间通路的超时配置、用户体验完全忽略,很典型的只关注单点技术产生的问题。
解决问题慢或者无法解决。 有不少的技术疑难杂症会出在前后台交叉的领域。如果不能从全局出去,想办法,建立更好的日志监控、设计更好的工具用以快速定位并解决问题,问题则会迟迟得不到解决影响更广泛的用户。而且最后很可能沦落到互相推诿责任。
在这些年的研发过程中,认识到许多优秀的技术前辈、老板,他们的技术视野都是非常广阔的,他们一般都是先从某项技术专精起家,有机会涉猎其它领域的技术并通过快速学习的能力掌握,这样他们才具备统领涵盖多项技术的跨技术团队的能力。另外我觉得有一点尤为重要,即较为复杂、牵涉各端的需求,最好都由一位对各项技术都有所了解的技术同事作为技术Owner,总领各方的整体的技术方案更为妥当,并且这位技术人也需要对产品特性逻辑比较清楚,才能领导设计出符合产品与用户要求的技术方案并将其落地。
我想学通用技术知识胜于业务领域的技术知识
为了更好地论证这个思想是偏见,有必要先定义一下通用技术与领域技术。这里的通用是指编程语言、数据结构、算法、设计模式等通用的计算机知识,如果是前端工程师可能会扩展到浏览器、V8等的一些相关知识。而业务领域技术,则专指该业务领域特别所需而其它业务领域可能不太需要的技术,比如直播行业需要直播录播、视频编解码等相关知识和技术;金融行业需要学习相应的股票、债券等知识,在国内券商甚至需要考证券从业人员资格证书;支付行业需要学习央行相关的法律规定还有支付的相关模型(读了内网的跨境金融技术深深感叹)还有各种数据库和各种锁保证交易和金额的一致性等等。
刚入行的年轻技术人总是希望学习更多的通用技术知识,但对业务领域的知识则表示抗拒,还发出灵魂一问:学了这些我到别的公司能用上嘛?我的回答是:有的用得上,有的用不上。比如视频技术,如果不在直播行业打工了,去长视频混口饭吃是绝对没问题的,但你说一旦跳槽到金融行业则完全用不上了。
有这样的想法很正常嘛,年轻的小伙未来的路还很长,可以尝试更多自己的兴趣,有很多转变赛道的机会,但你有没有想过,如果你成为某个业务领域的技术专家,这个支付模型整个公司只有几个人懂,核心视频编解码优化技术只有你能消化得了,办公文档的标准你了如指掌,你何愁不会成为业务的骨干与带头人呢?通用技术习得的人非常多,可替代性也比较强,但业务领域的技术知识,则还是需要沉浸在业务中,多年的摸爬滚打才能积累起来。通用技术与领域技术并不是互斥的,在修炼通用技术的同时,何不把自己所在业务所需要的业务领域技术与知识也一同学习,来个齐头并进呢?而且我相信,随着信息技术从消费互联网走向工业互联网,从新经济走向传统行业,我们所需要学习的业务知识、领域技术将会越来越多。而这类知识技术也将是技术人延长我们职业寿命非常重要的一环。
篇尾
文章写得比较曲折,并没有直接陈述什么才是正确的技术人产品观,而是通过四个大家常见的一些误区或者偏见,逐一阐述和批判从而得到个人认为比较正确的产品观。以上均为经验心得,如有冒犯或谬误,恳请原谅或斧正,也欢迎大家留言进行讨论。