做为一个业务前端,完成业务需求的同时,还要处理各类线上问题,加班辛苦忙碌了一年,还要被老板说“思考是不够的”、“没有业务 sence”,出去面试,被问项目,也说不出什么有亮点或者有挑战的东西,想作点牛逼的东西,也没有发现什么有价值的方向,好不容易找到一些方向,还要被老板一顿质问,业务价值是什么?ROI 怎样?最终可能就只是作了一点性能优化工做,抽离了一些可复用的组件……不由让人感叹,业务难、前端难、作业务的前端更难!前端
若是你也有这样的感觉和困境,我想告诉你,这真的是太正常了,在阿里内部的技术论坛就有多篇关于这个问题的思考,我根据根据本身理解和调研,同时参考了多位不一样前端领域专家的总结,整理成这篇文章,但愿能对你们有所帮助。面试
业务前端,顾名思义,作业务的前端,直接与业务的 PD、运营接触,对产品的用户直接负责。在实际的工做中,业务前端常常忙于业务的各类会议、项目和答疑,即使一条业务线上有多个前端同窗支持,面对成山的需求,可能依然感到吃力,这其中的缘由可能有:后端
前端岗位的特色就是有视觉稿就能够完成工做,不须要理解业务全貌,因此在繁忙期很容易让前端忽视了业务思考,加上以前描述的各类缘由,业务前端常常沦落为“资源”,当你沦落为“资源”的时候,其实就已经失去了和业务平等对话的资格,他们只会把你当成莫得感情的开发机器,跟你输入需求,让你吐出页面,而你在这样的关系中,原本写着还算工整的代码,为了快速实现业务需求,也开始写起乱糟糟的代码,对于你所创造的产品也没有话语权,长此以往也失去了激情和耐心。性能优化
失去激情,写的不开心也就算了,由于你没有作出什么特别的东西,老板也不会特别承认你的辛苦,还会以为你思考不够、没有业务 sence,对业务没有助力,没有让业务由于你的存在而有所不一样……架构
好吧,那我决定作点什么改变一下,因而跟老板提出了一系列想法:框架
老板每每会来一系列灵魂提问:前端性能
尚未开始,躁动的心就被老板的一系列“质疑”浇了一盆冷水。工具
若是没有回答好这些问题、说服老板,天然也争取不到什么资源,只能一我的搞搞,一我的搞的每每质量不行、也没有人用,长此以往本身也不维护了,只能又开始埋头在需求中。性能
干的不开心,也没有成长,最后只能暗淡离职,但换了一个公司就会好吗,极可能又是相似的过程……学习
这真的堪称是业务前端的“困境”,那么如何突破这种困境呢?首先咱们就要摆正心态,从了解业务开始。
在了解业务以前,首先咱们要知道,业务跟需求是不同的。理解需求并不等于理解业务,需求是业务通过产品消化后的产物,可能已经通过演绎或者拆解,所以需求并非业务自己,固然了解的需求越多,对业务的全貌也会更加了解。
那么什么是业务呢?业界对"业务"有多种定义,可是其主要思想基本不变,业务就是一系列人经过一系列活动完成某一任务的过程,所以,业务可大可小,能够无限拆分。
咱们本文涉及的业务泛指商业业务,就是与该 BU 或者公司商业模式直接关联的业务或其组成部分。
前端即便不学习业务,其实也不影响作需求,毕竟你只要告诉我交互是什么样的,前端就能够帮你实现,并且已经有产品经理的角色了,你们各司其职不就行了,为何一个作技术的,要狗拿耗子、或者是越俎代庖呢?这就要说到:
只有了解业务,才能从技术的角度想到业务方未曾想到的地方;不了解业务,你可能听不懂业务方要什么,甚至连需求的业务逻辑都搞不清,这种状况的合做模式只有一种,需求下来了,你接住,而后给排期。也许,这个需求的设计不合理,你不知道;这个需求有更好的实现方案,你不知道;这个需求能够经过现成的关联产品方案解决,省时省人力,你也不知道。
只有了解到业务背后的缘由,才能从全局的视角去规划技术的将来。不了解业务,会让你离用户的真实需求很远,你越难发现其中的一些痛点和挑战,无法真正提出你的思考和解决方案,去解决用户的难题。
做为一名产品研发工程师,天然是但愿亲手打磨一款解决用户问题、体验友好的产品,若是产品能获得用户承认,产生影响力、天然会特别有成就感。
阿里做为一家商业科技公司,对技术人的要求就是技术与业务相结合,在知足业务需求的基础上,成为技术与业务的桥梁,主动走进业务,思考如何经过技术手段帮助业务作赢、知足市场和用户需求,先一步技术规划、人才储备、技术架构和技术预研。
那么目前你了解你对接的业务吗?不妨尝试回答下如下问题:
找到该领域相关的评分较好的书籍集中阅读,快速造成知识框架。
与服务端同窗聊天,与 PM 聊天,与用户聊天,多角度看业务,但要注意的是,针对专业型比较强的业务,须要先作功课,至少一些英文的缩写要清楚的明白意思。
若是前面还须要花比较长的时间,那这一个能够如今就作起来,那就是把业务相关的数字记得越精细约好,越具体越好,越全面越多越好。这样作有两个好处:
对于项目中的需求,咱们要尝试分析背后的目的和价值,作了以后有什么预期的收益,为何这么作就能够达到这个收益,跟整体目标是否契合,还要判断业务方提到的点是否是有效的方案或者说成本太大的方案,看能不能给出替代方案,用现有的方案或者小成本的方式来知足业务方。
而在项目提测上线后,还要仔细分析以及多关注上线以后的业务数据和效果,会有以下好处:
提升本身对业务的理解能力,你在关注业务数据的同时,也就会更多的从业务的角度来看到这个功能所带来的价值是否符合预期,当出现不符合预期的时候,能够和业务方一块儿进行数据漏斗的分析从而找到问题所在,避免咱们的劳动成果成为一次性的工做。
总结的同时能够帮助本身梳理这个项目中本身哪些地方作的不足,或者相关推动中存在什么问题,以及后面怎么改进,提升了下次项目中的迭代效率和质量。好比这个项目是否存在需求理解不到位存在返工,或者沟通 & 联调低效,环境不稳定,本身设计的方案是否合理等问题,后续要怎么解决。
也能够从数据和总结中判断出什么样的需求是靠谱的 & 什么的样业务方是靠谱的,频繁争取资源上线效果又很差的业务方,下次再有需求过来则须要多增长一个心眼和思考的过程。
业务思考力,没有个至少半年是不会见效的
尽管平时的业务很忙,但再忙,也要抽时间思考,那么思考哪些内容呢?如下举一些例子:
和老板、团队同窗、业务方对焦,确认“我想作的”是否是“你们想要的”?
你可能会提出不少意见,但通常会遭到老板或者业务方无情的拒绝,并且问得你一脸懵逼,就好比:
而这每每是由于你提出要作的事情,有价值但不是必须作的,没有结合目前业务须要什么。也就是说,你想作的技术是我的和纯技术角度思考的,没有基于业务的现状和痛点去考虑技术方案,不接地气,投入产出比不高。
因此给技术产出先找好业务的阵地,看看有没有能够借力的地方,不要重复造轮子。快速验证这个方向的正确性后,再逐渐多加投入、丰满技术设计。不要本身YY、默默地作完,这样作出来的东西没有业务场景埋单。
业务赋能实际上是须要咱们紧贴业务规划,制定技术规划和方案。在了解业务方今年的 KPI 重点是什么,预计的拆解和实现路径是什么后,再结合本身的和团队状况,想一想本身能作哪些事情来帮助业务实现其 KPI,这里有两点须要注意下:
抓住本质从点及面,通盘考虑: 不少时候,咱们收到的痛点和业务需求都是单点的,这时咱们不能着眼于眼前的单点问题,而须要通盘来考虑,好比SEO的页面对性能很是敏感,常常可能会收到一些业务方来反馈,说目前咱们的SEO有这个地方,那个地方须要优化下,而单点解决这些问题可能对业务带来的收益并不大,对本身的技能也没有什么成长。这时候若是通盘考虑这个命题,其实会发现作SEO页面的优化,其实目的是为了提高SEO页面的收录和排名。而提高SEO页面的收录和排名其实不只有前端性能优化这一个路径,而是还有一些其余的路径:好比优化关键词&长尾词,采用Google的AMP技术改造SEO页面,优化爬虫爬取页面的耗时提高爬取率等等。这样就能吧点的问题转化为面的问题,才能制定更有效和全面的抓手来赋能业务。
既要解决眼前痛点,也要长远谋划: 不少时候咱们不能仅知足于眼前的KPI,还须要了解业务方长远的想法和能够预见的规划。就好比试点的新业务,一层规划是保证业务项目的按时上线,考虑到将来,另外一层规划可能就是如何作到技术方案的能够复制性。
当你须要制定一个产品化的方案或者工具和框架的时候,最好先放眼集团内部和行业进行一番调研,看看业界和其余同事是怎么解决这个问题的。尽可能站在别人的肩膀上作出创新或者参与共建,避免小团队内造出重复和质量低的轮子
“技术”不能是一个笼统的词汇,我想它至少能够分为“技术知识”和“技术能力”两大部分。
什么是“技术知识”?知识就是 I KNOW
什么是“技术能力”?能力就是 I CAN
一聊到“技术深度”,可能很天然地会认为是在某项技术上挖得很深,或者解决了一个业界公认难度很高的技术难题,但这只是“技术深度”的其中一部分:
真正有突破性的、带来重大价值的业务成果必然伴随着技术上的深刻乃至创新,因此在作业务成果的时候,必定会有让咱们增长技术深度的场景。
培养业务感确实是一件很是有难度的事情,他要求你以业务而非技术为第一视角,这可能违背了不少人心里的“技术坚持”,但若是一直作技术,实际上是很难有很是大的突破的,在工做中,若是能实现技术与业务双赢,将会助力你到达更高的高度。
改变的确很难,但结果值得冒险。
最后,说了这么多,是否是感受仍是没有什么体感,仍是不知道要作些什么? 为了让大家有更加深入的感觉,咱们淘系技术部举办了三场直播,覆盖 A/B、直播、边缘计算三大主题,让你更加明白“业务与技术双赢”。