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

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

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

    先来说说收集信息

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

分析问题

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

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

找对人，确定边界

    作为项目发起者，我们要关注每一个环节。所以首先我们要找到对应的业务方去“售卖”我们的思考。要找到目标一致的人一起做事，这里首先需要知道的是你要清楚你的业务方都是谁？他们都负责什么？我的方法比较简单，直接看运营在职能上的划分，要清楚自己对的人负责的方向以及他所负责的KPI。另外切记，一定要和对口PD一起去找，通常来说最直接的合作方是能帮你处理业务和技术衔接的那个人。

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

站在巨人的肩膀上做创新

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

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

立足当下，放眼未来

    要看当下更要看未来，不光技术要看未来，行业也要看未来。站在当下思考能解决业务目前遇到的最大的问题，思考未来能为业务带来弯道超车的机会。比如飞猪如果在行业里要追赶同行业的竞品，在资源投入方面没办法跟对方的体量比较的情况下，我们做到最后，最好的结果可能也只是追平对手。所以我们亟须找到未来行业争胜的关键按钮，把时间和精力聚焦在关键节点，用全球Fun战略突围。

    拿到业务结果的同时技术价值如何体现？

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

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

最后

    最后我想说的是来到一个新业务不要着急的去拿这两个结果（业务和技术）。要先去看业务在集团所处的位置，怎么和其他业务产生关联的，要去收集信息和问题，带着问题深入去做事情，通过跟其他人的信息交流补全业务痛点。先收集问题，边做边思考，先沉下心做业务项目。

     最好不要让业务推着你走，而是最终要做到你带着业务走。 这个“带”可能最初是理解业务打法之后的一种业务朝着你理解的方向去走的体感，但经过长期训练，这部分其实可以做实，最后真的是你通过技术创新引领行业变革最后驱动业务向前推进。