|心想技术驱动业务，却在背道而驰

我是一个着迷于产品和运营的技术人，乐于跨界的终身学习者。欢迎关注我哟～
每周五早6点按时送达～
我的第「165」篇原创敬上
大家好，我是Z哥。
相信每一位真正的程序员心里都有这样一个念想：只要我的技术够牛，就能驱动业务的发展。
但是往往我们在不自觉间做的是背道而驰的事情。
业务：我希望在这个报表里多展示某个字段行不行？现在每次我都得手动把数据合并一下，有点麻烦。
技术：这个字段不在我们的系统里，要加上的话，我们需要从别的业务系统拿数据，比较麻烦，而且可能准确性和及时性都会差一些。如果非要加的话，开发工期会比较久，你需要走需求流程。
业务：啊，不是吧。多个字段显示，有这么难吗？
业务：用户反馈这个活动链接分享给他的好友后他们点开是空白的。
技术：这个活动本身是站内活动，我们没考虑会分享到站外的情况，所以这里信息校验没通过，导致页面数据没有返回给客户端，造成了打开空白的情况。
业务：其实我只想知道……现在要怎么解决？
上面的这些景象是不是很熟悉呢？
那么技术驱动业务到底是不是存在呢？答案是肯定的。 Z哥我认为，主要体现在以下两个目标：

解决过去无法解决的问题
让解决问题的效率大大提升

但是我们仔细来思考一下这两个目标。
首先，「解决过去无法解决问题」。 “过去无法解决”这六个字就已经劝退99%的人了，这里面一部分人的想法是：过去无法解决，现在肯定也没法解决，算了。另一部分人甚至完全看不到这里存在问题，因为潜意识已经默认这个问题本就是现实的一部分。
其次，「让解决问题的效率大大提升」。这几乎肯定不是小打小闹能实现的，必然要从一个新的思路来解决问题才有可能。然而，人的思维惯性会阻碍新思路的产生，很少有人可以跳脱出现有解决方案的框架来重新考虑问题。
所以真正能做到技术驱动业务的关键并不在于你的技术有多牛，而是思维能否跳脱出过去的束缚，并且要拥有业务感觉，要懂业务。因为从概念上来说，业务是“钉子” ，技术是“锤子” ，前者是问题，后者是问题的解决方案。
其实，先不要说能「驱动业务」，能做好「支撑业务」的人我觉得就是一位优秀的程序员了，因为要达到这点也不容易。具体可以从以下三个方面入手。
/01 理解业务/
如果你无法吃透业务，真正理解业务，那么别说驱动业务了，你能把业务实现到预期的80%都不错了，就像上面提到的第二段对话。
当然技术人员对业务的理解方式和业务方、产品经理并不完全相同。最大的区别在于，技术人员需要对业务的“不可见”部分了解更多。比如，多个环节背后的流转过程，这会影响你的技术实现和程序设计。
对于这个方面， Z哥只给你一个建议，不管你用什么方式方法来理解业务，你一定要带着：这个业务的提出是为了解决什么问题或者实现什么目的？
要做到这点有难度，因为大家的本位意识会让你习惯于盯着开发工期、deadline这种方面。但是只要你能带着这个角度去思考，至少可以将业务实现地无限接近预期的100% 。
不过，理解业务最多算是一个目标校准的工作，而且还没涉及到技术。我们要做好「支持业务」甚至是「驱动业务」的动力源还是在技术方面。
/02 稳健、可扩展的基础架构/
能够支撑或者驱动业务的首要前提，必须是你的“地基”不但稳固而且要领先于业务去规划。所以底层的基础架构设计非常重要，如果视野仅仅关注“这个需求该怎么实现”自然达不到这样的效果。
这一点需要提升你的软件设计意识。简单的像设计模式之类的，复杂一些的则需要你吃透一些经典的设计原则和设计思想背后的优缺点和适用场景。