在业务团队做事的工程师摸爬滚打了一段时间后，一定会有所疑问：如何在业务中发现有技术价值的问题？发现问题后如何思考和发起再到解决？最后的技术结果跟业务结果如何衔接？接下来，阿里高级前端技术专家氐宿谈一谈，他是如何面对这三个问题的？

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

一位科学家一生可用于研究的时间极其有限，然而世界上的研究主题却多得数不清。如果只因为稍微觉得有趣就选为研究主题，那么还没来得及做真正重要的事时，一生就结束了。—— 日本科学家利根川进

要解答这个问题之前，我们要理解一个概念——什么是有价值的问题？我认为，议题度高和解答质高的问题就是有价值的问题。比较通俗的理解就是，这个问题是否存在，当前要解决这个问题的必要性够不够，问题对应的解决方案可行性高不高。如果要在业务里发现这种问题，理解业务战略、打法和定位非常重要。对于工程师来说，如何把前置信息做好是一个比较大的挑战。

首先，工程师其实大多数都是从事一线开发，对业务理解可能仅限于自己在做的事情；其次，工程师往往得到的信息都是别人过滤了五六手之后得到的，最终的结果可能就是一个任务和为什么做这个任务。相对制定战略的人，工程师肯定不如他们懂得战略背后的意义，信息也是不对等的。因此，我们需要收集信息，然后整理归纳，最后分析问题。

先来说说收集信息

其实有点像信息科学里的情报学，收集信息最好的方式就是，参加所处业务老大的 KO 会议。KO 会议会把战略上的拆解和背后的思考整体梳理之后，再宣讲传达给 BU 或部门的同学，虽然我们没有亲身参与到脑暴过程，但是也会对背后的思考有一定的理解。切记，一定要记得划重点、记笔记。

获取第一手信息之后，我们要先经过简单梳理，再开始收集外部信息，整理整体的知识脉络，这里我经常用的就是阿里学习（业务宝库阿里学习，技术宝库 ATA，注：阿里内部两个学习平台），可以获取不少业务相关的分享，当然很多外部渠道也同样可以收集到。比如这段资料 [1] 就是外部收集到的，可以得出几个关键词，数字技术赋能旅行行业、我们不是 OTA，这些都要整理到自己收集的信息池里。当然以上我提到的都是信息获取源的一种。具体收集信息的释义可以查一下百科 [2]，可以按照百科上的方法论学习一遍，以便找到适合自己的方法。总之这里我们要像产品经理一样去收集这些信息 [3]。这里也鼓励跟不同领域不同 BU 的同学多交流，不限于线下扯淡式的交流和线上问问题的方式（这里建议先看下知乎里这个回答关于学会问问题 [4] 以及如何进行有效社交 [5]）。

分析问题

我们通过不同信息源获取到的信息是散落的，如何经过加工融入自己的思考体系呢？首先，信息不能是简单的堆叠，我们要通过不同的入口理出头绪；其次，可以使用 MECE 法则进行思考拆解，通过无遗漏无重复地分类来把握整体，列出脑图和逻辑树；最后将逻辑树的信息匹配需求场景，尝试通过 C 端和 B 端不同入口去还原需求场景。这中间可以结合一定的方法论（演绎推理和归纳推理），将问题和挑战细化出来，帮助我们理解 BU 的战略。同时，我们也能从自身出发把战略拆解到对应的项目。

举个例子，去年我个人分析飞猪在整个 C 端面临的主要问题之一是流量格局过于单一，B 端供应链的成熟度不够导致无法给到商家更实质的体验服务，飞猪的类目交叉不够背后是各垂直业务存在业务隔离。

发现问题到执行该如何衔接

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

见龙在田，利见大人

作为项目发起者，我们要关注每一个环节。因此，我们要找到对应的业务方去“售卖”我们的思考，以及找到目标一致的人一起做事。

这里我们需要清楚自己的业务方都是谁？他们分别负责什么？我的方法比较简单，直接看运营在职能上的划分，清楚自己对应的人负责的方向以及他所负责的 KPI。另外切记，一定要和对口 PD 一起去找。通常来说，最直接的合作方是能帮你处理业务和技术衔接的那个人。

上下游的人都找到后，要开始准备 KO，理出需求排出优先级。因为在资源有限的情况下，我们需要自己先做哪些事，可以将不重要的要放在后面去做，优先考虑你产品最核心的功能。通常平台产品最优先的是运营使用的功能，所以要跟合作方确认哪些功能他们认为最重要。

站在巨人的肩膀上做创新

阿里巴巴已经非常大了，我们相信每一个想法都会有人想过，所以尽量不要走重复的路踩同一个坑，同理小公司利用开源技术亦是如此。那么在项目开始时，如果是平台，我们需要先拆出核心功能。这个核心功能需要看集团内是否已经有人在做了，或是有成熟方案，避免重复造轮子。同时，这也能最快、最直接解决你最紧急核心的问题。这其中最简单直接方法就是搜索 ATA（阿里内部技术论坛）和语雀（内部同学通常有知识记录的习惯），拆关键词、找到做事情的关键人。你要相信你绝不是第一个想到该问题的人，一些通用问题一定在集团内已经有通用的服务提供出来，即使没有也会有比较成熟的方案。

如果集团内部没有成型方案，这个方向也属于工业界比较前沿的领域。遇到类似这种问题，可以先看看是否有绕开的可能性，如果确实绕不开，你可以试试找到适合解决该问题的基础团队一起合作和共建，或者外部是否有付费方案可以购买和借鉴。总之，你要保障业务先赢。因为业务工程师要思考的是，你给业务能带来怎样的价值，而不是处理非常复杂的技术问题。利用某种技术或模型模式解决了非常复杂的业务问题，并且是具有普适价值的技术，这也是业务端工程师带给业务带来的价值。

立足当下，放眼未来

知几，其神乎！

要看当下更要看未来，不光技术要看未来，行业也要看未来。站在当下思考能解决业务目前遇到的最大的问题，思考未来能为业务带来弯道超车的机会。比如飞猪如果在行业里要追赶同行业的竞品，在资源投入方面没办法跟对方的体量比较的情况下，我们做到最后，最好的结果可能也只是追平对手。所以我们亟须找到未来行业争胜的关键按钮，把时间和精力聚焦在关键节点，用全球 Fun 战略突围。所以飞猪也要为国际化做好准备，这个领域里同样有前人探寻的技术经验供我们借鉴。所以为了让我们能更聚焦业务，可以说去年的平台化是为业务做了非常好的铺垫。

技术结果与业务结果如何衔接

其实这个小标题有点伪命题的意思，如果一开始我们就把业务理解的很清楚，执行没有偏离航道比较专注目标的话，不大可能会出现拿不到业务结果的情况，最后只剩下一个问题：拿到业务结果的同时技术价值如何体现？

从我自身出发，也常常有同学问我：在业务做开发，重复造轮子会被人挑战，但事情都有人干了我们的价值在哪？我之前一直都会回答，“搞基础技术的团队一直在基础工程 / 技术领域深耕，他们也需要关注从技术价值到业务价值的转变和衔接，本质上缺少业务场景，如果我们与他们合作就形成了互补，既拿到了业务结果同时也能从自身技术成长上得到一定历练。”

但之后我回想这段对话，里面存在很多问题。从业务工程师角度出发，我们要关注的核心就是保障业务先赢，如果没有达到这个目标就容易变成工程师自嗨。因此，我们在业务端需要的是，有技术视野能看到集团其他团队或者外部团队在做的事，能主动交流让这件事变成共赢，如果没有其他人在做，我们需要看这个投入产出比是否合理？也就是我们在开篇说的，议题度和解答质都高的有价值的问题。这个问题在集团其他团队是否存在共性，我们解决了能否为他们带来价值？当然，结合我们在前面讲到的在业务中发现有技术价值的问题，其实这里就有一个比较明确的答案，重中之重就是做之前把 Why 思考的清楚清晰，做最正确的事。只有做到这点，解决这个问题带来的业务价值就自然而然非常清晰的定位出来。所以说，最好的工程师必须要懂产品。

写给未来

小聊一下题外话，组里有同学会问我业务前端未来是否会被淘汰？因为我们在做的 lowcode/nocode 是在革自己的命。其实产生这种想法的人，首先是没有站在集团未来发展的角度去思考问题，也就是常说的屁股太小；其次是没有站在整个前端领域去回顾前端发展历程导致的悲观和担忧。

从目前在做的方向上来说，还是要思考如何解决低质量代码建设和低效的重复工作占用工程师大部分精力，将工程师的能量解放出来提升集团整体的研发效能。另一方面，前端在系统分层里的位置一直都属于应用层，就是最上层的表象 / 展现 / 渲染，应用层在过去几十年间经过了不断的变化和演进，职业也从最早的 GUI 工程师演进到之后的 Web 前端 / 客户端研发工程师，这中间也经历过 Flash 工程师的时代，在此期间应用层 / 展现层一直都在变化，所以前端同学总觉得状态是一直在学习新知识。但这个发展历程其实是有规律可循的，所谓万变不离其宗，应用层虽然在不断变化但无非都是朝着两个大方向在发展，一个是工程效率提升（工程角度出发），一个是图形图像研究（用户角度出发）。这两个大方向上目前也有非常复杂庞大的树状知识体系，并且还在不断延伸。同时，随着机器学习领域的兴起和硬件性能、网络带宽的提升以及人们在视觉呈现设备上的升级，带来的可能又是新一轮的技术洗牌，然后在两个方向上再来一次。所以，从这个视角出发，未来前端是不会消亡，可能只是会换一种形式存在，但是不学习的工程师是会消亡的。

最后

我想说的是，来到一个新业务时，不要着急的去拿这两个结果（业务和技术），所谓“潜龙勿用”。你需要先去看业务在集团所处的位置，在思考如何与其他业务产生关联的，再去收集信息和问题，带着问题深入去做事情，通过跟其他人的信息交流补全业务痛点。先收集问题，边做边思考，先沉下心做业务项目。要有导弹型思维，就是不管三七二十一，先干起来再说。在行动中实现智能导航，锁定并跟踪目标，根据实际情况修正自身路径，直至击中目标。

其实写了比较多，也是对我做事情的方法论做了一遍梳理和总结，也是说最好不要让业务推着你走，而是最终要做到你带着业务走。这个“带”可能最初是理解业务打法之后。业务朝着你理解的方向去走的体感，但需要经过长期训练，这部分其实可以做实，最后实现你通过技术创新引领行业变革，驱动业务向前推进。

参考资料

[1]《飞猪“新旅行联盟”赋能商家能讲出什么新故事？》
[2]https://baike.baidu.com/item/ 信息收集 /4012739
[3]《如何高效地获取、收集和整理信息》
[4]《成为聪明人的第一步，是学会「问对问题」》
[5]《如何区分有效社交与无效社交？》

本文由阿里技术(ali_tech)授权转载，关注 TGO 鲲鹏会公众号（ID：tgo-kunpenghui）了解技术管理的各样招式。

TGO鲲鹏会，是极客邦科技旗下高端技术人聚集和交流的组织，旨在组建全球最具影响力的科技领导者社交网络，线上线下相结合，为会员提供专享服务。目前，TGO鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名，60% 为 CTO、技术 VP、技术合伙人。

会员覆盖了 BATJ 等互联网巨头公司技术领导者，同时，阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀，成为 TGO 鲲鹏会荣誉导师。

创作场景

技术人的灵魂 3 问，看阿里 P8 专家如何解答