合肥市门窗工程在哪个网站接活做,做视频类型的网站,关于网的设计创意作品,如何开发自己的app软件作者 | 氐宿 阿里云高级前端技术专家
导读#xff1a;在业务团队做事的工程师摸爬滚打了一段时间后#xff0c;一定会有所疑问。团队同学在最初的一段时间都提出这样的疑惑#xff1a;如何在业务中发现有技术价值的问题#xff1f;发现问题后如何思考和发起再到解决…
作者 | 氐宿 阿里云高级前端技术专家
导读在业务团队做事的工程师摸爬滚打了一段时间后一定会有所疑问。团队同学在最初的一段时间都提出这样的疑惑如何在业务中发现有技术价值的问题发现问题后如何思考和发起再到解决最后的技术结果跟业务结果如何衔接很多时候我们听别人说“思考是不够的/要多思考”其实都是在说这几点。接下来阿里高级前端技术专家氐宿谈一谈遇到这三个问题时他是如何解决的
如何在业务中发现有技术价值的问题 一位科学家一生可用于研究的时间极其有限然而世界上的研究主题却多得数不清。如果只因为稍微觉得有趣就选为研究主题将在还没来得及做真正重要的事时一生就结束了。 ——利根川进 其实要解答这个问题之前我们要理解一个概念什么是有价值的问题议题度高和解答质高的问题我理解就是有价值的问题比较通俗的理解就是这个问题是否存在当前要解决这个问题的必要性够不够问题对应的解决方案可行性高不高。如果要在业务里发现这种问题首先要理解业务战略、打法和定位。那如何才能把这个前置信息做好对工程师来说是一个比较大的挑战。
首先工程师其实大多数都是从事一线开发对业务理解可能仅限于自己在做的事情。很多信息都是别人过滤了五六手之后的信息得到的可能就是一个任务和为什么做这个任务。相对比之下肯定不如制定战略的人懂得战略背后的意义信息也是不对等的。所以首先我们要收集信息然后整理归纳最后分析问题。
1. 先来说说收集信息
其实有点像信息科学里的情报学。收集信息最好的方式就是参加所处业务老大的 KO 会各种 KO 会会把战略上的拆解和背后的思考整体梳理之后宣讲传达给 BU 或部门的同学虽然我们没有亲身参与到脑暴过程但是也会对背后的思考有一定的理解切记一定要记得划重点记笔记。
获取第一手信息之后我们要经过简单梳理开始收集外部信息整理整体的知识脉络这里我经常用的就是阿里学习业务宝库阿里学习技术宝库 ATA注阿里内部两个学习平台可以获取不少业务相关的分享当然很多外部渠道也同样可以收集到。比如资料《飞猪“新旅行联盟”赋能商家能讲出什么新故事》就是外部收集到的可以得出几个关键词数字技术赋能旅行行业、我们不是 OTA这些都要整理到自己收集的信息池里。当然以上我提到的都是信息获取源的一种。具体收集信息的释义可以查一下百科可以按照百科上的方法论学习一遍以便找到适合自己的方法。总之这里我们要像产品经理一样去收集这些信息。这里也鼓励跟不同领域不同BU的同学多交流不限于线下扯淡式的交流和线上问问题的方式这里建议先看下知乎里这个回答关于学会问问题以及如何进行有效社交。
2. 分析问题
我们通过不同信息源获取到的信息是散落的如何经过加工融入自己的思考体系呢首先信息不能是简单的堆叠我们要通过不同的入口理出头绪。可以使用 MECE 法则进行思考拆解通过无遗漏无重复地分类来把握整体列出脑图和逻辑树最后将逻辑树的信息匹配需求场景可以尝试通过 C 端和 B 端不同入口去还原需求场景。这中间可以结合一定的方法论演绎推理和归纳推理去把问题和挑战细化出来帮助我们理解 BU 的战略同时我们也能从自身出发把战略拆解到对应的项目。举例来说去年我个人分析飞猪在整个 C 端面临的主要问题之一还是流量格局过于单一B 端供应链的成熟度不够导致无法给到商家更实质的体验服务飞猪的类目交叉不够背后是各垂直业务存在业务隔离。 发现问题到执行该如何衔接
拿到这三个问题我们不能马上就开干我们还要提炼这个问题带来的核心价值。否则很容易就会出现投入了巨大工作之后最后的技术产出和业务结果衔接不上所以说思考不要用蛮力工作不只靠体力。要去看里面跟自己角色相关的工作在什么地方
以端侧来说有优势的一点是靠近产品侧靠近用户侧所以基本展现模式都可以通过产品原型进行抽象形成体系化。以流量体系建设举例我们要对用户进行分层比较合理的方式可以用到几个经典模型RFM、AIPL、AARRR及其变种以便沉淀出承接的技术平台或产品。如流量体系建设我们在思考分层过后把用户按心智划分之后又从所属域分为散落在阿里域外的用户和阿里域内的内部用户从而针对性的设计出两个平台产品。 1. 见龙在田利见大人
作为项目发起者我们要关注每一个环节。所以首先我们要找到对应的业务方去“售卖”我们的思考。要找到目标一致的人一起做事这里首先需要知道的是你要清楚你的业务方都是谁他们都负责什么我的方法比较简单直接看运营在职能上的划分要清楚自己对的人负责的方向以及他所负责的 KPI。另外切记一定要和对口 PD 一起去找通常来说最直接的合作方是能帮你处理业务和技术衔接的那个人。
上下游的人都找到后要开始准备 KO理出需求排出优先级。因为在资源有限的情况下我们究竟该先做哪些不重要的要放在后面去做优先考虑你产品最核心的功能。通常平台产品最优先的是运营使用的功能所以要跟合作方确认哪些功能他们认为最重要。
2. 站在巨人的肩膀上做创新
阿里巴巴已经非常大了我们相信每一个想法都会有人想过所以尽量不要走重复的路踩同一个坑同理小公司利用开源技术亦是如此。那么在项目开始做的时候如果是平台我们需要先拆出核心功能这个核心功能要去看集团是否已经有人在做了或是有成熟方案避免重复造轮子同时也能最快最直接的解决你最紧急核心的问题。这其中最简单直接方法就是搜索 ATA阿里内部技术论坛和语雀内部同学通常有知识记录的习惯拆关键词找到做事情的关键人。你要相信你绝不是第一个想到该问题的人一些通用问题一定在集团内已经有通用的服务提供出来即使没有也会有比较成熟的方案。
如果集团内部就是没有成型方案这个方向也属于工业界比较前沿的领域。遇到类似这种问题可以先看看是否有绕开的可能性如果确实绕不开可以试试找到适合解决该问题的基础团队一起合作和共建。外部是否有付费方案可以购买和借鉴总之要保障业务先赢。因为业务工程师要思考的是你给业务能带来怎样的价值你的核心价值不是处理非常复杂的技术问题而是用你的技术能给业务带来怎样的价值增量。同样的利用某种技术或模型模式解决了非常复杂的业务问题并且是具有普适价值的技术这也是业务端工程师带给业务带来的价值。
3. 立足当下放眼未来
知几其神乎
要看当下更要看未来不光技术要看未来行业也要看未来。站在当下思考能解决业务目前遇到的最大的问题思考未来能为业务带来弯道超车的机会。比如飞猪如果在行业里要追赶同行业的竞品在资源投入方面没办法跟对方的体量比较的情况下我们做到最后最好的结果可能也只是追平对手。所以我们亟须找到未来行业争胜的关键按钮把时间和精力聚焦在关键节点用全球Fun战略突围。所以飞猪也要为国际化做好准备这个领域里同样有前人探寻的技术经验供我们借鉴。所以为了让我们能更聚焦业务可以说去年的平台化是为业务做了非常好的铺垫。
最后的技术结果跟业务结果如何衔接
其实这个小标题有点伪命题的意思如果一开始我们就把业务理解的很清楚执行没有偏离航道比较专注目标的话不大可能会出现拿不到业务结果的情况最后只剩下一个问题拿到业务结果的同时技术价值如何体现
从我自身出发也常常有同学问我在业务做开发重复造轮子会被人挑战但事情都有人干了我们的价值在哪我之前一直都会回答“搞基础技术的团队一直在基础工程/技术领域深耕他们也需要关注从技术价值到业务价值的转变和衔接本质上缺少业务场景如果我们与他们合作就形成了互补既拿到了业务结果同时也能从自身技术成长上得到一定历练”。
但之后我回想这段对话是有很多问题在里面的。从业务工程师角度出发我们要关注的核心就是保障业务先赢如果没有达到这个目标就容易变成工程师自嗨。所以我们在业务端需要的是有技术视野能看到集团其他团队或者外部团队在做的事能主动交流让这件事变成共赢如果没有其他人在搞我们去搞要有人站出来看这个投入产出比是否合理也就是我们在开篇说的议题度和解答质都高的有价值的问题。这个问题在集团其他团队是否存在共性我们解决了能否为他们带来价值当然结合我们在前面讲到的在业务中发现有技术价值的问题其实这里就有一个比较明确的答案重中之重就是做之前把 Why 思考的清楚清晰做最正确的事。只有做到这点解决这个问题带来的业务价值就自然而然非常清晰的定位出来。所以说最好的工程师必须要懂产品。
也写给未来
小聊一下题外话组里有同学会问我业务前端未来是否会被淘汰因为我们在做的 lowcode/nocode 是在革自己的命。其实产生这种想法首先就是没有站在集团未来发展的角度去思考也就是常说的屁股太小其次是没有站在整个前端领域去回顾前端发展历程导致的悲观和担忧。
从目前在做的方向上来说还是要思考如何解决低质量代码建设和低效的重复工作占用工程师大部分精力将工程师的能量解放出来提升集团整体的研发效能。另一层面从前端以往在系统分层里的位置一直都属于应用层就是最上层的表象/展现/渲染应用层在过去几十年间经过了不断的变化和演进职业也从最早的 GUI 工程师演进到之后的 web 前端/客户端研发工程师这中间也经历过 flash 工程师的时代在此期间应用层/展现层一直都在变化所以前端同学总觉得状态是一直在学习新知识。但这个发展历程其实是有规律可循的所谓万变不离其宗应用层虽然在不断变化但无非都是朝着两个大方向在发展一个是工程效率提升工程角度出发一个是图形图像研究用户角度出发。这两个大方向上目前也有非常复杂庞大的树状知识体系并且还在不断延伸。同时随着机器学习领域的兴起和硬件性能、网络带宽的提升以及人们在视觉呈现设备上的升级带来的可能又是新一轮的技术洗牌然后在两个方向上再来一次。所以从这个视角出发未来前端是不会消亡的可能只是会换一种形式存在但是不学习的工程师是会消亡的。
最后
最后我想说的是来到一个新业务不要着急的去拿这两个结果业务和技术所谓“潜龙勿用”。要先去看业务在集团所处的位置怎么和其他业务产生关联的要去收集信息和问题带着问题深入去做事情通过跟其他人的信息交流补全业务痛点。先收集问题边做边思考先沉下心做业务项目。要有导弹型思维就是不管三七二十一先干起来再说。在行动中实现智能导航锁定并跟踪目标根据实际情况修正自身路径直至击中目标。
其实写了比较多也是对我做事情的方法论做了一遍梳理和总结也是说最好不要让业务推着你走而是最终要做到你带着业务走。这个“带”可能最初是理解业务打法之后的一种业务朝着你理解的方向去走的体感但经过长期训练这部分其实可以做实最后真的是你通过技术创新引领行业变革最后驱动业务向前推进。当然这些是我来阿里三年的体会虽然在来之前也已经工作了七八年但在阿里成长的速度远远超过之前的成长并且也才刚刚三年还是个“新人”所以在这里也给自己个寄语希望五年、十年之后我的思考又会升华到一个层次。同时也欢迎大家拍砖/评论 原来我都是战战兢兢发文跟大家说轻拍需要鼓励但之后也是发现鼓励是最不容易发现问题这会导致发现不了自身思考上的盲点和盲区缺少成长路上的经验值所以这里鼓励大家一起多交流。
最后的最后也给大家推荐相关的几本书可能会对大家在上面几处没有展开来讲的去更详细的学习希望有所帮助《金字塔原理》、《麦肯锡教我的思考武器》、《思考快与慢》、《影响力》、《自控力》、《敏捷性开发》。
原文链接https://developer.aliyun.com/article/769432?utm_contentg_1000169093 本文为阿里云原创内容未经允许不得转载。
