07 法则三：架构师如何找到自己的商业模式？
你好，我是郭东白，今天我们来聊聊架构活动中对商业价值的考量。
今天我们要讲的是架构师的第三个生存法则：作为一个架构师，必须要在有限的资源下最大化架构活动所带来的商业价值。对于任何一个架构活动而言，架构师的可用资源，包括商业成本、研发成本、时间成本、迁移成本等等，都是非常有限的。但架构活动就是要在这些限制条件之下，将商业价值最大化。
你可能还处在职业生涯的初期，不太关注商业价值，不知道我们的工作最终能为公司带来什么样的商业收入。我刚工作时，也从来没想过我的工资是从哪里来的；公司凭什么会在明天、明年甚至十年后还会给我发工资；更别说思考我为社会创造的价值了。
但随着在职业上的不断成长，我越来越深刻地意识到，必须要为自己所在的企业创造出可度量的商业价值，这是我们获得有质量的长期收入的重要前提。
要了解商业价值，我们就要先了解商业模式。所以在正式讲解第三条法则之前，我先来对商业模式与商业价值做一个简单的区分。
什么是商业模式？什么是商业价值？
商业模式（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上去。但是最近你们发现，出于公司整体安全的要求，还需要在网关层上开发安全功能。这个时候，你作为一个架构师至少有三种不同的选择路径：
- 一种是在现有的两种网关上各自加安全功能；
- 一种是迁移和整合现有的网关，然后再加安全功能；
- 一种是在这两个网关之外再加一层安全网关，之后再想办法把现有的网关能力都迁移上去。
在不同的交付时间、需求压力、现有系统复杂度和研发人员能力的组合之下， 这三种方案都可能是最好的方案。但作为架构师，就要在兼顾方案可行性和实施路径合理性的同时，寻找一个最合理的结构化方案。所谓最合理的结构，就是从长期看，网关层不是越来越复杂，而是全公司统一、易维护和高可用。
如果相关方都能接受长期规划，那么构建第三个网关，然后逐渐把现有网关的功能都迁移上去，可能就是最结构的方案。反之，如果你的迁移项目烂尾了，那么两个网关变成三个网关，而且在迁移到一半的情况下，安全和网关逻辑散落在各处。那就是一个糟糕透顶的设计。
所以架构师在这个过程中创造的增量价值就在于能够审时度势，在企业内部各种资源限制和现实条件下，找到合理可行，并且能够最大化企业长期价值的架构方案。
事实上，除了一些现金流极度充足的大公司，大多数的创业公司都是要在平衡中逐渐迭代升级。我们在第三节课提到了，做架构和做业务一样，都不能靠饱和攻击取胜，而是靠对阶段性精确目标的最大化投入来取得进步。
那么下节课，我就来介绍一个我自己的案例，讲讲架构师到底该如何靠对阶段性精确目标的最大化投入而最大化自己的增量价值的。
小结
这节课我们介绍了架构师的第三个生存法则，那就是必须要在有限的资源下最大化架构活动所带来的商业价值。
不同的团队在以不同的方式为企业创造着商业价值。对于一个架构师而言，你要为公司、部门或团队提供可量化的增量价值，这样才能让自己处于价值创造的前沿，保障自己的长期收入。同时，这也是你增长技能、获取自尊的最佳路径。
那么在这种情况下，架构师创造自己的增量价值，就必须同时满足三个条件：
- 确保最终架构方案的可行性。
- 确保参与方达成一个合理的实施路径，最终能够完成实施。
- 确保设计方案可以最大化解决方案的结构性。
事实上，这三个条件很可能是互相冲突的，很难被同时满足。于是，靠对阶段性精确目标的最大化投入去取得成功，就成了实施架构活动的重点。这个我们下节课再深入讨论。
思考题
三个思考题，任选一个：
- 你理解自己所在公司或团队的商业模式吗？你知道自己在其中创造的价值是什么吗？这个价值能够长期维持吗？如果你有担心，为什么呢？
- 你身边有存在一些不合理的现象吗？为什么呢？
- 你有没有见到过一些架构方案，虽然可以满足我们所提到的三个条件，但是最终却失败了。这是怎么回事呢？你有个合理的解释吗？
如果今天这节课对你有帮助，欢迎你点击课程右上角的分享并赚钱按钮，把课程转发给你的同事或朋友，大家一起交流、进步。我们下节课再见！
- GAC·DU 👍（31） 💬（1）
疫情前在一家公司做过一段时间增长，技术、运营手段无所不用其极，企业的资金流水有明显的上升。但是我却天天做噩梦，疫情期间进行深度反思，看到了自己从满足用户需求，到刺激用户需求的转变。这就好比是从卖***的改成**。也许现在大多数互联网企业都这样吧😂，我从良心上过不去这道坎，觉得远离了技术的纯粹性。离职转到的了做PaaS，不管企业模式是什么，我只要保证降本增效就好。之前向外求，现在向内求，很踏实。
2021-12-21 - Helios 👍（11） 💬（5）
当看到“增量价值”的时候我感觉很羞愧，感觉不能给公司或者部门带来什么增长，只是完成任务，甚至都是低于平均线，最多从技术的角度看问题，这就引出了第二个问题“量化”， 我比较喜欢技术，觉得一件事情的技术含量低我就不想干（我想这是大多数人有过的想法），这就导致我“想干”的时候产出会比较高，在书上看到能改良现在代码的模式，我在等火车的时候就实现了一发。 这也都是局限于技术方面，我发现把能十行代码写的改为一行代码了，老板并不关心这个，他只关心结果，事故等级，我就开始思考，原来我从书中得到并运用的对于我来说增长很大，但是对于整个组来说成就很小。我的价值在哪里？却是我做的这个工作量化起来很难。 当有很多琐事的时候，或者没有目标的时候，我的热情就会降低变为糊弄，有两个同事和我说过类似的话： 1、 不能只做难的事情，难题➕琐事才是一件完整的事情 2、 向上汇报的时候，你攻克的难题对他们来说只是“应该如此”，反倒是一些小事能凸显你的能力 虽然我很同意这两句话，但是目前为止还是做不到。 我一直以为对于一个技术人，技术才是立身之本，找工作的时候都看你技术谁看你乱七八糟的这个那个能力呀…… 但事实却是工作中更需要态度……
2021-12-23 - 罗均 👍（9） 💬（4）
互联网在线课程百千万，唯独东白老师的课，以“道”为主，“术”辅之，其它的课程几乎全只有“术”。 针对老师的第一个问题思考，学生十几年以来一直在传统汽车制造商，有global也有local，商业模式很简单，就是卖车赚钱。自己的价值： * 相对有增量价值：车厂里99%的工程师都不会软件，供应商说啥就是啥。这个时候有一位工程师可以搭起全栈demo指导供应商开发并交付出领导层期望的产品或系统，相对会比较突出。 * 相对有可度量性：例如通过软件实现降低硬件成本，开发全栈E2E自动化测试系统大幅度降低测试周期和提升产品质量等等。 当然，没有老师对两个核心要素的讲解，自己也是云里雾里地干活，完全不清楚接下来怎么走。 对于这种价值能否长期维持，肯定是有担心的。主要的担心点是通过上一节课的学习后，发现自己所在的公司中，没有一家公司可以清晰的定位目标用户心智，部门内斗严重，自己的技能或经验，感觉更多时候是为领导争取funding或各种填坑——非常惭愧，学生所待过的团队，要么是靠funding的（往往是最高funding的团队），要么是被动接受需求或任务的。目前的形势比较严峻，汽车行业很快会像通信行业那样，传统制造商被高科技创新企业颠覆。因此，自己的担心，就是完全没有信心帮助现有的雇主拥抱科技时代的变迁，愧对公司。
2021-12-22 - 李 👍（8） 💬（2）
老师的法则很多都有共鸣，可惜我是通过教训得来的。如果能早个7、8年看到这这个专栏该有多好
2021-12-21 - Nick~毓 👍（7） 💬（1）
简单一点理解： 1、为什么我们公司会存在？（公司的商业模式） 2、为什么我们部门会存在？（部门的价值定位） 3、为什么我们团队会存在？（团队的核心职能） 4、为什么个人会存在？（个人的核心职责） 然后找到一些结构化的公式和量化的KPI； 不断的深入思考，如何最大化各个层级的KPI；
2022-08-25 - 术子米德 👍（6） 💬（2）
🤔☕️🤔☕️🤔 * 📖：架构师如何找到自己的商业模式？ * 🤔：技术人员，不都是等需求听安排，到手的活干得漂漂亮亮嘛。这个认知，也不知道啥时候种进我的思维，一直深根发芽开花。直到最近几年，在得到学了很多有的没的，这些东西像泥土里蚯蚓，来来回回挖松深根周围的泥土，这些东西又像泥土里的微生物，分解出新的营养成分，从根部开始影响到我的整个观念体系。然后在某天听到“技术商人”，感觉脑袋里哪个地方破了，瞬间问自己，为啥我不是技术商人，我就该是技术商人。作为技术商人，就该有自己的商业模式。不只是架构师，不只是技术人员，所有人，只要想在协作关系里寻找双赢，都该有自己的商业模式。 * 📖：架构师必须在资源有限的情况下，最大化架构活动所带来的商业价值 * 🤔：经常的口头禅，很难评估这么做实际的商业价值。现在想来，这不只是种懒惰的思维模型，更是种逃避责任的思维模型。如果不能反应出架构的商业价值，那所谓的架构活动，不只是缺乏度量这么糟，更是在浪费大家的时间和机会，还满嘴跑着所谓优秀技术方案的火车。 * 📖： * 三大生存法则：1）实现商业模式；2）提升商业模式效率；3）加速商业模式收敛速度 * 五大落实手段：1）理解商业模式；2）理解商业价值创造；3）保障长期商业价值；4）寻找扩大收入机会；5）寻找减少成本机会 * 🤔：作为架构师，首先要理解三大生存法则，其次要掌握五大落实手段，最终要能够回答为何需要理解和掌握，并且能把这些认知传递给决策层和执行层。这就是架构师的入门-进阶-资深之路嘛。 * 📖：个体的商业模式 = 提供可量化的增量价值 * 🤔：没我不行，还得搞明白没我那点不行，更得搞明白有我后到底增加多少价值。第一步没我不行，要么我有独门秘籍，要么我去做苦活累活。第二步必须搞明白到底是哪点没我不行，这是核心价值点，找得到抓得住，才能够投资它放大它。第三步要把帐算清，到底能创造多少价值，到底值多少钱，如何能够创造更多，如何能够更值钱。 * 😖：“确保设计方案可以最大化解决方案的结构性” * 🤔️：郭老师，你好！这句话没有特别理解。方案可行性，可以理解为技术可行，实施路径可以理解为加上人的因素，最终能够完成实施。那这里的结构性，如何理解呢？方案实施后的利益分配合理？价值创造最大化？还是……？
2021-12-25 - qinsi 👍（5） 💬（1）
题外话 “对于我们软件行业的从业者来说，价值创造永远是个衰减的过程，因为我们的经验会在信息扩散中迅速贬值。” 这个做交易的同学应该很有体会，好比某种交易策略逐渐被大多数人获知。同理，能在知识付费平台上学到的别人的经验也是在扩散中的，也就是说你花钱买到的是一些正在贬值的东西，区别只是贬值速度有快慢而已。(手动狗头保命
2021-12-22 - szs 👍（5） 💬（1）
我是公司平台部门的接触不到产品，请问老师GMV该怎么表达呢
2021-12-21 - Geek_sa2mt4 👍（4） 💬（2）
“在一家大企业里，只要是公司大力推动的项目，没有一个存活的。反倒是不怎么受公司高层待见的，由具备创业心态的员工自己发起的项目，最后都很成功。” 前半句和后半句都遇到类似的事情，但是和描述略有不同。 之前呆过一个未来配送的项目组，做机器人配送和智能柜配送，当时团队精力八分在机器人配送上，两分在智能柜配送上。因为业务同学及其看好机器人配送，觉得这是未来趋势，就烧钱去做，赢得了上面的支持，但进步缓慢，因为这个项目依赖于机器人硬件的迭代，周期长。而智能柜配送是业务不太看好的，但研发同学比较看好的项目，我们都觉得这个运营成本很轻，放个柜子在办公楼就行了，而且一旦占坑，竞对将很难进来，进来了也没好位置了。不像机器人配送，做了那么多代，还是得要人跟着，处理机器人出现的各种奇怪问题。 后来机器人配送因为长期没有产出，被上头diss，给的经费也少了，不受待见的智能柜配送因为疫情反而发展起来了。不可否认智能柜的兴起有运气的成分，但这两种模式的成本和收益是很容易算得出来的。业务同学在研发同学的要求下也计算过机器人配送多少年能回本，研发同学觉得这个太长，可能短期内还是靠智能柜先盈利比较好。但业务同学出于一些不能说(不是我不能在这说，是业务也没告诉我)的原因，一直坚持机器人配送。 我觉得这是一种很不好的决策方式，作为私企项目，就算是创新项目，还是应该有一个合理的可盈利的期限，如果做之前计算出的期限太长，则说明这件事情在理论上有很大的失败风险，要么减少投入作为长期项目，要么别做。
2022-09-11 - neohope 👍（4） 💬（1）
带团队其实也要不断量化团队贡献，相比销售团队，技术团队的贡献量化起来确实有些困难。我也自己发明了不少衡量贡献的方法，包括业务支持，业务增长，新业务开拓，费用节约，服务器节省等等，总归团队贡献超过团队成本，才能心安一些。 在架构层面的工作，很多收益是隐形的，比如偿还技术债务，修复历史遗留Bug，升级框架版本，老网关迁移到新网关，去掉代码坏味道，删除无用代码等，合理的量化这方面的价值，会帮此类任务获得更好的支持。
2021-12-30 - Geek_b7cb97 👍（4） 💬（1）
公司往往有多个业务增长点，IT部门跟对口的业务部门的商业模式对齐。但是像后台或者平台化的技术团队，如运维，测试或者OA技术等，如何找到自己的商业价值呢？
2021-12-22 - 勇敢的心 👍（4） 💬（1）
太有共鸣了！如何持续的创造价值是一个值得思考的问题，这个也是导致年龄大了以后比较焦虑的原因。
2021-12-22 - 聪明的傻孩子 👍（4） 💬（1）
这一章太有共鸣了，而且很多经验都是经历过的公司失败的教训得来的，老师将其总结为可以理解的法则，太棒了
2021-12-21 - ViCanary 👍（4） 💬（1）
加入一家企业之前一定要看到其他人还没看到的机会，这是跳跃式发展的前提。
2021-12-21 - Neil43 👍（3） 💬（1）
老师这句话：做架构和做业务一样，都不能靠饱和攻击取胜，而是靠对阶段性精确目标的最大化投入来取得进步，真是深有感触，真希望能早点听到老师这门课，因为自己在以往的架构决策中确实犯了饱和攻击的错误。 举自己的一个例子，前年春节期间，疫情突然爆发，年前一个公司和客户高管关注的重大项目优先级继续提高，因为正好能够提供疫情下的业务场景解决方案；但是由于疫情当时核心人员无法到岗、核心关联方商业化能力偏低(客户指定的供应商)、疫情期间只能联合办公，同时项目交付实践提前，但是最为整体项目技术负责人，首先想到的是大领导很关注这个项目，自己收到了重视，确没有意识到资源受限情况下需要马上调整方案的交付标准，重新制定合理可行的方案；因为本身疫情下业务方案是应该降低预期、优先跑通业务流程，先于市场提供场景方案，其他的机制客户体验、弱网兼容处理、音视频体验优化等应该放到第二阶段。不出所料最后这个项目整体延期了一个多月，个人发展也受到了较大影响，所以架构师的审时度势、决策能力真的应该关键，一定要在市场瞬息万变中看到阶段性精确目标。
2022-01-05