“升职靠业务，跳槽靠技术？”阿里技术专家谈职场晋升

来源 | 阿里技术（ali_tech）

作者：墨玖

导读：伐薪是阿里巴巴高级技术专家，14年初入阿里时，没有过多地思考业务痛点和了解业务策略。后来，经历过晋升，当晋升评委，主动学习业务，最后，完成了从技术专家向综合性 TL 转变。这一路下来，总结了不少经验，今天，分享给你们。

最近刚过晋升季，本身也作为评委参与了一些同学的晋升，整体上觉得业务与技术链接比较好的同学容易脱颖而出，另外也看到有些同学在业务理解上存在一些问题，也促使我最近一直在回顾和反思最近几年的经历，发现还是有很多可以写的，在此记录下来，希望能给新同学或者迷茫的同学带来少许启发。

首先我说下自己的经历，我在14年才加入阿里，以前也做的是2C的电商业务，现在想想以前是真的不懂业务，也没有业务意识，自己也不会去思考业务痛点和了解业务策略，几乎从来没和业务方（运营）沟通业务，都是和产品沟通需求（后面会说需求和业务的差别）。

晋升成功之后，我就陷入了迷茫之中，如果我不接触一线业务，是不可能有更大的成长和发展的，在和老板多次谈话的过程中，我逐步理清了我之后的方向，那就是做业务、技术两手都要抓的人，补齐业务理解，带动周围的同事一起加油。

为了促进业务的理解，我主动要求加入干部组织，了解更多技术 TL 的信息，主动阅读各种业务方的周报，遇到不理解的策略，厚着脸皮去找非对口的运营去问，由于没有直接对接的业务，因此也没有谁邀请我去做市场走访，因此我更多的是去看别人的走访记录去理解商家遇到了什么问题，目前市场的状况是怎么样的，主动思考业务问题，并且学习 odps 自己去分析数据，很多疑问用数据一查便知，主动去梳理 CBU 业务的产品树和对接团队，理清业务和产品脉络，在这种情况下，我对业务的理解逐步清晰起来。

此后各种主动或者被动的变化，负责的业务也越来越多，团队最多达到18人，是一年前的9倍，一开始业务带的很多觉得是一种荣耀，但是后来也慢慢发现，业务做的多，不如业务做的好，因此后面又和老板做了一些调整，团队负责的东西也越来越聚焦，目前主要负责 CBU 的营销、导购、内容以及工程技术，是 CBU 源头厂货战略的一线参与者，也是大促的前端对口 team 和主要搭投产品 owner，同时技术上也有不少抓手。自此，个人算是完成了从技术专家向综合性 TL 转变，接下来主要对自己在技术理解和判断上做一些回顾和总结，希望能给有同类问题的人一些小小的帮助。

业务先赢是技术第一要务

首先对于业务先赢这一点，我相信大家是没有争议的，一个公司是因为先有业务模式，才去招兵买马，组建研发团队的，皮之不存毛将焉附，业务好坏决定了公司的营收和前途，也决定了研发的效益和去留，因此技术人员首要任务是先把业务支持好，在这个前提下，再来讲技术沉淀和技术红利，支持业务又分这么几种层次，按对业务的影响程度排序，我整理了一个图：

这个图主要把研发过程对业务的影响分为了6类：

1.按时交付，质量一般，大概就是对外包的要求；

2.技术增值，能够很快而且很爽地完成交付，这种情况下需要磨刀或者升级研发工具，会存在研发效能提升的机会，事实上研发大部分的技术沉淀也会在此，就是升级自己的研发流程和工具，提升自己的交付效率和研发体验。我们听过业务方对我们最多的诉求就是希望快速上线，因此研发效能是技术的生命线。

当然研发效能提升也没那么容易，而且很难量化，因为即使是同一个人，不同时间面对的事情也是不一样的，而同一个事情，在不同阶段的策略和细节也不一样，因此即使你做了一些研发效能提升的事情，也很难说到底对交付效率提升了多少，很多情况下会是研发自己觉得爽了，当然研发自己爽这也很重要，因此对于这类研发效能类工具，研发满意度和用户数是比较重要的评价指标；其他类型的，尽量找定量结果，通常是一些可模式化的工作，比如还原一个视觉稿的速度，客户端发版的速度，编写一个 http 接口的速度，上线一个应用的速度。

3.技术增值，除了按时完成交付之外，还能把产出质量做得很好，比如端的体验（流畅度、性能）、稳定性、接口的速度与数据实时性，安全性等，按理说这些是基本的要求，为何要成为技术的增值价值呢？

因为从软件工程的角度来讲，软件质量是一定有问题的，而且与项目复杂度和周期成正比，而且业界也没有标准，说什么规模、特质的业务应该达到什么样的体验，因此这里更多要依赖于技术人员的工匠精神与技术挖掘能力，而且软件质量看起来对业务没有直接驱动作用，但是在竞争对手足够多而且用户更换成本又低的情况下，软件质量的好坏对用户留存有一定的影响。这是定性，当然大部分研发的困境也就在此，就是如何量化体验提升对用户转换和留存的价值？

如果无法量化，那么在软件体验上应该投入多少呢？ROI 如何衡量呢？当然有一点可以肯定的是，你的质量要做到一定范围的领先，超过同类产品，那么你的增值价值就更能体现，对于技术本身就是业务的公司如云计算公司，技术产品本身的质量对业务的价值则非常明显了。

4.仍然是技术增值，但是这里的技术具有鲜明的业务场景特色，比如 SEO 技术、B 类的大额支付、A 站的弹幕技术、广告的创意技术、店铺装修技术，这里所有的技术沉淀都是围绕业务来的，因此我把它画在中间，属于又有技术沉淀，又能带来业务结果的技术。

5.业务增值，就是做了一些业务方原以为技术不能干、干不好的那些能够直接促进业务发展的事情，这就是所谓的技术驱动业务。当然这里的抓手还是技术，但是，与前面说的区别是，这里的出发点或者说结果，是直接能对业务产生有利增长的，前面很多事情提升的都是一些技术指标，比如交付周期、crash 率、页面或接口性能等等。

技术驱动业务也是大部分工程开发最困惑的一点，也是对业务型开发影响最大的点，在前面的阶段，研发做的事情都是解决技术的事情，这个阶段，你需要去发掘业务痛点或机会，然后用技术力量去改善，当然这里的技术力量可以是有很大厚度的。比如算法与机器学习，也可以是不需要技术厚度，但是需要产品设计和链接的，也可以是老技术，也可以是新技术。总的来说，它更看重业务价值，而不是技术厚度，哪怕是简单的技术解决了业务问题，也是值得喝彩，这就是我经常说的，站在业务视角，技术价值能够被放大。

6.直接参与业务决策的阶段，在云计算公司、技术产品型公司或者业务模式简单的公司，技术参与决策的机会更大，部分高管本身也会是技术出身，也可能是技术高管直接担任业务负责人，在腰部，也会有一些技术主管直接带运营和产品。

但是大部分情况并不是这样，尤其是商业模式复杂，生态复杂的公司，产品、运营和技术，三位一体，角色分明，即使技术可以在一些产品和业务上提供建议或者分析依据，但通常不会成为业务的主要决策力量，是因为整体上，技术对商业的理解比较碎片，或者仅仅是想法而已。

运营通常在某一行业深耕许久，接触到的情况，实践过的东西非外行能够快速追赶，当然业务和技术对行业、对市场大局的洞察，以及做事情需要的优秀特质，这一点，并不存在很大的壁垒。

个人认为，技术是否要做到这一阶段，取决于个人的职业发展规划，属于做了需要奖励但不必作为基本要求，需要要求的是，对业务的理解尽量与业务高度接轨，对业务要有自己的洞察，清楚业务的痛点和难度，理解背后战略意义，做到这一点，可以做到上一个阶段说的很多事情，就是能够做更多技术驱动业务的事情，因为你对业务的理解有了，才知道业务更需要什么，也会有使命感去推进这些事情。

上述几个阶段，层层递进，对业务的影响不断提升，不管是间接还是直接地做效能、体验、质量、稳定，还是做直接促进业务增值的事情，最终都是要促进业务发展的，只是方式不一样，影响程度不一样，作为技术的职责，就是要想办法让业务能够更好，能让技术的价值有更大的体现。

那么不理解业务是不是就无法做驱动业务的事情，或者说就不做那些驱动业务或者参与业务决策的事情，只做那些技术的基本要素的事情——质量、稳定、体验、性能，就行了？事实上也是可以的，我看到很多优秀的同学发展得不错，他们也没怎么去看业务的事情，也有一些人对业务理解并不是那么好，但是能抓住一些小点，做了一些改善局部业务的事情，也取得了很好的结果。

这是因为我们讲究的是多元化人才，人是阿里的最大财富，每个人的特质不一样，有的人善于钻研技术，有的人善于做串联协调，有的人具有产品 sense，他们都是我们需要的人才，业务理解和业务结果不是唯一衡量研发或人才的指标。

但是有一点可以肯定的是，理解业务有助于你做技术决策去驱动业务，有助于你对资源的优先级做判断，而且还有助于提升你的研发效能，是不是听错了，理解业务有助于提升研发效能？我们一般讲研发效能都是依赖一些技术或工具手段来改善的，理解业务怎么能促进研发效能，大部分持这一观点的人，都忽视了人的精神因素，一个对业务理解的人，一个认可业务的人，他做事情的时候会有很大的使命感，业务有一定成绩会有很大成就感，这都能让他又好又快完成任务的交付，因此也是研发效能的提升，这就是我们的老板经常和我们讲业务策略，或者搞业务动员大会的原因；反之一个对业务背后的 why 不理解，没有使命感的人，如何要求他做出高质高效的交付呢？更不用说增值价值了。

如何理解业务

很多人认为理解需求就是理解业务了，需求其实是业务经过产品消化后的产物，可能已经经过演绎，或者是其中某个拆解环节，因此需求并不是业务本身。当然了解的需求越多，可以让你更清楚业务的全貌。

那么什么是业务呢？业界对"业务"有多种定义，但是其主要思想基本不变，业务就是一系列人通过一系列活动完成某一任务的过程，因此，业务可大可小，可以无限拆分，对 CBU 的批发业务来说，就是次终端用户通过1688批发商品并转卖给下游的行为，而 CBU 本身又分了很多子业务，如诚信通，是百万商家通过付费方式获取增值服务的业务。数字营销，则是让卖家通过采买流量促进转化的过程，而数字营销中的 CPS 业务，又是让商家为商品设置佣金，渠道推广商品促进成交而获得该佣金的业务，诚信通、实力商家和数字营销，又可以归结为 CBU 的商业化业务。

广义上来说，研发过程也可以是业务，比如对于 aone 来讲，产品在 aone 提需求，开发在上面建立项目、迭代，测试提交 bug，最终需求发布的过程也是业务，当然在本文中，我们讲的业务主要是商业业务，就是与该 BU 商业模式直接关联的业务或其组成部分。

据说老逍（阿里集团 CEO）对来给自己汇报新业务的同学都会提出3个问题：第一，这个业务的用户是谁？第二，这个业务解决了什么痛点？第三，这个业务为什么是你做？因此无论是从业务的定义还是从老逍的话里面来看，要理解业务，先要理解业务中的人，也就是角色，他们在干什么，为何而来，到何处去，获得何种收益，这是最起码的。比如线上打车这个业务，参与的角色有司机（社会车辆与营运车辆、乘客和平台），那么司机为什么来呢？因为可以充分利用闲置时间去赚钱，也可以接到更多的单子，乘客为什么用线上打车而不是直接在路边打车？因为路边打车难，线上的话可以充分调动附近的车辆，还可以提前打，可以看到线上打车最大化地提升了社会效率，解决了一个社会痛点。

再了解这里面的商业模式——流量如何来的？内容如何来的？生态情况怎么样？如何商业化的？再走到宏观上去，看看行业情况怎么样，竞争对手怎么样，最后回到产品和技术，这个业务什么产品在承载，主要对技术的依赖和诉求又是什么。前面摸到一些信息之后，接下来最好还能够有一些洞察和思考，比如你为什么要做这个业务，现在业务发展遇到了什么瓶颈？打算如何破局？基本上把这些摸清楚了，你对这个业务就有个比较清楚的脉络了，也能和业务方做对话了。

但是要达到这种程度是需要下苦功夫的，有些业务比较简单，比如打车，很容易明白业务框架，但是要了解细节不容易，比如你知道出租车与出租车公司的关系和利益是怎样的吗？如果不理解，怎么去颠覆它？对于零售、贸易、制造、跨境、金融等更复杂的业务，就更难了解流程和细节了，需要用各种渠道去补齐信息，比如阅读行业书籍、实地走访、与用户沟通、分析数据等方式，这里我列举了一些方法，分别从易到难，最简单的是唾手可得的东西，比如资料和书籍，其次是学会分析行业或者公司内数据，最后是用户调研和实地走访，并产生自己的洞察。

先说资料的阅读，比如我为了了解批发市场，探索批发市场的归途，看了一些政府的报告，也看了一些行业的调研：

为了了解商品流通渠道，查了很多与经销商有关的资料，并产生了一些洞察，输出了文章《从串货谈线下渠道与B2B》，思考未来商品流通方式，探古索今，还阅读了一些研究中国古代贸易的书：

除了书籍以外，公司内还有比较好的渠道，就是调研团队的报告，里面的数据和信息，都是他们亲身调研得到的结果，我自己也偶尔会去调研业务，公司里还有很多运营，乐于分享业务策略，也可以多和他们交流，这里推荐一下since 1979 放翁对业务思考的录音，曾经在飞机上把这些都听完了，了解到很多想了解但是还没来得及或者没办法去了解的东西。

分析行业数据或者业务本身数据也是理解业务的一种重要手段，业界很多公司专门做行业数据分析的，比如易观千帆、questmobile、托比网，经常会出一些行业报告可以让你了解市场，对于内部的业务数据，有一些现成的报表，比如 fbi、camp 等，但是要想查出自己想要的数据，还是建议自学 sql 去 odps 查询，因为有些你想看的报表是没有的，有些报表的分析维度也不是你想要的，以前运营和 pd 都依赖 DA 和 BI 分析数据，制作报表，但是最近几年，大家都在学习 sql，这是自上而下的要求，我个人也认为基本的数据分析最好自己搞。

目前团队的同学基本人人会数据分析，前一阵子还搞了一个专门袭击，在周会的前一天，给了一个命题：分析1688的买家身份占比和 GMV 贡献，按时做出来的同学还是不少，即使没做出来的后面也逐渐学会了去做，有的同学会分析，但不会做报表，刚好周会上一交流，就全会了。

学会数据就打开了一扇新的窗户，很多问题你都可以在这里找到答案，比如为什么跨境业务以前只是1688的一个垂直场景，后来为啥能够与1688平行成为 CBU 下的一个独立业务，查询数据可见端倪。因为跨境买家占比虽少，但交易贡献巨大，跨境业务的ROI 大，这是数据上的洞察，当然光靠这个是不够的，如果你走访了很多市场，了解了很多做跨境电商的卖家，就知道全国目前都没有专门做跨境商品的批发市场，非常零散，而1688这种线上批发市场就成为了跨境商品最集中的地方，很多做 AE、做 ebay，甚至 lazada 的商家，都会从1688进货，东南亚一些本地零售商和代购商，也会从1688进货，转运到当地。

所以说，要对业务有深入的了解，除了数据洞察以外，还要多和商家当面交流，多去实地走访，在过去的一年，团队做了很多次走访，整理了完整的走访最佳实践和走访报告集。从北方的烟台、白沟到南方的深圳、广州，从西部的重庆、成都，到东部的义乌、温州，从一批市场，到销地市场，从源头工厂到组货商，都有我们出没的身影，这里按时间从近到远列举一些例子：

• 霸天，5月份的《织里直播商家走访》，还引起了 BU 外的一些运营关注并前来咨询。

• 夕山，去年10月份《虎门互利共享工厂走访》，第一次近距离看见制造业居然和自助火锅一样变成共享。

• 陌笛，去年7月份，调研广州批发市场《对支付宝小程序的看法》。

走访工厂，了解服装制造流程

走访有时能拿到一些市场上的最新信息，比如店主的进货模式是否有变化。在2017年我去温州线下调研的时候，发现了一些服装店主借助2B的买手 APP 拼团，这是我首次发现 toB 的拼团场景。另外，我后面负责广告的 CPS 业务，因此也促使我后来游说1688一些产品和运营搞 B 类拼团，输出了文章《对2B拼团的设想》，后面1688也确实在策划相关能力，我也参与到早起的方案评审当中，并提出了一些见解，当然后面拼团的业务最终还是没有和我的预期一致。

一开始是困惑和感性的，但是后面随着对业务以及环境的理解，更加看到了拼团的本质，就是拼团仅仅是一种用户增长的营销方式而已，由于阿里系在社交上缺乏布局，因此这个事情存在天花板，至于2B的拼团，是否是用户痛点，能否规模化，可能都是需要打问号的。不管结果如何，整体上这个事情，还是对我的业务视野提升有了很大的帮助，也提升了我在业务理解上的信心，我感觉到自己有很多想法能够和运营 match，也越来越务实。

走访发现一些中间商使用群控手机在电商拉取商家 leads

回归到我们技术本身，不可能老是出去走访，而我们大部分时间会与产品开发有关，因此在办公室还可以多体验竞争对手的产品，了解 ISV 铺货和订单回流流程及其他商家自运营产品，对于自己对接的产品，我的建议是要用自己的思路梳理出产品矩阵，我对团队同学的要求是，禁止直接引用业务或产品的图来解释业务，所有的业务策略和产品架构图都要自己画一遍，只有自己用心画一遍，才会真正理解产品组成，消化业务策略。

走访四季青服装批发市场

事实上，业务了解的渠道是说不完的，只要你有心，我相信能抓住任何一个机会，比如去小店买瓶水，去地摊买个发夹，也可以和老板攀谈，另外亲朋好友之间总有做生意的，也可以了解他们的一些做生意的方式，总之，要对世界的运转以及自己接触的业务保持好奇心。

我自己在业务理解上的收获

对业务的理解日渐熟悉之后，那么能带来什么收货呢？个人觉得，如果是说希望技术理解业务之后能对业务产生影响，未免太过幼稚。理解业务更多是理解了运营决策背后的原因，理解了网站各个角色的诉求和痛点，理解了自己做的产品和项目对业务的价值和影响，让自己更加有使命感，也能对项目分清轻重缓急，并且有机会产生驱动业务的技术产品。而业务决策通常鲜有从0到1的，大部分是具体的一些运营策略，需要你懂市场，懂卖家和买家，最重要的还是要有执行力，要有聚拢资源的能力。

不要刻意追求理解业务之后能带来什么，我自己认为这是研发的职责，一个不理解业务的研发，和流水线的工人是没有很大的区别的。hr 以前跟我们说过，技术人的三大支柱：业务理解、项目管理和专业技术，可以看到业务理解也是非常重要的，而专业技术仅仅是其中一项，越到高年级，对业务的理解和影响占比就越大。

尽管我目前离做业务决策还比较远，也不应该是我要刻意去追求的事情，但是最近两年，由于对业务的理解有了质的变化，自己开始想着，假设我是业务老板，可能会干些什么，可喜的是，在最近一两年我思考的很多策略都能够和 CBU 的大战略 match。

比如在2017年，我认为产业带和工厂应该是1688的 B 类特色所在，拥有大量的源头好货，全国各地的零售商和组货商也会和产业带的工厂和组货商保持常买卖关系，因此在那个时候我就主动承接了产业带和淘工厂的业务，并期待它能发扬光大。

2019年， CBU 提出了源头厂货的战略，就是“围绕“一线产地，一手价”为核心，从内到外，提升供需两端流通数字化效率”，并且要在全国一百多个产业带造势，搞“一城一节一名片”。在商品上，也在和工厂直接对接做联营，拿到一手厂货。而淘宝直播和聚划算，也在去年针对产业推出重要策略。

在2017年，我认为 CBU 的 B 类特色应该是工业品，工业品背后链条可以做的更加深入，而工业品品牌站可以和零售通的快消品品牌形成 B2B 的双剑合璧，在2019年，工业品品牌站果然成为了战略级业务，属于一体两翼中的一翼，而在此之前，仅仅是一个垂直频道而已。除了这些大的以外，由于我自己对电商产品比较熟悉，各种杂七杂八的产品都深度使用，我也偶尔会给产品或运营提一些建议，完善产品矩阵和细节，这里就不细说了。

结语

前面说了这么多了，就用一些自问自答来作为结语吧，这些思考不代表我在这块做得很好，仅仅是我自己的思考角度和努力方向而已。

业务结果是否是评价研发绩效的主要指标？

不一定，今年的晋升主题就是"非凡不止一面"，包括我们的晋升体系，也支持对研发分类为专业技术型和业务开发型人才，今年的晋升场合，我也看到了很多有技术深度和特色的同学晋升成功，当然也看到了很多业务型人才，尽管技术深度相对不高，但是有较好的业务视角和协同推进能力，也有不错的业务结果，也得到了晋升，也看到了二者结合很好的人才。因此，最重要是你是一个出众的人，有想法，能搞事情，有技术或者业务结果的人。

从第一张图也可以看出来，尽管研发最终都是为业务服务的，但是不同的事情对业务的影响有强弱之分，有主要和次要之分，我们不应该简单地以业务价值来衡量研发的绩效。

但是有一点可以肯定的是，技术领域也要做出结果，结果也能说得清楚，技术领域的事情也有技术领域的衡量手段，尽管不能完全量化，比如研发效率提升多少？但是基本可以定性，定性上主要看两个点，一是是否代表先进生产力的发展方向，二看是否代表广大用户的根本利益。定量上，可以看落地场景数目、产品用户、用户满意度等等，比如引入和推广一门技术，能落地到多少场景，bug 数或者线上错误监控又能降低多少，或者用户对此的欢迎程度和满意程度。

因此技术人员不一定要去这么深入理解业务或者成果出在业务上，对技术很感兴趣的同学而且有抓手的同学，就安心地去专研技术并取得结果就好，注意要取得结果，不能是说不清楚的东西；对于技术上没有鲜明特色的同学，或者有技术深度但是暂时想不到什么技术挖掘点的同学，不妨去多看看业务，寻找技术驱动业务的机会。

近期热文推荐：

1.阿里架构总监一次讲透中台架构，13页PPT精华详解，建议收藏！

2.学阿里中台，就要学最值钱的部分：中台建设方法论！

 -End- 

想跟文章作者、100位互联网大咖交流学习？

加入“技术领导力社区”

长按扫描下方二维码，添加助理小姐姐Emma

注明“加群”，稍后她会拉你进社区群

---

往期精彩推文：

1.男,40,总监,失业,中年人,愿你终能体面的离开

2.学阿里中台最值钱的：中台建设方法论！

3.90后美女CEO想找个CTO,我给她个技术经理

4.我用了10年,从深圳工厂妹到Google程序媛

5.来做技术总监吧.要写代码吗?不写你来干嘛