工作轻松搞定，感觉啥都会？如何职场跃迁

工作轻松搞定，感觉啥都会？如何职场跃迁技术群聊天的时候，发现不同技术群或者个人也有过的一种现象：每日工作自己现在可以轻松拿捏，接下去如何破局？感觉工作内容也简单，似乎没有很大的挑战性。我该如何突围，跃迁到职场或个人职业生涯下一等级？

遇到的另一个问题是，项目协作方面的问题项目内容很简单，感觉工作没挑战性

项目内容很简单，感觉工作没挑战性

技术群聊天的时候，发现不同技术群或者个人也有过的一种现象：每日的工作内容，以自己现在的能力可以轻松拿捏，感觉没有挑战性，不好玩。个人能力发展到这个阶段，如何破局、如何突围，跃迁到职场或个人职业生涯下一等级？

就像群里这个前端同学所说“前端我该学该搞的都搞的差不多了，还要怎么扩展？”。这似乎是他当下的问题。开发一般分为业务侧开发、基础技术开发（也就是架构组）。各有优缺点，不做具体讨论。

做为一个业务同学，参与需求评审、出技术方案、画 UI、写动画、设计组件、测试、交付、没有任何问题了，但是业务同学发展的一定阶段，就应该考虑底层技术或者工程化相关的东西。比如 CI、CD 打包构建优化、线上稳定性、页面秒开、首屏渲染时长的优化。说起优化，那必须要聊监控，要可度量，有数据支撑才方便聊到底优化了多少、优化了百分之多少，否则感性说“我这个很牛逼，优化了好多”那就不是工程师的该有的做事风格。要做前端监控就必须了解从地址栏输入一个 url 到整个页面渲染出来都做了什么事情，知道浏览器工作原理才知道问题症结在哪，才知道具体如何做优化。但是很多写业务的同学不知道或者一知半解，很难系统化、全局分析问题。那这个问题如何解决？那就是平时做东西之后，多问一步、多思考一步，为什么这么做、为什么这么设计？优缺点是什么？基于什么样的考虑采取了目前的方案？该方案上线一段时间后去统计分析数据、复盘下符不符合当时的预期，不是终极方案的话，要做什么样的调整。比如我就问了“tree-shaking”的原理是什么？ast 和 webpack 的一些 loader 如何工作的？可能就说不出来了。比如 React、JS、Weex、Vue、RN、Flutter 都有异常捕获机制、捕获之后如何还原出具体的案发现场，比如前端 js 打包就需要将 SourceMap 产物和版本号相关联做保存。后续方便符号化为原始数据。

基础技术也不是什么很神秘的东西。基础技术同学也有类似问题，感觉纯粹的技术项目很有趣，但没啥成绩、苦于晋升。因为价值不够或者只是处理了某个单点问题，没有扩散到解决一类问题，没有推展到面。比如研究出某个问题或者库，推广到不同业务线，宣讲接入落地。数据追踪并不断优化。缺的是价值闭环。缺的是业务 sense，可能技术上很赞，但业务同学不痛，或者不那么痛，接入的 ROI 不高。所以技术同学也要追踪业务问题，做到能解决实际业务问题（最好是很痛的业务问题）的技术项目。

所以平时应该多学多想多问为什、不设边界、不要只管好一亩三分地。如果只是做好本职工作，没有学“边界”之外的知识，没有事先储备好，要做某些事情可能连思路和一些可选项都没有。会比较被动，类似于需求执行者，而不是需求或者技术项目挖掘者

项目合作的痛

写单个技术问题可能你很在行，但是项目写起来可能不那么顺手。

看起来你是在写程序，其实你做的是产品，那就不是简简单单的编程，无法像刷Leetcode那样，刷一刷就熟了，而是要面对软件工程中的各种问题。

所以你面临的问题一直在变，大部分时候你不是在解决代码的问题，是在解决类似于：
- 我怎么把需求抽象成设计？
- 我该选择哪个技术方案？怎么找到最佳实践？
- 这个技术、框架我没用过，怎么快速用它实现我要的功能？
- 这个Bug我该如何定位和修复？
- 这个Bug是解决了，但是这段代码我怎么重构才能避免问题？

这里面其实最容易的反而是代码问题，要实现一个函数，搜索一下可能别人已经写好了，要解决一个Bug，用错误信息搜索一下可能StackOverflow已经有人解决过。

难的是你怎么把这些代码放在一起能满足你的需求，还能运行的高效，还要好维护，这些事不是ChatGPT或者AI短时间能替代的了的，需要很多年的积累。

其实也没啥捷径，只能是投入时间去不断地学习优秀的代码，不断地实践，比如实现功能，重构代码。

可能在一个项目中，你自己的部分写的很顺手，但是多人协作，你无法大展拳脚。


有同学被项目协作方气死“遇到太菜的程序员队友，会被坑死”。可能是站在群里闲聊的一种话题，也可能是真的比较无力吧，但出现这个结果，有些原因是被动的，不可规避，但是问题发生了，就需要规避。出现问题不可怕，持续出现同一个问题（单点问题）、同一类问题（单点问题的解决能力拓展到面，问题抽象分析解决能力，可能是流程可能是机制）

任何项目，不管是互联网领域的技术项目还是桥梁工程这种建筑项目，最重要的是“过程管理”和“风险识别”。kick-off 后规定好项目的几个关键节点，一般会从技术项目的参与同学中选定几个关键的 O，每日日会或者隔几天的项目站会（根据实际情况而定），需要同步项目进度、目前遇到的风险，需要依赖的外界因素是什么，正常吗？不正常的话，需要协助什么资源，尽早干预或者协助。所以作为执行者，中间的一个角色，不要生气，没啥用。

往往一个系统一个项目是多个团队协作的，所以需要识别上下游边界，对外该暴露什么能力或者提供什么接口（一句很熟悉的话就是接口先行），协议先制定清楚，依赖的节点是什么，各个时间节点交付物是什么？

作为个体，项目中应该做做好本职工作，如果出现风险，及时向关键的 O 同步问题。如果 O 不作为，自己可以主动推动上下游，或者向真正的项目经理同步问题暴露问题。要么遇到技术问题，自己有把握的话可以私下攻克，把风险给干掉。这些都是有效的。