一直都是写关于技术的一些东西，从来没想过我会写一篇与技术没什么关系的文章，因为在之前的我看来，这种文章完全就是假大空

技术至上？

三年前我毕业进入第一家公司，个人很水的技术能力让我经常在实际的开发工作中捉襟见肘，于是就想着一定要尽快提升自己的技术水平，每天都在公司待到很晚，除了做需求就是自我学习，在这种情况下，我几乎所有能坐在电脑前的时间都用在了技术上，这就造成了一种后果，那就是我只关心技术方面的东西，其他的我一概不管，并且越来越严重

评审需求的时候，我不关心pm想要做什么，也不关心需求的目的是什么，更不关心是否是不合理的需求，我只考虑怎么从技术上实现pm的需求，哪怕是再复杂再不合理的需求我也一定要用我的技术手段去实现，甚至以此为荣，我认为这是体现我个人能力的方式，有些时候我的组长因为考虑到一些实现比较复杂，主动给我说一些简单的实现方案，我反而内心还有点鄙视，觉得组长太老油条了，什么复杂需求，不存在的，多给我一天的时间我就能给你实现出来

我相信很多做技术的小伙伴，都跟我有过类似的想法，但是三年过去了，回头想想，再思考一下现在，现在的我更想学习一些跟技术不那么相关的东西，比如业务

技术还是业务？

相辅相成

曾经的我认为，技术和业务就是两条不相干的路，我投入在业务上的时间多了，那么在技术上的时间必然减少，与其技术、业务两手抓，做出两个50分的成果，我作为一个技术人员，不如只抓技术，争取做出一个100分的成果来，但实际上这种想法有点天真

首先，除非你天赋异禀，否则很难将一件事情做到极致的100分，甚至80分都很难；其次，技术跟业务并不冲突，花费一些时间在琢磨业务上，并不会减少多少你在技术上的投入度，相反的，二者是相辅相成、互相促进的关系，是 1+1 大于 2 的组合

因为能够发现业务的痛点，所以想用技术去解决，带着明确的目的去学习与尝试，必然会有更高的效率；因为有了足够强的技术，所以能够解决更大的业务问题，获得更多的成就感

如果你没有做业务的主动意识，而是被业务方赶着走，这种行为就是搬砖，反之，如果是你推着业务走，让业务方因你而改变，那么就是你赋能了业务

经常看到一些三到五年工作经验的前端很迷茫，明明知道路已经走到底了，却不知道下一步该怎么走，于是开始尝试着去改变，但路子可能走得不太对，例如看Flutter比较火，所以跑去学Flutter，看到WebGL可能有前途，于是跑去学WebGL，甚至有的人跑去学java/python

不是说这些尝试新事物的行为不好，相反的，很好，敢于尝试敢于行动无论什么时候都是值得鼓励的事情，但是得明确你做这些事情的目的，考虑一下ROI，比如，你看好Flutter未来的发展，并计划好将来投身于Flutter领域，于是先自己学起来，打好基础为将来进入一个Flutter团队，甚至是在自己的团队内推广Flutter做好准备，那么显然是正确的思路

但是如果你只是觉得现在的工作到瓶颈了，觉得大家都在吹Flutter，反正自己也不知道要干啥，那就跟风学学吧，或许可能将来就派上用场了，到时候自己一鸣惊人，那么这种思路其实就有点跑偏了，Flutter确实能带给你新鲜感与学习到新东西的成就感，但这并不能解决你目前工作碰到瓶颈的问题，你只是选择去回避它而已，leader给你打绩效并不会看在你学会了Flutter的面子上，就手下留情，除非你团队真的在用Flutter并且你也参与其中做了贡献了

同样的，作为一个前端问如果会一点java/go会不会更有竞争力？我的答案是，聊胜于无（会一点当然最好，但不会也没关系）

你毕竟是前端，如果在前端面试的时候，连前端的基础知识都答不好，你哪怕会背Spring源码又有什么用？而如果你能做到无论是基础题、算法、项目经验都对答如流，跟面试官谈笑风生，谁还关心你是否知道什么是高并发？

拓展壁垒

技术这条路可以很宽广，但对于绝大多数人绝大多数场景来说，能够被实际使用到的技术只是一小部分，特别是前端，相比于后端、算法来说，技术含量较低，更倾向于技术的广度而非深度

可能从业三五年的C++程序员都还会写出有语法错误的C++代码来，但在前端很难发生这种事情，稍微勤快点的应届生毕业半年就不该再写有语法错误的前端代码了，有bug基本上也都是业务逻辑bug，一个五年工作经验的C++程序员和一个只有一年工作经验的C++程序员，他们的技术水平可能有着本质上的差距，但如果换成前端程序员，很可能两人的技术水平就是差不了多少了

但是很显然，就算是前端程序员，我们一般情况下还是会认为五年工作经验的会比一年工作经验的能力更强，技术水平可能二者差不了多少，差的是其他方面

技术广度吗？

可能不是，有较大技术广度的人在做技术选型的时候，可以有更多的选择与搭配，但这种能力并不是必不可少的，公司团队作战，很少会因技术栈的选择而产生困惑，你或许会因为从业时间较长，所以学会了更多的技术，例如React Native、Flutter、WebGL等，但这些更多地是赋予你切换技术栈的能力而非增加你个人总体的技术实力，如果你公司不用React Native、Flutter、WebGL，那么你会这些也没多大用，也没人会关心

如果你公司真的就用这些技术了呢？不好意思，这些又不是什么很难的东西，并不存在技术上的循序渐进，给一个应届生一段时间，他也能学会，一般情况下，一个部门或者团队也不可能用很多种技术栈，技术广度到达一定程度之后，再继续往上增加的意义只会越来越小

技术深度吗？

或许是

但是这个很难，还是前面说过的话，除非你真的是擅长技术，否则你很难有深入的机会，特别是前端这个领域，99.9%（可能需要在小数点后面再加几个9才符合实际）以上的场景，根本不需要考虑什么深度，也根本不需要考虑什么性能什么优化，我实在是想不到哪些前端的工作场景下，会需要用到编译层面或者操作系统层面的技术攻关

做出（注意是做出不是会用）小程序或者是做出React这种级别的东西，对于前端技术确实是一个重大考验，但是绝大部分人跟这些根本就没啥关系

真正需要深入到底层，比如编译层面或者操作系统层面，这种已经不能称为是前端开发了，而能深入到这个地步的技术人员，大概率也不会是前端出身

工作经验？

是，也不是

如果你工作三年，只是按部就班地搬了三年砖，那么你可能只是一年的经验又被你重复了两年而已

真正好的工作经验应当是持续学习与进步的，不仅限于技术上的进步，如何写好易于维护的代码、如何用技术能力保障业务的稳定性、如何引领新人快速融入团队，都是不可或缺的东西，想要获得这些能力，需要时间，但更需要你的主动探索与实践，而这些是无法速成的东西，也是你作为一个技术老鸟，能跟应届生真正拉开差距的地方

而无论是技术水平、技术广度、工作经验，它们之所以有价值，归根结底，还是因为它们都有服务业务的能力，所以一切都是围绕着业务展开的，既然无法避免，那么自然是越早学会游戏规则越好

什么是业务

在前三年，经常有资历更高的同事跟我提起业务这个词，听得多了，我有时候也想去了解它，但总是发现这个东西太虚无缥缈了，编程语言的语法、关键字、设计模式、算法我都可以实实在在地看到并运用，但业务到底是什么？我怎么学？我又该怎么去关注业务？

总之很苦恼，老是有人跟我说业务，但我却无从下手，硬着头皮去模仿，最终也只是学了个皮毛，于是逐渐放弃

目前在第二家公司入职的团队，相比于之前来说，业务压力大很多，几乎没法再像之前那样优哉游哉地搞自己的技术研究，然而在这种环境下，反而加速提升了我对于业务的理解，也明白了为什么之前那么多人跟我说业务很重要，但没有一个人能教会我到底什么是业务，因为这个东西真的很难说清楚，或者换句话说，其实每天都有人跟你说什么是业务，但因为你自己本身无法领悟，所以你觉得他们什么都没说

在绝大部分情况下，技术都是要为业务提供服务的，这句话蕴含着两层意思

第一，技术的唯一目的就是支撑业务

第二，业务并不仅由技术支撑，还包含了其他很多方面

业务是一个商业公司的命脉所在，而技术只是支撑业务的关键之一，所以业务真的很重要

那么，什么是业务其实也就很好理解了，你的技术所服务的就是业务，而你能够让业务蓬勃发展的一切正向能力（包括但不仅限于技术能力），都是业务能力

前端如何赋能业务

肯定有人会吐槽我说了半天还是啥都没说，没错，确实是这样，对始终不明白业务是什么的人来说，别人说得再多也很难理解，对于已经理解的人来说，业务就是业务，根本没什么可说的，可能真的就需要你自己领悟才行，或许某一天你自己就突然明白过来了

很难说清楚业务这个词到底是什么，但工作中处处是业务

前端如何赋能业务的话题比较大，但具体的例子却很多

运营页面自动搭建

运营手段对于C端产品来说是很重要的，运营迭代的速度也是影响产品发展最直接但也是最实用的关键因素之一，比如天猫618盖楼活动，美团的满减活动等，这些都是很常见的运营手段，几乎任何直面C端用户的产品都少不了这些

而这些运营活动往往是少不了各种各样前端层面的用户玩法，可以说是比较依赖前端的一个业务了，那么作为一名前端开发工程师，如果你的目标只是实现业务方提过来的具体的运营需求，当然也算是合格了，毕竟是完成了自己职责，但可能还不够

来一个运营页面你就做一个运营页面，来两个你就上两次线，难度倒是没什么难度，就是避免不了要走一遍整套开发流程，于是聪明的人就想到，是否可以把这种固定路径搬砖的行为自动化，于是运营页面自动搭建的概念就出来了，以后运营页面的开发与上线都不需要研发参与了，直接让运营来搞定，又快又稳又好，以前一个运营活动需要评审、排期、开发、验收、上线等多个流程，现在简化到只有验收和上线两个节点，极大地提高了生产力，这就是对业务的成功赋能

那么你能做什么呢？

业内知名的运营页面自动搭建项目有很多，例如阿里云凤蝶、阿里飞冰等，但是这些不一定完全适合你的公司，因为运营页面跟具体业务是强相关的，特比是C端，业务场景不同，运营页面自然不可能一样，如果你公司并没有这么一套运营页面自动搭建的工具，并且业务上又高度依赖于线上运营，那么这就是你的机会

adapter

移动端已成为主流，前端开发主要聚焦于app、m、小程序三端，而小程序端又可以细分为微信小程序、字节小程序、百度小程序、支付宝小程序、快应用等，如果为这些端每一个都专门开发一套代码，显然会对人力产生较大的需求，如果这么多端全做了的效果是 1+1等于2，那还算能说得过去，但现实情况肯定是1+1小于2的，如何能以最小的成本覆盖那么多渠道，就是一件很迫切的事情了

于是，多端适配的解决方案出现了，它极大地提升了开发效率，不仅又快又好地完成了一套代码多处运行这件事，同时还间接地为公司节约了一大笔研发费用，价值毋庸置疑

那么你能做什么呢？

类似于Taro这种多端适配框架，确实适配了很多东西，但适配的都是开放的东西，例如微信小程序、字节小程序、ReactNative等，这些都是对外开放的开发平台，但是你公司自己开发的app，例如抖音app、支付宝app，肯定有自己私有的一些协议，比如唤起app、打开页面、调起拍照功能等，这些私有协议一般是不对外开放的，如果你不仅想让一份代码运行在小程序、m端，还想让这份代码也能在app端正常运行，那么适配app这部分的能力，显然需要公司内部员工来完成

组件库

哪怕是在前端刀工火种的时代，Bootstrap 这类前端框架就已经大行其道，到现在前端组件化大行其道，各类前端组件库层出不穷，本质上都是为了提升开发效率，一些通用的UI与逻辑拿来即用，作为开发者只需要专心业务逻辑即可

但也并不是说 iview、ant-design这些组件库就可以横行无忌了，pc后台项目还好，但如果是移动端C端的产品，对于组件库的选择就需要谨慎很多了，特别是那些知名度较高或者场景较为鲜明的产品，对于风格的要求比较高，被广泛使用的开源组件库并不一定能满足要求，比如，支付宝和微信显然都有自己独特的UI风格，开源组件库不可能专门去适配某一个产品的风格，否则就失去了通用性，而支付宝或微信这类具体的app也不可能为了省事就放弃自己的风格直接用开源组件库，所以打造专属于自己的组件库就成了一件很明显的事情

实际上用户量稍微多点的C端产品，对于专属组件库都是存在需求的，所以如果你所在公司业务场景主要在移动端，而且你发现还没有专属于公司内部的组件库，那么不要犹豫，马上放手去做，这么明显的事情你不做，早晚有人做

其他的还有很多，例如脚手架、国际化、工具函数库等，都是一些有实际需求的东西

从点滴入手

可能你所在的部门比较成熟，一些大的能做的事情都早就有人做完了，先发优势羡慕不来，也不是说就没有任何机会了的，大的事情搞不了，小的事情肯定是一直存在的

我之前的一篇文章 # 两万字长文-电商sku组合查询状态细究与实现，主要探讨如何在前端层面解决 sku的选择问题，算法稍微复杂一点，有人评论说不需要那么麻烦，前端啥也不计算，等到用户提交的时候，再让后端查询数据库，没有的话就报错提示用户

这个做法当然是可以的，但很明显，从业务角度，肯定不如在前端实时计算来的要好，如果其他人只会让后端查询数据库来解决这个问题，而你能做到前端实时计算，那么在业务看来，肯定你的贡献更多

还有一篇文章 # 前端UI设计稿对比工具 - chrome+webpack插件，这个插件可以用于解决UI稿还原度问题，降低了UED与FE之间来回 battle的频率，提高了人效，对于业务肯定是有促进作用的

再比如，你了解到业务所属的一个移动端项目，将来很可能需要跨端，那么你在立项的时候就前置使用跨端框架，或者渐进式地后续引入跨端框架，在将来某天真的需要跨端的时候无缝接入，那么在业务看来，前端省了很多事，因为这个事情 pm对于技术不是太明白，所以他可能一开始根本就不会提这个事情，那么就需要你主动去问才能发现

再比如，新增一个页面，你根据PRD内容感觉这可能是一个通用的页面，将来可能会承载很多类似的通用功能，那么你跟 PM确认了下，发现果然是，那么你在做技术设计的时候就可以按照通用业务页面去做，后续真有类似续期的承载，前端一键接入，无需开发量

再比如，很常见的一个事情，即文档的输出，页面对接文档（页面路径有哪些、页面上有什么功能、具体页面主要由谁负责、怎么接入、需要哪些前提条件）、埋点整理文档（都有哪些埋点、埋点代表什么含义、在哪个平台上可以查询）等都是业务感兴趣的东西，过来问你要这些东西的时候，直接一个完整的文档甩过去，你省事对方也省事，并且在对方看来，肯定是对于业务有一定了解才能整理出这个东西的

这些东西虽然工作量没有上述那些技术项目那么大，但却需要你对业务有更深的了解，因为你不了解业务的话，你是不可能发散到这些方面的，或者说是有心无力

前端如何参与业务

在绝大多数公司，一般都是由pm来主导产品，前端毕竟是开发人员，想要在产品层面上跟产品经理 battle，无异于是业余挑战专业，既不合适也没有胜算，但并不意味着开发就完全无法参与到业务中去了，pm对于整个产品的宏观全貌肯定把握得比你深，但在一些细节的部分就不一定比一线实际开发人员清楚了，而细节往往是从具体的需求中体现的

需求一般是由产品提出的，但需求往往需要开发来实现，而产品提需求的目的是为了实现这个需求，侧重于产品层面，目的性较强，开发层面的事情还需要开发来评估，那么这个gap天然就是开发参与业务的机会

提需求

提需求并不完全是pm的特权，作为开发同样可以提需求，业务需求或许不是那么容易就能提出的，但是技术需求却是你作为开发人员的专利

作为前端，肯定是要关心自己所做前端页面的一系列的指标的，主要围绕性能、交互与风格样式这三个方面，页面加载快不快、交互是否流畅、风格是否舒适统一，都是需要时刻关注的点，出了问题你就要去主动解决它，而不是等pm来找你，这是技术上的事情，该由你来负责

所以你可以光明正大地提技术优化需求，不敢保证一个流畅的页面会让用户忠诚度更高，但一个糟糕的页面肯定会让用户流失的（除非你是银行网站），所以技术需求表面上是技术需求，实际上也是为了业务考虑

需求可大可小，小的如样式风格统一，大的则可以建立一个前端技术项目

例如，产品希望通过持续的运营活动迭代来维持用户活跃度，那么他想要的就只是开发人员能够按时完成运营页面的上线，至于开发怎么去做这件事他不关心，只要达到产品目的就行

那么作为前端开发，你意识到运营页面可以做成可配置化的形态，所以就需要你去跟pm进行商讨，例如这种做法是否可行、配置后台做成什么样、需要预置哪些模板、需要预置哪些页面能力、数据存储的形态等

再进一步，你还可以继续跟产品确认，这这些运营活动将来是否可能会在多端铺开，如果是，那么你就还需要考虑多端兼容的问题了

看起来，本来一个简单的运营活动，没啥难度也没啥工作量，应届生一天就搞完了，然后你作为开发参与进去，硬是把这个需求拆成了好几个大项目，好像是自己没事给自己找事

确实，有些人就擅长无中生有，整天搞些看起来高大上实际上屁用没有的东西，但也别一棍子打死一群人，无中生有并不一定是贬义词，如果运营搭建后台和多端适配确实是有需求的，那么这件事情早晚得要做，而你能提前看到这一点并且提前做好准备，为业务的平滑过渡提供了保障，这就体现出了你工作经验的价值

砍需求

pm提出的需求并不一定就是合理的，一个负责的技术人员对于需求应当有一定的判断力，对于不合理的需求要坚决说不

这里的意思并不是让你去鸡蛋里挑骨头给pm的工作制造人为障碍，相反的，而是给出更好的见解，共同为业务负责

比如，你事先和产品约定好了一套解决方案，在某个具体的功能上，产品发现数据不达预期，于是想要你专门为这个功能开发一个特定的逻辑以提升数据，这件事情可能确实可以做，并且技术上也不难实现，但作为开发人员你还要为整体的技术方案负责，约定好了的方案，为了某个特定的功能添加额外的逻辑，会不会对整个技术方案造成破坏？会不会因小失大产生长远的负面影响？还有没有其他更好的解决方式？

看起来，似乎有点推诿扯皮的意思了，但如果你的出发点确实是为项目考虑，并且理由足够让人信服的话，谁又能说你是在推诿扯皮呢？

能够有理有据地阻止不合理的需求，将有限的人力、时间花费在更重要的需求上，才能更好更快地推进业务

只是前端？

很多人都说后端比前端更加贴近业务，理论上似乎是这样，但我的看法是，具体到个人的话，还是要看你自己的态度，如果后端只是日复一日地CRUD，既不主动了解业务，也不赋能业务，再贴近业务又有什么用？同样的，前端如果只是甘心于当切图仔，哪怕每个需求pm都专门给你讲得清清楚楚也没用

所以还是要看个人的主观能动性，在技术之外，要主动去看更多的东西，我不是让你去一行行看后端代码，当然，你有时间看也可以，只是没必要，业务代码没什么好看的，反而看得脑壳疼，业务由一个个需求迭代而来，那么想了解业务就从需求着手

pm提了一个需求，你不仅要关心前端需要切哪些图片做个什么样式使用什么组件等技术问题，还要弄明白pm为什么提做个需求，这个需求解决了什么问题，涉及到的上下游关系等业务层面的事情

跟后端约定接口字段，不仅仅是盯着后端给你返回所需的字段就行了，还要多考虑一些，例如，接口是否有可复用性、字段是否冗余、有没有必要做接口的拆分或整合、前端如何保证接口出错的情况下页面仍旧是可被用户接受的？有些可能应该是后端应该做的，但你不能保证所有人都尽职尽责，那么你就可以多关心一些事情

当需求评审的时候，pm更多地询问你的意见，当约定接口的时候，后端更习惯你来制定接口规则，当你关心的事情越来越多范围越来越大，这个时候，你还觉得前端只是切图仔吗？

如果你成了最熟悉业务的人，那么团队中其他成员遇到不理解的业务问题，第一个想到的肯定是你，那么你在这个团队中就有了具有实质性存在的价值，而且是不容易被替换的那种

需要注意哪些事情？

技术是立身之本

上面说了那么多业务多么多么重要的东西，可能会引起一些人的误解，觉得既然是这样，那我赶紧 all in业务得了，反正技术似乎也不重要

这种想法也是错误的，你既然是一名技术人员，那么技术对你来说就是本职工作就是立身之本，想要往外延伸到更多的领域，首先必须要先把自己的根基打牢才行，若是连技术这点事情都没整明白，就嚷嚷着要搞什么业务和管理，可能最后得到的只是一盘散沙

那么如何平衡这二者的关系呢？

对于前端这一行来说，我的建议是，前两到三年，更多的精力（最起码80%以上吧）投入到技术上面，保证在两到三年内在前端技术层面，能够达到合格的状态

什么是合格的状态？量化一点地说，就是网上正常场景下的任意前端面试题，你有80%以上的把握能答出来，可以实现工作上提出来的任意前端需求，能够保证自己所写代码项目的稳定性和可扩展性，前端领域新出现的技术你都能快速上手并且理解其原理，对于大部分人来说，这个应该不难

然后，剩下的20%用来关注业务，注意是关注业务，至于参不参与不太重要，因为两年工作经验之内的菜鸟，在业务上是没有多少话语权的，并且思考方式还不成熟，这个阶段更多地是观察，观察业务是如何运转的，观察其他更高级别的人是如何参与业务的，学习他们身上的优点，进而形成自己的思考观念

两到三年后，你差不多也升了职级，在团队中的地位有了少许的提升，你说话的分量也能引起其他人的注意了，这个时候，你再开始尝试着去参与业务，将自己在前两年学到的、总结下来的技巧和观念，真正地运用到业务中去

不要闭门造车

无论你想做什么事情，首先都要以开放的心态去面对，而不是打定了一个主意后就立马埋头苦干，在做之前先倾听其他人的意见，看看是否有更好的解决思路

比如，你想做一个前端错误监控系统，你可能从网上查了详细丰富的关于前端错误监控的资料，然后觉得信心满满可以开干了，然后你自己一个人起早贪黑默默干了几个月，终于弄出了一个像样的项目，这个时候你拿出来准备一鸣惊人的时候，结果你leader却满脸诧异地跟你说你难道不知道有Sentry这个东西吗？

或者你在网上查找前端错误监控资料的时候，无意间发现了 Sentry，于是决定自己先上手熟悉一遍，弄清楚了所有开发部署流程之后，拿出来准备干一票大的，结果你leader满脸诧异地跟你说你难道不知道隔壁部门前段时间就已经基于 Sentry 搞出了一套适用于咱们公司的监控系统了吗？

所以，一定要多跟外界进行交流，一方面是为了能从外界获取更多的信息，另外一方面则是让其他人知道你在做什么事情(至于为什么要让其他人知道你在做什么事情，这个各位自行领悟)

用数据说话

作为前端，你可以提需求，也可以砍需求，甚至可以对后端指手画脚（当然，我更建议你谦虚一点），但前提是一定要有足够的底气，而实际的数据可以赋予你这个底气

你要提一个性能优化的技术需求，需要好几天的时间，如果你只是说前端性能不好需要几天优化一下，这显然无法说服担心项目进度被延误了的pm，但是如果你能拿出实际的数据，例如，现在网站加载需要多长时间、发起多少个http请求、代码体积多大、FP/FMP/TTI都是多少、低于行业标准多少距离、可能会对业务造成什么样的影响，然后优化后又能达到什么样的效果，有理有据地摆好数据后，pm只要是个正常人，肯定会认真考虑一下你的建议的，即坚持以理服人

良好的心态

不同于技术的纯粹，业务上的事情肯定跟人有关，跟人有关的事情肯定就会有磨合的过程，在推进一项业务发展的过程中，肯定会遇到很多有意无意的阻力，这可能会让抱着一番好心努力做事的你感到憋屈，觉得自己一番好心不被认同，还不如每天划划水算了，这不仅是对工作不负责，更重要的是，对你自己不负责(毕竟，你肯定不想35岁就失业了吧)

业务基本是都由团队推进，几乎不存在个人单打独斗的可能，团队中的每个人都有自己的长处，每个人的长处汇聚到一起，才成就了团队的战斗力，能够顺利地推动团队融合与发力，可能比你攻克了一个技术项目还要重要的多

不要总觉得同事sx，你们既然同属于一个公司甚至部门，就说明你们的能力是差不了多少的，如果你觉得身边人都是sx，那么你大概率也是，所以当你斗志昂扬地要完成一个业务目标却遇到了阻力的时候，先别急着骂同事sx，心平气和地讲事实摆道理，实在不行就走个流程，大家都是打工的，谁没事去故意针对你？

你只是在工作而已，犯不上因为工作上的事情让自己不开心，有问题就解决问题，做好你认为该做的事情就行了，要相信领导能坐在那个位置上成为领导，大概率不是傻子(如果真的是，建议你为了前途着想还是赶紧换一家公司吧)，真正实干的人，肯定更容易得到机会与赏识

小结

本来只是想写怎么深入业务的，但后面感觉写着写着更像是职业发展指导了，就这样吧

以上只是我目前个人的一些见解，毕竟经验有限，所以可能有些观点还不是太成熟，欢迎更多的讨论