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等的一些相关知识。而业务领域技术，则专指该业务领域特别所需而其它业务领域可能不太需要的技术，比如直播行业需要直播录播、视频编解码等相关知识和技术；金融行业需要学习相应的股票、债券等知识，在国内券商甚至需要考证券从业人员资格证书；支付行业需要学习央行相关的法律规定还有支付的相关模型（读了内网的跨境金融技术深深感叹）还有各种数据库和各种锁保证交易和金额的一致性等等。
刚入行的年轻技术人总是希望学习更多的通用技术知识，但对业务领域的知识则表示抗拒，还发出灵魂一问：学了这些我到别的公司能用上嘛？我的回答是：有的用得上，有的用不上。比如视频技术，如果不在直播行业打工了，去长视频混口饭吃是绝对没问题的，但你说一旦跳槽到金融行业则完全用不上了。
有这样的想法很正常嘛，年轻的小伙未来的路还很长，可以尝试更多自己的兴趣，有很多转变赛道的机会，但你有没有想过，如果你成为某个业务领域的技术专家，这个支付模型整个公司只有几个人懂，核心视频编解码优化技术只有你能消化得了，办公文档的标准你了如指掌，你何愁不会成为业务的骨干与带头人呢？通用技术习得的人非常多，可替代性也比较强，但业务领域的技术知识，则还是需要沉浸在业务中，多年的摸爬滚打才能积累起来。通用技术与领域技术并不是互斥的，在修炼通用技术的同时，何不把自己所在业务所需要的业务领域技术与知识也一同学习，来个齐头并进呢？而且我相信，随着信息技术从消费互联网走向工业互联网，从新经济走向传统行业，我们所需要学习的业务知识、领域技术将会越来越多。而这类知识技术也将是技术人延长我们职业寿命非常重要的一环。
篇尾
文章写得比较曲折，并没有直接陈述什么才是正确的技术人产品观，而是通过四个大家常见的一些误区或者偏见，逐一阐述和批判从而得到个人认为比较正确的产品观。以上均为经验心得，如有冒犯或谬误，恳请原谅或斧正，也欢迎大家留言进行讨论。