07｜法则三：架构师如何找到自己的商业模式？

2021-12-21 郭东白

《郭东白的架构课》

课程介绍



讲述：郭东白

时长23:12大小21.25M



你好，我是郭东白，今天我们来聊聊架构活动中对商业价值的考量。
今天我们要讲的是架构师的第三个生存法则：作为一个架构师，必须要在有限的资源下最大化架构活动所带来的商业价值。对于任何一个架构活动而言，架构师的可用资源，包括商业成本、研发成本、时间成本、迁移成本等等，都是非常有限的。但架构活动就是要在这些限制条件之下，将商业价值最大化。
你可能还处在职业生涯的初期，不太关注商业价值，不知道我们的工作最终能为公司带来什么样的商业收入。我刚工作时，也从来没想过我的工资是从哪里来的；公司凭什么会在明天、明年甚至十年后还会给我发工资；更别说思考我为社会创造的价值了。
但随着在职业上的不断成长，我越来越深刻地意识到，必须要为自己所在的企业创造出可度量的商业价值，这是我们获得有质量的长期收入的重要前提。
要了解商业价值，我们就要先了解商业模式。所以在正式讲解第三条法则之前，我先来对商业模式与商业价值做一个简单的区分。
什么是商业模式？什么是商业价值？商业模式（Business model) 就是讲一个企业是以什么样的方式赚钱的，比如电商行业，有自营和平台两种不同的商业模式。
商业价值 (Business value) 呢，就是从现金收入的视角看价值创造的过程。你每天忙碌的工作，从企业的收入上来说，可以为公司带来什么样的短期和长期现金和其他收入，那么对这部分收入的量化，就是你创造的商业价值。简单来说，商业价值就是帮助公司获取商业收入。
那么作为一个技术人员，本来是写代码做架构设计的，那你是怎么为公司创造商业价值的呢？从创造商业价值视角来看，你的代码和设计有三个作用：
实现一个商业模式；
提升一个商业模式的效率；
加速一个商业模式的收敛速度。
也就是说，你作为一个程序员，主要通过上面这三个路径为公司赚钱。
举个例子来说，你写代码实现一个电商平台的一部分功能，最终电商平台可以获取交易收入。或者是你实现一个算法，提升了买家转换率，从而提升了电商平台这个商业模式的效率。你也可以通过 A/B 实验的平台、数据仿真的功能等等，加速一个公司的商业模式收敛速度。这些都是为公司增加收入的办法，所以公司多赚的这部分钱就可以归因到你，也就是你为公司创造了商业价值。
或许你是一家企业里做软件基础设施的，比如说写云平台、自动化测试平台、财务系统和数据平台。那么当你通过企业内部用户来间接创造商业价值，通过提升用户的日常工作效率、产品质量、运营效率、决策质量和商业洞察的质量，这个时候，你同样也为企业创造了商业价值。
我会把第三条生存法则分为五个部分来讲：
理解你所在的企业或团队的商业模式；
理解你在自己所处环境中创造的商业价值；
保障架构活动的长期商业价值；
在架构规划中寻找扩大收入的机会；
在架构规划中寻找减少成本的机会。
这节课我们先来讲前三个部分，下节课再来学习后面两个。
理解一个企业或团队的商业模式我们先来看第一个话题，理解一家企业或团队的商业模式。
我发现，在一个领域做了很多年的研发人员、架构师，甚至是团队主管，都不太清楚自己开发的模块和所在领域的商业模式是什么。这很危险，不知道商业模式，就没法主动创造商业价值，你的日常工作很可能只是不断被动实现需求。这时候，你的成长也会是缓而慢的。
一家企业必须要有收入，虽然这个收入不一定来自当下，但它肯定会有一个可持续的商业模式。也就是从长期来看，有稳定且健康的收入，以及可控的成本，并且最终要做到盈利。这个商业模式，就是我们主动创造商业价值的突破口。
一个商业模式的技术表达公式作为技术人，我们可以把自己领域的商业模式用一个公式来表达；然后学会在这个公式中，寻找并创造自己的价值。
这个公式，其实就是对所在行业的商业逻辑的数学表达，也就是我们常说的 KPI 的逻辑。
比如说天猫这个电商平台，它的主要收入来自于交易抽成：
总收入 = GMV * Commission
网站的交易额越大，抽成就越多。网站规模越大，总收入就越多。
但到了不同的细分领域，每个领域的商业模式，就会分解成不一样公式了。比如说你负责天猫平台的一个由算法驱动的购物频道，那么你们的商业模式可能是这样的：
GMV= 流量 * 转化率 * 平均订单金额
对于你们整个团队而言，入口流量是一定的，那么你可以通过优化算法，来获得更高的转化率和更高的平均订单金额。
如果你负责天猫平台某个垂直行业的招商团队，那么你们的商业模式可能是这样：
GMV= 日均动销店铺数 * 店铺日均销售额
假设每个店铺的销售额差不多，那么你的目标就是让平台上有越来越多的店铺。显然，这种商业模式不同于上节课讲的放大马太效应的拼多多模式。你需要发现更多的玩家，努力扩大你的基盘。所以这种商业模式就特别适合用于像履约范围和能力都有限的场景，比如外卖、社区团购或便利店。
如果你负责某个垂直行业的大商户运营团队，那么你们的商业模式可能是这样：
GMV= 活动参与次数 * 平均计划销售额 * 计划达成率
你需要说服平台的大商户来参加平台活动。而且每场活动，大商户和平台双方都要达成一个计划销售额，保障双方可以投入足够的流量和营销资源，确保销售计划达成率到 100%。很显然，这种商业模式需要双方的深度配合，来确保营销活动的成功。
如果你负责商品团队，那么你们的商业模式可能是这样的：
GMV= 动销商品数 * 订单数 * 每订单件数 * 件单价
那么你们团队的商业模式需要找到更多受用户欢迎的商品，来提升动销商品数；通过撬动更多的商家参与营销活动，来提升动销商品数和订单数；通过满多件打折等营销方式，来提升每个订单的商品件数；通过更多的功能和商品的可选配置，来提升每件商品的单价。
刚才讲的这些公式里，有些术语你可能不太懂，没关系，因为我想表达的是：哪怕大家是在为同一家公司工作，但如果各自所在的领域不同，那么为公司创造商业价值的方法也有所不同。
对于一个架构师而言，你必须深入理解自己所在公司和团队的商业模式，并且想尽一切办法去最大化这个商业模式的成功概率。这样你才能通过工作为公司创造商业价值，同时也为你自己创造长期的商业价值。
还是那个简单的道理，我们的工资和各种收入，都来自于公司的商业收入和融资。
当然，并非每一家公司的商业模式都是绝对清晰和稳定的。大多数公司往往处在商业模式的探索期，有的团队连自己的 KPI 是什么都不知道。但无论如何，至少要理解你的团队为什么存在，你的工资收入从哪里来。
有句话叫做“良禽择木而栖”，就是说你要选择能够最大化自身成长的工作环境。那么接下来，我就通过一个例子教你怎么从创造商业价值的视角看一个部门， 帮你“择木”。
理解自己所处的工作环境在一个企业里，从 CEO 到一线员工，大多数人的行为和决策都是基于资金的流转逻辑而来的。对此，我们的老祖宗有一句精辟的总结：“有钱能使鬼推磨”。
一位朋友曾给我讲过这么一个有意思的现象。在一家大企业里，只要是公司大力推动的项目，没有一个存活的。反倒是不怎么受公司高层待见的，由具备创业心态的员工自己发起的项目，最后都很成功。
在我认真思考，也近距离观察了这个过程后，我认为自己理解了这种现象的本质。我们还是通过一个真实的案例来说明。
一个大企业的独立核算部门，之前一直保持着高增长，也做到了盈利。但公司高层不满意现在的下滑增速，认为团队的人才构成、营销方法、运营能力有问题。而且认为部门的管理层自以为是，给的建议也不怎么听。于是公司高层就更换了部门的管理层。
新管理层到岗后，按照高层的指点，把之前的精细化运营方式，换成了高举高打的靠营销和大量模式探索投入来获取高增长的模式。很快，该部门的营销和运营成本一飞冲天，增速却变慢了。虽然业绩一塌糊涂，不过团队上下反倒天天颂扬公司高层的英明决策。仿佛自己受领导重视了，日子也就越来越有盼头了。尝试了两年下来，统计指标越来越玄虚，越来越难看懂，增速也一落千丈。
增速为什么会这样呢？新管理层是高层指派的，按理说双方有绝对的信任，应该是有一说一啊。但是仔细想一想，在新的环境下，公司高层的任何发言都变成了圣旨，别说是抗旨不遵，哪怕稍稍让领导觉得你缺乏信心和激情的表情都不会有。
对比之下，反倒是部门前管理团队一直坚持“客户第一”的原则和市场规律，对公司高层的不合理建议会据理力争。
为什么会有这种截然不同的行为呢？答案很简单：部门的资金来源逆向选择了人才及其行为。
部门重组后，成本一下子膨胀了很多倍，完全没有办法养活自己。这时整个部门都要靠公司高层调拨的预算来求生存。公司高层选择了言听计从的乖乖虎，那么这个乖乖虎就会以他最擅长的方式来获取部门赖以生存的收入，也就是公司的拨款。所以他们只有一条路，就是无时无刻讨取高层的欢心。
然而一个以客户为导向的团队，他们的首要目的不是听从上司的声音，而是去倾听客户的声音，从客户的需求中寻找自己能够创造商业价值的地方。所以这样的团队，绝不会靠公司的拨款过日子，他们的收入必须源自为客户创造的真实的商业价值。
这就是为什么越是受公司大力赞助的项目就越难存活的道理。
我们研究一家公司的商业模式，就是希望你认真理解自己所处的工作环境。
如果你活在一个靠公司拨款而生存的部门，那么你学习到的能力是有限的，因为你们部门从上到下都不是在求生，也不是为客户创造价值，所以你也学不到真正的生存技能。
或许短期内，你作为一个一线技术人员可以不必担忧。但是你越资深，待的时间越长，你对公司的依赖性就越大，那么你的风险也会越大。因为公司遇到困难必然会收缩资金，公司真的到了生死存亡的时刻，就只能依靠自力更生的部门了。想想看，这种靠拨款才能生存的部门，还会有保留价值吗？
总结来说，对于一个业务部门而言，存在不一定合理，只有提供稳定商业价值的存在才是合理的。
每个人都要有自己的商业模式我们刚才讲了，你应该对自己所处环境的商业模式有一个深刻的理解，而且你最好能在一个可持续的商业模式下工作。
现在我还要给你讲另一个理念，就是每个人都要有自己的商业模式。意思是说，你必须在工作环境中找到创造价值的方式，这样才能保障自己一直被需要，也能保障未来的收入。
具体怎么做呢？那就是你要为公司、部门或团队提供可量化的增量价值。
这里面有两个关键元素。第一是增量价值，就是你通过工作所创造的价值，是在社会提供的平均价值之上的。
举个例子。2010 年之前，如果你是一个做微服务框架的高手，那你的增量价值就非常大，一个人能顶十个甚至一百个研发。因为那时候开源的微服务框架还不够成熟。但到了今天，如果你还是单兵作战，擅长写微服务框架，那跟开源的 Spring Framework 相比，你提供的增量价值可能就是一个负数了。因为团队剩下的同学还要花时间来学习、使用和维护你写的框架，公司也要为这些同学付出工资成本。
虽然你的工作没有变，但社会提供的开源解决方案的价值增加了，那你的增量价值相应地就会减少，甚至不存在。
第二个是可度量性。有些做技术的人会秉持这样一种态度，似乎他创造的价值极其普适，普适到像空气一样，以至于不能量化成商业价值，甚至谈度量就是对他工作的一种侮辱。
这个态度我觉得无异于自毁前程。
对于我们软件行业的从业者来说，价值创造永远是个衰减的过程，因为我们的经验会在信息扩散中迅速贬值。如果你不度量自己的增量价值，那就无法确保自己处在价值创造的前沿。你也不知道应该朝什么方向努力，才能最大化你未来的增量价值，更不能在一个相对未知的环境下扩大你的增值空间。
所以现在的问题就是，该怎么度量自己的增量价值呢？
答案是，把自己的工作放到我们刚才讲的公式里去。假设你是做商品相关的技术，那么：
GMV= 动销商品数订单数每订单件数 * 件单价
你需要度量的是，你的工作对公式中的某一项或某几项会起到什么促进作用。
比如说，你实现了一个需求分层的功能，使得不同需求层次的人群更容易发现自己所喜爱的商品，那么结果就是动销商品数在上线之后明显增加。同时，A/B 测试显示与之前相比，动销商品数增加了 15%，那么这 15% 就是你所创造的直接增量价值。
事实上，你还创造了其他的增量价值。比如动销的商家数肯定也有所增加。此外，用户维度的转化率也会有提升。相应地，用户满意度和回购率也应该提升。
有了这些度量，你就会不断调整自己的知识和技能，不断搜索新的突破口，最终为公司创造源源不断的价值。而你的这个能力，会被周围人以及领导注意到，也会因此获得更多可以施展才能的机会与场景。
再进一步，随着时间的推移，你不仅能得到马斯洛所讲的有底气的自尊，还能得到从目标到实现手段的完整闭环。这个时候，这个技能就会成为你的一个核心技能。
架构师如何创造自己的增量价值？如果你已经是一个架构师了，你可能发现刚才讲的这两种方法已经不够用了。因为架构师需要做的是，在一个相对复杂的问题上引导实施一个结构化的解决方案。这个方案的参与者是一群人，所以架构师的产出不完全靠自己，而是靠撬动一群人来完成架构目标。
在这种情况下，一个架构师想要创造长期的商业价值，就必须同时满足三个条件：
确保最终架构方案的可行性。
确保参与方达成一个合理的实施路径，最终能够完成实施。
确保设计方案可以最大化解决方案的结构性。
事实上，这三个条件很难被同时满足。架构师之所以参与一个方案，往往有这么几个原因：已经有现成的方案，但比较复杂；参与团队众多，但各个团队的优先级不一样；公司压力大，能够投入到现存方案的人力资源有限。这就意味着你作为一个架构师，需要在资源有限的条件下做取舍。
举个例子。假设你们已经有一套在一些核心系统上使用的老网关，之后又开发了新系统，却发现老网关落后，于是就把老网关迁移到了 Spring Cloud Gateway 上去。但是最近你们发现，出于公司整体安全的要求，还需要在网关层上开发安全功能。这个时候，你作为一个架构师至少有三种不同的选择路径：
一种是在现有的两种网关上各自加安全功能；
一种是迁移和整合现有的网关，然后再加安全功能；
一种是在这两个网关之外再加一层安全网关，之后再想办法把现有的网关能力都迁移上去。
在不同的交付时间、需求压力、现有系统复杂度和研发人员能力的组合之下， 这三种方案都可能是最好的方案。但作为架构师，就要在兼顾方案可行性和实施路径合理性的同时，寻找一个最合理的结构化方案。所谓最合理的结构，就是从长期看，网关层不是越来越复杂，而是全公司统一、易维护和高可用。
如果相关方都能接受长期规划，那么构建第三个网关，然后逐渐把现有网关的功能都迁移上去，可能就是最结构的方案。反之，如果你的迁移项目烂尾了，那么两个网关变成三个网关，而且在迁移到一半的情况下，安全和网关逻辑散落在各处。那就是一个糟糕透顶的设计。
所以架构师在这个过程中创造的增量价值就在于能够审时度势，在企业内部各种资源限制和现实条件下，找到合理可行，并且能够最大化企业长期价值的架构方案。
事实上，除了一些现金流极度充足的大公司，大多数的创业公司都是要在平衡中逐渐迭代升级。我们在第三节课提到了，做架构和做业务一样，都不能靠饱和攻击取胜，而是靠对阶段性精确目标的最大化投入来取得进步。
那么下节课，我就来介绍一个我自己的案例，讲讲架构师到底该如何靠对阶段性精确目标的最大化投入而最大化自己的增量价值的。
小结这节课我们介绍了架构师的第三个生存法则，那就是必须要在有限的资源下最大化架构活动所带来的商业价值。
不同的团队在以不同的方式为企业创造着商业价值。对于一个架构师而言，你要为公司、部门或团队提供可量化的增量价值，这样才能让自己处于价值创造的前沿，保障自己的长期收入。同时，这也是你增长技能、获取自尊的最佳路径。
那么在这种情况下，架构师创造自己的增量价值，就必须同时满足三个条件：
确保最终架构方案的可行性。
确保参与方达成一个合理的实施路径，最终能够完成实施。
确保设计方案可以最大化解决方案的结构性。
事实上，这三个条件很可能是互相冲突的，很难被同时满足。于是，靠对阶段性精确目标的最大化投入去取得成功，就成了实施架构活动的重点。这个我们下节课再深入讨论。
思考题三个思考题，任选一个：
你理解自己所在公司或团队的商业模式吗？你知道自己在其中创造的价值是什么吗？这个价值能够长期维持吗？如果你有担心，为什么呢？
你身边有存在一些不合理的现象吗？为什么呢？
你有没有见到过一些架构方案，虽然可以满足我们所提到的三个条件，但是最终却失败了。这是怎么回事呢？你有个合理的解释吗？
如果今天这节课对你有帮助，欢迎你点击课程右上角的分享并赚钱按钮，把课程转发给你的同事或朋友，大家一起交流、进步。我们下节课再见！

分享给需要的人，Ta订阅后你可得20元现金奖励

生成海报并分享

赞 4

提建议

06｜法则二：拼多多是如何通过洞察用户人性而脱颖而出的？

 写留言

精选留言(16)

GAC·DU
2021-12-21
疫情前在一家公司做过一段时间增长，技术、运营手段无所不用其极，企业的资金流水有明显的上升。但是我却天天做噩梦，疫情期间进行深度反思，看到了自己从满足用户需求，到刺激用户需求的转变。这就好比是从卖***的改成**。也许现在大多数互联网企业都这样吧😂，我从良心上过不去这道坎，觉得远离了技术的纯粹性。离职转到的了做PaaS，不管企业模式是什么，我只要保证降本增效就好。之前向外求，现在向内求，很踏实。
展开
作者回复: 拥有平静的内心是真正的福分啊！
6
罗均 - Jun
2021-12-22
互联网在线课程百千万，唯独东白老师的课，以“道”为主，“术”辅之，其它的课程几乎全只有“术”。

针对老师的第一个问题思考，学生十几年以来一直在传统汽车制造商，有global也有local，商业模式很简单，就是卖车赚钱。自己的价值：

* 相对有增量价值：车厂里99%的工程师都不会软件，供应商说啥就是啥。这个时候有一位工程师可以搭起全栈demo指导供应商开发并交付出领导层期望的产品或系统，相对会比较突出。
* 相对有可度量性：例如通过软件实现降低硬件成本，开发全栈E2E自动化测试系统大幅度降低测试周期和提升产品质量等等。

当然，没有老师对两个核心要素的讲解，自己也是云里雾里地干活，完全不清楚接下来怎么走。

对于这种价值能否长期维持，肯定是有担心的。主要的担心点是通过上一节课的学习后，发现自己所在的公司中，没有一家公司可以清晰的定位目标用户心智，部门内斗严重，自己的技能或经验，感觉更多时候是为领导争取funding或各种填坑——非常惭愧，学生所待过的团队，要么是靠funding的（往往是最高funding的团队），要么是被动接受需求或任务的。目前的形势比较严峻，汽车行业很快会像通信行业那样，传统制造商被高科技创新企业颠覆。因此，自己的担心，就是完全没有信心帮助现有的雇主拥抱科技时代的变迁，愧对公司。
展开
作者回复: “* 相对有可度量性：例如通过软件实现降低硬件成本，开发全栈E2E自动化测试系统大幅度降低测试周期和提升产品质量等等。”
这个我觉得非常厉害啊！如果能做到价值很大啊。仿真不就是做这个玩意吗？更能吹的人会管这个技术叫数字孪生。。。
我很想听听你是怎么做到的。
共 2 条评论
1
Geek_b7cb97
2021-12-22
公司往往有多个业务增长点，IT部门跟对口的业务部门的商业模式对齐。但是像后台或者平台化的技术团队，如运维，测试或者OA技术等，如何找到自己的商业价值呢？
作者回复: 运维、测试、安全、OA都是有非常准确的价值定位的。比如说运维，那么提升系统的可用性、简化系统变更操作的复杂性，就是运维团队可以创造的核心价值，这个价值是可以直接以上面的指标度量的。至于转换成商业价值，一般我们不做这方面的直接度量，尤其是安全，出了事情总是很大，不出事情又似乎没创造价值。我还真不知道是不是有某种会计方法把风险最终量化成金钱。不过至少有一点是肯定的，就是在由CEO， CTO确定可承受的风险之后，那么运维、安全、测试的团队就要以最小成本达到这些目标。
类似的问题前面也问到，建议也看一下我的回复。
1
szs
2021-12-21
我是公司平台部门的接触不到产品，请问老师GMV该怎么表达呢
作者回复: GMV是举例子的。你搭建的平台应该是有某些可度量的价值的，你需要把那个价值表示出来，我不知道你具体做什么平台，也猜不出来。举个例子，假设你做公司内部的CRM平台。那么你平台对客户留存或者是转化应该有贡献。那你就应该度量你的技术创新对这两个指标的直接贡献。
1
李
2021-12-21
老师的法则很多都有共鸣，可惜我是通过教训得来的。如果能早个7、8年看到这这个专栏该有多好
作者回复: 能帮助到你的未来就好
共 2 条评论
1
欧阳绍聪
2021-12-24
有个问题，我一直思考。在面试，或者与研发人员沟通的过程中，总有一个观点被多次提及。业务研讨会不能增长技术，要去做有技术深度的工作，比如做中台，做架构。我个人的观点就是，没有整明白自己在做什么，把工作与写写代码划等号。想请教老师如何才能帮助大家更好理解自己呢？
展开
作者回复: 没太看懂
彭彭😄
2021-12-23
实际场景中某个指标可能与多种因素有关，比如客户转化率、留存率，是各个团队协作的结果。很难归因到某个团队，请问老师这种场景下如何量化呢
作者回复: 一般还是分开看AB的效果。产品、运营、工程、算法自己看自己的。有时候像大促这样的场景就不太好分了
BIZ_UI_3
2021-12-23
字字珠玑，句句箴言。感谢郭老师醍醐灌顶的教诲。
作者回复: 谢谢！
Helios
2021-12-23
当看到“增量价值”的时候我感觉很羞愧，感觉不能给公司或者部门带来什么增长，只是完成任务，甚至都是低于平均线，最多从技术的角度看问题，这就引出了第二个问题“量化”，
我比较喜欢技术，觉得一件事情的技术含量低我就不想干（我想这是大多数人有过的想法），这就导致我“想干”的时候产出会比较高，在书上看到能改良现在代码的模式，我在等火车的时候就实现了一发。

这也都是局限于技术方面，我发现把能十行代码写的改为一行代码了，老板并不关心这个，他只关心结果，事故等级，我就开始思考，原来我从书中得到并运用的对于我来说增长很大，但是对于整个组来说成就很小。我的价值在哪里？却是我做的这个工作量化起来很难。

当有很多琐事的时候，或者没有目标的时候，我的热情就会降低变为糊弄，有两个同事和我说过类似的话：
1、不能只做难的事情，难题➕琐事才是一件完整的事情
2、向上汇报的时候，你攻克的难题对他们来说只是“应该如此”，反倒是一些小事能凸显你的能力

虽然我很同意这两句话，但是目前为止还是做不到。

我一直以为对于一个技术人，技术才是立身之本，找工作的时候都看你技术谁看你乱七八糟的这个那个能力呀……
但事实却是工作中更需要态度……
展开
作者回复: 技术的确是立身之本。慢慢的判断力也很关键。
共 2 条评论
1
勇敢的心
2021-12-22
太有共鸣了！如何持续的创造价值是一个值得思考的问题，这个也是导致年龄大了以后比较焦虑的原因。
作者回复: 我感觉其实和年龄关系不大，还是我们所处的年代技术进化的速度太快了，而且还在加速。比我们年轻的人未来面临的年龄压力可能比我们还大。
D.L
2021-12-22
请问下老师怎么理解2B2G类的业务，这类业务经常是市场导向的，在这种模式下架构师怎么衡量自己的增量价值呢？
作者回复: 2G的业务我没有经验，不太清楚。
2B的业务我自己认为架构师和产品经理协同，对自己的产品的准确定位上的价值非常大。另外如果2B产品的API设计主要是架构师的工作，虽然是面客产品，这里面API的简洁性、数据模型的稳定性、API的可扩展性，都是架构师的工作。
qinsi
2021-12-22
题外话

“对于我们软件行业的从业者来说，价值创造永远是个衰减的过程，因为我们的经验会在信息扩散中迅速贬值。”

这个做交易的同学应该很有体会，好比某种交易策略逐渐被大多数人获知。同理，能在知识付费平台上学到的别人的经验也是在扩散中的，也就是说你花钱买到的是一些正在贬值的东西，区别只是贬值速度有快慢而已。(手动狗头保命
展开
作者回复: 是的，营销手段尤其是。
欧阳斌
2021-12-21
回答一下问题2，不少公司有这样一批架构师（技术主管？），他们每到一个新部门，就想着做大项目，因为大项目有影响力，容易吹嘘出某种成绩。这导致一个什么后果呢，一个事情有好几个系统在承接，由于系统数目多，相互之间数据又不互通。系统客户的使用成本都是成倍增加、系统维护的成本也是成倍增加，后续维护的一线人员苦不堪言。而开启这种项目的人，往往由于一开始提炼出来的某些优势，该拿奖拿奖，该晋升晋升了
展开
聪明的傻孩子
2021-12-21
这一章太有共鸣了，而且很多经验都是经历过的公司失败的教训得来的，老师将其总结为可以理解的法则，太棒了
作者回复: 很高兴能帮助到你
dbtiger
2021-12-21
老师本专栏讲的架构是系统架构、业务架构、应用架构还是三种集合呢
ViCanary
2021-12-21
加入一家企业之前一定要看到其他人还没看到的机会，这是跳跃式发展的前提。
作者回复: 是的

