Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

技术人的产品观 #36

Open
lcxfs1991 opened this issue Feb 1, 2022 · 0 comments
Open

技术人的产品观 #36

lcxfs1991 opened this issue Feb 1, 2022 · 0 comments

Comments

@lcxfs1991
Copy link
Owner

lcxfs1991 commented Feb 1, 2022

原文链接

李成熙,腾讯文档前端Leader,负责DOC业务前端研发。2014年度毕业加入腾讯AlloyTeam,先后负责过QQ群、花样直播、腾讯文档等项目。2018年加入腾讯云云开发团队。2019年加入Shopee金融前端团队任一线前端Leader。专注于性能优化、工程化和小程序服务。微博 | 知乎 | Github

这是一篇由内部分享转成的文章。因为最近有一些新的感悟,因此加入了一些新的内容。为什么还是想将一次分享铸成这篇文章呢?因为在日常工作中,还是能感受到很多同事一心只扑在技术上,对业务、对产品的关注过少,更有甚者是不想做业务需求,只求做艰涩的技术需求。

这并不是一个技术人正确的产品观。错误的产品观,会让技术人在技术上只求深入,不问业务,业务与技术的脱轨会让钻研的技术前功尽弃,也会让业务发展停滞。在商业公司里面从事技术,离不开商业世界基本的运行逻辑:收入 - 成本 = 利润。技术人就是要做功能将收入做得多多的,成本降得低低的,获得利润。当然你可以选择自己干,像两位马爸爸一样当创始人;或者做开源,像Vue、Redis、Nnginx 等开源应用的作者那样既做开源又做商业。只有通过技术手段获得利润,并且利润可持续,我们作为技术人的职业生涯才是可持续的。君不见,Webpack的作者由于拿不到足够的赞助又去上班了。​连自己都养不活,更不要说烧些钱去探索星辰大海了。

那怎么样才是技术人良好的产品观,以及可以怎么树立呢?接下来我从四个常见的反面的思维为阐述。

产品的数据是多少,我不知道

image (1)

在日常闲聊中,还是有很多同事对自己的产品数据不甚清楚,尤其许多前端的同事。可能后台经常要为机器发愁,生怕服务撑不起用户的并发,所以会经常问产品相关的产品数据。但前端的同事总觉得将页面切完接口调完就完事儿了。许多新的前端同事可能没想到,其实我们的HTML页面、其它静态资源部署,都是要考虑流量问题。一旦用户量很大,还需要要求云服务商给我们的服务、静态资源扩容。

下面列举了一些技术人最关注的数据。这些数据跟我们日常工作都是最息息相关的。有经验的技术人一般都会有所了解,新同事可能并不熟悉,本文只是做一个全面的列举,有兴趣可以专门学习,每一种类都有比较深的学问。

英语名称 作用 平台
Metrics 聚合数据/事件(比纯粹的Event更复杂) Prometheus + Grafana
Event 事件 腾讯云RUM
Tracing 链路跟踪 如Jaeger
Logging 日志 腾讯云CLS
Error 错误栈信息 如Sentry
Performance 性能 腾讯云RUM

接下来我会列举一些跟产品更紧密关联的数据种类,这些连许多工程师都会忽略其重要性。一般来说,这类数据可以分为行为数据业务数据。关注这些产品的数据有什么意义呢?

  1. 方便做A/B测试,对比目标的行为数据,验证功能成败 —— 比如按钮颜色对用户操作的影响
  2. 协助产品与财务人员,对收入进行对账 —— 比如会员的收入,对比银行账户与用户实际的支付
  3. 帮助审计、风控、安全人员,降低公司内外的业务风险 —— 帮助发现是否有内部贪腐;打击外部灰产和羊毛党
  4. 反馈公司业绩 —— 比如腾讯、阿里、百度等上市公司,会披露不同业务的收入与利润情况

行为数据

一般来说,行为数据最常见的埋点有以下三种:

名称 英文 含义
页面查看 Page View 统计页面的查看量
元素曝光 Element Impression 统计元素出现在屏幕可视区的量
元素点击 Element Click 统计元素点击量

基于上面埋点数量进行一些计算,常见可以得出行为数据三种最常见的指标:

名称 英文 含义
(日/月)活跃用户 Active User, DAU/MAU 统计日/月活跃的用户,活跃的标准不同的产品有不同的选择,可以是查看,也可以是操作。也非常严格的比如查看多少分钟才纳入统计的
跳失率 Bounce Rate 统计通过某入口访问了一个页面就离开的的访问占总访问的比例
留存率 Retention Rate 统计前一周期访问但后一周期不再访问的用户占总用户的比例

一般来说,产品都会告知开发人员,尤其是前端或客户端帮忙做以上行为数据的一些埋点,再将数据导入数据仓库进行清洗后再加以分析。开发人员往往做完埋点就觉得工作完成了,在此也是希望开发人员可以要求产品人员提供相关功能、运营活动的行为指标,来看到自己做的功能是否受到用户青睐、运营活动是否带来用户的增长或留存。如果数据好当然可喜可贺,如果不好也没关系,可以用于复盘,为下一个爆款的功能和活动打好基础。至于如何做好埋点、如何分析复盘,这将是一个非常庞大的议题,但是有了以上数据埋点与指标的基本概念,才能做好复盘。

业务数据

除了前端和客户端经常关心的行为数据,还有后台和数据同事经常打交道的业务数据。不同细分领域关注的业务数据可能不太一样,初创公司可能更关注用户规模,而电商金额公司则更看着实实在在的金额。以下列举一些常见的业务数据指标和比较关注这些指标的细分领域:

名称 英文 领域
注册用户 Registered Users 社交软件、效率工具
活跃用户 Daily/Monthly Active Users(DAU/MAU) 社交软件、效率工具
客单价 Per Customer Transaction 电子商务
订单数 Transaction Volume 电子商务
调用量 API Call 云服务

这些业务相关的数据,即使平时没有关注,如果你有投资科技领域的股票,这些数据相信也是经常见诸于财报,这些数据对这些公司的股价有实质性的影响。既然你用“真金白银”投资科技股会关注这些指标,而你“肉身”投资到某个业务,何不也多多关注这些业务的核心指标呢——这毕竟关乎你的前途和钱途。

我是一个没得感情的需求机器

image (2)

这是一个典型的需求工具人思维。“产品说啥,我就干啥”;“为什么产品说这么干,背后的产品逻辑是啥,我不清楚”。抱有这种心态的技术人,很难真正投入到产品的研发中,往往敷衍了事,也无法将根据产品的特性与逻辑提供最适合的技术手段进行支持。更正确的想法应该是:让产品因你存在而大不同!让“技术”和“业务”互相成就彼此,共同成长。业务发展倒逼技术改进,技术改进成就业务,相佐相成。

那要怎么样才可以践行这样的理念呢?可以尝试以下的几条:

  1. 对产品的设计多思考,有哪些不足,从产品设计、运营增长、技术架构等多方面进行思考,如何能对产品更好。
  2. 提前对技术体系做布局,引领技术与项目,避免业务突然变化时陷入被动
  3. 对现有支撑业务“较为成熟”的“有瓶颈”的技术体系做出改革与突破

那是后台/客户端的事,与我无关

image

这也是一种常见的思维误区,只管自己的一亩三分地,总觉得多干一点自己就吃亏了。只关注自己“端”的技术,会导致:

  1. 没法从宏观、全链路的技术角度,去设计技术方案,做出用户体验最好的功能。
    一个典型的反面案例,导出导入任务用户等待时间长,容易超时,最差劲的做法就是前端只管将页面和提示做好,后台只将导入导出接口写好,两边的衔接、中间通路的超时配置、用户体验完全忽略,很典型的只关注单点技术产生的问题。

  2. 解决问题慢或者无法解决。
    有不少的技术疑难杂症会出在前后台交叉的领域。如果不能从全局出去,想办法,建立更好的日志监控、设计更好的工具用以快速定位并解决问题,问题则会迟迟得不到解决影响更广泛的用户。而且最后很可能沦落到互相推诿责任。

在这些年的研发过程中,认识到许多优秀的技术前辈、老板,他们的技术视野都是非常广阔的,他们一般都是先从某项技术专精起家,有机会涉猎其它领域的技术并通过快速学习的能力掌握,这样他们才具备统领涵盖多项技术的跨技术团队的能力。另外我觉得有一点尤为重要,即较为复杂、牵涉各端的需求,最好都由一位对各项技术都有所了解的技术同事作为技术Owner,总领各方的整体的技术方案更为妥当,并且这位技术人也需要对产品特性逻辑比较清楚,才能领导设计出符合产品与用户要求的技术方案并将其落地。

我想学通用技术知识胜于业务领域的技术知识

image

为了更好地论证这个思想是偏见,有必要先定义一下通用技术与领域技术。这里的通用是指编程语言、数据结构、算法、设计模式等通用的计算机知识,如果是前端工程师可能会扩展到浏览器、V8等的一些相关知识。而业务领域技术,则专指该业务领域特别所需而其它业务领域可能不太需要的技术,比如直播行业需要直播录播、视频编解码等相关知识和技术;金融行业需要学习相应的股票、债券等知识,在国内券商甚至需要考证券从业人员资格证书;支付行业需要学习央行相关的法律规定还有支付的相关模型(读了内网的跨境金融技术深深感叹)还有各种数据库和各种锁保证交易和金额的一致性等等。

刚入行的年轻技术人总是希望学习更多的通用技术知识,但对业务领域的知识则表示抗拒,还发出灵魂一问:学了这些我到别的公司能用上嘛?我的回答是:有的用得上,有的用不上。比如视频技术,如果不在直播行业打工了,去长视频混口饭吃是绝对没问题的,但你说一旦跳槽到金融行业则完全用不上了。

有这样的想法很正常嘛,年轻的小伙未来的路还很长,可以尝试更多自己的兴趣,有很多转变赛道的机会,但你有没有想过,如果你成为某个业务领域的技术专家,这个支付模型整个公司只有几个人懂,核心视频编解码优化技术只有你能消化得了,办公文档的标准你了如指掌,你何愁不会成为业务的骨干与带头人呢?通用技术习得的人非常多,可替代性也比较强,但业务领域的技术知识,则还是需要沉浸在业务中,多年的摸爬滚打才能积累起来。通用技术与领域技术并不是互斥的,在修炼通用技术的同时,何不把自己所在业务所需要的业务领域技术与知识也一同学习,来个齐头并进呢?而且我相信,随着信息技术从消费互联网走向工业互联网,从新经济走向传统行业,我们所需要学习的业务知识、领域技术将会越来越多。而这类知识技术也将是技术人延长我们职业寿命非常重要的一环。

篇尾

文章写得比较曲折,并没有直接陈述什么才是正确的技术人产品观,而是通过四个大家常见的一些误区或者偏见,逐一阐述和批判从而得到个人认为比较正确的产品观。以上均为经验心得,如有冒犯或谬误,恳请原谅或斧正,也欢迎大家留言进行讨论。

Repository owner deleted a comment from alonehover Feb 4, 2022
@lcxfs1991 lcxfs1991 changed the title 前端工程师与业务领域知识 技术人的产品观 Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant