qq发网站链接怎么做,可以做微课ppt模板 网站有哪些内容,网站建设电话销售技巧,龙华网站开发公司阿里妹导读#xff1a;做业务就好比打仗#xff0c;团队是我们的归属。在团队中#xff0c;我们既要通力协作#xff0c;又要定义问题#xff0c;既要业务先赢#xff0c;又要技术成长。越来越多的前端投身业务研发中。想要有更好的发展#xff0c;业务理解力非常关键。…
阿里妹导读做业务就好比打仗团队是我们的归属。在团队中我们既要通力协作又要定义问题既要业务先赢又要技术成长。越来越多的前端投身业务研发中。想要有更好的发展业务理解力非常关键。阿里巴巴前端技术专家悟寻将他在阿里的成长思考送给在业务中深耕细作的你。
前言
我将我经历过的或者正在经历的状态分成三个阶段进行总结求生存谋发展修体系。 阶段一埋头苦干求生存
作为一个服务一线业务的前端同学支撑好业务占据我们50%-60%左右的KPI纵观行业前端本身很容易成为整个业务的资源瓶颈而身为业务的前端我相信一定经历过疲于奔命经常线上救火的事情。我入职后的前一年主要做进口业务天猫国际一个包含平台和自营的业务。当时的进口业务还处于野蛮生长竞争激烈的阶段。经常面临一年两大改日常需求不断期间还要应付一年的5个S级的大促和一些小促我记得最忙的时候是17年双十一面临着自营和平台两块业务的大迭代同时还需要面临双十一大促各种需求每天除了做业务几乎没有什么思考和总结的过程。而经过那次之后我也深刻体会到对于需求管理和时间管理 如何避免避免线上起火的重要性。这里我结合自身和团队的经验梳理了如何打破这种状态方法也欢迎各位补充。
需求管理
首先需求是做不完的所以要有取舍集中人力和精力做核心的业务需求才能发挥最大的价值如果你所在团队目前处于各种零散的需求纷至而来导致无法应节的情况则有必要进行相应的需求管理措施
1.需求双周排期会比如拉上老板PD和业务方 开发一起每两周(时间可自定义)坐到一起对焦这两周的项目进展和接下来所有需求并且确定好优先级哪些是应该安排资源进行开发哪些应该进行取舍让更多的精力和人力focus在业务的重要事情上。当然比如业务方靠谱或者有大的规划则一般会对财年的目标进行战役级别的拆解并且梳理出业务今年必须要要拿下的几场战役那么技术同学就可以根据战役来排兵布阵了业务和技术同学也有明确的统一的战线和目标比如我们目前就是以各种战役为主日常需求穿插为辅。
2.如何拒绝一句话需求在需求双周排期会中基本能搞定80%的核心需求和优先级但在平时还是会存在一些业务方/PD会找你提一些没有经过梳理和思考的一两句话的需求比如这个这个商品坑我想从一排一换成一排二的或者想这个地方的icon或者营销标我觉得字体不好看想修改下等等这样的诉求。那面对这样的诉求在左耳朵耗子的极客专栏中 小胡子哥的博客都有提到如何拒绝一句话需求的方法结合我自己的经验觉得有如下三个递进的方法来解决
1.多问几个为什么这比如你这个需求背后的目的和价值是什么做了之后有什么预期的收益为什么这么做就可以达到这个收益你可以不直接问业务方但是你也需要问自己业务方的这个目标和做这个需求的路径是否可以匹配得上如果实现路径存在逻辑漏洞或者不是最佳的则这个需求也就没有做的必要性。
2.给出替代方案经过上面的步骤其实你会发现你已经过滤了一批无效的一句话需求而有些需求可能是有一定的存在价值但是可能业务方提到的点并不是有效的方案或者说成本太大的方案这时你就需要思考替代方案尽量通过现有方案或者小成本的方式来满足业务方间接的达到“拒绝”的效果。
3.不能直接说不但可以有条件的说是当你确定这个需求是ok的但你确实暂时抽不出时间来搞定这个事情的时候这时关键在于我们不能直接拒绝业务方长此以往会影响到后续的合作关系这种情况你可以说这个需求我接受但是我可能需要较长一些的缓冲时间或者砍一些需求(部分满足)又或者必须要按时上的话不能保证项目的上线后的效果、质量等让业务方来做部分的取舍。
提升开发效率 质量
当然作为技术人员需求管理只是一方面还需要从自身的角度出发提升开发效率和质量这个我相信大家都深有体会尽量不要做低质量的重复事情。比如通过统一开发技术体系和封装相应的可复用的组件和提效工具等来释放自己和团队同学的生产力千万不要因为太忙而放弃思考和做这些事情这样只会欠下更多的技术债。
当然这里也有个误区并不是鼓励大家造轮子身为业务团队的同学尽量把眼光能放到行业或者集团内借助现有的技术方案快速的定制来满足自己的业务诉求比如之前我们借助之前舒文团队的魔系列产品定制了海外自己的魔石模块来满足满足海外营销场景的需求开发现在基本上大促类似坑位模块都得到了比较好的解决。
再者就是质量问题需要抽空对线上经常出现问题的产品和代码进行梳理和方案的重新设计在做国际时我一般是利用周末的时间来做这种事情进行部分的重构来达到这种问题的彻底解决避免三更半夜出现“连环夺命call”。剩下的方式和手段就是增加开发环节质量保证和必要线上监控了。
关注上线效果 及时总结
有的时候我们认为项目提测上线后就完成了这是一个不好的习惯长此以往自己也就在合作方当中沦落为一个项目资源的角色处于被动的状态。其实仔细分析下多关注上线之后的业务数据和效果 分析总结有如下好处
1.提高自己对业务的理解能力你在关注业务数据的同时也就会更多地从业务的角度来看到这个功能所带来的价值是否符合预期当出现不符合预期的时候可以和业务方一起进行数据漏斗的分析从而找到问题所在避免我们的劳动成果成为一次性的工作。
2.总结的同时可以帮助自己梳理这个项目中自己哪些地方做的不足或者相关推进中存在什么问题以及后面怎么改进提高了下次项目中的迭代效率和质量。比如这个项目是否存在需求理解不到位存在返工或者沟通 联调低效环境不稳定自己设计的方案是否合理等问题后续要怎么解决。
3.也可以从数据和总结中判断出什么样的需求是靠谱的 什么的样业务方是靠谱的频繁争取资源上线效果又不好的业务方下次再有需求过来则需要多增加一个心眼和思考的过程。
小结
以上就是我在应对业务需求井喷所总结的一些经验总体来说就是虽然业务占据我们大部分的KPI但不能在业务中迷失了自己需要给自己安排总结和反思的时间做到主动掌握节奏的支撑业务。
阶段二四顾茫然谋发展
当然做到主动掌握节奏支撑业务还是不够的如何让自己在做业务的同时能获得更好的沉淀和成长呢下面说说做我经历的第二个阶段我把它称为四顾茫然谋发展。这个阶段你会发现你虽然能较好地支撑了业务和有一定的时间来思考了但是作为业务前端有个困境就是似乎不知道往哪些方向来发力来提升自己特别是在每次制定规划和写KPI时总会出现除了业务不知道该做啥的困境。在我看来身处在业务团队的前端可以试着从两个角度去探索和思考
业务赋能角度
业务赋能其实是需要我们紧贴业务规划制定技术规划和方案。这里建议从财年开始后就需要陆续和老板和还有自己对口的业务PD还有业务去聊找一些线索和输入了解业务方今年的KPI重点是什么预计的拆解和实现路径是什么再结合自己的和团队情况想想自己能做哪些事情来帮助业务实现其KPI其实这并非是一个简单的事情我自己也在慢慢的锻炼和训练的自己目前的有两点感受可以谈下
1.抓住本质从点及面通盘考虑很多时候我们收到的痛点和业务需求都是单点的这时我们不能着眼于眼前的单点问题而需要通盘来考虑比如SEO的页面对性能非常敏感经常会收到一些业务方来反馈说目前我们的SEO有这个地方那个地方需要优化下而单点解决这些问题可能对业务带来的收益并不大对自己的技能也没有什么成长。这时候如果通盘考虑这个命题其实会发现做SEO页面的优化其实目的是为了提升SEO页面的收录和排名。而提升SEO页面的收录和排名其实不仅有前端性能优化这一个路径而是还有一些其他的路径比如优化关键词长尾词采用Google的AMP技术改造SEO页面优化爬虫爬取页面的耗时提升爬取率等等。这样就能把点的问题转化为面的问题才能制定更有效和全面的抓手来赋能业务。
2.既要解决眼前痛点也要长远谋划很多时候我们不能仅满足于眼前的KPI还需要了解业务方长远的想法和可以预见的规划。比如我们目前正在做一个集团非常重要的项目这个项目时间非常紧张(前端需要300多个人日, 且只有48个工作日一度成为项目的风险点)业务和技术的第一要务就是按时上线这时如果按着常理规划的目标肯定围绕着如何按时上线的事情而可以预见的未来可能还需要基于这个模式落地到其他的站点所以这里在规划和需要做的事情又增加了如何做到技术方案的可以复制性做到未来能新开站点如何做到缩短前端人力的问题帮助业务能做到海外站点快速规模化这就是第二个维度的事情了而当我吧这个项目的所有可能的近的问题和远的问题都挖掘一遍那我们要做的事情其实就是海外分站前端整体解决方案。 所以这需要我们不断的挖掘问题和定义问题然后再找到对策这样才能找到更好的的赋能业务抓手。
技术体验角度
技术体验角度相对前端同学来说比较熟悉而身在业务团队前端这块也可以做比较多的事情比如研发效能的提升性能体验优化新技术试点和落地与端的融合等等。如果想重点投入在这方向里面有几个点我觉得是需要重点关注的
1.避免重复造轮子当你需要制定一个产品化的方案或者工具和框架的时候最好先放眼集团内部和行业进行一番调研看看业界和其他同事是怎么解决这个问题的。尽量站在别人的肩膀上做出创新或者参与共建避免小团队内造出重复和质量低的轮子这里建议可以多关注集团前端委员会的规划和动态多关注集团内外的分享当发现有感兴趣和共同有需要面对的问题和场景时参与共建和共享。
2.方案的深度和广度这个比较好理解比如就拿前端的性能优化来说目前我们已经不怎么谈资源压缩combo请求之类常规操作了而是进入了和客户端深入结合的深水区进行优化(深度)如之前天猫的Webbased方案而之前我在做海外性能优化Global Lite方案的时候也是从全链路的角度来规划和思考的(广度)。所以规划方案的深度和广度决定了这个方案的收益面而提升深度和广度的方向或者说技巧我觉得可以是一是多跨出一步以上下游和合作方的角色来思考和其他团队角色深度合作探讨可能的方案。二是以终局的思维来思考比如这个事情最后应该是要做成什么样的然后和现实做match考虑落地方案。
3.关注方案的ROI这里其实涉及到你规划的方案如果完整实施下来的成本和收益的问题这个会最终衡量你做这个事情或者方向的价值。那如何衡量成本和收益呢成本可以考虑从两个角度来说一个是平时我们理解的成本, 比如投入了多少人日花费了多少经费等还可以从另一个经济学的机会成本来考虑即放弃了的最大代价。收益其实比如提高了多少人效提升了多少业务数据提升了多少性能等建议采用对比的方式来凸显。
4.引进来走出去引进来的意思是尽量基于现有的方案和能力来进一步创新或者定制走出去其实是将成果和方案能反哺出去比如将方案覆盖到集团其他行业和BU解决类似场景的问题或者开源申请专利 多参与集团内外的分享交流等等。
小结
关于思考业务赋能和做技术规划其实是一个非常值得不断探讨锻炼过程建议平时多和老板 团队内高P沟通和交流一般他们会比较有经验可以在思考的深度和格局给出非常多的建议有的时候这种交流会有一种醍醐灌顶的感觉。
阶段三千锤百炼修体系
有的时候当我们找到一个觉得可以深耕的方向 机会的时候脑子里面也许就已经有了大致的思路和方案这时候可能会迫不及待的就想要开工陷入了各种技术方案的细节之中这样的坏处在于可能会导致我们做着做着偏离了主航道导致最后的产出不理想。这里我们需要有一套理论和方法来保证对问题理解是准确的完整的 足够高度的。这个块有没有方法和套路呢答案是有那就是养成结构化思考和做事方式。
结构化的思维
1.建立核心目标当我们在面对一个问题和挑战(挑战即机会)的时候需要明确我们做这个事情的核心目标是什么建立问题的核心目标。举个简单的列子比如在开发中遇到了项目编译慢的问题, 目标可以定义为解决项目编译问题但是我们也可以升华一层为提升整个开发流程的效能这时的核心目标就是是对整个开发流程进行提效。进一步升华的目的是为了提升整个事情的价值和解决问题的覆盖面。
2.进行目标拆解这里可以根据不同的场景选择不同的逻辑顺序(时间/结构/程度)来进行拆解比如开发提效这个目标我们就可以按开发的时间顺序来进行拆解比如: 本地开发调试- 联调 - 预发验证-发布上线等。这里面需要关注的点就是需要做到拆解的完备和独立拆解出来的子项能够做到相互独立和完整。
时间顺序中心执行的步骤、流程等。结构顺序中心的空间、地理位置、内部外部条件等。程度顺序中心的轻重缓急、重要性等。
3.子项的清理事业是无限的人力总是有穷、认知高度总是不够(from 承风)所以这里需要做到取舍并不是所有的子项都是值得在现阶段做或者需要花费较大成本去做的。需要抓住其中的核心子项也就是核心抓手。
小结
这里我建议大家可以直接阅读下《金字塔原理》一书(我自己也在学习中)和一些职业发展的其他书籍补充自己除了技术方面之外一些思考和项目管理人际沟通等方面的知识当然书和文章都是理论知识还是需要在工作当中千锤百炼的去修炼这种思考和做事的方式才能体现出它的价值。这块我目前也在不断的在工作中尝试中等后续如果有较多的体会和经验了再来分享。
最后
以上就是我在这几年摸爬滚打出的一些经验借此机会也在这里感谢下我的老板和帮助过我的朋友你们一直都是我学习和参考的榜样。
原文链接 本文为云栖社区原创内容未经允许不得转载。
