江苏龙网

  1. 首页 > 人文 > >

|技术人的灵魂 3 问，阿里工程师如何解答？



|技术人的灵魂 3 问，阿里工程师如何解答？
本文插图

导读：在业务团队做事的工程师摸爬滚打了一段时间后 ， 一定会有所疑问 。 团队同学在最初的一段时间都提出这样的疑惑：如何在业务中发现有技术价值的问题？发现问题后如何思考和发起再到解决？最后的技术结果跟业务结果如何衔接？很多时候我们听别人说“思考是不够的/要多思考” ， 其实都是在说这几点 。 接下来 ， 阿里高级前端技术专家氐宿谈一谈遇到这三个问题时 ， 他是如何解决的？
如何在业务中发现有技术价值的问题？
一位科学家一生可用于研究的时间极其有限 ， 然而 ， 世界上的研究主题却多得数不清 。 如果只因为稍微觉得有趣就选为研究主题 ， 将在还没来得及做真正重要的事时 ， 一生就结束了 。 ——利根川进
其实要解答这个问题之前 ， 我们要理解一个概念 ， 什么是有价值的问题？议题度高和解答质高的问题我理解就是有价值的问题 ， 比较通俗的理解就是这个问题是否存在 ， 当前要解决这个问题的必要性够不够 ， 问题对应的解决方案可行性高不高 。 如果要在业务里发现这种问题 ， 首先要理解业务战略、打法和定位 。 那如何才能把这个前置信息做好 ， 对工程师来说是一个比较大的挑战 。
首先工程师其实大多数都是从事一线开发 ， 对业务理解可能仅限于自己在做的事情 。 很多信息都是别人过滤了五六手之后的信息 ， 得到的可能就是一个任务和为什么做这个任务 。 相对比之下肯定不如制定战略的人懂得战略背后的意义 ， 信息也是不对等的 。 所以首先我们要收集信息 ， 然后整理归纳 ， 最后分析问题 。
1. 先来说说收集信息
其实有点像信息科学里的情报学 。 收集信息最好的方式就是参加所处业务老大的 KO 会 ， 各种 KO 会会把战略上的拆解和背后的思考整体梳理之后宣讲传达给 BU 或部门的同学 ， 虽然我们没有亲身参与到脑暴过程 ， 但是也会对背后的思考有一定的理解 ， 切记 ， 一定要记得划重点记笔记 。
获取第一手信息之后 ， 我们要经过简单梳理开始收集外部信息 ， 整理整体的知识脉络 ， 这里我经常用的就是阿里学习（业务宝库阿里学习 ， 技术宝库 ATA ， 注：阿里内部两个学习平台） ， 可以获取不少业务相关的分享 ， 当然很多外部渠道也同样可以收集到 。 比如资料《飞猪“新旅行联盟”赋能商家能讲出什么新故事？》就是外部收集到的 ， 可以得出几个关键词 ， 数字技术赋能旅行行业、我们不是 OTA ， 这些都要整理到自己收集的信息池里 。 当然以上我提到的都是信息获取源的一种 。 具体收集信息的释义可以查一下百科 ， 可以按照百科上的方法论学习一遍 ， 以便找到适合自己的方法 。 总之这里我们要像产品经理一样去收集这些信息 。 这里也鼓励跟不同领域不同BU的同学多交流 ， 不限于线下扯淡式的交流和线上问问题的方式（这里建议先看下知乎里这个回答关于学会问问题以及如何进行有效社交 。
2. 分析问题
我们通过不同信息源获取到的信息是散落的 ， 如何经过加工融入自己的思考体系呢？首先信息不能是简单的堆叠 ， 我们要通过不同的入口理出头绪 。 可以使用 MECE 法则进行思考拆解 ， 通过无遗漏无重复地分类来把握整体 ， 列出脑图和逻辑树 ， 最后将逻辑树的信息匹配需求场景 ， 可以尝试通过 C 端和 B 端不同入口去还原需求场景 。 这中间可以结合一定的方法论（演绎推理和归纳推理） ， 去把问题和挑战细化出来 ， 帮助我们理解 BU 的战略 ， 同时我们也能从自身出发把战略拆解到对应的项目 。 举例来说去年我个人分析飞猪在整个 C 端面临的主要问题之一还是流量格局过于单一 ， B 端供应链的成熟度不够导致无法给到商家更实质的体验服务 ， 飞猪的类目交叉不够背后是各垂直业务存在业务隔离 。
【|技术人的灵魂 3 问，阿里工程师如何解答？】
|技术人的灵魂 3 问，阿里工程师如何解答？
本文插图

发现问题到执行该如何衔接？
拿到这三个问题我们不能马上就开干 ， 我们还要提炼这个问题带来的核心价值 。 否则很容易就会出现投入了巨大工作之后 ， 最后的技术产出和业务结果衔接不上 ， 所以说思考不要用蛮力 ， 工作不只靠体力 。 要去看里面跟自己角色相关的工作在什么地方？
以端侧来说 ， 有优势的一点是靠近产品侧靠近用户侧 ， 所以基本展现模式都可以通过产品原型进行抽象 ， 形成体系化 。 以流量体系建设举例我们要对用户进行分层 ， 比较合理的方式可以用到几个经典模型RFM、AIPL、AARRR及其变种 ， 以便沉淀出承接的技术平台或产品 。 如流量体系建设我们在思考分层过后 ， 把用户按心智划分之后 ， 又从所属域分为散落在阿里域外的用户和阿里域内的内部用户 ， 从而针对性的设计出两个平台产品 。
|技术人的灵魂 3 问，阿里工程师如何解答？
本文插图

1. 见龙在田 ， 利见大人
作为项目发起者 ， 我们要关注每一个环节 。 所以首先我们要找到对应的业务方去“售卖”我们的思考 。 要找到目标一致的人一起做事 ， 这里首先需要知道的是你要清楚你的业务方都是谁？他们都负责什么？我的方法比较简单 ， 直接看运营在职能上的划分 ， 要清楚自己对的人负责的方向以及他所负责的 KPI 。 另外切记 ， 一定要和对口 PD 一起去找 ， 通常来说最直接的合作方是能帮你处理业务和技术衔接的那个人 。
上下游的人都找到后 ， 要开始准备 KO ， 理出需求排出优先级 。 因为在资源有限的情况下 ， 我们究竟该先做哪些？不重要的要放在后面去做 ， 优先考虑你产品最核心的功能 。 通常平台产品最优先的是运营使用的功能 ， 所以要跟合作方确认哪些功能他们认为最重要 。
2. 站在巨人的肩膀上做创新
阿里巴巴已经非常大了 ， 我们相信每一个想法都会有人想过 ， 所以尽量不要走重复的路踩同一个坑 ， 同理小公司利用开源技术亦是如此 。 那么在项目开始做的时候 ， 如果是平台 ， 我们需要先拆出核心功能 ， 这个核心功能要去看集团是否已经有人在做了或是有成熟方案 ， 避免重复造轮子 ， 同时也能最快最直接的解决你最紧急核心的问题 。 这其中最简单直接方法就是搜索 ATA（阿里内部技术论坛）和语雀（内部同学通常有知识记录的习惯） ， 拆关键词找到做事情的关键人 。 你要相信你绝不是第一个想到该问题的人 ， 一些通用问题一定在集团内已经有通用的服务提供出来 ， 即使没有也会有比较成熟的方案 。
如果集团内部就是没有成型方案 ， 这个方向也属于工业界比较前沿的领域 。 遇到类似这种问题 ， 可以先看看是否有绕开的可能性 ， 如果确实绕不开可以试试找到适合解决该问题的基础团队一起合作和共建 。 外部是否有付费方案可以购买和借鉴 ， 总之要保障业务先赢 。 因为业务工程师要思考的是你给业务能带来怎样的价值 ， 你的核心价值不是处理非常复杂的技术问题 ， 而是用你的技术能给业务带来怎样的价值增量 。 同样的利用某种技术或模型模式解决了非常复杂的业务问题 ， 并且是具有普适价值的技术 ， 这也是业务端工程师带给业务带来的价值 。
3. 立足当下 ， 放眼未来
知几 ， 其神乎！
要看当下更要看未来 ， 不光技术要看未来 ， 行业也要看未来 。 站在当下思考能解决业务目前遇到的最大的问题 ， 思考未来能为业务带来弯道超车的机会 。 比如飞猪如果在行业里要追赶同行业的竞品 ， 在资源投入方面没办法跟对方的体量比较的情况下 ， 我们做到最后 ， 最好的结果可能也只是追平对手 。 所以我们亟须找到未来行业争胜的关键按钮 ， 把时间和精力聚焦在关键节点 ， 用全球Fun战略突围 。 所以飞猪也要为国际化做好准备 ， 这个领域里同样有前人探寻的技术经验供我们借鉴 。 所以为了让我们能更聚焦业务 ， 可以说去年的平台化是为业务做了非常好的铺垫 。
最后的技术结果跟业务结果如何衔接？
其实这个小标题有点伪命题的意思 ， 如果一开始我们就把业务理解的很清楚 ， 执行没有偏离航道比较专注目标的话 ， 不大可能会出现拿不到业务结果的情况 ， 最后只剩下一个问题：拿到业务结果的同时技术价值如何体现？
从我自身出发 ， 也常常有同学问我 ， 在业务做开发 ， 重复造轮子会被人挑战 ， 但事情都有人干了我们的价值在哪？我之前一直都会回答 ， “搞基础技术的团队一直在基础工程/技术领域深耕 ， 他们也需要关注从技术价值到业务价值的转变和衔接 ， 本质上缺少业务场景 ， 如果我们与他们合作就形成了互补 ， 既拿到了业务结果同时也能从自身技术成长上得到一定历练” 。
但之后我回想这段对话 ， 是有很多问题在里面的 。 从业务工程师角度出发 ， 我们要关注的核心就是保障业务先赢 ， 如果没有达到这个目标就容易变成工程师自嗨 。 所以我们在业务端需要的是有技术视野能看到集团其他团队或者外部团队在做的事 ， 能主动交流让这件事变成共赢 ， 如果没有其他人在搞 ， 我们去搞要有人站出来看这个投入产出比是否合理？也就是我们在开篇说的议题度和解答质都高的有价值的问题 。 这个问题在集团其他团队是否存在共性 ， 我们解决了能否为他们带来价值？当然结合我们在前面讲到的在业务中发现有技术价值的问题 ， 其实这里就有一个比较明确的答案 ， 重中之重就是做之前把 Why 思考的清楚清晰 ， 做最正确的事 。 只有做到这点 ， 解决这个问题带来的业务价值就自然而然非常清晰的定位出来 。 所以说最好的工程师必须要懂产品 。
也写给未来
小聊一下题外话 ， 组里有同学会问我业务前端未来是否会被淘汰？因为我们在做的 lowcode/nocode 是在革自己的命 。 其实产生这种想法首先就是没有站在集团未来发展的角度去思考也就是常说的屁股太小 ， 其次是没有站在整个前端领域去回顾前端发展历程导致的悲观和担忧 。
从目前在做的方向上来说 ， 还是要思考如何解决低质量代码建设和低效的重复工作占用工程师大部分精力 ， 将工程师的能量解放出来提升集团整体的研发效能 。 另一层面从前端以往在系统分层里的位置一直都属于应用层 ， 就是最上层的表象/展现/渲染 ， 应用层在过去几十年间经过了不断的变化和演进 ， 职业也从最早的 GUI 工程师演进到之后的 web 前端/客户端研发工程师 ， 这中间也经历过 flash 工程师的时代 ， 在此期间应用层/展现层一直都在变化 ， 所以前端同学总觉得状态是一直在学习新知识 。 但这个发展历程其实是有规律可循的 ， 所谓万变不离其宗 ， 应用层虽然在不断变化但无非都是朝着两个大方向在发展 ， 一个是工程效率提升（工程角度出发） ， 一个是图形图像研究（用户角度出发） 。 这两个大方向上目前也有非常复杂庞大的树状知识体系 ， 并且还在不断延伸 。 同时随着机器学习领域的兴起和硬件性能、网络带宽的提升以及人们在视觉呈现设备上的升级 ， 带来的可能又是新一轮的技术洗牌 ， 然后在两个方向上再来一次 。 所以从这个视角出发未来前端是不会消亡的可能只是会换一种形式存在 ， 但是不学习的工程师是会消亡的 。
最后
最后我想说的是来到一个新业务不要着急的去拿这两个结果（业务和技术） ， 所谓“潜龙勿用” 。 要先去看业务在集团所处的位置 ， 怎么和其他业务产生关联的 ， 要去收集信息和问题 ， 带着问题深入去做事情 ， 通过跟其他人的信息交流补全业务痛点 。 先收集问题 ， 边做边思考 ， 先沉下心做业务项目 。 要有导弹型思维 ， 就是不管三七二十一 ， 先干起来再说 。 在行动中实现智能导航 ， 锁定并跟踪目标 ， 根据实际情况修正自身路径 ， 直至击中目标 。
其实写了比较多 ， 也是对我做事情的方法论做了一遍梳理和总结 ， 也是说最好不要让业务推着你走 ， 而是最终要做到你带着业务走 。 这个“带”可能最初是理解业务打法之后的一种业务朝着你理解的方向去走的体感 ， 但经过长期训练 ， 这部分其实可以做实 ， 最后真的是你通过技术创新引领行业变革最后驱动业务向前推进 。 当然这些是我来阿里三年的体会 ， 虽然在来之前也已经工作了七八年 ， 但在阿里成长的速度远远超过之前的成长 ， 并且也才刚刚三年还是个“新人” ， 所以在这里也给自己个寄语 ， 希望五年、十年之后我的思考又会升华到一个层次 。 同时也欢迎大家拍砖/评论 ，原来我都是战战兢兢发文跟大家说轻拍 ， 需要鼓励 ， 但之后也是发现鼓励是最不容易发现问题 ， 这会导致发现不了自身思考上的盲点和盲区 ， 缺少成长路上的经验值 ， 所以这里鼓励大家一起多交流 。
最后的最后也给大家推荐相关的几本书 ， 可能会对大家在上面几处没有展开来讲的去更详细的学习 ， 希望有所帮助：《金字塔原理》、《麦肯锡教我的思考武器》、《思考 ， 快与慢》、《影响力》、《自控力》、《敏捷性开发》 。
作者 | 氐宿 阿里云高级前端技术专家
本文为阿里云原创内容 ， 未经允许不得转载 。


    推荐阅读


    上一篇：生活小六子|印度美食有多“黑暗”？辛香炒饭不算啥，看到最后：真能吃？

    下一篇：史上最大器晚成之人，西汉名相张苍：生的好不如活得久