阿里妹导读：伐薪是阿里巴巴高级技术专家，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进货，转运到当地。
所以说，要对业务有深入的理解，除了数据洞察以外，还要多和商家当面交流，多去实地走访，在过去的一年，团队做了很屡次走访，整理了完整的走访最佳实践和走访报告集。从北方的烟台、白沟到南方的深圳、广州，从西部的重庆、成都，到东部的义乌、温州，从一批市场，到销地市场，从源头工厂到组货商，都有我们出没的身影，这里按时间从近到远列举少量例子：
走访工厂，理解服装制造流程走访有时能拿到少量市场上的最新信息，比方店主的进货模式能否有变化。在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 数或者者线上错误监控又能降低多少，或者者客户对此的欢迎程度和满意程度。
因而技术人员不肯定要去这么深入了解业务或者者成果出在业务上，对技术很感兴趣的同学而且有抓手的同学，就安心地去专研技术并获得结果就好，注意要获得结果，不能是说不清楚的东西；对于技术上没有鲜明特色的同学，或者者有技术深度但是暂时想不到什么技术挖掘点的同学，不妨去多看看业务，寻觅技术驱动业务的机会。
最后打个广告，阿里巴巴 CBU 技术部招聘前台、算法、java、测试等领域的高级工程师、专家和高级专家，有意者请投递简历至 huiqi.xhq@alibaba-inc.com。1688 是阿里巴巴在产业互联网的重要布局，主要服务于各种商品流通的次终端客户，最近二年发展迅猛，重新成为阿里的明星部门，今年重点战略是全国数万产业带的数字化，错过了消费互联网，别错过了产业互联网！
阅读原文
本文来自云栖社区合作伙伴“阿里技术”，如需转载请联络原作者。
