z

zhouhua

V1

2022/09/23阅读:14主题:默认主题

想对年轻工程师说的话

今天跟团队里几个刚毕业不久的研发同学聊天,有一些感想,整理成对年轻工程师的几点建议:

业务是大家的,成长是自己的

绝大多数研发都是投入在业务需求的开发中,很多人在其中花费了超过 100% 的工作时间,却体现不出参与感。为什么?或许是一种流水线思维。富士康产线上的装配工人能意识到手下的 iPhone 有多强的产品力吗?或许吧。能左右 iPhone 的产品设计吗?绝对不行。但我们不同,我们并不是只要把分配的工作完成就好,我们与业务中各个角色紧密协作,共同推动产品的不断完善和演化。我们常常想的问题不应该只是,这个需求实现起来难不难,要几天;而更应该是,这个需求背景是啥,是不是合理,是不是完善,预期收益是怎样的,优先级是否合理。也许你会发现,很多问题你没办法回答,没办法评估,这只是说明你了解的信息还不够多,判断能力还不够强,要学习的内容还有点多。但一旦你向这个方向前进了,你的视野、参与度、重要性、owner 意识都会有很大的提升。这才是真正的成长。

如果我做了很多需求,业务蒸蒸日上,不算成长吗?如果现在给你换一个业务方向,你与 6 个月前开始做这个业务时相比,有不一样的地方吗?真正的成长并不是你对旧的业务需求有多了解,做了多少需求;而是这段时间里,你的知识深度和广度有没有提升,你的沟通能力、产品意识、思维方式有没有提升。而这些能力的提升与你具体做什么业务是无关的,也无法直接依赖日常的需求迭代自然获得,是需要我们主动学习和培养的。如果你还是觉得自己超过 100% 的时间都花在业务需求上,自己缺乏成长感,请尽快找到我,重新协调你的工作内容。请一定要主动关注自己的成长,因为这是你自己的事情。

敏锐观察,碎片思考

研发团队在践行『贴近用户,助力用户』,可有人说,我不知道怎么培养产品 sense;我也不知道用户反馈该怎么落地;我觉得 prd 写的内容都对,但看看别人的评论又觉得说得好有道理,为什么我想不到……

我感觉或许我们不用对自己提多难的要求,我们只要多留意观察身边的现象,多进行一些简短的思考就够了。比如两款你常用的 app 都有同样的功能,交互却不太一样,不妨自己想想这是为什么,是用户群体不同,还是产品调性不同,还是别的什么原因;比如最近玩一个游戏比较上瘾,不妨想想这个游戏吸引你的地方是什么,比同类做得好的地方是什么;等等。你不用真的想出一个绝对正确的答案,观察到现象,并有自己的思考,这样做就够了。

好记性不如烂笔头

技术的学习,就跟别的技能学习一样,看一遍,脑子说『我会了』,但实际上,你不完全会。我的一个体会是,当日常工作中遇到问题,不要轻易放走它。也许你查了一些资料,已经搞懂了这个问题,但我还是建议你,把这个知识点记录下来,写一篇文档,详细地解释一些技术细节。当你把脑中的描述写到文档里的时候,你会不由自主地怀疑自己:这个概念是我理解的意思吧?这句表述准确吗?这个技术名词我还不太了解,别人问起来怎么办?当你把这些所有的疑问和不确定都一点点变成肯定和确定,那么在这个过程中,你学会的不仅仅是这一个知识点,而是纲举目张,掌握了以这个知识点为起点的知识网。我认为用这种方式来学习,来提升知识的深度和广度,不仅效率高,而且未来也能回顾。

技多不压身

有的人可能还会有一种担心:我现在做的事情、用的技术栈值得我长期投入吗?我的回答是不要怕投入。我们大多数人都难以在一个技术领域有深度的理解;少数人可以在一个技术领域里有深度的理解。但是,真想在一个技术领域里做到极致,反而对知识的广度有更深的要求,需要精通很多领域才有可能。不过这不是我想说的重点,我想从另一个角度来说:视野。我们常常面临技术方面的选择,该怎么选择呢?一般来说很简单:这项技术能支持的功能点大于需求所需要的功能点就可以了。但这样对吗?实际上应该考虑的因素还有很多,比如架构的合理性、学习成本、研发成本、维护成本、替换方案的迁移成本、技术更迭的趋势,甚至后续招人的难度等等。有些因素的评估非常主观,信赖决策者的认知,而如果你本身在多个不同技术领域都有涉猎,那么你的判断会更加地立体,那么在这些场景,你的决策会更加地合理。

分类:

其他

标签:

生活感悟

作者介绍

z
zhouhua
V1