阿里老曾P9_L2从个人贡献者向管理者进阶视频课 28节视频_09能力简.系统架构力
在上一节课呢给大家讲到，就是我们做所有的事情都要回应到公司的价值。
那么在这里呢我们开始讲的是能力篇啊，能力篇。
其实我们抽象为五个能力叫做武力模型。
那主要的这个武力模型呢，其实都是围绕着如何让公司能够发现，或者是认为你对公司来讲，未来是能够帮助公司创造价值的人这个角度来设计的。
那么武力是哪五力呢？首先是产品的架构力，这也是我们产品人的一个基本的素质和能力要求。
啊，然后第二例呢是业务的认知力，这个是必须要有的。
第三是内部影响力。
第四是团队管理能力。
第五是行业的洞察力。
那么这五力我们把它放在一起，其实主要是由一个比较硬的技能，加上四个相对来说比较软的技能组合起来。
那么下面呢我给大家先开始拆解一下什么是架构力。
首先你作为一个p七的同学，我们为什么要学习架构的能力呢？是因为在大厂里面呀p七叫做架构师预备役。
因为从p七开始，你叫专家了，对吧？你的整个岗位的名称已经发生了变化。
那你在这个岗位上，实际上你是要帮助公司提供。
那在应该如何设计我们公司的，或者我们BU的这个产品的架构，这么一个思考的东西的。
所以如果你想升级为p七，那你在晋升的时候很可能会面对这样的问题。
类似于说你怎么考虑公司的产品的架构的设计啊，怎么看公司的这个业务的这些问题啊，那么这种问题哎，你就需要有这方面的能力啊，这是为什么？你需要有架构的利益。
那在架构这个事情上，很多同学可能都听过架构，但是何为架构呢？啊，架构其实它来自于一个建筑学的一个术语啊，就是我们都知道我们盖一座房子，对吧？那么我们是实际上是要去构架出这个整个房子的这个结构来的。
比如说先画出一个房子的蓝图，然后再根据这个蓝图呢去确定我们的施工的这个呃整个结构。
比如说哪里是客厅，哪里是厨房对吧？然后我们要分步骤，比如说先打地基，然后一步步的去把这个框架搭建起来。
然后呢，我们要留出一些空间怎么样走电啊，怎么走水啊，怎么走线啊，然后最后用各种材料把它给装修起来，然后最后成为一个可以让别人住的房子。
最个是架构的一个整个的意义啊，就是整个的我们把一个完成一个复杂的事情呢，我们去把它抽象成一个基本的一个框架，一个思路啊，这是一种抽象它的能力。
然后另外呢，我们需要设计它整个结构的前后的顺序，先做啥再做啥，各个团队之间怎么分工啊，怎么一起达到那个最终的结果。
最后让整个公司里面所有的人后或者是呃层层也能理解说我们怎么慢慢的到那一步去啊，最终呢能够实现我们的战略目标，这个是架构的意义啊。
那么在一个公司里面，我们怎么去拆解或者理解公司的产品架构呢？其实在公司里面有好几种架构，我们从第一层来拆呢是战略层战略层拆什么架构呢？拆组织架构啊组织架构。
如果你作为一个产品的架构师，或者是呃想要了解架构的人，你先要了解公司的组织，或者战略上他是如何拆解的。
然后从战略知道了组织的分工啊，组织的定位。
然后在组织上，我们再来考虑我们从产品的规划架构分工上该怎么去给他们做知持和保障。
这是第一层啊，也是最上面的一层，从上往下拆的那一层啊，那么我们经常在公司聊战略聊战略，那战略是一个什么样的一个状态呢？其实我们都知道每个公司啊每年可能他们都会开各种各样的大的小的战略会。
那比如说在年初的时候，对吧？把大家拉到一个郊区的小院子里面，那些高管们坐在一起闭门三天。
然后我们看他们在一起聊说聊公司的战略，聊未来的发展。
他们主要聊什么？其实就聊这么几个事情。
第一，我们目前是个什么阶？那那么竞争对手在做什么？行业里面又有什么新的机会，他们会先聊这件事情啊。
第二呢就是聊我们公司的业务。
在这种情形下，老业务怎么做？新业务怎么开展，这是第二层。
第三个是如果我们知道了老业务，新业务大概我们可能怎么做，那我们就在里面立出哪些新的项目，或者是哪些必须要落地的事情，对吧？这个是抽象项目的过程。
然后第四呢，就是这些项目，哪些是公司级的核心项目，哪些是部门级的核心项目，把它一一列举出来。
第五就是谁来做，比如说这个组织上有哪个BU可以保证落地这件事情，或者哪几个BU一起来保证落地这个事情。
那么有的情况下呢，我们也会出现说有一个项目啊，他往往这个部门需要多个部门一起协作。
那这个时候我们就立项做一个项目，然后让几个BU来参与，我们定一个主要的负责人作为PM,对吧？这个是做战略会的时候，他们怎么拆解？那拆解过了以后呢，往往他们会发一个呃公司的一个邮件讲解。
今年的战略是定位是什么？然后核心关键字是什么？然后几个重要的项目是什么？负责人是谁？那往往这个时候伴随的是什么呢？伴随的是组织架构的调整对吧？那组织架构的调整调整完了以后，他们是为了保证什么？为了保证这些核心的工作的落地，那我们在产品的设计上，我们就要因为他们组织架构的调调整和迎合他们组织的需要，去对这个架构做设计或者做调整，这是最核心的。
第一层。
我们通过组织就能了解，我们在架构上应该做什么事情啊，那么往往呢其实公司的组织也好，人也好，资源也好，这些东西其实最终他们的侧重就是代表着哪些事情可能是最关键最重要的。
我在前面的课程给大家讲，我们一定要迎合公司的战略的价值的发展。
其实公司会把资源投向哪里，就说明那件事情更重要吧。
我们做的事情跟那件事情有没有关？我们做的事情如果跟这些东西有关，那就说明他们更重要。
所以这是一种在架构上思考什么事情更有价值的一种方法，对吧？然后第二层是什么呢？第二层其实是业务层，就是当你架构拆出了组织架构，就是从战略层拆出了。
组织架构以后，你们组织架构就是到了业务，业务这一层更来拆分产品架构。
你看产品架构其实在中间啊这第二层，那么往往呢其实是你的公司的业务模式或者商业模式，决定了你们公司的组织或者产品架构应该如何设计，对吧？那里呢我其实给给大家分享一个大家可能有点了解的一个案例。
比如说我们在阿里阿里呢第一家公起了一个叫中台战略这件事情，其实中台战略就是一个特别明显的一个架构设计上的一个东西。
那阿里为什么要发起中台架构呢？是因为有一年啊这个公司的高层啊，他们去国外考察，然后呢就发现有一家公司的人效，特别高人效是什么？是一家公司的收入除以人的数量，代表每一个人大概能够为公司创造的价值，对吧？那他们就发现有一家公司呢，一年的营收能有几十亿，可是他们公司只有十几架人，这是一家游戏公司。
然后他们就特别数亚，因为我们知道阿里呀一个可能这样的大公司基本上都是几万人十几万人。
那么他们就好奇说，那这家公司如何做到人效这么高的呢？其实就是因为这家游戏公司，它有一个核心的游戏引擎。
这个游戏引擎上面这些人可以不断的在上面换皮推出各种新的游戏。
但是核心的那些东西呢是一个他们叫做中台的东西，能够保证呢共用的东西能够大家通用啊，这样就保证了他们公司的效率最高。
所以他们回到国内呢，阿里那边就觉得说嗯因为我们有很多的业务都是偏电商。
所以呢他们就觉得说我们是不是也可以抽象一个中台这样的东西，来保证各个业务都能够通用。
而且未来做新的偏电商的产品的时候，我们也不用重新再构建一套系统了。
这样的话我们能极大的节省维护的成本。
还有就是包括很多的研发这样的重复造轮子的工作也可以减少，这样我们就可以提高整个公司的人效，对吧？所以当时在CTO的这个响应之下啊，所以阿里就推出了中台战略。
后来呢全行业各个公司看到阿里推出中台战略，然后他们也开始构建中台，对吧？那么实际上这就是一个非常经典的啊根据公司的战略的目标和组织上的一个方向，在业务的层面开始推进的一个架构性的设计的一个动作。
那么后来呢就是特别最近的时候呀，那个阿里又突然开始讲说，我们可能要去中台。
你看他还开始的时候，他构建中台，然后带着整个行业做中台。
可是现在他又要去中台，他为什么要去中台？是因为各个业务的发展阶段产生了比较大的区别。
啊，比如说拼多多兴起以后，阿里要去追上拼多多的发展节奏，他就要建立一些新的业务线，去跟拼多多去抢市场。
但是老的电商的这个基本的结构和架构模型是不能适用于这种新新的创新业务的，反而拖慢了创新的节奏。
所以我们就需要重新的考虑，把原来的这种通用中台去拆解成各个BU自己去完成自己的闭环，来保证迭代的高效。
这样从而让创新能够变得更容易，能够让新业务发展更快，这样能够抢占新的市场。
所以所有的产品架构的设计，其实都是围绕着业务的变化在发展的。
不知道大家听明白没有啊，那么在第三层其实是服务层，对吧？就是前面讲到是战略层拆组织架构。
业务层呢拆产品架构。
第三层其实就是服务层，拆技术架构。
其实下面可能还有一些层啊，比如说配置层，就是其实我们通称他们其实偏技术这一点。
然后技术架构它跟产品架构它是有关联的。
技术架构的设计设计成什么样子？我们产品架构的上面搭建的时候，我们就会被他制约。
因为最终你的产品的模块怎么拆，你最后是需要技术同学去帮你去拆解出来的。
可是如果他原来的技术架构上已经设计的比较死，你这边就不好动了啊，很多的接口啊，很多的东西你就动不了。
所以往往呢你需要去早一点跟研发同学去沟通啊，我们的技术架构怎么做，我们的产品架构怎么做，拉通一致。
所以这个是我们必须去了解技术架构的原因。
那么讲完了一个公司的架构，有哪几层？一个产品的架构师可能要理解，哪一层以后呢，我们大概了解一下产品架构师的核心的工作是什么？产品架构的核心工作有三点。
第一点，负责搭建部门或者整个公司的产品的基础框架。
啊，这个大家可能能理解啊，就是整个的我们公司的所有的产品的系统，他们是一个什么样的结构啊，都是由产品的架构师来设计的。
那么五到六这个阶段呢，其实我们还谈不上架构。
所以我们一般是从一个单一的功能模块，大概上升到一个系统。
啊，一个六的同学可能开始负责一个小一点的系统，它会有几个产品的功能模块组成。
但是六到七以后呢，我们就要从系统上升到整个这么一个业务流的抽象。
我们要能够抽象出这一个业务里面包含有哪几个系统来支撑他们一个整个的系统结构什么样子的。
那么用户的流向什么样子？资金流向什么样子的，数据流向什么样子的，那么这个是对七的一个基本的要求。
那如果到八到九，那你可能就了解的范围就更宽，或者是思考的深度就更深。
啊。
在这里呢我给大家分享一个特别好玩的案例啊，这是我以前的一个下属的一个情况。
当时呢我们在做的是一个偏交易的平台，然后我从京东挖了一个p七的一个高阶的产品专家啊，然后他在京东呢是负责的商品库和整个交易流的这设计计。
然后以我们对他呢也很认可，因为大厂嘛又比较了解情况，对吧？然后呢，他在做这个商商库库设计的时候呢，他他根据以以前的经验把它设计出来。
比如说啊SKU怎么设计，SU怎怎设计？然后后所有的商品品资包，包括它的资包，包括它的模价格格么定定，然后怎么去回述啊，设设计挺挺好，然他自己呢也很满意。
然后后完了呢拿来了就给我汇报，说老板我们做好了我们的商品库的设计。
然后呢，我就问了他一个问题，我说你做这个商品库的设计之前，你有去跟业务了解，或者是跟业务去沟通吗？然后呢，这个同学就很奇怪的跟我说，他说我为什么要去听那些业务同学的呢？我这个才是专业的设计呀，我是专家呀，我对商品库这种东西了如指掌。
所以我设计的这个东西是代表着业界最先进的水平的。
我还要去跟他们聊，那他们能教我怎么做商品库吗？是不可能的呀，当时我听完这个以后，我就拍脑袋完了，糟糕了。
糟糕的点在哪里呢？因为我们做的业务是一个偏线下交付型业务。
我们的所有的服务的交付是需要有一个非常明确的交付人的close的。
那么电商平台的那个废付，我实际上业赖的是库存，对吧？但是我们的交付我们对库存的管理是特别的技时性或者灵活性的。
我们最终是靠一套呃非常计时性的调度系统在决定那个最后的交付的。
所以当商品库这个东西不能够跟我的业务流相关联的话，我们这个商品库就是废的。
我们没有办法把原来的这个逻辑直接的装到这个商品库里面。
这个商品库的设计是个废的。
这个东西呢，我去跟那个同学沟通了一下，然后我说你现在开始花一个月时间去业务那边，不把业务那个流程搞清楚，你不要再回来。
所以这个同学后来就没有办法，他到了业务那边，反正花了两三周吧，去把那个业务的整个过程搞明白以后，然后回来就跟我讲了一遍，他对业务的理解和业务流的情况，然后重新把他的商品库再迭代了一次。
啊，这个其实就是很多的产品同学，特别是一些产品专家产品架构师会遇到的一个问题。
就是他居然在做一个产品的设计的时候，认为自己把那些模块，把那些过去公司的经验设计的比较好就可以了。
完全无视了真正的在这家公司或者自己真正服务的那个业务上，该如何去支持到业务，如何让他们落地这个东西如果不了解，就很容易出篓子。
那么第二点，关于产品架构师的核心工作是负责定义产品单元模块并且进行分工。
啊，因为呢产品到了气上。
我跟大家讲，其实呢如果你能带人尽量的去考虑一下，怎么呢？如人或者管理一些下属的产品。
那实际上你做管理的过程中呢，你需要跟大家做分工，对吧？那你是架构师，甚至有时候有一些不汇报给你的产品的部门。
因为你是架构师，或者你负责那个整个大的产品的架构设计，所以他们的工作也要依赖于你的定义，哪些模块他来做哪些模块，你来做类似这样。
那你对模块的大小的划分就决定了哪些人为哪些事情负责，哪些研发，又为这些产品的工作去做交付。
那一旦你的模块的分工或者设计这个结构不合理，或者是单元设计的偏大或者偏小，那就会极大的影响到大家的工作。
比如说有重叠的部分，谁也不知道谁来负责，这个就是大忌。
啊，所以产品架构师的一个功利的体现就是能够把模块拆分拆分的比较好啊，这是它的第二个重要的点。
第三个点是什么呢？第三个是负责结合业务思考未来的产品演进路线。
那么我们在做产品的架构设计的时候，我们要充分考虑到每一家公司，它在未来都会发生很多的业务的变化，组织的变化，对吧？刚才我讲到我们很多时候做架构是为了迎合到业务的设计。
那么在这种灵活的变化的过程中，我们怎么保证我们的产品架构做完以后，能够不要因为业务的变化调整呢经常就发生变化。
或者是说我们在有新的方向出来的时候，我们在现有的产品架构上能够兼容到它，能够支撑到它。
那这个就比较考验架构师的一个对行业的理解，对业务的理解的一个基本的东西。
所以呢有的时候我们作为架构师，还要去跟公司在更高层做交流。
特别是在刚才讲战略会的时候，产品的高级人员也可以去讲发表意见，说我们认为组织结构设计上可能怎么样更合理。
那我们产品上怎么支持他们更合理，从而影响到公司对组织的划分。
这样保证我们在产品的设计和划分上能够一直能够响应他们最高效。
那么我这里呢也在举一个特别有趣的例子，大家回去都可以想一想。
比如说最近因为阿里整个又调整了自己的组织的规划，对吧？形成了两个大的事业群，一个是海外的商业发展，一个是国内商业发展。
那大家知道过去呢可能是比如说天猫呀、淘宝这样，那现在都是整合成大的，然后国内国外分开。
另外呢还有比如大文娱这样的单一线，对吧？所以当公司的大的组织大的调整发生了变化。
那我们在公司里负责架构的这些人，这些产品，同学们我们该怎么适应或者迎合到这些大的变化呢？我们该怎么去拆分我们原有的架构模块，然后快速的跟上产品的转升的这个节奏呢？这个希望大家都去好好的想一想啊。
那么在下面呢我给大家讲几个做产品架构的时候，可能需要注意的关键的点。
第一个呢是做产品架构，一定核心围绕的是业务流。
你们公司的业务是怎么流向的那我们的架构基本上是围绕着这个业务流向在设计，我们尽量的去抽象的那些比较核心的稳定的节点，然后把它抽象出来，形成一个固定架构。
然后在这些固定的节点和架构上，我们再去把一些分支的架构在上面设计出热插拔的这种方式。
这样的话，那些经常变的东西，我们用的时候我们就把它插上去。
我们不用的时候，我们就把它卸下来，这样也不影响我的核心业务流。
这样也防止我们的技术分工，对吧？第二个是我们要关心资金流向。
因为在一个公司里面呀，财务口径跟业务口径是完全不一样的。
从资金角度看待产品架构上会造成什么样的账目的情况，极大的影响到公司未来的发展。
比如说上市啊或者是被收购的情况下，这个都很重要。
那么这里呢我给大家也举一个例子，比如说大家知不知道什么是VIE架构？Vie架构是一种财务架构，也是一种公司的架构，它其实主要是为了避税，对吧？一个公司呢在早期它可能到开曼群岛啊或者这样的避税天堂去开一家公司，然后再用这家公司呢控股一家财务公司，再用这家投资或者财务公司去控一个业务公司，从而达到在税务上可能做到合理避税。
那但是当他做这种VIE的架构设计的时候呢，它很可能在业务的控股上，他们把公司拆成了多家子公司。
那么如果从财务口径上，这些科目这些公司都是独立的。
你以为在这家公司里面，比如说你从自己的产品或者技术角度看，你觉得那东西都是一体的。
你很可能会犯大错误。
比如说把一些不同公司之间的资产放到了一个产品模块下，这会导致什么结果呢？会导致你未来上市，或者是未来去跟财务口交代的时候会出现你根本没办法落地的情况，根本不合规或者根本不合法，而且很容易造成诉讼。
比如说利益诉讼啊，或者是你的税务出现问题啊都会出现。
所以我们一定要特别的关心我们的资金流，还有我们的财务口的这种对接。
然后考虑我们在产品架构上怎么设计。
那么第三个呢是关心数据流，所有的公司里面所有的业务，最后它都会抽象成数据。
比如说用户数据业务数据对吧？然后实际上我们在很多时候为什么要搭建公司的产品架构？包括刚才我讲的做中台有一个重要的点，就是为了横向的把各个业务的数据在一个标准上拉通。
就我们听过叫数据中台，对吧？其实这也是架构上的一个设计啊，就是为了让所有的数据汇集到一起。
未来我们可以形成什么？形成用户画像，形成用户的门户，形成这个大数据的应用，对吧？那么在数据流的这个走向上，我们在产品架构设计上千万，要注意数据的统一性、归集以及安全的控制权限的控制。
因为很多的数据它放到一起以后，它不是谁都能看的对吧？然后我们在架构设计的时候呢，我们就要提前的想到这个权限的分权限的设计该如何去控制。
那么这个地方呢也跟大家提醒一下，因为最近国家呢正在推进用户信息的隐私，安全法规的完善。
所以各个公司可能现在都特别重视在产品架构上。
在这个点上设计的如何，我们做产品的架构，就一定要优先的考虑这些事情，防止未来在打补丁。
根据以上的三个视角呢，我们对系统啊其实做的很多事情就是拆分整合这么多的工作，对吧？那么我们做拆分或者整合这样的工作。
那我们其实更多的也要考虑到下面的执行，做这些产品的模块，负责的这些研发呀、产品啊这些人啊，他们的工作的边界，然后尽量保证他们的互补性。
但是同时尽量减少重叠性啊，这也是产品架构是特别重要的一个点。
刚才我已经提到，那么做架构力既然这么重要，那我们该如何提升我们的架构能力呢？其实有这么几个方法啊，第一个是到业务里去提升。
就像刚才我讲的那个京东的PC同学一样，对吧？你必须深入业务，了解业务，你对业务的理解越深，你越能够理解我在架构上怎么设计更合理，这个是相辅相成的一个过程啊。
那么如果你埋着头只干自己的产品工作，或者是因为有一些经验就在那儿拼命的画架构图啊，各种你自己以为的这种结构啊这种东西。
他最后在公司里是没有办法落地的，研发同学也没办法帮你做啊，所以这个是一定要在业务里去提高你自己的架构能力。
然后刚才我也提到呢，产品到了七八以上，你一定要开始带人。
那实际上你要带人的时候，你有一个重要的工作，就是给你下属平工。
你给下面的同学分工的时候，你对业务不了解。
那你在架构设计上不合理，你分工不合理，他们去支撑业务的时候也会出现瓶颈。
他们在接口的时候，也不知道自己这个事情是不是应该他做，或者他如何去支撑别人。
那到最后就会乱成一团。
所以在充分的了解业务的情况下，我们要做好怎么去对我的下属分工，哪些人做哪些模块，哪些人跟哪些人是业务流啊，先到谁再到谁啊，从而最终形成一个整个的架构图，这个架构图才是真正的可用的可落地的。
啊，那么第二呢是在日常的工作中的努力去尝试。
因为今天听课的同学呢很多都可能偏p六以下。
那p六的时候，可能公司还没有要求你做更大的这种公司级或者BU级的架构的设计。
但是你从现在开始可能就要训练自己这方面的意识。
比如说现在你整个负责一个系统或者一个模块多个模块吧。
那你这个时候就要去考虑我的上游模块，我的下游模块是什么样子的。
你要多跟其他部门的产品，其他的这种业务去沟通，通了解整个他们是怎么样的一个流向，他们是一盘棋是什么样子的。
从而慢慢的一点一点的画出你心中那个样子啊，每天都去思考这件事情情，然后慢慢的你就会形成一个对业务的理解，对产品结构的理解，对产品人员分工的理解，对技术底层的理解。
这个理解越深后后，他去架构构果果的有这个机会，让你做的话就是水到渠成的事情情么。
第三呢其实是是从一些行业案例或或者公事发生生的一失失败，总总结经验和教训啊，因为种东西往往往发出出一个事事故告啊，或者是一个新闻出来。
大家知道我给大家举一个我亲身体会的例子。
好了啊，有一年呢我去跟支付宝一个老大去沟通一个业务合作啊，然后呢就坐在那儿听吐吐啊，因为他是一个呃支支付宝的一个特别高阶的产品的架构啊，然后他们讲还一个啥事儿呢？就是早期啊支付宝的账号跟淘宝的账号，他们不是一一绑定的。
因为当时蚂蚁金服独立，所以支付宝独立的去做了自己的一套账号系统。
然后呢，中间因为公司的组织或者架构上的一个设计，所以他们需要保证淘宝的用户在支付宝上能够正常的登录，所以他们就做了一个账作。
所以当你从淘宝去支付宝去支付的时候，你就q出一个新的账户，对吧？然后这样呢，就直接两边做了绑定。
但是反过来呢，因为支付宝本身也是对所有消费者开放的。
所以他允许一个用户去开出多个支付宝账户，他就会导致出现所有的账号系统之间有很多的错综复杂的情况。
比如说一个淘宝账号下绑定了多个支付宝账户，或者一个支付宝下面绑定了多个淘宝账户。
甚至有时候我们发现有的人他注销了自己的手机号以后，对吧？这个手机号可能流转到其他人手上，但是因为支付宝是用手机号登录的，导致就是一个人的淘宝账号下莫名其妙的出现了别人的支付宝账户，这个都会出现。
然后当时他跟我吐槽说，当时的架构师可能没有想的这么远，不知道说未来我们支付宝会对外开放去呃让普通的消费者直接就可以使用。
他们最早以为支付宝只是为了给电商平台做一个支付工具啊，所以这个就是架构如果在早期设计不合理的时候，为未来埋下的坑，他来他们怎么解决的呢？他们花了大量的人力和大量的时间对所有账账号做了一次清洗。
但是这个清洗最终也没有办法完全的解决。
因为支付宝也好，淘宝也好，他们的用户量级已经那么大了，他不可能再去在上面做重构啊，只能修修补补。
所以这个就是一个特特别经典的失败案例。
我们从这个案例中就学到了说，ok那我们未来如果我负责做一个关联账号的一个系统的架构设计的时候，我该如何保证从失情况不要发生？这个就是失失败，吸吸收一个经验。
然后在这节课的最动作，但是大家讲讲两个产品司员问我的问题啊。
第一个问题呢是有一个同学，他们公司的技术的话语权比较强。
所以他就问我，他说如果技术们话语权强，他们的架构设计的比较死。
刚才我讲了是吧，技术架构设计比较死的情况下，他们影响到了我在产品上做动作，该怎么办？其实这个呢是一个特别经典的问题。
因为往往很多公司的c to他们有自己对一个公司业务的理解，所以他们就上来大手一挥，可能就开始做他们自己的技术的架构。
但是有时候忽视了我们在产品上要支撑业务的时候，有一些临时性架构，有一些过程性架构该怎么设计？那这个该怎么办啊？第一呢很多的产品同学觉得自己听不懂技术的架构。
因为比如说技术同学开一个大会，对吧？召集所有人来讲，他们用了更多术语啊，更多的技术的一些底层的东西啊，大家可能因为对技术没那么了解，也听不太明白。
那么最后回来的时候，你问他说这架构合理吗？他也说不上个一二三。
那么其实在这个点上啊，因为研发同学是愿意分享他们自己在架构上的理解的。
所以你们要做的事情呢，不是在大会上去反驳他或者是质问他。
然后呢，你们要尝试先一对一的跟他们聊一聊，说你能不能把你的架构为什么这么设计，你对业务怎么理解？跟我讲一遍，他们很愿意跟你去讲的啊，因为他们自己对自己做的事情是很骄傲的，他们强势嘛，对吧？那么你听完了这个东西以后，你试着从哪理解呢？你不要试着从产品理解，你要试着从业务理解，因为最后产业言殊途同归，你们最后都是为业务服务的。
所以你们在交流的时候一定要拉平认知，一定要在一个频道上对话。
那这个频道就是业务频道，你们要一起讨论说，哎，那我们这个结构怎么设计以后，我们能支持到业务知色比较好。
我们如何理解这件事情的？然后呢，再来影响到他们对整个技术架构上的设计的调整。
因为他们有时候会自己发现说哦，原来我这样设计会影响到我们在上面构建这些系统的时候，没办法让业务跑的更快，那么他们就会默默的把他的系统给改掉。
虽然人家没有说我做错了，对吧？但是他还是会改的，所以这就是跟强势的技术的架构师去沟通的一个基本方法。
啊。
第二个问题呢是有人问我说，那如果我们公司是一个早期一点的企业，那我们公司需要邀请一个比较资深的架构师来帮我们前期做一个架构吗？这样防止我们未来迭代出问题，对吧？那我给他们的回答是说，在一个初创企业里面，因为你的业务的变化特别的快，特别的多。
甚至有时候我们连主业是什么，我们都可能调整了。
那我们在产品的架构上，其实我们有个基本原则，就是你先能跑就行。
我们保证几个基本的系统能够支撑你的业务的功能就可以了。
我们反正未来一定会迭代了，因为前期这些小的投入其实不会太浪费的。
啊，我们没有必要一上来非要做一个大而全的架构。
比如说你做一个小的电商公司，我上来非要让你按照阿里或者京东的那个架构做一个设计。
你怎么保证未来你不会跑成个拼多多呢？对吧？所以这个给的回应就是先不谈架构，先谈功能的支撑，然后等你跑到MVP跑完稳定期了，我们再来谈架构。
以上就是第一例架构力啊。