1.背景

最近由于业务在进行发展，业务规则的复杂度在不断提升，但是由于各个需求都很急，没有人能够从整体架构的角度去考虑问题，所以实现的时候各条线的产品经理往往只顾部分不顾整体；
从部分的角度看问题，需求确实是当前某种程度上的最优解决方案：满足当前需求的成本最低的解决方案，是各条线产品经理基于对于现有业务、系统、资源、时间要求给出的帕累托最优解；（帕累托最优：在一个经济系统中，不损害到其他人的利益而使其中某一部分人的生活变得更好，从这个角度来看，改革开放就是标准的帕累托最优；但是换朝换代的农民起义不是帕累托最优，而是资源的再分配，损害了既得利益者的利益，但是既得利益者也是经济系统的一个部分）。
但是从整体的角度来看，由于长时间的追求部分最优，导致了整体的冗余，系统逐渐变得越来越不敏捷，就算是很小的一个需求，不管是产品设计还是系统实现，均需要耗费很长的时间；

image.png

所以需要重新梳理当前的业务架构、系统架构、数据架构等，在此基础上，从整体的视角去考虑，如何能够通过架构调整的手段，去实现整体的效率提升；
通过明晰产品的架构设计，最终影响到工作的分配，对应产品条线的产品经理只需要了解自己条线的产品规则及交叉模块的产品规则即可快速的推进需求的落地，即使是需要多业务条线接入；
好的架构能够将部分的作用充分的发挥出来，最终形成一个有机的整体。

2.问题

2.1效率的下降

产品的设计需要考量的业务场景过多，由于缺乏整体的视角，需求分析的周期会被拉的特别长；

2.2跨产品条线的需求难以落地

当一个需求被验真，不是一个伪需求，是一个对用户有真正价值的真需求；
但是涉及到产品条线多，需要多产品条线的产品经理共同参与的一个复杂需求时，该需求的落地进度不会特别理想，甚至会有相互推诿的现象发生；
最终除非高级领导挂名负责该项目，否则该需求将会难以落地；
但是高级领导者往往对于细节的把控程度不高，做出的决策可能会有偏差，所以最终导致了跨产品条线的需求落地效果不好、落地速度慢。

3.什么是架构？

3.1架构类型的例举

1.古代的官职
明朝时期因为胡惟庸案废除了宰相的制度，使用皇帝直接统治六部的架构，这就是一种新的架构；
但是由于取消了宰相，皇帝直接进行管理，一天需要处理200多份公文，精力与能力都无法跟上；
所以明朝又设立了内阁大学士，由有理政经验的大臣来辅佐皇帝处理国事；
后来内阁大学士中有能力的大臣，被封为内阁首辅，成为事实上的宰相；
事实证明废除宰相的制度行不通，或许在皇帝有丰富的理政经验、充足的精力、无上的威望、充分的意愿时，这个制度可以行得通；
但是随着朝代的更替，最高统治者的能力参差不齐，制度也就随着时代的变化在不断变更。
2.法律制度
宪法作为最高的法律指导全部的立法工作，是法上之法；
民商法、刑法、经济法等是下位法；
各级行政单位的行政法律法规是更下位的法律；
下位法如果违背上位法，则以上位法为准；
各个法律之间各司其职，却又相互联系，最终形成一个国家的法律体系；
作为法制基础规范全国人民的行为；
3.财经领域
布雷顿-森林体系（各国汇率以美元为基准，美元固定兑换一定比例的黄金）就是一种架构；
规范了全球的贸易、金融规则。
4.传统家庭架构
男主内、女主外、孩子努力学习
5.自然层面-人体的架构
人体的九大系统：
运动系统、消化系统、呼吸系统、泌尿系统、生殖系统、内分泌系统、免疫系统、神经系统和循环系统；
相互独立，又相互联系，组成一个完整的人体；
每个系统内部又有各种器官组成。
6.计算机的架构
冯-诺依曼架构（运算器、控制器、储存器、输入设备、输出设备）；

3.2架构的组成要素

1.有一些组成部分
组成部分之间各不相同，各司其职
2.形成有机整体
组成部分之间相互联系，形成有机整体
3.组成的整体，最终达成一个目的
古代官职——为了可以更好的维护皇帝的统治；
法律体系——为了可以规范全体国民的行为；
财经体系——为了国际之间可以更好的进行贸易、投资；
家庭结构——为了能够更好的应对个体风险；
人体结构——为了更好的适应自然环境的物种竞争。

3.3架构的变更

每个架构都有它的目的，这也意味着，一旦目的变了，架构也要发生改变。（由预存型产品→后付费产品）
改变可能是某些部分的消失或出现，也可能是部分之间的互动关系发生变化。
例如封建时代结束之后，政府的目的不再是维持皇帝的独裁统治，所以一些部门消失了，一些部门又现了，部门间的关系也发生变化。
在一个企业里，当战略目标与方向变化之后，组织架构也会 有大的调整，有的部门被取消，部门之间的管辖关系也会调整。
当鱼从水里来到岸上， 它的目的从适应水里的生活，变成适应陆地生活之后，它会产生新器官，旧器官会退化消失，也就发生了架构变化。
如果部分之间的关系没有发生变化，只是部分的内部发生 了—些调整，不能称之为架构调整。
例如人给自己的头发染了颜色，公司里某个部门改了名字，这都不是架构的变化。
架构在变化，换句话来说，就是架构随着环境、目标的变化而逐步演逬。
以一个图书馆为例子：
当它只有一个书架，只有五十本书的时候，它很简单。
当它有十万本书的时 候，为了方便读者借阅图书，人们发明了复杂精细的图书分类方法，建设了查询、阅览、借书还书、播放音视频等功能不同的空间，甚至还发展出一门图书馆情报学。
一家公司也是一样，4、5个人的时候，和4、5千人的时候，架构也完全不同。架构是演进出来的，也意味着，我们做任何事情，不用上来就搞一个复杂的架构。
在目标还不清晰，没到一定规模的时候，与其 时间虚空推演设计架构，不如把时间投入落地执行。
做一段时间，明确了自己的目标， 做到了一定规模，自然会演化出更复杂的架构。我经常看到一些很荒谬的现象。
例如， 从大厂来了一位领导，总共带四个人，还得分两个小组，每个小组设置一个组长，这就是简单问题复杂化，强行搞架构设计。
他可能会说，这是为做大做强提前准备，也有道理，但是往往与实际脱节。
除了极少数纯理论性质的哲学体系之外，架构都是在实操中演进出来的，不是脑海中推导出来的，我们一定要关注实操。

3.4人为什么要给所有的东西赋予一个架构呢？

人为什么总根给事物一个架构呢？
自然在创造我们人类的时候，可没有在我们身体里写，这是消化系统，这是呼吸系统，我们为什么要总结出一套架构，创造—堆的词语，来认知和解释一切呢？
从马斯洛需求理论来看，人追求安全感、掌控感，希望世界可理解、可解释。
从这个角度看，对身边一切复杂事物总结出一个架构，也是人的一种安全需要。
从脑科学的角度看，人的大脑有优点，也有局限性，人脑擅长用很低的功耗，在数据不足的情况下，处理复杂模糊的问题，但是人脑无法同时处理太多的信息，还很容易疲倦。
所以，人们需要分工合作。
有的人研究天文，有的人硏究地理，有的人研究政治体制，这种研究和工作领域的划分，便是对世界的一种架构。
如果没有架构与分工， 我们不可能开上汽车、用上电脑。（涂尔干的书《原始分类》）书中说 ”最初的自然图式的中心不是个体，而是社会。人们对事物的分类，再现了人的分类"， 大意是，人们在原始社会形成族类之分，进而将各种事物、地点归给不同的族类，族类之间又有敌人、朋友、方位关系，进而万事万物都有了关系。
人必然形成社会，人也必然在社会化中，形成对万事万物的分类、关系的认知，所以人必然产生架构的思维方式。
架构什么？
架构是人类在演化的过程中，逐步发展出的，对于万事万物的分类、关系的认知。

4.产品架构

4.1什么是产品架构

来到产品的领域，产品架构无外乎还是以上三点，不同的组成部分，相互配合与互动以组成整体，最终达成特定的目的。
产品架构中的组成部分，我们通常称之为子产品，或者产品模块。
模块之间的配合互动，一般通过通信的方式来实现，更具体来说，就是接口服务的相互调用。
不同功能的模块相互配合组成产品，其目的是与用户发生一系列交互，为用户提供服务，满足用户的需求。
用户和产品的互动就好像跳舞，用户走一步，产品走一步，密切配合，跳完整个舞蹈。
产品走每一步时，都需要内部各个子模块的默契配合，就像人在跳舞的时候需要眼睛、 耳朵、肌肉的默契配合一样。
—般来说，所有产品都有其架构，除非产品功能极度单一。
举个例子，一个记事本APP：
打开只有一个空白页，用户只能在这一个页面上写东西，而且只能写纯文本，不能插入图片、视频，也不能新建其他记事本，所以也没有目录结构，甚至连登录账号都没有，那这个产品确实谈不上产品架构。
不过，简单到这个地步，它好像也不能被称为一款产品，市场上不存在不谈架构的产品。
还以记事本APP 为例：
正常来说，它得有登录注册模块、文件管理模块，富文本编辑器模块，账号管理模块，权限管理模块。
用户打开产品，先看到登录注册模块，输入账号密码点击登录， 调用账号管理模块的能力；
然后进入文件管理模块，查阅自己的文件目录和记事本，点开记事本则进入编辑器模块；
进编辑器之前还要调用权限模块，校验当前账号是否有权限编辑当前的文件。
如此一来，就有了模块的划分和模块之间的交互关系，就有了产品的架构。
随着用户提的需求越来越多，既有产品模块的能力要不断增强，例如编辑器要支持插入图片，甚至能直接编辑美化图片。
当然，这没有改变整体架构。
也可能会新增模块，例如为了支持编辑器内的纠错功能，我们新增了一个大语言模型模块，提供错别字检测、语法纠错、遣词用语诊断建议、事实错误检查等功能，并接受编辑器模块的调用，产品架构便发生了变化。
如果产品经理的脑海中，对整个产品的架构把握得非常清楚，则任何需求提过来，产品经理只需要思考几秒钟，就能给出结论：是要调整架构， 还是只用丰富当前模块的功能，便能做到心里有底。
当然，模块里还可以细分架构，整体的架构不变，模块里的架构可能要变，具体负责这个模块的产品经理，又可以继续去细分，是新增模块，还是调整模块间关系，还是怎么做。如此一来，各层级的产品经理便能很好配合和衔接。
清晰的产品架构会带来什么好处呢？
上面已经有提到，首先是便于分工合作、提高效率，一个复杂产品，必然有很多模块，也有多个产品经理配合，如果架构很清楚，每个产品经理便能各自专心硏究一个模块，效率更高。
其次，也有利于降低管理成本，架构清楚了，各模块的功能定位清晰，来了需求知道谁承接，产品出了问题也容易定位和解决。
架构如果不清楚，一堆功能乱糟糟堆在一起，有的功能一群人做，有的功能没有人管，管理起来就很麻烦，产品也很难给用户好的体验。
分工、效率、管理成本。
这么说来，产品架构好像与管理更相关？
产品架构到底是什么？
定义：产品架构是产品管理的工具。
很多初阶的产品经理，主要的工作是接需求、做功能，并不管理产品，所以也不理解产品架构。
一旦开始管理产品，就不可避免要回答两个问题：
第一，向内看，你的产品分哪几层、哪几块，它们分别起到什么作用，相互之间是什么关系，如何配合以达成产品的目标。
第二，向外看， 你的产品周围，有哪些其他的产品，你的产品和它们有什么区别，有什么关系，怎么配合，以达成更高一层的目标。
这两个问题考察的都是对架构的理解。
产品经理的发展粗略分为四个阶段：
1.潜心练技能：需求的分析、处理、管理能力
2.向内做思考：我负责的产品模块与其他产品模块的边界在哪里、产品定位是什么、市场上该产品模块是怎么做的
3.放眼向外看：其他产品模块的边界在哪里、产品定位是什么、市场上这些产品模块是怎么做的、模块之间的关联互动关系是怎么样的
4.真正懂业务：真正的业务现实是什么样的、针对业务现实我应该采取怎样的经营策略、为了配合经营策略我应该打造怎样的一套信息化系统
前两个阶段都是在做功能，到了第三个阶段【向外看】时，产品经理对产品内部的各个模块有深入理解，对自己的产品与其他产品之间的边界定位有深入的理解，才能有产品管理的能力，才能明白产品的架构。

4.2产品架构图

具象来说，产品的架构是什么样子的呢？怎么表达产品架构呢？
我们一般通过架构图的 方式来呈现产品架构。架构图主要有三个元素，一是用户，二是产品模块，三是交互关系。
用户一般用一个图标小人表示，产品模块用方框表示，模块间的交互关系用箭头表示。
在绘制架构图时，用户一般放在图的最上方，而产品模块放在用户的下方。模块很多，不能杂乱无章、随意摆放，它们得有各自的位置。
从水平视角看，所有模块处在不同的层级，从垂直视角看，所有模块又处在不同的业务域。
从水平视角看，最上层是与 用户直接交互的前台产品，前台往下是能力层，其中的产品经常被称为中后台产品。
前台产品靠近用户，要跟着用户跑，更加生动有趣，但是变化快，产品更新换代也快。
中后台产品，既要支持前台创新，也要在复杂多变的需求中做抽象，形成稳定、可靠、可重复使用的能力，所以中后台产品离用户更远，没那么生动有趣，但是每天推演逻辑也很有意思。
越通用，被越多模块调用的产品模块，越是在底层，例如前面提的账号模块，在很多大公司就是非常底层的产品模块。
从垂直视角看，产品可以划分为不同的业务域。
例如，对抖音、快手来说，它的短视频和电商就是两个大的一级业务域，到了电商领域内，流量、营销、交易等又是更细的业务域，大部分产品模块分布在这些业务域的里面，也有少数模块会横跨多个业务域。
在所有模块之间，有复杂的调用关系，我们在画图的时候，通常从底往上画箭头，表示底层对上层的支撑，例如底层的财务产品，支持上一层的支付产品，再支持上一层的电商产品，结合短视频Feed流，给用户提供看视频、买东西的流畅体验。
这张架构图，便是我们管理产品的作战地图，当我们新增或者下线模块的时候，要对着这个架构图，考虑对所有其他模块的影响。
做产品规划的时候，也可以利用架构图来表达，新增的模块和箭头标绿，删除的模块和箭头标灰， 要优化的模块标蓝，一张图就能把要做的事情讲清楚。
业务域，其实这里还有一个很深入的话题，就是业务架构决定产品架构，产品架构不能虚空生造、闭门造车，更不应该阻碍业务的发展。
—个复杂的产品，必然有一个复杂的架构图，那我不会画复杂的架构图怎么办？
罗马不是一天建成的，微信、抖音的第一版，都比今天简单很多，也不会有很真杂的架构图。此外，我们也不要把产品架构想象成什么玄奧神秘的东西；
产品架构从杂七杂八的产品工作里来，只不过要做一些总结提炼而已。

4.3产品架构绘制的案例

假定我要做一款软件产品，面向有知识储备、也愿意帮助别人的独立咨询顾问，为他们提供一个工具，向潜在的咨询客户开放时间，以完成预约咨询。

未命名文件.png

4.4架构设计的工作性质

置身在这一年或者三年之中，做产品工作的时候，我们会发现，其实绝大多数的工作还是出方案、做功能、推上线，而不是天天对着架构图，做所谓的架构工作。
更直白点说，产品架构一直都在，而且一直都在演进，但是产品架构相关的工作，绝不是每天都做。
只有当我们做大的架构调整、版本迭代时，才会对着架构图详细规划和讨论。
日常各模块的UI优化、交互调整、流程环节调整等，不涉及到产品架构工作。
所以，如果有人说，他是产品架构师，每天都在处理复杂架构问题，有很大的概率是在吹牛。一个好的架构，尤其是顶层架构，应当具备一定的前瞻性和可扩展性，不会每天都改，所以， 我们大部分的时间都在做日常产品工作并不是问题；
但是，如果我们从来都没考虑过产品的架构，那确实是问题。我们的脑海中要有架构图，要带着架构的思维做工作，不要彻底沉没到日常细节工作中去。
所以，回到一开头的问题：一个功能，不知道放在哪里合适，到底是不是个架构问题呢？准确来说，它是一个与架构有关的问题，而不是架构本身有问题。
我们做产品，一开始通常都有清晰明了的产品架构，大家协作也很高效，但是随看时间的推移，人员的变换，理解架构的人走了，大家又不断做新的东西，产品架构就会越来越模糊混乱。
这个混乱度增加的过程，往往是温水煮青蛙式的：今天上一个功能，本来应该放在产品模块A，因为时间着急先单列出来；明天产品模块B下了一个功能，其他模块受影响无法运转，没办法临时去调模块C... 很多类似的事，当时觉得问题不大，积累一段时间，回头一看，发现产品架构已经乱七 八糟。在技术领域，有一个词叫"架构腐化"，说的也是类似问题。

5.推荐阅读的资料

1.书籍——《领域驱动设计》
2.书籍——《原始分类》
3.理论——企业信息化
整个企业的信息系统架构，宏观来看，分为管内部资源的ERP，管客户的CRM，还有独立的 Bl、AI模块等，如何进行企业内部划分是一个重要的视角。
4.理论——企业4A架构
即业务架构、应用架构、技术架构、数据架构四个架构
要根提高自己的产品架构能力，关键还在动手，做更多的产品工作，在工作中抽象总结架构，从简单架构到复杂架构，逐步提升自己的架构能力。此外，架构也不是一个岗位，而是一种思维方式和管理能力。

6.拓展思考

第一，初中阶的产品经理，不要把架构当作一个垃圾桶
遇到自己搞不定的、比较模糊的工作，就第一时间甩给它，认为这是架构师的事，不是我该想的。我们可以想想，架构师是怎么来的呢？是天生有人是架构师，而我们只能做产品小朋友吗？不是吧。如果架构师是成长起来的，那为什么不是我呢？就从今天开始，从下一个架构问题 开始，我站出来想这个问题，并提出我的方案，提错了我改，万一提对了呢？多做几次，我就成了那个架构师。凡事要敢做、敢犯错，错着错着，就会了。
第二，我们对一切事物的架构的理解，代表我们认知的高度，决定我们最终能够达到的水准。
我空闲的时候，会看退役的竞技游戏职业选手的直播，主播经常有一些很差的操 作，按错道具、点错方向等，但是他分数一直很高，这是怎么回事呢？因为他对整个游 戏的架构有更深入的理解。普通人看到的，只有手头的操作，但是在他的看来，一局游戏在操作之外，有阵容搭配，装备选择，局势判断，对地图资源点位的控制等很多"产品模块"，他的操作可能有问题，但是他通过其他的模块，弥补了这个模块的不足，最终达成获胜的目标。而没有这种架构思维的人，眼里只有操作，水平就高不到哪儿去。我们在职场上打拼，也经常看到一些管理者做出下限级的操作，但是他们持续坐在管理者位置，可能也是类似道理。虽然他操作有误，但是他对工作的架构的认知，可能远高于我们，我们只看到了局部，而他看到了整体。当然，他对工作架构的认知可能很畸形，甚至他就是完全不行的水货，即便如此，我们也没必要去做道德审查，我们只需要取其精华、去其糟粕就行。很多toB的大型产品，它的某些细节设计做得也不好，例如SAP和Oracle的产品，也有很多晦涩难懂的设计，和非常离谱的交互，但是他们产品的架构非常先进。如果我们对一切事物，没有架构上的理解，视角总是盯着细节，并在细节上充满抱怨，便很难提高自己的水平。我们得俯下身，每天做落地工作，但是我们不能永远趴着，还得偶尔跳出来，看一看全局。
第三，产品架构思维方式。
人们做事，有两个视角，或者说两种思维方式，一是流程思维，二是架构思维。
流程思维，就是跟单子，做任务，手上接一堆的事，每个事都按固定步骤，也就是SOP，—步步处理。
例如，产品经理手上有五个需求，一个待沟通，两个产品方案设计中，一个开发中，一个测试中。
我们一个个做，一年做了三十多个需求，写到简历上，就是我在《如何写好简历》节目里说的"大象冰箱" 的写法："我的工作是，需求调硏、方案设计、推逬上线、运营迭代"，浮于表面、泛泛而谈。
架构思维则不同，我脑海中有一个蓝图，产品分几层，每一层要支现什么目标， 又分几个业务域，分别支持什么业务场景。
我一年做了很多需求，哪些是在增强中台能力，哪些是在前台体验上的创新，整体做下来，产品架构发生了什么变化，最终支撑了什么业务目标的达成。
用流程思维看事情，说的永远是步骤，例如我要开一个店，第一步选址，第二步装修，第三步招人，在第一步我可能就被卡住了，然后就此放弃。
我把所有事情分布在单一的时间线索上面，我成了时间的奴隶。
用架构的思维看事情，时间似乎消失了，我开一家店，需要营销能力、销售能力、产品能力、运营能力以及与用户交互的场所，我可以先准备这个，也可以先准备那个，我可以自己做，也可以找人做，只要把这些组件凑齐，就像灭霸找齐了手套和五个宝石，事情就做成了。
我可以先在企业里打工，做两年销售，把销售能力学到位，利用做销售时积累的供应商资源，和人合伙开个网店，卖点小东西，学习如何选品，如何营销，三五年之后，我的能力基本全面了，做自己的事情便水到渠成。
用架构思维做事，有目标，有达成目标需要的组件，我可以灵活处理所有事情，我不便再是时间的奴隶。
电商平台的架构例子
按业务目标与价值划出三个层次：
最底下一层是下单流程跑通，让用户迅速进入下一步支付坏节，提升转化效率，对应到产品上，就是调用一堆能力，填充必要业务字段，让流程表单能提交；
往上一层，是帮助用户自动选择最合适的优惠，自动填充常用地址等，还是为了提单，但是关注的是用户的体验，对应到产品上，会做一些新的能力，例如优惠组合推荐的能力等；
再往上一层，关注的不是流程跑通，或者使用体验，而是通过推荐搭售商品，用高频商品带长尾商品，用低利润商品带高利润商品，加快库存周转，提升利润率，用产品能力提升公司业绩。
我做的所有事情，都可以放到这三层蛋糕上。
接下来，还可以切蛋糕，竖看几刀切开不同的业务域，例如，标品非标品切开，自营三方切开，国内海外切开，我做的所有事情，还可以放到这些业务域里。
在我的脑子里，有一个面向业务和用户的分层、 分领域的产品架构图，对着架构去做事情，便有了规划能力。
一直关注流程，先做什么、后做什么，自然没有规划。
如果转而关注架构，为了达成某个目标，怎么分模块， 模块怎么互动，就能化被动为主动，从时间的困局中跳出来，站在更宏观的视角把事情做得更好。
再拓展一点来看，如果我们把自己的人生当做一款产品，把人生的架构想清楚，家庭、职业、亲情、友情，各个业务域，我希望建设哪些模块，做到什么程度， 它们之间是什么关系，达到什么目的，我们可能就能更主动、更好地度过我们的一生。