Lishunyang's Blog所有人都应该关注业务，工程师也不例外
# 拿衣服的例子
作为一个研发工程师，在我刚工作的的那会儿，其实是很反感做业务的。因为我觉得这个世界上的业务千变万化，而唯一不变的只有技术，就像有句话叫“学好数理化，走遍天下都不怕”。所以我想我还是应该把更多的精力放在技术上，多关注技术，少关注业务，甚至不关注业务都可以。每次我看到有研发同事跟产品同事关于一个产品方案要讨论很久的时候，我就会深感迷惑：研发应该把精力放在技术上，至于产品逻辑，业务逻辑，那是产品经理的本职工作，交给他们就行了，研发只要负责实现，一手交PRD，一手交代码，难道不应该这样吗？
我记得每次迭代开始前，有一个全体研发和产品参与的需求宣讲会，由产品或者设计给大家介绍下个sprint我们要做什么，包括需求背景、产品方案等等，这往往要占用一个下午时间。当时我就觉得这是世界上最没效率的会，理由很简单：我只关心我要做的任务，至于其他人的任务，我压根不感兴趣，一个下午的时间都够我写完一个小需求了，为什么我们要坐在那里浪费时间呢？这简直就是双倍的浪费。所以我曾经多次找上级反馈过这个事情，希望以后不要开这种大会了，建议每个产品下来单独找开发沟通。
现在回过头来想想，当年还是太naive了。
# 关注业务有利于提升自己的能力
如果说，能用金钱或者时间解决的问题不叫问题，那么所有能用代码解决的问题，也都不算是问题了。换个说法，技术手段解决的问题都是具体问题，比如写一个网页或者往数据库里写入一个数据。因为问题足够具体，所以解决方案呼之欲出，剩下的只是实现罢了，肯定能解决。比如你叫一个完全不懂技术的文科生，那枪指着他说必须3天之内给我写出一个网页，我相信这是大概率可以做到的。还有一种问题是抽象问题，比如在大冬天在车流量小的地方打车很困难，怎么解决这个问题？（甚至很多人都都不认为这是个问题）这个问题没有一个确定的答案，你可以换个地方再打车，或者你可以选择不打车了直接走路，或者你可以发明一种类似滴滴的网约车软件，问题都算解决。抽象问题就是这样，有时候仅仅是把问题描述清楚都是一件困难的事情，更别说解决问题的方案了。毫无疑问，解决抽象问题的难度和价值往往是高于解决具体问题的。很多人都会觉得领导很好当，动动嘴指挥别人干活就行了太容易了，正好相反，管理类工作基本上都是在解决各种抽象问题。
而在开发的整个过程中，同样充满了种种抽象问题和具体问题，而且越是早期（确定产品需求、讨论产品方案）抽象问题占比越多，越是后期（技术方案确定、编码实现、测试上线）具体问题占比越多。解决抽象问题需要的能力包括但不限于：沟通能力（听得懂对方说什么，说得清自己在想什么，见人说人话，见鬼说鬼话），情绪控制能力（不受外界干扰，保持冷静思考），共情能力（理解他人感受，发掘他人内心想法），辩证思维能力（多角度思考问题），决策能力，临场应变能力等等等等。
如果你排斥业务只关注技术，那么就相当于是排斥了很多解决抽象问题的锻炼机会，只把目光放在了编码实现等具体的技术问题上。时间久了，也许技术能力确实能够提升，但解决抽象问题的能力就未必也能得到提升了。相当于是无形中给自己设了一个限，只追求技术发展，只在技术领域发展。就好像在学生时代，擅长考试就行了，只追求考试名次，永远做学生永远不毕业。原本我以为，不论业务逻辑怎么变化，技术是不变的硬道理，现在我知道了，更合适的说法是：不论业务逻辑怎么变化，解决问题的能力是不变的硬道理。
作为一个开发者，多问问自己：为什么要做这个需求？是要解决什么样的问题？解决问题的产品方案的逻辑是什么？这是最合适的吗？怎么检验自己真的理解了？下次你跟爸妈视频通话的时候，试着给他们讲讲你在做什么吧。
# 理解业务有助于找到技术进步的方向
有很多刚入行的小朋友经常会问这样的问题：
我该怎么提升自己的技术水平？我该看些什么？看js基础、刷算法题，还是看最近流行的东西？
这个问题其实我也一直在寻找答案，毕竟每个人的基础能力、成长速度、追求都不相同，所以很可能也没有一个统一的答案，每个人心中有一个最适合自己的回答。但如果你暂时还没想明白，我倒是有一个建议：从业务出发，沿着业务去熟悉、掌握相关的技术知识和技能。
举个例子，我是一个前端开发工程师，我所在的公司的业务是在线教育。那么就顺着业务开始捋。
首先列举出主要业务有哪些。比如我们有教师系统、学生系统、家长系统。核心功能有视频课堂，师生问答互动，在线布置作业考试答疑，家长查看学习进展等等。
然后从这些业务中整理出用到了哪些技术栈。比如客户端有桌面端（Web）和移动端（原生应用和小程序），多媒体传输和播放，IM消息聊天，自定义复杂表单，支付等。
接着在看看这些技术栈目前遇到了哪些问题。比如Web端卡顿性能差，移动端兼容性不好，多媒体传输弱网环境下体验差，复杂表单不够灵活开发效率低等。
最后分析造成这些问题的原因是什么，如果要解决，怎么解决，需要用到哪些技术知识。你可能需要学习、调研、与他人讨论。
不知道你发现了没，这其实是先不断将具体的业务抽象成一些通用问题，然后再把这些抽象问题不断具体落实到技术上面的过程。通过这样一个过程梳理出来的技术知识，既能够解决实际问题非常有价值，又能处理一类通用问题不至于很局限。
业务产生问题，促使技术进步，技术的进步又催生新的问题，可以说业务和技术二者是相互促进螺旋式发展的。但他们并不是鸡和蛋的关系，业务是源头，技术不是。如果一个技术被发明出来不是为了解决业务问题，那人们为什么要发明这样一个技术。
记得小时候家里有本残缺的三国演义，前几章丢了不知道讲了啥，反正上来就开始讲赤壁之战，看得我是一脸懵逼。类似的道理，正因为业务是核心和源头，先理解了业务，对于理解后续的技术会是非常有帮助的。“产品不可怕，就怕产品懂技术”，同样地，“技术不可怕，就怕技术懂产品”。
有些研发工程师觉得，总是做业务，技术上没有挑战，没法提升个人能力。其实这句话是有逻辑漏洞的，导致“技术上没有挑战，没法提升个人能力”的原因未必是“总是做业务”，真正的原因很有可能是你陷入了一种自我感觉良好的状态，觉得自己已经很厉害了。而造成这种想法只有两种可能，第一种是你的技术水平确实没有短板了，已经登峰造极了，第二种是你的技术水平存在短板只是你不知道。建议有这种困惑的朋友按照前文提到的从业务梳理技术的方式捋一遍，你确定那些技术问题的原因和解决方案你都很了解吗？你能清晰地写下来吗？你实践过吗？（因为很多坑是实践的时候才会发现）如果答案是否定的，恭喜你，你找到了一个可以进步的方向。
# 提升幸福指数
当然还是讲我自己的例子。
在我特别排斥业务的那段日子，我特别容易对工作感到无聊。因为我不关心业务，所以不知道我做的东西到底有什么意义，于是我理解的工作的意义就是：赚钱。但钱永远是不够的，所以这又会让我产生沮丧。有段时间我甚至对技术的态度慢慢变得十分悲观，觉得技术不过如此，无尽的需求，看不到尽头。
后来我看了一本书，书名叫《赋能，打造应对不确定性的敏捷团队》，这是一部非常好的书，刷新了我的很多观点。其中提到了知识共享的重要性，于是我开始尝试着去多关注业务，思考用户遇到的问题，思考问题的本质，思考如何解决，这很难，但我喜欢挑战，渐渐地我开始觉得需求评审会很有趣，哪怕会占用我一个下午的时间。
现在我觉得开发需求也挺有趣的，工作没有那么无聊了。
# 后记
其实关注业务，不光对个人，对团队也非常有益。DDD（Domain Driven Design）告诉我们，一个团队要想紧密高效地协作，那么就必须有一套统一的领域语言，而这个领域语言一定是对业务逻辑的表达。只有当团队中每个人（不论是产品、设计、研发、测试）都对业务逻辑非常了解的情况下，做出来的产品才能符合所有人的想法。
所以，下次见到产品需求评审会的时候别玩手机了，仔细听听，有问题跟产品battle一下。这不是挑刺，问题发现得越早，解决问题的成本越低。