技术的价值，以及技术如何产生价值

关于技术的价值这件事情，很多同学容易陷入两个极端，要么觉得技术是服务于业务的，技术不重要，业务才重要；要么会觉得业务同学不懂技术，不理解技术的价值，技术这么牛逼业务竟然用不起来。

想要回答这个问题，就需要定义下什么是技术，什么是价值。

我们本次聊得技术的定义，泛指互联网公司的研发技术，包括前后端的软件工程技术。

对于互联网公司的技术团队而言，他们所产生的价值，往往是通过业务换算得来的。比如为业务创收了多少，为业务节约了多少。

技术的价值，往往可以通过这幅图体现。

就是业务有个目标，但是现状不允许，如何基于现状，实现业务目标，往往是技术价值体现的地方。

影响技术价值不能体现主要有两个原因，技术不行和业务目标理解有偏差。

先说技术不行。

很多人因为觉得技术是服务于业务的，而且觉得技术很难产生价值，所以一股脑全变成了业务”专家“，把技术放在了一边，不去精进技术，一些本该好好搞技术的同学，都去提升软素质和业务理解力去了。

慢慢的导致一些半吊子技术人在负责一个系统，系统里面很多技术问题发现不了，业解决不了，在一辆破旧的草车上支撑业务发展，终有一天技术联同业务一起垮掉。应该知道技术是基本盘，软素质和业务理解力是锦上添花。

某种程度上，这有管理者的责任，他们可能过多的宣扬技术价值低或者技术无用论，导致很多人没有继续精进。

另一部分责任是这个技术人自己的，他们对于自己的技术需要精进到什么程度和水平没有预期，过早了放弃对于技术的追求，进而后面就很难再拿起来了。

我推荐P7+及以上才可以追求业务理解力，以下的职级还是要把技术搞扎实。

比如我们最近接手了一个IOT的业务，里面很多架构设计和代码编写都不合理，里面存有巨大的债务，就会导致业务的迭代变慢、稳定性变差、扩展性降低、人员心智压力大、资源成本居高不下。

比如一台车上有很多设备，每个设备都有自己的规格产品，他们竟然对每个规格的设备上报都独立了一个微服务，导致一台车上50+设备，背后就有50个微服务，很多问题都来了。

这就是技术没能很好的赋能业务产生价值，而且还产生了巨大的债务，拖累了业务的发展，很多业务功能的迭代不得不背上这个沉重的包袱，扩展的灵活性无从谈起，成本也优化不掉，只能重构。

那这项目的架构师就富有不可推卸的责任，如果这个架构师因此还升职了，还挂着一个技术负责人的头衔，那这个业务后续的迭代发展我是不看好的。

这还是一个小系统，如果是一个大系统，肯定会让业务崩掉，业务价值无从谈起。

比如要做单元化架构，就要了解前端、ios、安卓、pc ，还要了解cdn、网络、接入层、服务发现、服务路由、rpc等，还有数据层各种mysql、redis、mq、es、hive的有状态存储，要知道数据同步方式、多点写、一致性处理等。

只有把这些都了解透彻，你才能对实施过程中遇到的问题有心理预期，而不会产生巨大的返工问题。

这种技术的广度是需要积累的，你需要下笨功夫、苦功夫，积累多了，才有可能广度加深，老天爷不会直接向你嘴里喂饭的。

了解的多了，认知就深了，心里就形成体系了，能力会有很大的提升。

上面那位架构师，如果不具备这样的技术能力和技术广度，他肯定是负责不了这样的技术系统的，也很难让自己的业务更上一层台阶。

简单来说，对于技术人来说，技术一直很重要，先把技术硬实力练好之后，再去聊别的。不要本末倒置，技术二把刀的时候就去追求那些有的没的，最后啥都没捞到，毫无竞争力。好不好的标准，就看对标 p7 吧。

技术想要做好，就必须要落地，而不是飘在天上。目标和做什么事定义的非常清楚，要达到什么样的结果也要定义的非常清楚。

比如双十一这种大促活动是靠技术支撑的，技术的要求不只有高并发、高可用，背后还要考虑低成本和高效率。

通过技术手段，整合好业务，支撑好业务。

同样是做异地多活、机房容灾的价值，就需要结合业务去看。

比如单元化架构，通过部署异地单元，将生产流量完整的运行在千里之外的独立机房，从而连续性的运行业务。

这里面落地实现有几个关键点，异地、千里之外，独立、连续性。

要想这套架构对业务有帮助，需要对业务吃得很透才行。

比如阿里的中台架构，内部叫星环。

星环的架构本质是将单纯的代码共建模式，抽象成横向和纵向的业务包模式，类似于外包，做到业务与业务隔离，业务与平台隔离。

它解决的问题是，如果之前不这么做，营销、商品、会员、交易、支付、库存耦合在一起，只能通过if/else的方式，这对代码的扩展性和可读性就会有非常大的影响，开发难、上线难、测试也难，由于技术设计的不合理，导致业务背上了这个包袱，业务想跑得快也会变得很难。

技术的价值是需要通过业务拿到的。

真正要帮助业务产生价值，就需要有一定的商业意识和产品意识。

需要了解这个业务是什么、谁在用，还需要和前后端链路，比如交易环节、履约环节、售后环节串联起来，有个这个业务全局视角，才能知道你负责的这个业务具备是怎么最终服务用户价值的。

技术既是一种具体的代码，也是一种思维。用这种思维解决实际的技术和业务问题。

好的架构师是潜移默化，以前瞻性的思维通过技术手段把一些问题在萌芽期解决了。

如果技术能力差的同学，更多的是case by case的去解决问题。

技术不仅仅解决业务提出来的高并发、高可用的需求，也需要关注用户体验、效率提升、成本浪费问题。

​

要想真正的通过技术手段解决自己业务上面的问题，就需要走出去和业务的上下游多聊。

了解他们是怎么思考的、怎么理解的、哪里他们还认为有问题、业务想要什么样的效果，这样你才能找到关键点，把握关键点。不然你可能只做到了局部最优，难以做到全局最优。

技术产生价值对技术同学的要求是什么？

技术同学的能力产生价值，总结起来是发现问题、分析定义问题、解决问题。

发现问题要识别是局部问题还是全局问题，更应该具有发现未发生问题的能力。

对于解决方案，应该知道哪些是治标的方案，哪些是治本的方案，这些都是基本的判断力。

需要结合业务发展，考虑未来业务发展到某个节点，可能产生的问题是什么，哪些是技术可以解决的，通过技术预埋的方式，解决将来会面对的问题。

很多时候，我们会说发现问题和解决问题都很重要。

但有的人只是说我发现了问题，但其实他只是情绪的宣泄，他并没有对问题进行定义。我们不缺少发现问题的同学，但缺少的是对问题准确定义的同学。

如果一个问题没有被很好的定义就提出来，那其实不是发现了问题，你只是不爽，在抒发情绪。

定义问题需要抽象和归纳的能力，还需要区分出哪些是短期，哪些是长期需要解决的问题。

只有把问题定义清楚了，你才能知道怎么最好的解决问题，才能真正推动业务前进。

架构要解决的问题一定要是全局问题，而不是一个局部问题。只有你定义好了问题，你才有能力推动全链路同学一起去解决这个问题。

有的时候一些问题是非常复杂的。

复杂是由于人员规模、系统规模、链路长、周期长导致的。

比如用户体验、提升效率、降低成本这些事情都不是一蹴而就的，时间跨度、人员规模都是非常大的，那么它就是复杂的。

对于这种复杂的问题，你就很难找到一种一本万利的方法，必须用新的思路解决这些问题，会倒逼我们把复杂问题简单化。

想要具有全链路同学共识这件事的能力，就需要花功夫对全链路、上下游都有了解，比如业务层面的系统、业务下面的平台系统、平台下面的中间件都需要有了解，这样层层打通了，才能把全链路整合起来，解决全链路上所有同学的问题。

不能闷头做事，也要抬头看路，要有良好的沟通表达能力，所有同学才能真正共识这件事，一起前进。

想要技术帮助业务实现价值，就要到业务中去，要知道不是业务离不了架构，而是架构离不开业务，研发同学要变成复合型人才，业务、架构、技术三位一体才能达到最佳效果。

比如说云计算。

云本身是软件和服务，软件和服务的基础是人，做好云要靠人，而不是靠产业链。

如果懂技术的不懂商业，懂商业的不懂技术，就不可能出现合格的云业务产品经理。

我们要磨刀，但不能一直磨刀，要结合业务需求实践后，才能知道下一步怎么做，哪里需要优化、迭代。

和业务结合起来，用技术思路解决业务的实际问题，带来更低的成本、更高的效率。

将技术的先进性转化为业务的先进性，很多复杂的事情不是你一个人能搞定的，要有能力协调更多的人办事。

遇到难题、难啃的骨头，要有决心。逢山开道、遇水搭桥，一定能干成、一定要干成的决心。