技术人如何通过了解业务，获取晋升机会？

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

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

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

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

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

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

业务先赢是技术第一要务

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

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

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

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

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

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