文章背景
作者这段时间考虑跳槽，被问的非常多的是一个问题，为什么考虑跳槽？
在和前ld的一次请教中，我提到一点原因是：认为当前被分配的工作内容技术复杂度不够，不利于晋升。前ld在结合一些我给的上下文输入后，认为我在当前位置不够主动，凡事都在等，想的太多，做的太少，换工作解决不了我的问题。
交流一番后，我认为需要对当前自身职业发展的情况进行一轮复盘，幸运的是这时候想起了公司内某位大佬关于工程师成长曾有一个经典分享，找出来再次观看后，惊喜地发现解决了很多思想上内耗的点。想记录其中一些引起共鸣的观点，进行分享。
目标是自己选的，别人的只是参考
怎么定义成长？成长是需要自己定义的。
成长的定义无关乎内容的对错，核心在于人大多在走向自己定下的目标时，才感到自洽。
解决问题
怎么更好地解决问题？
反复自省，你要解决的是什么问题？你的目标是什么？当前的问题是你真正需要解决的问题吗？尽量挖掘出问题背后的根本诉求（参考马斯克的第一性原理：从最基本的原理出发，通过逻辑推理找出问题的本质和解决方案）
基于问题深挖来扩大scope
通过深挖问题的根本诉求的过程，你可以扩大scope。 举个例子：
- 改进捕鼠器
- 改进捕鼠器的部署方法
- 发明灭鼠药
- 改进灭鼠药的效果
- 成立粮食免危害小组
一开始交给你的问题只是捕鼠器效果不好，解决一下。随着问题的深挖，结合保护粮食这个出发点，可以发展到成立粮食免危害小组，从scope层面看，比最开始的问题已经大很多了。
新人成长
- 【基础】重视自己的事情，努力做到最好，赢得信任
- 如果你不觉得自己做的事情重要，就没有人觉得
- 想要获取别人的信任，需要先付出，需要先积累
- 把简单的事情做到极致，就是最有挑战的工作
-
不管什么问题，都可以和ld沟通，解决，包括成长、绩效等，不要羞于沟通。
-
如何确认当下的工作方向？
- 向上：了解ld，了解他在解决什么问题，有哪些问题你觉得可以做的更好，或者有新的办法
- 左右：了解其他同事做的项目，扩展自己的知识面
- 向外：了解业界的新技术、工作或业余时间写点demo，去体验不同公司的新产品、感受产品，找bug、改进点等
组织架构——业务or技术
无论业务还是技术团队，都应该以建设服务型团队为目标。
产品型团队
目标: 产品目标（DAU、时长、收入）
评价人: 产品Owner（通常是PM）
支持方: 基础服务组等
可能的误区
- 和产品沟通是否充分?
a. 是否目标一致
b. 是否相互了解 - 合作是否充分
a. 探索不足，支持不够？
b. 无脑支持，思考不够？
事实
- 鼓励事情层面讨论，最终有Owner。
- RD、PM都会积累对产品的贡献。
- 产品贡献 决定了 影响力。
- RD需要足够人力去支持探索。
可能的变化
- 和PM沟通不足
进行接口建设，建立例行沟通，指派POC完善交流、同步机制；
建设看板、重点项目进度看板等透明化组内工作 - 对产品理解不足
主动学习、体验产品，和PM产生更多的交互，尝试在小点上，提些建议 - 支持不足
招聘，多角度思考，见微知著，形成更大的方向和规划来构建团队。（激进建设） - 会有更多成功率低的项目进行
这是正常的，也是需要的，但需要控制比例，敢于刹车
基础技术团队
目标：提供技术支持，最终支持产品
支持方：其他基础技术团队，或者外部供应商
可能的误区
-
是否真正明确，如何（谁）来评价你的工作-你的客户到底是谁？
-
标准不够高
举例（错误率要求）：应用层95%，应用层-1 99%，应用层-2 99.9%，应用层-3 99.99% -
假设大家都懂你的领域，过多暴露细节，接口不够傻瓜，易用。
可能的变化
- 真正了解你的客户，包括谁、如何评价
a. 大客户定期沟通
b. 广泛客户建立反馈通道（比如问卷，内部系统反馈） - 有宏观了解——透过上层，大致了解产品的全路径，有发现分解错误的可能性
- 根据服务层级、设定合理的质量要求
尤其是非常基础的服务，要非常高的标准 - 主动对技术普及加强，增加信任度和相互理解
- 团队，考虑加强售前、客服、测试。可以设置专人专岗
经典困惑
-
我疲于应付，没有时间思考
要有良好的时间管理意识。合理划分时间，考虑如何改进手头的工作，如何看到更多的问题。 -
我觉得无事可做
那是你看不到。去学习、了解。当然，也可以考虑换个方向。 -
和lead相处不满意，怎么办？
发现原因，通常沟通不够有效，是最主要的原因——双方了解信息或者预期不一致。
a. 建立信任、有效沟通，换位思考
b. 不要恶意假设 -
技术、产品（综合型）、管理怎么选？
- 先了解自己
更在乎？成就（回报、名气） ，兴趣，前者适合产品，后者适合技术
更擅长？ - 管理非常重要，纯管理岗位相对少，更多是综合性发展，过程中不断加强管理能力要求
