零、导读
作为业务团队中的工程师，我们要如何摆脱给人一种我们是CRUD（增删改查）工具的错误印象？业务团队如何在日常工作中做出在横向技术工作上的突破？笔者在互联网行业从业7年，作为一个技术团队的管理者，有一些心得体会。
一、横向技术工作是什么
横向技术工作给业务或者技术提供通用的服务与能力，能够帮助开发者高效地构建业务，在云原生应用的场景下，也有利于帮助业务规模化扩张。
这里谈到的横向技术工作，我把它分为3种类型的工作：中间件、类库和业务中台。
中间件
如TDDL为了解决数据库分库分表之后对业务方接入的复杂度、配置中心解决应用级别配置的问题、Dubbo为了解决服务间调用的问题、消息队列为了帮助微服务解耦等。
这种统一解决研发过程中的通用技术问题、为了提升技术效率和稳定性的工作，沉淀出来的技术产品就是中间件。
一个完善的中间件，除了提供给应用接入的client之外，还会有配套的图形化后台操作界面，帮助用户更好地管理一些配置和设置，也就是说中间件应该是一个端到端完整的技术产品。
上面提到的这些中间件看起来和直接的业务稍远，业界有很多成熟的东西。
不过也存在一些中间件会与业务结合得更加紧密一些，它们是为了解决某些业务场景下的一类通用技术问题，因此会带上比较强的适配业务场景改造的倾向。
这类中间件更容易脱胎于业务开发团队，因为他们直面一线业务，写了很多业务代码、处理了很多业务场景之后，慢慢会发现一类痛点，解决这类痛点的方式可能存在于业界，也可能需要自建，和业务的特点有关系。而这类中间件也会更加上层一些，它们可能是由多种已存在的中间件配合少量的开发与定制组建起来的。
类库
有一些技术问题的解决，上升不到“中间件”的层次，可能只是大家日常工作中的一些BP，或者基于已有模式的统一抽象，这类工作可以变成类库。
举个例子，在我们公司，获取用户IP，大部分场景下，是从request里获取一个header的值，那么这段代码就可以封装到一个类库中；再者，我们日常可能有对list、string的一些处理比较常见，我们也可以封装到类库中，方便复用；又，我们使用了多种序列化工具，我们实现一个上层的adaptor，这种也可以复用。
因此类库是一种相对中间件更轻量级的代码复用，一般apache、google等都开源了一些常用的类库，这些类库具有稳定性高、性能好的特点，也得到了长足的可靠性验证，能不自己造轮子的时候，就不自己造，站在巨人肩膀上，才能走得更远。
业务中台
业务中台就是企业级的能力复用，概念不多赘述，这种场景下，一般都需要产研一起共建，业务中台更多意味着同质业务能力的沉淀。
不过，除非顶层设计立起业务中台，在更多时候，业务中台在早期可能是从一个内聚的微服务开始孵化的：我们在做架构设计的时候，将同一个业务领域的内聚的业务逻辑归总到一个微服务中，并提供接口给其他微服务调用，分享能力。
因此需要业务研发团队在日常业务工作中，有对业务的正确认知，以及对业务架构的合理思考，以微服务开始，构建高内聚的应用，收拢和沉淀同质的业务能力，同时要保持对其他业务的关注，思考自己的业务服务是否可对其他业务进行支持，这样就能慢慢往业务中台的方向成长。
二、为什么要做横向技术工作
在上面对于横向技术工作的介绍时，有几个关键字，“高效”、“稳定”、“可靠”等，这些词描述了这些工作背后的逻辑。
首先，效率是一个很重要的因素。互联网行业的竞争是很激烈的，除了团队和产品因素之外，快人一步意味着对市场掌控的机会更大，因此人效永远是一个很重要的问题，何况人效提升还能减少企业支出成本。
横向技术工作通过复用能力，减少大家的重复建设工作，可以很明显提升工作效率，让大家更专注在业务上，业务中台甚至还被定义为“企业级能力复用平台”。
其次，稳定与可靠。
横向技术工作，其实也是最佳实践沉淀的过程。怎么解决这类问题最快、性能最好、稳定性最高，是在做横向技术工作中必须要考虑的，沉淀了最佳实践，也就意味着我们具有了解决这类问题最可靠的方式。
第三，“破壳”。
“鸡蛋从外面打破是食物，从里面打破是生命。”
横向技术工作也是工程师思维“破壳”的一个渠道，我们是重复地、以点带点地解决实际工作中碰到的问题，等待问题上门，还是往上一步走，以更宽广的视野、更大的决心与魄力解决同一类问题？想必大家心里都有答案。否则等到问题到来的时候，与之而来的肯定是线上的故障、数据的错乱，给我们带来的工作是bug修复、数据订正，治标不治本。
对于一个有技术追求的、不想成为单纯的CRUD工具的业务团队，这点还是很重要的。
三、如何在横向技术工作中做出突破
站在业务开发团队的角度来说，我们如何在横向技术工作中做出突破？在我看来关键在于回答好以下两个问题。
1、如何找准问题
做中间件的团队与做业务的团队，在工作模式上其实有一个差别，那就是中间件团队的“业务”其实大部分工作就是技术问题，而这些技术问题在很多时候是已经被定义出来的，比如“做一个配置中心”。而对应到业务团队，他们被定义好的是做什么业务，比如“实现一个账号管理功能”。
对于业务团队的开发人员，横向的技术问题就显得隐蔽了，因此需要有人能够找准这个问题，将其定义出来，变成一个像业务需求一样的任务。
找问题 —— 特别是找准问题 —— 这个过程可能并不简单，它需要你深入了解手上的业务工作，多思考平时效率和稳定性折损在哪里，还要经常和团队其他成员聊聊，这和产品经理找寻用户痛点其实差不多。
不管是出于在业务开发中能做得更好，还是出于能够在技术上有所成长，业务开发团队迟早要具有这样的“找问题”的能力，这需要大家有更强的技术敏锐度，“产品”思维，以及更强的反思、抽象、总结能力。
2、如何ROI高地解决问题
我们作为技术人员，发现一个技术问题之后，特别是对于一些年轻的工程师，很容易有的一个心态是“迫不及待撸起袖子写代码”，这是一个误区。
上面提到我们找问题其实和产品经理找用户痛点差不多，那我们以做产品来做类比，当一个优秀的产品经理发现一个用户痛点之后，他应该做什么？如果他懂写代码，他会直接研发吗？不会的，他会了解市场、做市场调研、做竞品分析、写MRD、写PRD、做MRD与PRD评审，并且在这个过程中，还要做权衡与决策，最终确定产品是靠谱的，定义出MVP，才会进入研发阶段，以最快速度完成MVP的研发之后，投入市场验证，并确定下一步的迭代计划。因为如果没有这个过程，他会受到质疑：你了解痛点与目标是什么吗？你做的产品真的有市场竞争力吗？搭建产品的速度不能够更快而要从0开始研发吗？第一个版本就要做那么大而全吗？等等，他会受到很大的压力。
那么你知道我们做横向技术工作要怎么做了吗？立项（发现问题） → 调研（了解“市场”与“竞品”调研） → 技术设计（长远计划与MVP） → 评审（团队是否觉得靠谱？团队是否能给我一些我不知道的信息？） → 调度资源 → 写代码（或使用现有框架与组件） → 接入 → 推广 → 持续迭代与优化 → 走上人生巅峰。是不是和做产品的思路是一样的？
直接开始写代码会遇到什么问题呢？我相信大家常见甚至经历过的：写完了发现有开源的东西可以直接使用；写完了发现其他团队已经做了类似甚至一样的事情；写完了发现过度设计，浪费了大量时间。如果结果是这样，那么你就做了一件失败的事情，你得到了一个你本不应该得到的失败经验，你在面对结果的质疑失去了成就感，并且很重要的一点：你在伤害团队。当然可能幸运女神刚好青睐你，你没有碰到这些问题，做成了这个事情，但这不是可持续的做事方式与思路，长此以往，你迟早会在更大的地方摔跟头。
上面说到的这些，其实是提醒大家首先应该在做事方法和意识上提升，问题能不能找准、解法是不是正确，更多考验个人与团队的能力，就像做用户产品时能不能抓准产品定位、产品能不能有好的用户体验一样。
只是产品的天地非常广阔，而通用的技术问题相对来说就那么些，大多在业界总是有迹可循、有物可考的，我们的技术视野越广，对自己的业务场景和痛点越了解，就越能帮我们在这个事情上做得更好。
四、总结
写在最后，作为业务团队，我们不能本末倒置：抛开业务工作，一门心思只想在技术上“做出点花样”。
以价值驱动来说，我们的所有工作都应该在“做好业务支撑，驱动公司成长”这条价值链路上，所以正确的逻辑是：
不以标新立异、磨练技术作为技术工作的出发点，而是以提高业务团队的人效，以及提升业务的稳定性、健壮性、安全性为出发点，并以做用户产品的心态和方法论来做技术产品。
对于只对纯技术感兴趣的同学，可能在那些业务就是开发技术产品的公司或团队（比如技术产品公司、中间件团队等）会待得更有成就感，产能更高，并更符合职业发展路径。
本篇文章由一文多发平台ArtiPub自动发布
