今天跟团队里几个刚毕业不久的研发同学聊天，有一些感想，整理成对年轻工程师的几点建议：
业务是大家的，成长是自己的
绝大多数研发都是投入在业务需求的开发中，很多人在其中花费了超过 100% 的工作时间，却体现不出参与感。为什么？或许是一种流水线思维。富士康产线上的装配工人能意识到手下的 iPhone 有多强的产品力吗？或许吧。能左右 iPhone 的产品设计吗？绝对不行。但我们不同，我们并不是只要把分配的工作完成就好，我们与业务中各个角色紧密协作，共同推动产品的不断完善和演化。我们常常想的问题不应该只是，这个需求实现起来难不难，要几天；而更应该是，这个需求背景是啥，是不是合理，是不是完善，预期收益是怎样的，优先级是否合理。也许你会发现，很多问题你没办法回答，没办法评估，这只是说明你了解的信息还不够多，判断能力还不够强，要学习的内容还有点多。但一旦你向这个方向前进了，你的视野、参与度、重要性、owner 意识都会有很大的提升。这才是真正的成长。
如果我做了很多需求，业务蒸蒸日上，不算成长吗？如果现在给你换一个业务方向，你与 6 个月前开始做这个业务时相比，有不一样的地方吗？真正的成长并不是你对旧的业务需求有多了解，做了多少需求；而是这段时间里，你的知识深度和广度有没有提升，你的沟通能力、产品意识、思维方式有没有提升。而这些能力的提升与你具体做什么业务是无关的，也无法直接依赖日常的需求迭代自然获得，是需要我们主动学习和培养的。如果你还是觉得自己超过 100% 的时间都花在业务需求上，自己缺乏成长感，请尽快找到我，重新协调你的工作内容。请一定要主动关注自己的成长，因为这是你自己的事情 。
敏锐观察，碎片思考
研发团队在践行『贴近用户，助力用户』，可有人说，我不知道怎么培养产品 sense；我也不知道用户反馈该怎么落地；我觉得 prd 写的内容都对，但看看别人的评论又觉得说得好有道理，为什么我想不到……
我感觉或许我们不用对自己提多难的要求，我们只要多留意观察身边的现象，多进行一些简短的思考就够了。比如两款你常用的 app 都有同样的功能，交互却不太一样，不妨自己想想这是为什么，是用户群体不同，还是产品调性不同，还是别的什么原因；比如最近玩一个游戏比较上瘾，不妨想想这个游戏吸引你的地方是什么，比同类做得好的地方是什么；等等。你不用真的想出一个绝对正确的答案，观察到现象，并有自己的思考，这样做就够了。
好记性不如烂笔头
技术的学习，就跟别的技能学习一样，看一遍，脑子说『我会了』，但实际上，你不完全会。我的一个体会是，当日常工作中遇到问题，不要轻易放走它。也许你查了一些资料，已经搞懂了这个问题，但我还是建议你，把这个知识点记录下来，写一篇文档，详细地解释一些技术细节。当你把脑中的描述写到文档里的时候，你会不由自主地怀疑自己：这个概念是我理解的意思吧？这句表述准确吗？这个技术名词我还不太了解，别人问起来怎么办？当你把这些所有的疑问和不确定都一点点变成肯定和确定，那么在这个过程中，你学会的不仅仅是这一个知识点，而是纲举目张，掌握了以这个知识点为起点的知识网。我认为用这种方式来学习，来提升知识的深度和广度，不仅效率高，而且未来也能回顾。
技多不压身
有的人可能还会有一种担心：我现在做的事情、用的技术栈值得我长期投入吗？我的回答是不要怕投入。我们大多数人都难以在一个技术领域有深度的理解；少数人可以在一个技术领域里有深度的理解。但是，真想在一个技术领域里做到极致，反而对知识的广度有更深的要求，需要精通很多领域才有可能。不过这不是我想说的重点，我想从另一个角度来说：视野。我们常常面临技术方面的选择，该怎么选择呢？一般来说很简单：这项技术能支持的功能点大于需求所需要的功能点就可以了。但这样对吗？实际上应该考虑的因素还有很多，比如架构的合理性、学习成本、研发成本、维护成本、替换方案的迁移成本、技术更迭的趋势，甚至后续招人的难度等等。有些因素的评估非常主观，信赖决策者的认知，而如果你本身在多个不同技术领域都有涉猎，那么你的判断会更加地立体，那么在这些场景，你的决策会更加地合理。
