累死累活作业务,绩效还不怎么样,我只能帮你到这了……

前言

做为一个业务前端,完成业务需求的同时,还要处理各类线上问题,加班辛苦忙碌了一年,还要被老板说“思考是不够的”、“没有业务 sence”,出去面试,被问项目,也说不出什么有亮点或者有挑战的东西,想作点牛逼的东西,也没有发现什么有价值的方向,好不容易找到一些方向,还要被老板一顿质问,业务价值是什么?ROI 怎样?最终可能就只是作了一点性能优化工做,抽离了一些可复用的组件……不由让人感叹,业务难、前端难、作业务的前端更难!前端

若是你也有这样的感觉和困境,我想告诉你,这真的是太正常了,在阿里内部的技术论坛就有多篇关于这个问题的思考,我根据根据本身理解和调研,同时参考了多位不一样前端领域专家的总结,整理成这篇文章,但愿能对你们有所帮助。面试

1. 业务前端的困境

1.1 业务前端“好忙”

业务前端,顾名思义,作业务的前端,直接与业务的 PD、运营接触,对产品的用户直接负责。在实际的工做中,业务前端常常忙于业务的各类会议、项目和答疑,即使一条业务线上有多个前端同窗支持,面对成山的需求,可能依然感到吃力,这其中的缘由可能有:后端

  1. 用户侧产品每每须要快速上线,大部分需求都须要倒排工期,开发时间尤为紧张
  2. 对业务不熟悉,在项目需求已肯定的时候才去参加视觉评审,没有办法判断需求背后的业务逻辑跟业务大节奏是否匹配、需求自己是否可以达成业务目标、有没有更好的实现方式,只能接下需求,而后排期
  3. 维护成本高,天天还要忙于解决各类线上问题,好比这里样式有点问题,那里怎么没有显示……各类琐碎问题让你过的很是“充实”
  4. 需求响应速度较慢,好比业务的技术栈较老,或者定制逻辑过多,边写代码还要边查文档,查不到可能还要查源码,效率大幅下降。又或者跟别的业务技术体系不一样,难以复用和沉淀,若是要用,可能还要重写一遍……

1.2 业务前端是“资源”?

前端岗位的特色就是有视觉稿就能够完成工做,不须要理解业务全貌,因此在繁忙期很容易让前端忽视了业务思考,加上以前描述的各类缘由,业务前端常常沦落为“资源”,当你沦落为“资源”的时候,其实就已经失去了和业务平等对话的资格,他们只会把你当成莫得感情的开发机器,跟你输入需求,让你吐出页面,而你在这样的关系中,原本写着还算工整的代码,为了快速实现业务需求,也开始写起乱糟糟的代码,对于你所创造的产品也没有话语权,长此以往也失去了激情和耐心。性能优化

失去激情,写的不开心也就算了,由于你没有作出什么特别的东西,老板也不会特别承认你的辛苦,还会以为你思考不够、没有业务 sence,对业务没有助力,没有让业务由于你的存在而有所不一样……架构

1.3 业务前端想突破

好吧,那我决定作点什么改变一下,因而跟老板提出了一系列想法:框架

  1. 这里技术体系太老了,为了进一步提高开发效率,咱们想要搞技术重构
  2. 先后端联调有点费劲,咱们想搞个联调数据中台,提高联调效率
  3. 那里展示速度太慢了,咱们要搞性能优化
  4. ……

老板每每会来一系列灵魂提问:前端性能

  1. 为何要作?(有什么业务价值?有什么技术价值?)
  2. 为何是如今作?
  3. 为何是你作?
  4. ROI(投入产出比)怎么样?

尚未开始,躁动的心就被老板的一系列“质疑”浇了一盆冷水。工具

若是没有回答好这些问题、说服老板,天然也争取不到什么资源,只能一我的搞搞,一我的搞的每每质量不行、也没有人用,长此以往本身也不维护了,只能又开始埋头在需求中。性能

干的不开心,也没有成长,最后只能暗淡离职,但换了一个公司就会好吗,极可能又是相似的过程……学习

这真的堪称是业务前端的“困境”,那么如何突破这种困境呢?首先咱们就要摆正心态,从了解业务开始。

2. 了解业务

2.1 业务和需求

在了解业务以前,首先咱们要知道,业务跟需求是不同的。理解需求并不等于理解业务,需求是业务通过产品消化后的产物,可能已经通过演绎或者拆解,所以需求并非业务自己,固然了解的需求越多,对业务的全貌也会更加了解。

那么什么是业务呢?业界对"业务"有多种定义,可是其主要思想基本不变,业务就是一系列人经过一系列活动完成某一任务的过程,所以,业务可大可小,能够无限拆分。

咱们本文涉及的业务泛指商业业务,就是与该 BU 或者公司商业模式直接关联的业务或其组成部分。

2.2 前端为何要学习业务

前端即便不学习业务,其实也不影响作需求,毕竟你只要告诉我交互是什么样的,前端就能够帮你实现,并且已经有产品经理的角色了,你们各司其职不就行了,为何一个作技术的,要狗拿耗子、或者是越俎代庖呢?这就要说到:

  1. 只有了解业务,才能从技术的角度想到业务方未曾想到的地方;不了解业务,你可能听不懂业务方要什么,甚至连需求的业务逻辑都搞不清,这种状况的合做模式只有一种,需求下来了,你接住,而后给排期。也许,这个需求的设计不合理,你不知道;这个需求有更好的实现方案,你不知道;这个需求能够经过现成的关联产品方案解决,省时省人力,你也不知道。

  2. 只有了解到业务背后的缘由,才能从全局的视角去规划技术的将来。不了解业务,会让你离用户的真实需求很远,你越难发现其中的一些痛点和挑战,无法真正提出你的思考和解决方案,去解决用户的难题。

  3. 做为一名产品研发工程师,天然是但愿亲手打磨一款解决用户问题、体验友好的产品,若是产品能获得用户承认,产生影响力、天然会特别有成就感。

  4. 阿里做为一家商业科技公司,对技术人的要求就是技术与业务相结合,在知足业务需求的基础上,成为技术与业务的桥梁,主动走进业务,思考如何经过技术手段帮助业务作赢、知足市场和用户需求,先一步技术规划、人才储备、技术架构和技术预研。

2.3 你了解业务吗?

那么目前你了解你对接的业务吗?不妨尝试回答下如下问题:

  1. 业务作的是什么?产品大图有吗?
  2. 业务的核心指标是什么?KPI目标是什么,这些数字背后的含义是什么?要达成这些目标,业务策略是什么?
  3. 业务的用户是谁?流量怎么分层?占比多少?分别在业务中是怎样的定位?
  4. 业务的商业模式?靠什么吸引流量,盈利模式是怎样的?
  5. 咱们作的页面是什么东西?为业务带来什么价值?要创造更多的价值,咱们能够作什么?

2.4 如何学习业务?

2.4.1 业务领域知识的阅读

找到该领域相关的评分较好的书籍集中阅读,快速造成知识框架。

2.4.2 了解业务背景和规划

  1. 刚刚接手新的业务,能够邀请业务方老板或者资深的运营/产品同窗,给你讲讲这块业务的过去、如今、将来、愿景、财年规划,以及对技术同窗的指望;
  2. 花时间读合做方(运营、产品、研发)的周报,了解如今在发生什么,是否是离目标愈来愈近了;
  3. 了解业务目标、落地策略、衡量目标的数据口径,关注数据,关注目前作的项目是否为了达成目标而战,若是不是,提出你的想法和建议;
  4. 多参会,创建产品 sense。收集信息最好的方式就是参加所处业务老大的 KO 会,各类 KO 会会把战略上的拆解和背后的思考总体梳理以后宣讲传达给 BU 或部门的同窗,

2.4.3 多交流

与服务端同窗聊天,与 PM 聊天,与用户聊天,多角度看业务,但要注意的是,针对专业型比较强的业务,须要先作功课,至少一些英文的缩写要清楚的明白意思。

2.4.4 谨记数字

若是前面还须要花比较长的时间,那这一个能够如今就作起来,那就是把业务相关的数字记得越精细约好,越具体越好,越全面越多越好。这样作有两个好处:

  1. 所记的数字指标自己,很大程度已经涵盖了这个业务价值方向,你便知道了这个业务重点关注的是哪一个维度的东西
  2. 这些数字能够做为和业务方以及产品“平等对话”的源头,不然连最基本的对话基础都没有

2.4.5 从平常需求入手

对于项目中的需求,咱们要尝试分析背后的目的和价值,作了以后有什么预期的收益,为何这么作就能够达到这个收益,跟整体目标是否契合,还要判断业务方提到的点是否是有效的方案或者说成本太大的方案,看能不能给出替代方案,用现有的方案或者小成本的方式来知足业务方。

而在项目提测上线后,还要仔细分析以及多关注上线以后的业务数据和效果,会有以下好处:

  1. 提升本身对业务的理解能力,你在关注业务数据的同时,也就会更多的从业务的角度来看到这个功能所带来的价值是否符合预期,当出现不符合预期的时候,能够和业务方一块儿进行数据漏斗的分析从而找到问题所在,避免咱们的劳动成果成为一次性的工做。

  2. 总结的同时能够帮助本身梳理这个项目中本身哪些地方作的不足,或者相关推动中存在什么问题,以及后面怎么改进,提升了下次项目中的迭代效率和质量。好比这个项目是否存在需求理解不到位存在返工,或者沟通 & 联调低效,环境不稳定,本身设计的方案是否合理等问题,后续要怎么解决。

  3. 也能够从数据和总结中判断出什么样的需求是靠谱的 & 什么的样业务方是靠谱的,频繁争取资源上线效果又很差的业务方,下次再有需求过来则须要多增长一个心眼和思考的过程。

2.4.6 坚持

业务思考力,没有个至少半年是不会见效的

3. 助力业务

3.1 思考

尽管平时的业务很忙,但再忙,也要抽时间思考,那么思考哪些内容呢?如下举一些例子:

  1. 养成天天记工做内容的习惯,分析一下本身的时间到底耗在哪了
  2. 在业务开发中,有遇到让你特别想吐槽的点吗?想下问题背后的缘由,有什么方法能够避免下次不犯,能不能提炼为更加通用的解决方案,其余同窗怎么解决的,我能够怎么解决?
  3. 不断地输入、观察,业务的真实需求是什么?站在业务方的角度思考,业务遇到的痛点、挑战在哪里?

3.2 沟通

和老板、团队同窗、业务方对焦,确认“我想作的”是否是“你们想要的”?

你可能会提出不少意见,但通常会遭到老板或者业务方无情的拒绝,并且问得你一脸懵逼,就好比:

  1. 当前业务背景下,为何要作?(有什么业务价值?有什么技术价值?)
  2. 如今必须作么?
  3. 为何是你作?
  4. 怎么作?(体系化、全链路、单点技术挑战)
  5. 有什么业务和技术结果?可否被复用?
  6. 将来规划(可否跟BU或集团的方案联动、共建)

而这每每是由于你提出要作的事情,有价值但不是必须作的,没有结合目前业务须要什么。也就是说,你想作的技术是我的和纯技术角度思考的,没有基于业务的现状和痛点去考虑技术方案,不接地气,投入产出比不高。

因此给技术产出先找好业务的阵地,看看有没有能够借力的地方,不要重复造轮子。快速验证这个方向的正确性后,再逐渐多加投入、丰满技术设计。不要本身YY、默默地作完,这样作出来的东西没有业务场景埋单。

3.3 技术规划

业务赋能实际上是须要咱们紧贴业务规划,制定技术规划和方案。在了解业务方今年的 KPI 重点是什么,预计的拆解和实现路径是什么后,再结合本身的和团队状况,想一想本身能作哪些事情来帮助业务实现其 KPI,这里有两点须要注意下:

抓住本质从点及面,通盘考虑: 不少时候,咱们收到的痛点和业务需求都是单点的,这时咱们不能着眼于眼前的单点问题,而须要通盘来考虑,好比SEO的页面对性能很是敏感,常常可能会收到一些业务方来反馈,说目前咱们的SEO有这个地方,那个地方须要优化下,而单点解决这些问题可能对业务带来的收益并不大,对本身的技能也没有什么成长。这时候若是通盘考虑这个命题,其实会发现作SEO页面的优化,其实目的是为了提高SEO页面的收录和排名。而提高SEO页面的收录和排名其实不只有前端性能优化这一个路径,而是还有一些其余的路径:好比优化关键词&长尾词,采用Google的AMP技术改造SEO页面,优化爬虫爬取页面的耗时提高爬取率等等。这样就能吧点的问题转化为面的问题,才能制定更有效和全面的抓手来赋能业务。

既要解决眼前痛点,也要长远谋划: 不少时候咱们不能仅知足于眼前的KPI,还须要了解业务方长远的想法和能够预见的规划。就好比试点的新业务,一层规划是保证业务项目的按时上线,考虑到将来,另外一层规划可能就是如何作到技术方案的能够复制性。

3.4 站在巨人的肩膀上

当你须要制定一个产品化的方案或者工具和框架的时候,最好先放眼集团内部和行业进行一番调研,看看业界和其余同事是怎么解决这个问题的。尽可能站在别人的肩膀上作出创新或者参与共建,避免小团队内造出重复和质量低的轮子

4. 技术深度

4.1 技术知识与技术能力

“技术”不能是一个笼统的词汇,我想它至少能够分为“技术知识”和“技术能力”两大部分。

什么是“技术知识”?知识就是 I KNOW

  • 《TypeScript 从入门到放弃》
  • 《React 从入门到放弃》
  • 《Webpack 从入门到放弃》
  • ......

什么是“技术能力”?能力就是 I CAN

  • 我用 TypeScript 重构了一个大型系统,代码健壮性及研发效率大幅提高。
  • 我用 React Hooks 给全栈同窗进行前端培训,培训效果大幅提高。
  • 我深刻研究了 Webpack,优化配置,使得系统构建速度大幅提高。
  • .....

4.2 培养技术视野

  1. 关注平常业界新技术。不必定要深刻了解,但对新技术保持好奇心,大概了解它是作什么的,若是在工做中遇到匹配的落地环境,能够考虑写个 demo 看看是否是有价值
  2. 关注集团和业界的解决方案。在业务中发现问题,作解决方案的时候,咱们很容易陷入本身的设计中,一脑子地想把全部东西都本身作出来,但投入会很是大,产出的价值是否同样大呢?不知道。大部分状况下,你想作的,在ATA能搜到,前人踩的坑,或者已有的成熟的解决方案,只要你去沟通去接触,就能够轻松地接进来,为何要花大量的时间去造轮子呢?能够借力的地方,就去借力吧,把时间剩下来,作你的解决方案中更核心更有价值的事情。

4.3 技术深度

一聊到“技术深度”,可能很天然地会认为是在某项技术上挖得很深,或者解决了一个业界公认难度很高的技术难题,但这只是“技术深度”的其中一部分:

  1. 体系化 / 系统化 体系化思惟是认识事物的一种方式,在面对问题的时候,可以针对复杂的问题,列出关键的要素和解决方法,将散乱无序的问题,变得逻辑清晰,有章可循。 在问题的定位和解决的体现,从表象到本质,拆解出形成问题背后的缘由,针对性地去解决本质的缘由,而非治标不治本,有解决方案有节奏地解决。
  2. 全链路 除了前端的部分,向前向后的技术栈,还能挖多深。
  3. 单点技术挑战 在某个技术挑战上,你的思考和解决方案是怎样的。

4.4 技术与业务双赢

真正有突破性的、带来重大价值的业务成果必然伴随着技术上的深刻乃至创新,因此在作业务成果的时候,必定会有让咱们增长技术深度的场景。

5. 给你更多体感

培养业务感确实是一件很是有难度的事情,他要求你以业务而非技术为第一视角,这可能违背了不少人心里的“技术坚持”,但若是一直作技术,实际上是很难有很是大的突破的,在工做中,若是能实现技术与业务双赢,将会助力你到达更高的高度。

改变的确很难,但结果值得冒险。

最后,说了这么多,是否是感受仍是没有什么体感,仍是不知道要作些什么? 为了让大家有更加深入的感觉,咱们淘系技术部举办了三场直播,覆盖 A/B、直播、边缘计算三大主题,让你更加明白“业务与技术双赢”。

宣传海报2.png
相关文章
相关标签/搜索