14 能力篇：专业技术+技术赋能业务能力=立身之本
你好，我是雪梅。
上一节我给你梳理了能力模型图，这一节我们来深入聊聊能力T型图的“竖线”，也就是我们的立命之本，专业技术+技术赋能业务能力。 这是技术人在自我学习上投入精力最多的地方，但事实上，也是误区最多的地方。
先说问题案例。前段时间有个小伙伴说，觉得自己发展遇到瓶颈了，项目都会做了，但是感觉自己没提升，想跳槽。于是，我们一起梳理了他过往的工作经历。
他一直认为业务规模小，阻碍了他技术能力的发展。而仔细一问，这个系统的用户量是百万级别的，一点也不小，只是淡季、旺季非常明显。旺季时经常会有卡死、提交延迟的情况。
我问他，你作为核心系统的主程开发，怎么看待这些问题，有哪些优化思路？他挠了挠头，说不上来。我看他还做过重构，就问他那个系统为什么要重构？他给出的理由是，原来的框架太老了，市面上现在大家都用了新框架。而重构带来的收益，也说不清楚……
这个小伙伴是典型的只看到了技术能力最表层的技能，觉得会编程，会完成需求开发，会发布上线等等就够了。事实上，技术人的硬技能远远不止这些。
专业技术能力
我们先来说说专业技术能力。在我看来，如果用冰山模型来形容，有很多是看得见的能力，还有更多藏在冰山之下的“看不见的能力”。
拿Java开发工程师来说，日常你能用Java编程，会使用编程的工具，比如Eclipse，还会一些Linux命令，知道后端开发三大中间件（MySQL、Redis、MQ）的API如何调用，可能你还能遵循公司的编码规范和稳定性要求……这些都是看得见的能力。
但是，还有更多看不见的能力藏在冰山下边，我给你画了一个图，你可以参考。其实还有很多JVM原理，数据库原理等等很多知识和能力需要具备。
如果一个技术人只把注意力放在冰山上面，那极大概率会出现两种情况。
要不，就是 很快陷入成长瓶颈 。 你可能会觉得天天在CURD，没什么成长。更可怕的是，如果一个技术人完全不懂设计原理，不懂如何写出一个好的代码，他所处的环境也没有很好的设计和Code Review机制，长久以往，这个系统就会变成“一座垃圾山”，技术债越垒越高，完全无法维护。
《代码整洁之道》的作者罗伯特·C·马丁说过， “不管你们有多敬业，加多少班，在面对烂系统时，你依然会寸步难行，因为你大部分的精力不是在开发需求，而是在应对混乱”。相信很多技术人对于这段话非常有共鸣。
要不，就是 变成“定制的螺丝钉”。如果你在大厂，可能会发现工作里用到的大部分底层服务，比如Redis、MQ等都有专门的同学在维护，可能他们还在上面做了一些定制开发。如果你把它们完全当作一个黑盒，出了问题就找相应的同学解决，也不是完全不可以。但硬伤就是协作成本高，而且最重要的是你真的成了“螺丝钉”，还是“定制的螺丝钉”，只能在特定的体系下生存，换个系统可能就“拧不上”了。
因此，从个人职业发展角度看，如果一个人技术人的专业技术能力只专注在“冰山之上”，那就真成了“搬砖”的了。而且越在冰山之上的能力越是简单、入门门槛低，越是底层能力，鲁棒性越强。
我之前带的团队经历过技术栈更换，从PHP系统全部重构为Java系统。一个很有意思的发现是，那些之前在PHP技术栈做得不错的同学，经过几个月的语言熟悉，在Java技术栈依然做得不错。原因很简单，作为后端开发，难的是网络通讯、存储、消息中间件、系统设计、故障排查等这些更底层的经验积累。语言学起来不难，智商正常的人，2周就可以入门，接下来就是需要熟悉的事了。
再举个例子，前端小伙伴经常抱怨前端技术更新迭代太快，追不过来。而一个工作15年的前端大佬一针见血地指出了前端工作的本质：前端交付的是用户的使用体验，而使用体验的核心在于交互。前端同学要多花时间去了解交互以及背后的渲染，理解底层CPU、GPU的渲染原理，弄清标准化端容器（如浏览器这类）的工作原理。
因此，为了让技术成长的坡道变得更长，让你的“兼容性”更高，能解决更复杂的问题，适配更多样的环境，你需要更关注冰山之下的技术，得“往下沉”。
怎么往下沉呢？还是以Java开发工程师为例，往3个方向走，可以大幅提升你的技术深度。
- 语言深钻：底层以及高级玩法
当你能完成日常基础的需求开发之后，可以再深入一些，掌握一些更高级的使用。比如Java至少了解下JVM原理，知道一些Java系统的调优方法，会让你的服务更轻盈。
- 周边服务：与你日常工作息息相关的底层服务原理
拿Java来说，三大中间件的原理你得很熟悉。比如MySQL，你至少要了解透彻数据库引擎、事务、索引等等的底层原理；比如MQ，你也得清楚底层实现，了解市面上几种通用的MQ，在做技术选型时知道什么场景应该选什么……
熟悉这些最基础的内容，是为了让你在日常工作出现问题、故障时可以高效应对，更重要的是你的工作域变大了，不再是被一群黑盒包围了。
- 系统设计：常见设计原理 、 应用、经典场景的设计
技术人专业能力的成长，体现在你刚开始只能开发一个小功能，到维护一个模块，再到一个子系统，甚至一个业务域系统。这里面，系统设计能力非常关键。作为后端研发，需要把相应设计原理，具体应用方法，还有一些经典场景的设计思路都做到门清。
比如如果你了解了高可用系统架构设计的原理和实践，你一定会对公司这样那样的“稳定性红线要求”有更深刻的理解，甚至你还可以主动思考自己做的模块强依赖哪些服务？弱依赖哪些服务？如果需要做降级，应该怎么去设计？
当你了解了语言的底层、底层服务的原理以及系统设计，你就把自己的“技术世界”撑大了，也给自己的发展打下了更坚实的基础。当然，如果你是一个很有技术热情的人，愿意去研究很多新的技术，在地盘稳定之后，学习速度也会加快。
技术赋能业务能力
专业技术往下渗透，了解底层原理相当于技术人工作的“微观环境”撑大了，那再进一步，就是需要去理解技术周围的系统了。毕竟技术不是一个独立的世界，是一个工具，工具需要回到真实场景下去衡量价值，这就是我们马上要聊到的“技术赋能业务能力”。
要说清楚这个能力，必须先来澄清一下技术和业务的关系。
技术和业务的关系
我跟很多朋友探讨过这个话题。其中一位非常资深的前辈用了一个很好的比喻来解释这个事情。他说，我们的技术技能就好比一个锤子或者一个锯，业务好比要做一张桌子。做一张桌子需要很多道工序，需要设计，需要锯木头，需要锤子钉钉子，需要打磨，需要抛光，可能还需要营销推广……
如果我们看不到桌子的全貌，就很难知道什么时候需要用锤子，要锤多少次，怎么锤才能锤得更精准。换句话来说，业务研发的价值绝不仅仅是你的代码写得多好、没有Bug、你做的接口TPS多么厉害，还要看你到底用技术解决了多少业务问题，带来多少业务增量，给客户创造了什么价值。 在完全不了解业务情况下，空谈技术，那就是耍流氓，也是空中楼阁，没办法长久。
很多技术人把自己的发展只定义在专业技术能力上，这其实是一种惯性。在职场初期，我们的工作要求被定义得非常清晰，这是公司的高层和各级管理者定义好的。比如一个做电商商家端的团队要找一个Java工程师，那么电商系统的划分，比如用户、交易、商家端等框架划分，还有整个系统具体要承接的功能、解决的问题，甚至解决问题的方式以及对这个岗位的考核，都是提前定义好了的，只是需要人来“填坑”。
我们要做的，就是从“坑”里走出来。 到了一定年龄，给企业带来的价值更多是在一些不确定的、不清晰的事情上，去定义什么是有价值的，从而定义自己的工作。 就像刚开始那个比喻，我们有锯、有锤子，那么做桌子时怎么用这些工具呢？
就是这个“怎么用”，去定义这些事情，这才是我们更大的价值所在。对于一个技术打工人，想要发挥更大的价值，想要追求自身更长远的发展，除技术本身技能之外，你必须懂得技术赋能业务。
如何做到技术赋能业务？
具体如何赋能，以我的经验，可以分为4个步骤。
- 了解业务：就是你要理解商业价值，比如清楚当前业务的重要指标，要达成这些业务指标需要解决哪些问题，哪些可以通过技术手段解决？如果你的企业用OKR做技术管理，那就是业务重要的O。
- 定义问题：当你找到要解决的问题，就要把这个业务问题转化为技术问题。
- 解决问题：这一步是技术人相对擅长的，用技术手段去解决问题。
- 数据回证：提前做好数据埋点，通过数据统计论证最开始的设想，检验是否真正解决了问题？有哪些收益？
这么说可能有些抽象，我举个例子。小A是客户端研发，他所在的部门负责外卖物流配送系统，即管理和调度外卖配送员的系统。随着外卖日渐发达，公司越来越重视骑手的安全，今年的业务有个考核指标就是关于骑手配送过程中的事故率的。比如配送1万个订单，可能出现的交通事故率要控制在多少。
你可以停一分钟，想一想，如果你是小A，你会怎么做？
第一步 ， 了解业务。 想一想， 骑手配送事故，跟什么相关？
可能跟对骑手的考核相关，比如要求30分钟送达，不过这个是业务运营规则，跟市场环境相关，技术能干预的部分很少；也可能跟调度系统相关，比如给骑手派了太多的订单，或者不顺路，导致骑手赶时间，不得不超速，甚至闯红灯，造成交通事故。这个是调度算法团队在解决的议题，客户端研发能参与的不多。
眼瞧着没希望了，对不对？但是，小A线下调研了骑手的配送。结果发现很多骑手在送餐的过程中，会一只手扶车把手，一只手刷手机，因为可能来新的订单，而骑手要抢单嘛。这个过程增加了事故的发生概率。这个可以用技术解决么？可以。你可能想到了，这里完全可以用语音交互，这就是技术帮助业务提升的点。
接下来， 第二步 ， 定义问题，将业务问题转化为技术问题。
看起来，刚才就是一个语音交互系统的问题。但回到业务场景里，这个问题还不够精准。首先，骑手配送都是在户外，快速移动、没有稳定电源，耗电量是个问题。其次，配送过程的环境声音嘈杂，有的地方可能网络环境还不好。
所以，这个问题可以进一步精准定义为需要一个低功耗，弱网、噪音环境下可用的语音交互系统。
精准定义问题之后， 用技术手段解决问题 这第三步就没那么难了。最后，还需要做 第四步，数据回证。 你可能需要做AB测试，对比上线前后期骑手事故率的变化，用数据证明收益。
以上，就是技术赋能业务的完整闭环。
小结时刻
这一节我们讨论了技术人的硬技能。在专业技术能力上，我们不但需要会编程，会排查问题，更需要深钻，知其然，还要知其所以然，不断打磨自己的技术之剑。但磨剑还不够，还要把“这把剑”拿到真实世界去运用，历练我们在不同场合“舞剑”的能力，这就是我们说到的用技术去赋能业务。
从职业发展角度来说，专业技术能力和技术赋能业务能力，这两个硬技能是我们在技术岗安身立命的根本，是我们更好发展的基础。 抛开这些，技术能力还帮我们历练了非常好的抽象能力，以及极其务实的精神。
如果说互联网是把真实的世界搬到线上，那这个“搬”其实是靠技术人把真实世界抽象成线上的一个个数据结构、一个个对象、一个个模块，一个个系统来实现的。我们做系统设计、写代码的过程，就是在历练从具体世界的“现象”中抽丝剥茧，提炼本质的能力。
代码的世界来不得半点虚头巴脑，一个手抖写错一个字符，就可以让庞大的系统轰然倒塌。在这样要求极度精准的工作磨炼之下，大多数技术人都非常务实，能静得下来，能扎得进去，能啃得下硬骨头。这种抽象复杂事物本质的能力以及极其务实的精神，都会是我们职业发展之船能航行更远的燃料。
聊聊发展
试试用今天说的“技术赋能业务”的方法，梳理一下你所在的业务域，有哪些技术可以赋能业务的事情呢？欢迎留言交流。
如果觉得有所收获，也可以把课程分享给更多的朋友，一起学习程序员职业规划手册，心里不慌，脚下不乱，做好每一天的成长。