Deep Dive
Shownotes Transcript
各位播客的听众朋友,你好前段时间产品经理小张找我交流说他接了个需求要上一个新的功能推动起来感觉非常困难新功能本身不复杂业务流程,原型图的设计也不难那为什么很难推动呢?
因为这个功能到底谁来做一直了不清楚这个新功能是 2B 的一个配置端依赖上游业务对象的一些技术信息做一些配置在下游的 C 端去做展示跟好多个产品模块都有关系
小张找自己团队的研发研发说这个模块不该他们做小张又转头去找其他相关的团队也都觉得不该他们做业务上确实有需求也应该去做但是没有人愿意接而且呢大家说的也都很有道理那怎么办呢
我还没来得及谈我的说法小张突然一拍脑袋问我说诶 这是不是一个产品架构问题啊是不是不应该我这个小产品经理去考虑呢是不是应该由架构师来看这个问题呢随着这三个问题的产生啊小张也宣告正式加入了 DB9 的行列之前呢还有他帮着业务去想办法这下他顿悟了也就彻底没人管这件事情了
一个确定有必要的业务需求一个不算复杂的产品功能因为不知道放在哪里而难以推动落地这种看似有些荒唐的现象在各大公司里面比比皆是小张的恍然大悟这是个架构问题到底对不对呢大家经常挂在嘴边的产品架构到底是什么意思呢
产品经理如果未来不做管理岗走专业发展路线是不是只能往架构师的方向发展呢今天我来尝试谈一谈这个还算热门的话题也许能够给你一些启发甚至帮助你走出产品架构的迷雾本期节目分三个部分第一部分讲我对架构这个概念的理解第二部分探讨产品架构的内涵第三部分发散思考
第一部分架构我认为架构就是部分如何构成整体以达成特定的目标他强调的是各部分的结构关系结构关系特别重要同样都是碳元素一种结构产生的是普通的碳而另一种结构产生的是钻石好的架构能够把部分的作用发挥出来形成更有价值的整体
在日常生活当中架构随处可见接下来我会举一些架构的例子以便我们对架构这个概念有更直观更丰富的感受首先声明啊这些例子仅仅只是为了从某一个侧面去体现架构的内涵我没有针对他们一一去做严格的学术考究还请大家见谅近一年我看了很多有关明朝历史的研究著作所以一提到架构的时候呢我最先想到的就是明朝的政府治理的架构
明朝开国皇帝朱元璋因为胡维雍档案彻底废除了宰相这个职位并且还要求子孙后代都不要设置宰相这个职位那没了统领各项事务的宰相统治机器便少了一个关键的部分无法顺畅地运转架构就有问题也就是大家常说的不 work 那怎么办呢
朱元璋将原来中枢省下的六个部门,吏部、户部、礼部、兵部、刑部、工部的级别提上来皇帝直接管理六部工作,六部呢还是内六部但是直接向皇帝汇报,结构关系发生了变化,这便是一种新架构皇帝用这个架构来达成维护明朝统治和皇帝绝对权威的目标
为了加强自己的权力皇帝又额外设置了锦衣卫和东西厂锦衣卫监察一切官民而东西厂还可以监察锦衣卫他们都凌驾于官府之上形成对政府机构的一种制衡这也是一个架构总之呢各个部门有不同的职责与作用部门之间相互配合或者前置最终形成了一套体系去维护皇帝的绝对权威
很有意思啊在废掉宰相亲自捅射六部之后皇帝发现啊自己根本忙不过来他发现这个架构是有 bug 的是不是很像现在某些企业里面老板拍了个脑袋之后发现有问题据学者考据废除宰相只管六部之后皇帝平均一天要批阅 200 份公文
处理过工作邮件的朋友都知道一天 200 封工作邮件远远超过了人的处理极限何况有些公文写的实在是又臭又长就像我们有些管理者的周报又臭又长一样实在是看不过来
为了解决这个问题皇帝又对整个架构做了优化找了一批擅长处理公文的大学士来协助工作其中能力强的经常去文元阁文化殿等宫殿上班被称为内阁大学士后来内阁大学士之中呢又逐步发展出内阁首辅又成了事实上的宰相嘉靖年间的奸相严松便做到了内阁首辅
事实证明朱元璋废除宰相的架构设计是行不通的在法律领域也有架构宪法是最上位最权威的法律往下有民商法刑法经济法等再往下有各种行政法规还有一些地方性的规章制度上位法比下位法的效率更高如果相互冲突以上位法为准
各部分法律各司其职又相互联系成为一个国家的整体法律体系作为法治基础规范人的行为保障社会的稳定与安全这便是法律的架构光有直面的法律也不行立法司法执法等各部分还要配合起来保障法律体系得到有效的应用这也是一种架构
在隋唐时期法律体系叫律令格式律是对违法行为怎么惩罚令是规定大家事情怎么做格呢是对律的补充解释式是官府的办事细则这是四类文件相互补充也是一种架构
在金融领域也有架构,财经博主们经常动不动就提布雷顿森林体系,即将美元与黄金挂钩,规定一美元含金量为 0.888671 克黄金,将国际货币基金会员国的货币与美元保持一个固定的汇率,这样支持整个国际货币体系的运转,以及国际间经济活动的开展。
这一套架构加速了两次世界大战之后世界经济的复苏各国货币都有自己的定位和作用它们相互之间定好一个关系最终以黄金为根本这便是一种架构
财税领域也有架构在 1994 年以前我国的财税体系里中央对地方实行包干制每个地方政府跟中央谈一个上交金额任务维持几年不变如果地方政府的收入超过了这个任务那多的部分可以留在地方的手里
当年经济发展很快上交任务几年一谈根本跟不上经济的变化加上统计数字非常艰难复杂地方与中央的谈判成本也非常高
大量的财税收入留在了地方政府,中央政府的财力不够一些全国性的基建项目都很难拿出钱来总之呢,大家发现这个架构不合理为了解决问题,国家推进了分税制的改革将税收划分为中央税、地方税、中央地方共享税将全国大型国有企业的税收直接纳入中央税快速提升中央的财力
各种税起到什么作用中央与地方怎么分税就形成了税收的架构此外传统的家庭制度之下一夫一妻一个小孩男主外女主内孩子主刻苦读书考大学它也是一种架构但是这种架构不是唯一的也不一定是最合理的相关的话题在最近几年也非常火热此处就不再展开了
从政治经济社会等相对抽象的领域回到相对具体的自然科学领域再举几个例子在生物学的领域人体也有架构人体有九大系统运动系统消化系统呼吸系统泌尿系统生殖系统内分泌系统免疫系统神经系统循环系统它们相互独立又相互联系组成整个人体让人能够持续生存活动
我的胃不太好有一段时间经常胃痛去医院做检查发现胃部没有气质性病变是神经系统的功能紊乱导致了胃痛足以见得这些系统之间有非常复杂的互动关系在每一个系统里还有内部的架构例如消化系统由口、咽、食道、胃、小肠、大肠、肛门等部分组成它们相互配合完成消化系统的功能与目标
在建筑的领域一套房子也有架构例如城市的普通民宅通常有卧室 客厅 厨房 餐厅 厕所等各个子空间贯穿在这些空间里面有上下水 强弱电 燃气等各个系统这些空间和系统各自有自己独特的定位和用途例如我们一般不会把燃气罩装在厕所里面 对吧因为与厕所的定位不符
这些部分连通起来形成整个居住空间支持我们日常的生活起居也是一种架构
回到与产品更相关的计算机科学的领域计算机也有自己的架构也就是冯诺伊曼结构一台计算机包括运算器控制器存储器输入设备输出设备五个组成部分运算器和控制器就是我们常说的 CPU 存储器包括内存硬盘等常见的输入设备包括键盘鼠标摄像头常见的输出设备包括显示器音箱等
这五大基本部件各自独立各有各的功能它们组装起来相互配合形成完整的计算机这个经典架构从提出至今已经过去了快 80 年它依旧是我们计算机的基础架构
把目光投向更底层的哲学领域也有很多架构体系在古老的时代哲学家便尝试了去用朴素简洁的架构解释世界的本源在西方有水火土气四元素说在中国有金木水火土五元素说每个元素各有特点元素之间相生相克最终构成了整个世界这也是一种架构
更现代一点呢在黑格尔庞大的哲学体系里逻辑自然和精神精神中的主观精神客观精神和绝对精神它们相互独立又相互联系也形成了一整套解释世界的架构
可以讲的例子很多很多我不再一一列举了回顾总结这些例子会发现架构有三个要点一有一些组成部分它们各不相同有独特的作用例如力部工部客厅厨房二这些部分相互联系配合形成游击整体例如人体的九大系统计算机的五个部件
三组成的整体最终达成一个目的对于人造物来说例如政府计算机它的目的是人所赋予的是满足人的某一种诉求而对于天然物来说例如生物它的目的是生存延续适应环境具备以上三点就可以说它有一种架构如果有一点不符合就谈不上架构例如我的办公桌上随意放了一堆东西电脑书水杯抽纸帽子
它们各不相同都有作用但是它们没有相互作用形成一个整体便不能说我桌上这堆东西有架构
又例如在周星驰的电影《国产 007》里面我记得达文西发明了一个手电筒有光的时候亮没有光的时候不亮用另一个正常的手电筒去照射这个文西手电筒让文西手电筒亮起来两个手电筒形成了互动关系这是不是一种架构呢显然不是因为他没达到什么目的当然你可以说他达到了无厘头搞笑的目的啊
说起文西手电筒我发现职场上有很多人都是文西手电筒领导盯着自己的时候亮领导不盯着自己灭了我也是打工人实话实说我觉得这样其实也不太好还是得多做一些事情才能学到知识增长能力
再例如,客厅的地面上铺了 20 块瓷砖,瓷砖相互之间有关系,最终达到了装修的目的但是呢,因为这些瓷砖它们的功能没有什么不同,不是不同的组成部分所以也不能说这 20 块瓷砖有什么架构总之呢,不同的部件相互配合形成整体达成一个目的,便是我所认为的架构的内涵
每个架构都有它的目的这也意味着一旦目的变了架构也要发生改变改变可能是某些部分的消失或者出现也可能是部分之间的互动关系发生了变化例如封建时代结束之后政府的目的不再是去维持皇帝的独裁统治所以一些部门消失了一些部门出现了部门之间的关系也发生了变化
在一个企业里面当战略目标与方向变化之后组织架构也会有大的调整相信很多人都经历过当鱼从水里来到岸上它的目的从适应水里的生活变成适应陆地生活之后它会产生新器官旧器官会退化消失也就发生了架构变化
如果部分之间的关系没有发生变化只是某些部分的内部发生了一些调整我们就不能称之为架构调整例如咱们人给自己的头发染了颜色公司里面某一个部门改了名字这都不是架构的变化架构在变化换句话来说就是架构随着环境目标的变化而逐步演进以一个图书馆为例子当它只有一个书架只有 50 本书的时候它很简单
当然它是不是个图书馆另说当他有十万本书的时候为了方便读者借阅图书人们就发明了复杂精细的图书分类方法建设了查阅 阅览 切除还书 播放音视频等功能不同的空间甚至发展出一门图书馆情报学那可能有的听众以前就学这个学科所以呢图书馆也就演进出了更复杂的架构
一家公司也是四五个人的时候和四五千人的时候架构也完全不同架构是演进出来的也就是说我们做任何事情不用上来就搞一个非常复杂的架构
在目标还不清晰没有做到一定规模的时候与其花时间去虚空推演什么架构更完美不如把时间投到落地之行里面去做一段时间明确了自己的目标做到了一定的规模做着做着自己也有感觉了自然就会演化出更复杂的架构
我经常看到一些很荒谬的现象例如从大厂来了一位领导总共带四个人还得分两个小组每个小组还要设置一个组长这就是简单问题复杂化强行搞架构设计他可能会说哎呀这是为以后做大做强提前做准备麻雀虽小五脏俱全嘛说的呢都有道理但是我不认同
我认为除了极少数纯理论性质的哲学体系之外所有的架构都是在实操当中演进出来的不是在脑海当中推导设计出来的我们一定要关注实操
最后再谈一点人为什么总想给事物一个架构呢自然在创造我们人类的时候可没有在我们的身体里面写上这部分是消化系统这部分叫呼吸系统我们为什么要总结出一套架构创造出一堆的词语来认知和解释身边的一切呢这个问题很有深度也特别有意思
我在阅读系列第一期里讲马斯洛需求层次理论的时候提过人追求安全感掌控感希望世界可理解可解释从这个角度看对身边一切复杂事物总结出一个架构来是人的一种安全需要
从脑科学的角度来看人的大脑有优点也有局限性人脑擅长用很低的功耗在数据不足的情况下处理复杂的问题但是人脑没有办法同时处理太多的信息还特别容易疲倦所以人们需要什么呢需要分工合作有的人研究天文有的人研究地理有的人研究政治体制这种研究和工作领域的划分其实就是一种对世界的架构
如果没有架构没有分工我们所有人不可能能开上汽车用上电脑最后呢再介绍一本图尔干的书《原始分类》书中说最初的自然图示的中心不是个体而是社会人们对事物的分类再现了人的分类嗯有一点抽象那我理解呢他大概的意思是人们在原始社会里面就形成了族类之分进而将各种事物啊地点啊去归给不同的族类
族类之间又有敌友方位等等之间的关系进而万事万物就都有了关系人必然形成社会而人也必然在社会化当中形成对万事万物的分类关系的认知所以人必然要产生架构的思维方式这部分说的有点多有点发散希望能够让你对架构这个词语有一些新的理解如果你有不同的观点或者有其他的感受也欢迎通过评论区与我交流
接下来我们快速进入第二个部分吧第二部分产品架构来到产品的领域产品架构无外乎还是上面说的三点不同的组成部分相互配合与互动以组成整体最终达成特定的目的
产品架构中的组成部分我们通常称之为子产品或者说产品模块模块之间的配合互动一般通过通信的方式来实现更具体来说就是接口服务的相互调用不同功能的模块相互配合组成产品其目的是与用户发生一系列的交互为用户提供服务满足用户的需求
借用我在第二期阅读节目中的例子用户和产品的互动就好像跳舞用户走一步产品走一步密切配合跳完整个舞蹈产品走每一步的时候都需要内部各个子模块的默契配合就像人在跳舞的时候需要眼睛耳朵肌肉的默契配合一样一般来说所有产品都有它的架构除非产品的功能极度单一举一个例子
我做了一个记事本 APP 打开只有一个空白页用户只能在这一个页面上去写东西而且只能写纯文本不能插入图片视频也不能新建其他的记事本所以也没有什么目录结构甚至连登录账号都没有那这个产品确实谈不上产品架构不过简单到这个地步它好像也就不能被称为一款产品了就好像我们前面说的 50 本书的图书馆是不是图书馆一样
做了这么多年的软件产品我还真没见过哪个产品谈不上架构还是以刚刚说的记事本的 APP 为例子正常来说它得有登录注册的模块文件管理的模块复文本编辑器模块账号管理模块权限管理模块
用户打开产品先要看到登录注册模块输入账号密码点击登录调用账号管理模块的能力然后进入文件管理模块去查阅自己的文件目录和记事本点开记事本则调起编辑器模块进编辑器之前还要调全线去校验当前登录的账号是不是有全线编辑这个文件如此一来就有了很多模块的划分和模块之间的交互关系就有了产品架构
随着用户提的需求越来越多既有的产品模块的能力要不断增强例如编辑器要支持插入图片甚至能够直接编辑美化图片当然这没有改变整体的架构
也可能会新增模块例如为了支持编辑器内的纠错功能我们新增了一个大语言模型的模块当然这个现在很火热提供错别字检测语法纠错前次用语的诊断建议事实错误的检查等功能并接受编辑器模块的调用产品架构便发生了变化
如果产品经理的脑海当中对整个产品的架构把握得非常清楚则任何需求提过来产品经理只需要思考几秒钟就能够给出结论是要调架构还是只用丰富当前模块的功能心里便很有底
当然模块里面又可以去细分模块里的架构整体的架构不变模块里的架构可能会变具体负责这个模块的产品经理又可以继续去细分去新增模块还是调整模块之间的关系还是怎么做如此一来各个层级的产品经理也能够很好的配合和衔接清晰的产品架构会带来什么好处呢上面其实已经有提到了首先是便于分工合作提高效率
一个复杂产品必然有很多模块也有很多产品经理配合如果架构很清楚每个产品经理便能各自专心研究一个模块效率更高其次也有利于降低管理成本架构清楚了各模块的功能定位很清晰来了需求知道谁承接产品出了问题也容易定位和解决
架构如果不清楚一堆功能乱糟糟堆在一起有的功能一群人做有的功能没有人管那管理起来就很麻烦产品也很难给用户很好的体验听到这里你可能有一点疑惑分工效率管理成本这么说起来产品架构好像和管理很有关系没错这就是我今天要抛出来的一个重要观点我认为产品架构是产品管理的工具
很多初阶的产品经理主要的工作是接需求做功能并不管理产品所以不理解产品的架构一旦开始管理产品就不可避免要回答两个问题第一向内看你的产品分哪几层哪几块它们分别起到什么作用相互之间是什么关系如何配合以达成产品的目标
第二,向外看你的产品周围有哪些其他的产品,你的产品和它们有什么区别,有什么关系,怎么配合,以达成更高一层的目标。这两个问题考察的都是对架构的理解,也是我在面试中高阶产品经理的时候常问的问题之一。
有一些产品经理在简历上写着负责产品的管理甚至负责产品经理团队的管理但是当他被问到这些架构问题的时候经常答不上来那便证明他没做过产品管理或者做了但是完全没做明白我在第二期播客节目里讲产品经理的发展阶段时也说了类似的观点我把产品经理的发展粗略地分为四个阶段潜心练技能向内做思考放眼向外看真正懂业务
前两个阶段都是在做功能到了第三个阶段向外看的时候产品经理对产品内部的各个模块有了深入的理解对自己的产品与其他产品之间的边界定位有了深入的理解才能有产品管理的能力才能明白产品的架构具象来说产品的架构是什么样子的呢怎么表达产品架构呢我们一般通过架构图的方式来呈现产品架构
架构图主要有三个元素一是用户二是产品模块三是交互关系用户一般用一个图标小人表示产品模块用方框表示模块间的交互关系用箭头表示在绘制架构图的时候用户一般放在图的最上方而产品模块放在用户的下方模块很多不能杂乱无章随意摆放它们得有各自的位置也就是定位
从水平视角来看所有模块会处在不同的层级从垂直视角来看所有模块又处在不同的业务域从水平视角看最上层是与用户直接交互的前台产品前台往下是能力层其中的产品模块经常被称为中后台产品前台产品靠近用户要跟着用户跑更加生动有趣但是变化快更新换代也快
中后台产品既要支持前台创新也要在复杂多变的需求中做抽象形成稳定可靠可附用的能力所以中后台产品离用户更远没那么生动有趣但是每天去推演那些严谨的逻辑也很有意思越通用越被多模块调用的产品模块越是在更底层例如前面提到的账号模块在很多很大的公司里面都是底层的产品模块
从垂直视角来看产品可以划分到不同的业务域例如对抖音和快手来说它的短视频和电商就是两个大的一级业务域到了电商领域内流量 营销 核心交易等又是更细的业务域大部分产品模块都分布在这些业务域里面当然也有少数的模块会横跨多个业务域在所有模块之间有复杂的调用关系我们在画图的时候通常从底向上去画那个箭头
表示底层对上层的支撑例如底层的财务产品支持上一层的支付产品再支持上一层的电商产品结合短视频费的流给用户提供看视频买东西的流畅体验这张架构图呢便是我们管理产品的作战地图当我们新增或者下线模块的时候要对着这个架构图考虑对其他所有模块的影响
做产品规划的时候也可以利用架构图来表达新增的模块和箭头可以标个绿色要删掉的模块和箭头标灰色要优化的模块标个蓝色一张图就能把我要做什么事情讲清楚
刚刚我谈到的业务域其实这里面还有一个非常深入的话题就是业务架构决定产品架构产品架构不能虚空生造闭门造车更不应该阻碍业务的发展那由于时间的关系来不及细讲未来有机会再谈吧
一个复杂的产品必然有一个复杂的架构图那我不会画复杂的架构图怎么办呢是不是说明我做不了产品心理呢完全不是也不用焦虑罗马不是一天建成的微信抖音的第一版肯定都比今天要简单特别多也不会有那么复杂的架构图
此外呢我们也不要把产品架构想象成什么玄奥神秘的事情产品架构从杂七杂八的产品工作里来只不过就是要做一些总结体验而已为了帮助你更好的理解产品架构接下来我会虚构一个产品架构演进的例子假定我要做一款软件产品面向有知识储备也愿意帮助别人的独立咨询顾问为他们提供一个工具向潜在的咨询客户去开放时间完成预约咨询
为什么举这个例子呢因为我自己就是目标用户谈起来会更加生动有趣一点这一款产品的架构会是什么样子的呢会怎么演进呢欢迎你跟着我接下来的讲述一起思考
首先先有目的再谈架构我们要先明确产品支持什么用户达到什么目标产品主要支持咨询顾问达成开放时间接咨询的目的当然也要面向咨询者让咨询者能够看到顾问的空闲时间不然怎么去预约呢对吧
按照 MVP 的原则,产品第一期暂时不面向咨询者提供预约的功能因为一旦要做预约就得做库存管理等一些复杂的业务逻辑,投入太大了那第一期产品需要做哪些功能呢?最基础的要有面向顾问的前端注册登录的模块它的底下要有账号模块去提供能力支持
注册登录进来了得给顾问一个个人主页以呈现顾问的基本信息在这个前台模块底下要有后端的顾问档案的模块支持顾问去设置基本信息为了支持顾问开放时间前端要有一个咨询时段列表的模块在底下呢要有一个咨询时段管理的模块作为对应的后台
为了方便用户查看和配置时间我们还需要一个日历的模块到这里一个简单的产品架构就设计好了前台有注册登录顾问个人主页咨询时段列表三个模块中后台呢有账号模块顾问档案模块咨询时段管理三个模块另外还有一个独立的日历模块一共七个模块
这里面做了一个前后台的拆分在产品的初期也许也没那么必要例如前台的顾问个人主页和后台的顾问档案如果严格一一对应也就是说顾问档案里配什么个人主页就显示什么那就没有必要拆开
但是在实际情况中顾问个人主页一定会调其他的后台能力例如个人主页要展示顾问是不是有空闲时间展示出来可能就一句话该顾问未来一个月有三个空闲时段这句话也是跳转咨询时段列表页的一个入口那就需要调用咨询时段管理的模块这个时候前后台拆分就有必要了因为前台这个个人主页并不严格对应后台的顾问档案
模块拆完了需要拿整个用户旅程来做一个校验看这些模块是不是够用能不能配合起来达成目标我们假定顾问已经有了账号他先来到注册登录页输入账号密码点击登录调用后台的账号模块去做校验通过之后进入初始的个人主页
顾问发现个人主页是空白的于是点击进到顾问档案模块去修改档案回来个人主页看到信息已经更新了但是提示尚无开放时段于是又点击进入咨询时段列表页发现确实是空的再进到咨询时段管理模块新增空闲的咨询时段又回到个人主页发现哦有了咨询时段
点击右上角的分享,生成链接发送给他的潜在客户,完成时段的开放。客户点开顾问生成的链接,进入顾问的个人主页,看到未来一个月有一个空闲时段,点击进入咨询时段列表页查看具体的时段,私下联系顾问预约时间。
双方约定之后顾问打开自己的个人主页进入咨询时段列表页再进入咨询时段管理模块有点绕删除该咨询时段以免多人预约整个业务流程就得以完成了
从这个例子里面我们能看出来产品经理在设计产品架构的时候要以用户需求为起点也要以用户需求为终点即先按用户场景业务架构为起点来设计产品架构当设计完了还要回头去验证这个架构能不能支持业务的运转能不能满足用户的需求千万不要跟朱元璋一样一顿设计最后发现不 work
在这个架构里面各个模块有什么能力模块之间有什么关系呢以比较核心的咨询时段列表页为例子要有展示咨询时段进入时段管理两个主要的功能点当用户进入这个页面的时候还得去调账号模块判断当前登录人是咨询顾问才展示进入时段管理的入口
当顾问新增咨询时段的时候还需要调用日历的能力以便用户去选择年月日和小时段并且还要限制时间段不可以交叉等当其他用户访问的时候只有展示咨询时段的功能那这个时段可以用列表展示也可以调用日历的能力放在一个日历上展示这样能够看清时段都在几月几号星期几
日历还要支持切换阅读视图和单天视图在阅读视图上有空闲时段的日期标一个颜色点击展开到单天在单天里面再给空闲的小时段去标一个颜色等等随着用户越来越多大家开始提醒需求了顾问提出来他不希望每次都要手工去删掉那个被预约了的空闲时段他希望能够把所有的时段都保存下来但是去区分它的未占用已占用的状态
他还希望能让客户去点击预约自己接受预约的时候系统自动把对应的时段切到占用状态
产品经理听完一想有道理那这不仅要在已有的模块上面加一些功能还得新增模块这就要调架构了因为预约逻辑特别复杂多人在预约同一个时段的时候只能有一个人预约成功那其他人就会预约失败失败的人可能还需要去收到通知成功的人呢在预约完成了之后可能他还要取消那大概率我们要给顾问和客户去做一个新的预约管理的模块
这个新的模块会和已有的模块发生很多的交互于是就有了架构的调整
再往后顾问觉得自己的个人主页实在是不好看希望在简单的文本之外做一些装修的功能例如补充自己的照片这个时候需要什么呢需要引入一个 CMS 内容管理模块用户可以利用 CMS 的副文本编辑器来创作内容个人中心页面调用 CMS 的能力来实现复杂内容的展示这也是一种架构的调整也得更新产品架构图
再往后面我们发现预约得付定金不然总有人随便预约一大堆的时段给大家造成麻烦于是催生了支付收盈的模块后台便有一堆的财务模块要建设架构又更复杂了
既然做了定金为什么不把咨询本身的支付给做了呢反正都是做对吧于是又更复杂了客户付了款咨询完了之后是不是要对咨询做评价于是又多了评价相关的模块做着做着这个平台便越来越像一套电商的 SaaS 产品了当然也不是只有电商一个方向产品经理调研发现顾问有面向咨询场次的内容管理需求
每一场咨询顾问都可以把相关的内容传上来咨询的录音文字的记录等这些内容可以开放给咨询的客户去收藏下载让客户得到更多的帮助为了实现这个功能产品购买了一个在线会议的模块支持在咨询时段上直接进入会议室然后把会议内容回传到平台把产品往知识库的方向转变
咨询顾问的个人主页便会越来越像知乎的打主的主页而这个产品的架构与上面做成电商的产品的架构又完全不同当然呢在现实世界里面老板很有可能会怎么说呢说这两个方向我们都得做那这个虚构的案例并不完善但是大概也能表现出来产品架构如何随着用户需求和产品发展不断的演变
在现实世界里面这样的演进可能会花很长的时间也许一年也许三年置身在这一年或者三年当中做具体的产品工作的时候我们会发现其实绝大多数的时候我们还是出方案做功能推上线而不是天天对着架构图去做所谓的架构工作
更直白点说产品架构一直在而且一直在演进但是产品架构相关的工作绝不是每天都做只有当我们做大的架构调整版本迭代时才会对着架构图去做详细的规划和讨论
日常各个模块的 UI 的优化交互的调整流程环节的调整等并不涉及到产品架构工作所以呢如果有人说我是产品架构师每天都在处理复杂的架构问题那很大概率上来说是在吹牛
一个好的架构尤其是顶层架构应当具备一定的前瞻性和可扩展性不会每天都改所以我们大部分的时间都在做日常的产品工作它不是个问题但是呢如果我们从来都没有考虑过产品的架构那确实就是问题了我们的脑海中要有架构图要带着架构的思维去做工作不要彻底沉默到日常的细节工作当中去
所以回到一开头的问题一个功能不知道放在哪里合适它到底是不是个架构问题呢准确来说它是一个与架构有关的问题而不是架构本身有问题
可能就是因为产品的架构没有人太明白所以大家不知道把它放在哪里那这个问题是不是应该由架构师来考虑呢如果我们有通盘管理整个产品架构的人确实由他来考虑更合适他不一定要挂了架构师的 title 但是他对整个架构得非常清楚如果没有专业的人那产品部门领导得承担这个职责
实际上我们有些产品领导自己不懂产品又容不下具备全局视野的架构师导致整个团队没有人有架构管理能力就会导致这类问题迟迟得不到解决比这更可怕的是什么呢是领导拍了一个把燃气灶修在厕所里面的方案让产品经理更纠结不做吧交不了差做吧实在是无法认同也是挺惨的
所以怎么办呢最好的解决方案就是自己变强变成那个架构师在这一部分的最后再聊一个小的体会我们做产品啊一开始通常都有清晰明了的产品架构大家协作也很高效但是随着时间的推移人员的变换理解架构的人走了大家又不断在做新的东西做的还很急产品架构就会越来越模糊混乱
这个混乱度增加的过程往往是温水煮青蛙似的今天上一个功能本来应该放在产品模块 A 里面因为时间着急就先单列出来了明天产品模块 B 下了一个功能其他模块受到影响无法运转没办法临时去调产品模块 C 很多类似的小事情当时觉得问题不大积累一段时间回头一看才发现产品架构已经乱七八糟了
在技术领域有一个词叫架构腐化说的也是类似的问题如果感兴趣你可以搜索相关的材料看一看关于架构我再推荐一些学习资料吧在软件开发的领域有一个叫领域驱动设计的方法论简称 DDD 三个 D 字母可以读读看也许有启发读不懂也没关系因为我也没读懂
整个企业的信息系统架构宏观来看分为管理内部资源的 ERP 管客户的 CRM 还有独立的 BI AI 模块等这也是一门专门的学问叫企业信息化有一些教科书也可以买来看看
还有一个理论叫企业 C 架构,即业务架构、应用架构、技术架构、数据架构四个架构也有很多相关的文章与著作可以读一读看当然还有系统论、控制论等也蕴含了架构的思想这些都是理论,很难快速在实际的日常工作当中用到但是可以帮助我们拓宽视野
想要实际上提高自己的产品架构能力关键在什么呢关键还在于动手做更多的产品工作在工作当中抽象总结产品的架构从简单架构到复杂架构逐步提升自己的架构能力
此外,架构其实也不一定是一个岗位,而是一种思维方式与管理能力所以回应开头的问题,产品经理走专业路线是不是只能往架构师的方向发展呢?严格来说不是,不论走专业路线还是管理路线无论最终坐不坐那个架构师的位置,作为产品经理都得有架构思维与能力
第三部分拓展思考终于可以轻轻松松地聊一聊我的一些胡思乱想了说三点吧第一我们初中阶的产品经理不要把架构当作一个垃圾桶遇到自己搞不定的比较模糊的工作就第一时间甩给他说这是架构师的事不是我该想的我们可以想想架构师是怎么来的呢是天生有人就是架构师而我们只能做产品小朋友吗不是吧
如果架构师是成长起来的那为什么不能是我呢就从今天开始就从下一个模糊复杂的架构问题开始我站出来想这个问题并提出我的方案提错了我去改万一提对了呢多做几次我就成了那个架构师凡事要敢做敢犯错错着错着就会了
第二我们对一切事物的架构的理解代表我们认知的高度决定我们最终能够达到的水准我在空闲的时候会看退役的竞技游戏职业选手的直播主播经常会有一些很差的操作堪称下限级按错道具点错方向等但是他的分数很高这是怎么回事呢这是因为他对整个游戏的架构有更深入的理解
普通人看到的只有手头的操作但是在他看来一局游戏在操作之外还有阵容的搭配装备的选择局势的判断对地图资源点位的控制等很多很多的产品模块他的操作可能有问题但是他通过其他的模块弥补了这个模块的不足最终达成获胜这个目标而没有这种架构思维的人眼里只有操作水平也高不到哪里去
我们在职场上打拼也经常看到一些管理者做出下限级的操作但是他们持续地坐在管理者的位置上可能也是类似的道理虽然他操作有问题但是他对工作的架构的认知可能远高过我们我们只看到局部而他看到了更全面的整体当然他对工作的架构的认知可能是个很畸形的甚至他就是完全不行的一个水货
即便如此我们也没有必要去做详细的道德审查我们只需要去取其精华去其糟粕就可以了很多 2B 的大型产品他们的很多细节设计做的其实也不好例如 SAP 啊 Oracle 的一些产品也有一些地方有很灰色难懂的设计和非常离谱的一些交互但是他们整个产品的架构确实非常先进
如果我们对一切事物没有架构上的理解视角总是盯着细节并且在细节上充满抱怨那就很难提高自己的水平我们需要俯下身来每天去做落地的工作但是我们不能永远趴着还得偶尔跳出来去看一看全局第三也是我今天最想讲的一部分我把它放到了最后今年以来呢有一些朋友找我咨询我也提到这一点
多年工作下来我发现人们做事情有两个视角或者说两种思维方式一是流程思维二是架构思维流程思维就是跟单子做任务手上接一堆的事每个事都按固定的步骤也就是 SOP 一步一步的处理
例如产品经理手上并行有五个需求一个带沟通两个产品方案设计中一个开发中一个测试中我们一个一个的做一年做了二三十个需求写到简历上就变成了我在如何写好简历这期节目里面说的大象冰箱式的写法
我的工作是需求调研方案设计推进上线运营迭代等浮于表面泛泛而谈架构思维则不一样我脑海中有一个蓝图产品分几层每一层要实现什么目标又分几个业务域分别支持什么业务场景
我一年做了很多需求哪些是在增强中台的能力哪些是在前台体验上的创新整体做下来产品架构发生了什么变化最终支撑了什么业务目标的达成用流程的思维看事情说的永远是步骤例如我要开一个店第一步选址第二步装修第三步招人在第一步我可能就被卡住了然后就此放弃
我把所有的事情分布在单一的时间线索上面我就成了时间的奴隶用架构的思维看事情时间似乎就消失了我开一家店需要营销能力销售能力产品能力运营能力以及与用户交互的场所我可以先做这个也可以先准备那个我可以自己做也可以找人做只要把这些组件凑齐就像灭霸找齐了手套和五个宝石事情就做成了
我可以先在企业里打工做两年销售把销售能力学到位利用做销售的时候积累的供应商资源和人合伙开个网店卖点小东西学习如何选品如何营销三五年之后我的能力基本全面了做自己的事情便水到渠成用架构思维做事有目标有达成目标需要的组件我就可以灵活处理所有的事情我便不再是时间的奴隶
五一假期的最后一天我在深圳接了一位朋友的咨询他为某个电商平台的下单页面做了很多需求对需求的流程很清楚但是总是感觉自己没有产品规划的能力对自己的发展方向也比较困惑探讨之后呢我提了一个建议他完全可以把产品上面的业务目标与价值划出三个层次
最底下一层是下单流程的跑通让用户迅速进入下一步支付环节提升转化的效率对应到产品上就是调用一堆的能力填充必要的业务字段让流程表单能够提上去往上一层呢是帮助用户自动选择最合适的优惠自动填充常用的地址等还是为了提单但是关注的是用户的体验对应到产品上会做一些新的能力例如优惠组合推荐的能力等
再往上一层呢关注的就不是流程的跑通或者说使用体验了而是通过推荐搭售商品用高频低利润的商品去带动常委高利润的商品加快库存周转提升利润率用产品的能力去提升公司的业绩
产品经理做的所有的事情都可以放到这三层蛋糕上接下来还可以去切蛋糕竖着几刀切开不同的业务域例如标品和非标品切开自营和第三方切开国内和海外切开那我作为产品经理做的所有的事情还可以归到这些业务域里面去在我的大脑里有一个面向业务和用户的分层分领域的产品架构图对着这个架构图做事情我就有了规划能力
一直关注流程先做什么后做什么自然没有规划如果转而关注架构为了达成某个目标怎么分模块模块怎么互动就能化被动为主动从时间的困局中跳出来站在更宏观的视角把事情做得更好
再拓宽一点来看,如果我们把自己的人生当作一款产品,把人生的架构想清楚,家庭职业亲情友情,各个业务域我希望建设哪些产品模块,做到什么程度,他们之间是什么关系,达到什么目的,我们可能就能更主动,更好的去度过我们的一生。
今天的播客节目有点长希望能够对你有一些启发和帮助结尾再打一个小偷广告欢迎加入我的知识星球 ROY 的产品圈子在里面和我问答互动以及约一对一的咨询沟通帮助你开阔新视野获得新感悟如果想要阅读播客的文字稿也欢迎你访问我的微信公众号亲和查试你也可以通过公众号的自动回复与我取得联系我是 ROY 感谢你收听我的播客节目我们下期再会