简介： 在业务团队做事的工程师摸爬滚打了一段时间后，肯定会有所疑难。团队同学在最后的一段时间都提出这样的纳闷：如何在业务中发现有技术价值的问题？发现问题后如何思考和发动再到解决？最初的技术后果跟业务后果如何连接？很多时候咱们听他人说“思考是不够的 / 要多思考”，其实都是在说这几点。接下来，阿里高级前端技术专家氐宿谈一谈遇到这三个问题时，他是如何解决的？

作者 | 氐宿  阿里云高级前端技术专家

导读：在业务团队做事的工程师摸爬滚打了一段时间后，肯定会有所疑难。团队同学在最后的一段时间都提出这样的纳闷：如何在业务中发现有技术价值的问题？发现问题后如何思考和发动再到解决？最初的技术后果跟业务后果如何连接？很多时候咱们听他人说“思考是不够的 / 要多思考”，其实都是在说这几点。接下来，阿里高级前端技术专家氐宿谈一谈遇到这三个问题时，他是如何解决的？

如何在业务中发现有技术价值的问题？

一位科学家毕生可用于钻研的工夫极其无限，然而，世界上的钻研主题却多得数不清。如果只因为略微感觉乏味就选为钻研主题，将在还没来得及做真正重要的事时，毕生就完结了。
——利根川进

其实要解答这个问题之前，咱们要了解一个概念，什么是有价值的问题？议题度高和解答质高的问题我了解就是有价值的问题，比拟艰深的了解就是这个问题是否存在，以后要解决这个问题的必要性够不够，问题对应的解决方案可行性高不高。如果要在业务里发现这种问题，首先要了解业务策略、打法和定位。那如何能力把这个前置信息做好，对工程师来说是一个比拟大的挑战。

首先工程师其实大多数都是从事一线开发，对业务了解可能仅限于本人在做的事件。很多信息都是他人过滤了五六手之后的信息，失去的可能就是一个工作和为什么做这个工作。绝对比之下必定不如制订策略的人懂得策略背地的意义，信息也是不对等的。所以 首先咱们要收集信息，而后整顿演绎，最初剖析问题。

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 工程师的时代，在此期间应用层 / 展示层始终都在变动，所以前端同学总感觉状态是始终在学习新常识。但这个倒退历程其实是有法则可循的，所谓万变不离其宗，应用层尽管在一直变动但无非都是朝着两个大方向在倒退，一个是工程效率晋升（工程角度登程），一个是图形图像钻研（用户角度登程）。这两个大方向上目前也有非常复杂宏大的树状常识体系，并且还在一直延长。同时随着机器学习畛域的衰亡和硬件性能、网络带宽的晋升以及人们在视觉出现设施上的降级，带来的可能又是新一轮的技术洗牌，而后在两个方向上再来一次。所以从这个视角登程将来前端是不会沦亡的可能只是会换一种模式存在，然而不学习的工程师是会沦亡的。

最初

最初我想说的是来到一个新业务不要焦急的去拿这两个后果（业务和技术），所谓“潜龙勿用”。要先去看业务在团体所处的地位，怎么和其余业务产生关联的，要去收集信息和问题，带着问题深刻去做事件，通过跟其他人的信息交换补全业务痛点。先收集问题，边做边思考，先沉下心做业务我的项目。要有 导弹型思维，就是不管三七二十一，先干起来再说。在口头中实现智能导航，锁定并跟踪目标，依据理论状况修改本身门路，直至击中目标。

其实写了比拟多，也是对我做事件的方法论做了一遍梳理和总结，也是说最好不要让业务推着你走，而是最终要做到你带着业务走。这个“带”可能最后是了解业务打法之后的一种业务朝着你了解的方向去走的体感，但通过长期训练，这部分其实能够做实，最初真的是你通过技术创新引领行业改革最初驱动业务向前推动。当然这些是我来阿里三年的领会，尽管在来之前也曾经工作了七八年，但在阿里成长的速度远远超过之前的成长，并且也才刚刚三年还是个“新人”，所以在这里也给本人个寄语，心愿五年、十年之后我的思考又会升华到一个档次。同时也欢送大家拍砖 / 评论，原来我都是战战兢兢发文跟大家说轻拍，须要激励，但之后也是发现激励是最不容易发现问题，这会导致发现不了本身思考上的盲点和盲区，短少成长路上的经验值，所以这里激励大家一起多交换。

最初的最初也给大家举荐相干的几本书，可能会对大家在下面几处没有开展来讲的去更具体的学习，心愿有所帮忙：《金字塔原理》、《麦肯锡教我的思考武器》、《思考，快与慢》、《影响力》、《自控力》、《敏捷性开发》。