早教app的组织架构
经过需求的收集、分析和筛选，对产品定位和用户需求有了更深入的了解，对整个产品方向的把控和版本迭代的节奏会更有感觉。你也可以把这种感觉称为“产品感”。虽然有点模糊，但确实存在。从我个人的经验来看，不断了解用户需求和场景也是积累产品感的好方法。有了好的产品感，还要继续前进，才能把产品推向更高的层次。
产品经理之前已经整理了第一版产品的功能需求，也输出了详细的功能需求清单。这时候要做的工作就是为产品搭建好框架，这是产品设计的第三个环节——取景。任何互联网产品都应该有产品架构。有了这种强大而坚实的架构作为产品的基础，我们就可以一个一个的填充产品需求，让产品变得丰富而立体，更加有血有肉。
到底什么是产品架构，产品经理应该如何构建好的产品架构？我们继续吧。
什么是产品架构？
每个产品都有自己的产品架构(很多人称之为信息架构)。就像每个人都有自己的骨骼系统一样，你骨骼的大小决定了你的大概身材会是什么样。每个人的身材都不一样，高矮胖瘦都不一样。
有些产品的产品结构比较复杂，比如大多数to b产品，比如客户关系管理系统、ERP软件、电子商务网站管理后台、物流管理后台、SaaS软件等有些结构比较轻简单，比如绝大多数的to c产品，比如途游、摩拜单车、直播APP映客、花椒等。，最近一直在玩的，当然还有微信(虽然现在功能越来越多，但大体结构还是简单明了)。
让我们直接看几个例子:
天猫商家后台工作
这是天猫商家的后台。看到左边那排完整的导航菜单了吗？是不是感觉超级复杂？仅门店管理就有10多个二级菜单。梳理淘宝和天猫的电商平台的产品架构真的不容易。不过我也经常好奇，卖家能在这么复杂的背景下，清楚的知道每个功能在哪里。
架构复杂的产品，需要产品经理的能力，这就要求产品经理提供一个功能齐全、结构良好的架构体系，让用户通过操作流程使用各个功能。所以这样的架构的特点就是会带来一定的学习成本，有的甚至需要对产品的用户进行培训(比如淘宝已经开设了淘宝大学和淘宝社区)。这种架构产品的用户群体一般都是聚焦的，只针对某一类人群，需要合理整合海量功能，灵活安排，聚焦核心用户场景。
连萌官方网站
让我们看另一个例子。这是官网，曾经风靡一时的萌脸app的产物。下面我们来仔细分析一下这个官网的产品架构。是不是超级简单，简单到只剩下两个菜单——首页和关于我们？这里需要注意的是，即使是简单的两个菜单(有些官网只有一个菜单)仍然构成了完整的用户体验，因为通过这个框架，网站的目标和用户的需求已经得到了充分的满足。当然，如果你想重新定义网站的目标，或者用户的需求发生了变化，那么你就要准备重新调整产品结构了。
轻架构产品，其目标是为用户提供一个简单明了的信息架构，让用户使用方便，体验流畅。对于产品经理来说，轻架构设计产品的难点在于体验和创新。我们可以通过做产品减法，不断聚焦用户的核心使用场景，让用户轻松上手。当产品的用户量上升到一个新的水平，我们会拓展产品的使用场景，延伸产品架构。
几种典型的产品架构模型
杰西·詹姆斯·加勒特(Jesse James Garrett)在《用户体验要素》(Elements of User Experience)一书中，为我们系统地阐述了互联网产品的几种典型的产品信息架构模型。第一个信息架构模型更符合我们产品经理对产品架构的理解和定位，后三个信息架构模型可以看作是对第一个模型的补充，也可以看作是页面级的信息架构梳理。
第一，层级结构。
层次结构模型
书中原文是这样描述这种产品架构的:“在层级结构中，节点与其他相关节点之间存在父子关系。子节点代表一个较窄的概念，从属关系代表一个较宽的父节点类别。不是每个节点都有子节点，但是每个节点都有父节点，一直到整个结构的父节点。层级关系的概念非常容易让用户理解，软件也倾向于以层级的方式工作，所以这种类型的结构是最常见的。”
这种伞状的产品架构大概是互联网和移动互联网产品中使用最多的信息结构，比如微信和Q，各种to c移动app甚至复杂的to b产品，都是用于产品设计的。这种架构的特点是符合人类的认知习惯，因为人类天生就有整理的习惯，比如书桌，我们会习惯把书放在一起，把录音带放在一边；再比如我们的衣柜。我们有一半人会把不同季节的衣服放在不同的地方。生活中，整理东西是为了更容易找到自己需要的东西。
下图显示了蜻蜓fm早期版本的分层信息架构:
蜻蜓fm的产品信息架构
在使用层次结构时，我们需要注意层次的深度和宽度。
每个人都有逛街的经历。其实有时候做产品和购物很像。有些商场设计合理，可以很容易让用户找到想要的商品类别。有些商场经常让你迷路，来回折腾好几次。在确定产品结构时，考虑产品结构的深度和广度已经成为产品经理的必要课题。以淘宝APP和唯品会APP为例，淘宝属于宽深结构，唯品会属于浅窄结构(相对)。在深度架构中，用户的操作效率不高，用户获取信息和完成目标任务的路径增多，但相对而言，用户选择的入口减少。在部分广度架构中，用户面对的入口更多，在选择入口时比较耗时，但减少了用户的操作路径。
广度和深度的建筑模式
宽而浅的产品架构和窄而深的产品架构各有利弊。使用哪种产品架构，关键是要结合自身产品的定位、业务特点、发展阶段、用户特点、使用场景来进行选择和判断。
第二，有机结构。
自然结构模型
原文描述如下——“自然结构不会遵循任何一致的模式。节点是一个一个连接起来的，这种结构没有很强的分类概念。自然结构非常适合探讨一系列关系不明确或者一直在演变的话题。但是，自然结构并没有给用户提供一个明确的指示，让用户感觉自己处于结构的哪个部分。如果你想鼓励自由探索的感觉，比如一些娱乐或者教育类的网站，那么自然结构可能是个不错的选择；然而，如果你的用户下次需要依赖相同的路径来找到相同的内容，那么这种结构可能会将用户体验变成一种挑战。”
事实上，这种形式的产品架构一般广泛应用于to c的游戏、娱乐、资讯类产品，如优酷视频、好奇心日报等。当然，在很多情况下，自然结构要结合层级结构来考虑。例如，当用户进入网站好奇心日报时，一种可能的使用方法是，用户心中已经有一个明确的信息目标，并希望看到业务最近发表了哪些大故事，因此用户会点击顶部的“所有类别”，选择电影，选择业务板块，然后浏览。还有一种使用方法，就是没有目标，只是从上到下浏览，点击你感兴趣的文章标题。
好奇心日报官网
自然结构非常适合轻架构产品的浏览形式，尤其是to c的娱乐休闲类产品，因为这类产品的目标用户大多以枯燥的方式浏览，没有明确的用户目标，也不需要解决任何具体的任务。
第三，线性结构。
还是看原描述——“线性结构来自你最熟悉的线下媒体。连贯的语言流是最基本的信息结构类型，处理它的装置早已深深植入我们的大脑。书籍、文章、视听、视频都是设计成线性的体验。在互联网中，线性结构常用于小规模结构，如单篇文章或单个主题；大规模线性结构用于限制为了满足用户需求而需要呈现的应用，比如教材。”
说白了，所谓线性结构，就是你用讲故事的方式向用户介绍你的产品，这种方式在产品专题页面和帮助文档的设计中比较常见。其实这部分没什么好谈的。关键是你讲故事或者问题的时候思路是否清晰。很多情况下，这部分工作会由我们的运营同事替我们完成。
金山快线专题页面
上图是金山快盘做的一个活动页面，用线性结构讲故事的方式宣传其“100G空间永远免费”的活动。
第四，矩阵结构(matrix structure)
矩阵结构模型
书中对矩阵结构是这样描述的:“矩阵结构允许用户沿着两个或多个“维度”在节点之间移动。因为每个用户的需求都可以与矩阵中的一个轴相关联，矩阵结构通常可以帮助那些带着不同需求而来的用户，让他们在相同的内容中找到自己想要的东西。
举个例子，如果有的用户真的想按颜色浏览产品，而有的用户只想按尺寸浏览产品，那么矩阵结构就可以同时容纳这两种不同的用户。但是，如果你期望用户将此作为主要的导航工具，那么超过三维的矩阵可能会有问题。在四维或更多维中，人脑基本上不可能很好地可视化这些运动。"
看完上面这段话，你的第一反应是不是想到了下面这个产品设计界面:
淘宝的宝贝详情页
矩阵式信息结构需要将多种信息内容放在一个页面中，因此其重点和难点是如何做好信息分层，使信息更高效地传达给其目标用户。这个问题我们以后再说。
一般来说，产品经理了解这些典型的产品信息架构模型，在后期设计自己的产品架构时，会更加明确自己应该往哪个方向努力。这就好比建筑师在设计房子之前需要有足够的建筑设计知识，其中搭建建筑的框架是必不可少的重要一课。
在具体的工作场景中，大部分产品经理基本分为两类。一个是C端产品经理，负责和普通用户打交道，测试对用户痛点和兴奋点的把握和把握；另一个是B端产品经理，负责和企业用户打交道，测试商业本质和行业战略的思维。那么，如何构建这两类产品的产品架构呢？
如何搭建To C产品的产品架构？
首先简单介绍一下业务背景:
2014开始升温的O2O行业，已经从表层迅速向深水区转变，很多O2O相关的商业模式被验证错误或者发展迅速。在这个过程中，无数的创业公司被创立和倒下。除了商场，吃喝玩乐的商家，线下服务商家等。，居家养老模式也成为新的热点。很多修指甲、按摩、泡脚的手艺人都成了流动工作(比如海狸之家)。如果说吃喝玩乐是期望辐射商圈流量的话，那么上门服务无非是希望获得社区的“富矿”。
15年初，我的公司正好看中了社区O2O行业(当然老板有相关资源，觉得市场前景广阔)。作为社区O2O，有一个无法回避的门槛——物业。谁要是肯下功夫啃财产这块硬骨头，谁就有机会赢得未来。
于是我们成立了一个小团队，先做了一些市场调研，看看市面上的这些社区O2O产品在连接社区居民方面做了哪些服务，得出了这样一份竞品分析报告:
竞争产品分析报告
玩了几十个app，发现只有少数公司的产品向业主提供在线缴纳物业费和停车费，更不要说在线维修和呼叫保安服务了。
总的来说，当时的社区O2O还不是一片红海，还有市场空间和切入的机会。从产品开发背景来说，无非是两类app，一类是以“丁咚社区”、“社区无忧”为代表的第三方创业公司，一类是“住在这里”、“彩云”等开发者自己的移动应用。
第一种平台模式，如“丁咚社区”，没有用户基础，只靠烧投资人的钱来铺垫。当时圈了很多社区，但是因为没有基础，用户随时会被抢走。不知道要用多少年才能大规模应用。目前传闻好像已经倒闭了，估计资本的钱已经烧得差不多了。
第二类应用大多停留在测试阶段，扮演着匹配房源的角色，尚未找到完整的盈利模式。“彩云”可以算是其中的杰出代表，其垂直电商模式或许是与阿里争夺“最后一公里”的突破口。
当时BAT等巨头还在持观望态度，没有太大动作，或者等待创业公司进行投资收购。显然大家都把这块硬骨头放在一边了。
因为当时公司在楼盘物业有相关资源，所以我们团队把产品的突破点定位在物业公司，物业服务站，以及这里的物业从业人员。然后通过在相关小区的试点验证产品的可行性后，将产品的使用场景拓展到车位信息管理、小区商户平台——商户通过物业平台、投放广告进入小区，为成熟的业委会、小区教育等提供线上管理平台。当时产品的名字暂时命名为“安居乐业”，意思是社区的人拥有我们的产品就可以安居乐业。
经过一系列的产品设计准备，就要开始搭建APP的产品架构了。结合之前的市场调研和产品路径规划，以及团队对O2O的理解，我梳理了自己对社区O2O产品架构规划的思考，主要由四个tab组成:
社区:负责连接人。这部分可以满足邻里之间的交流。可以在这里发布相关信息寻求帮助或者交流需求，也可以找志同道合的邻居一起做点事情。包括后来的业委会，居委会等。，您可以在此显示相关信息。
物业:负责连接人和物业。这部分是通过移动互联网提高业主和物业的连接效率，让物业的服务成本降低，效率提高，业主的用户满意度提高。
周边:负责用O2O服务连接人。这部分是第三方O2O(如家政服务、维修服务、养老服务、社区教育等)的综合展示舞台。)和电商团购。通过整合资源，实现各具特色的O2O社区服务。
我的:负责管理所有与“车主”相关的信息，比如“我的报修申请”、“我的付款”、“我的课程”如果以后做社区教育做产品开发的话。
社区o2o的产品架构
当然，对于第一个产品版本的开发，我们计划先做两个部分——“物业”和“矿山”。既然以物业为出发点，那就先把这个做好，在相关小区试点可行后马上迭代产品，再引入其他功能，丰富产品的使用场景。
仔细分析的话，应该能看出框架逻辑——联系。
这就涉及到对O2O最本质的理解。它的本质是什么？O2O的本质其实就是用互联网来改善消费者和服务商之间的连接，让他们之间的连接更高效，更便宜。所以整个产品架构是一个围绕连接的作业，连接人、人和物业服务、人和其他服务，这样对于用户来说，他们对你产品的认知逻辑会非常清晰，每次打开产品，都能很容易的找到自己想要的东西。
在这种情况下，我们试着做一个总结:
1.做好分类
我们之前说过，人类天生就有整理的习惯，这个习惯也是为了更方便的找到自己需要的东西。超市的商品摆放也是如此。所有的商品都需要按照不同的分类放在不同的货架上，并在上面贴上相应的标志，告诉用户这是什么商品区。
我们常用的Windows Explorer也是一个很好的例子。想象一下:如果我们把电脑上所有的文档放在一个磁盘里，而这个磁盘没有文件夹的形式让你分类管理你的文件，word文档，excle文档，ppt文档，pdf文档，视频文件，图片格式文件等等。都混在一起，那么你要找到你需要的文件就太难了。幸运的是，在Windows资源管理器模式下，我们可以创建文件夹，并根据文件的名称、修改日期、类型和大小对其进行排序和分组，这使得我们可以更快地找到我们需要的信息和文档。
同样，网站或者手机APP应用也是如此。信息越多，越需要整理和组织。我们可以按照逻辑习惯对信息进行分类，比如上面举的例子，按照社区O2O“连接”的逻辑进行分类；当然，你也可以直接探究用户的想法，了解用户的使用习惯。一个好的产品经理往往是这个行业的老手，或者是行业专家。因为只有产品经理本人对所从事的行业有深刻的理解，才能更准确的击中产品架构的脉搏，有时甚至一击即中。
2.平衡用户和企业
产品架构的设计，一方面是了解用户的信息需求，另一方面也需要了解整个产品的商业目的和诉求。一般情况下，用户目标和业务目标肯定是有矛盾的。比如用户不想看广告，但是公司希望能够把自己的业务和广告推荐给用户(比如微信朋友圈广告)。如果一个产品只符合用户的目标，产品体验当然会好，但是这个产品也很难走的长远。毕竟企业的最终目的是盈利。
这个时候，如何平衡用户和业务，就成了考虑产品经理基本功的重要一环。在这方面，我们向微信团队学习，微信在平衡用户体验和商业目标方面做得非常好。还记得2015和1在朋友圈的广告吗？一经推出，立刻成为朋友圈的热门话题。大家争相在广告下方点赞评论，仿佛品牌突然变成了我们身边的朋友，直接在朋友圈和我们分享故事和内容。在社区O2O的情况下，我们也是将周边带有商业和广告性质的功能放在后期版本进行迭代开发，并没有马上尝试将产品商业化，这也是一种平衡的体现。
微信广告
3.快速访问重要的功能设置
产品架构要清晰有逻辑，让目标明确的用户快速找到自己需要的信息；目标不确定的用户，通过浏览和搜索，一点一点明确自己需要的信息；没有目标的用户可以在探索中激发需求。所以对于后两种用户来说，如果重要功能和常用功能隐藏的太深，很可能会让他们对产品失去兴趣。
为重要功能和常用功能设置快速入口，就像在原有的产品架构上设置了一个“快速通道”。比如微信把“购物”放在了“发现”的菜单里，手Q的“购物”入口改成了“在京东购物”。COM”。JD.COM和腾讯的“联姻”是由微信和手机QQ的社交应用入口、朋友圈、朋友圈、微信官方账号和广点通组成的。
当然快捷入口的设置也是一个需要权衡的过程。必要的快捷入口可以提高用户的使用效率，满足产品的某些业务目标。但如果快速条目太多(尤其是业务目标太多的)，产品会变得混乱复杂，降低用户此时的使用效率，得不偿失。所以你会看到微信的这个产品并没有通过快捷入口展示所有业务，而是在“I-wallet”中展示其他第三方服务。这样这些功能隐藏的很深，产品的用户就不会觉得微信是一个复杂混乱的产品。
JD.COM微信手机QQ购物两周年庆典
当然，我们在业余时间玩产品的时候，也可以尝试解构一下其他公司的APP产品，看看他们的产品结构是如何搭建的，有哪些值得我们学习和借鉴的地方。这也是很重要的学习方法。
说说我平时的方法吧，分为三步:
拆解产品骨架，将所有模块和功能点绘制成思维导图。
分析关键功能的使用场景和流程。
分析次要功能的使用场景和流程。
当然，在分析产品的时候需要考虑很多因素，不仅仅是从产品设计上考虑，还要从行业背景、公司战略、运营、实际资源等等方面考虑，才能得到更接近真相的答案。
如何为To B产品构建产品架构
To B产品(通常是后台产品)的设计是很有挑战性的，因为大家都培养了使用To C前台产品的习惯，对功能有一定程度的了解，见过足够多的模型，能建立一定的产品模型，很容易找到参照物模仿。而To B的后台产品中几乎没有竞品可供你参考和模仿，所以在构建产品架构时，要求产品经理对业务非常了解，这是对PM核心竞争力——业务知识储备、结构化思维和系统抽象能力的极大考验。不同行业的产品，对整体结构的想法可能不一样。
稍微简单类比一下，产品架构复杂度从弱到强的感觉是这样的——
设计或操作以下车辆:
自行车；自行车运动
汽车
飞机
火箭
宇宙飞船
……
是不是感觉越来越难了？然而，我们知道复杂产品的架构是什么样的。其实还是有相应的方法来设计的。在构建后台产品的产品架构时，往往有两个思路可以参考:
1.按功能模块划分
按功能模块划分是什么意思？如下图所示:
按功能模块划分
如果一个后端产品的目标用户比较单一，用户的需求比较统一，不存在一个用户只需要使用其中一个功能模块的时候，功能之间也没有太大的逻辑关系，可以经常尝试使用按功能模块划分的方法。比如百度移动统计，它的目标用户是互联网公司内部的运营和产品人员，运营和产品关注的大部分数据都是可以通用的，也就是说用户需求是相对统一的。
2.按照业务逻辑划分。
另一种划分逻辑是按照业务逻辑划分。很多公司的内部信息管理系统都是用这种产品架构设计的，因为这种产品的目标用户往往涉及到很多角色，包括公司的业务人员，比如市场、销售、客服、前台等。、以及公司的职能部门人员，如人事、财务、行政等。这个时候用功能模块来梳理后台产品架构就不那么适用了。
按照业务逻辑，要求产品经理在规划系统的时候，要思考这个系统解决什么问题，更具体的说，是哪个用户解决什么问题。在这个大环境下确定之后，在需求收集和分析阶段，按照业务角色进行相关的工作，然后梳理产品结构就会更加得心应手。如下图所示，研发管理的一个子系统，对应了这么多人不同角色的不同需求。
按业务逻辑划分
那么，一个产品经理做a到b的产品，在做业务规划和产品架构之前，需要储备哪些能力？
你需要具备一定的技术理解能力，帮助你清楚地理解信息在不同系统之间是如何交换、存储、耦合和解耦的。
有基本的商业逻辑思维，比如节约成本，增加收入，提高效率。
业务整合需要对行业和业务本身有深刻的理解，也需要对公司的整体运营逻辑有一定的了解，比如销售、市场、财务、运营、产品、技术等。
需要有更强的抽象能力。不仅把一个工作流抽象成一个功能，还要把一个业务抽象成一个系统，知道这个系统在产品中的位置；不是明确任务之间的关系，而是明确业务和业务之间的关系，以及这种关系最终是如何交织和演变的，从而促进产品的繁荣。
最后，下面是一些优秀的后台产品，供大家参考和学习:
淘宝的商家背景
有赞微商城后台。
微信公众平台后台
综上所述，产品架构涉及的范围很广，从产品的宏观规划到产品的功能模块，包括产品的目标和愿景、用户需求、业务需求、数据业务流程和设计框架，还涉及到产品的生态结构，所以建立一个产品框架并不容易。产品经理也要做好在这条道路的学习中进行长时间认知迭代的准备。
好的产品架构有什么特点？
好的产品结构对于一个产品来说是非常重要的东西，就像人的骨架之于人，房子的框架之于房子，起着支撑、导向、承载的作用。回到互联网产品，一个好的产品架构应该具备的几个特征可以概括为:易用性、稳定性、扩展性。
什么是易用性？人天生懒惰。试想一下，如果用户在简单使用产品后，就能记住每一个操作，并能反复使用，不用刻意学习具体操作，用起来一定很“爽”。对于产品经理来说，必须尽力让用户方便地使用产品，这就需要产品架构提供清晰的路径导航，让用户不会迷路等不愉快的用户行为。
什么是稳定？这部分通常与背景的技术架构有关。在产品不断进化迭代的情况下，系统的架构能否承受这么多用户的同时访问，对性能和响应速度有没有影响？所谓稳定性原则，就是你提供的服务必须稳定可靠，能够及时响应需求，尽量避免提示突然失效、服务器异常、空等情况。
易用性和稳定性不再用文字解释。让我们来看看产品架构的可扩展性。
扩展性其实是在传递一个信息，就是产品经理在设计产品架构的时候，要多考虑产品未来会不会增加新的功能或者内容，这也需要产品经理有产品规划的意识。如果一个新产品刚刚推出很久，页面的信息结构会因为需要添加新功能而重新调整，相关人员会有怨言，产品的用户也会增加产品的认知成本。可见，产品架构的可扩展性非常重要，需要产品经理根据实际情况和可预见的未来规划进行构思，力求产品的维护成本最小化。