根据上一本书《如何构建产品架构——第一部分》，我们已经知道了什么是产品架构，以及几种常见的产品架构实体模型。接下来大家需要去实战演练，根据实际的例子来分析。
如何为C类产品构建产品架构
首先，简单详细介绍一下业务流程:
2014年开始升温的O2O领域，早已从表层向深水区快速转型。很多O2O相关的运营模式被认证错误或者快速稳定发展，成千上万的初创企业在这整个过程中起步、落地。除了开设大型商场、休闲娱乐店、线下推广服务店等。，这些都成为O2O网络上的热点，进入家庭的方式也成为一种新的趋势。很多做美甲、按摩、热水泡脚的手艺人都成了流动工作(典型的如海狸之家)。如果说休闲娱乐是指望从商圈总流量中辐射出去的话，那么进入居家服务项目只指望拿下社区这个区域的“银矿”。15年年初，当时企业也恰好看好社区O2O领域(自然老板有相关资源，觉得行业前景广阔)，但社区O2O有一个无法回避的门槛——物业管理。如果有人想努力啃物业管理这块硬骨头，他们仍然有机会获得未来。
所以我们成立了一个小精英团队，先做了一些市场调研，看了一下目前市面上这个社区的O2O产品，得到了一份竞争对手分析报告:
玩了几十个app，大家发现只有少数公司的产品确实向小区业主展示了在线缴纳物管费和停车费的服务，更不用说小区业主可以在线报障、叫保安等服务了。
总的来说，当时的社区O2O还不算火热，还是有机会做出选择的。在开发设计方面，app只有两种，一种是第三方初创公司，意思是“丁咚社区”、“无忧社区”，另一种是房地产商已经有的“住在这里”、“彩云”等应用。
第一类服务平台，如“丁咚社区”，没有基础用户，只靠烧投资人的钱铺路。当时看起来很多住宅小区都被围剿了，但是因为没有基石，随时随地都会把用户带走。不清楚需要多少年才能保证经营规模。到了这个阶段，好像已经破产了，可能钱也烧的差不多了。
第二类使用多卡在供水环节，扮演物业管理互相配合的人的角色。目前还没有找到详细的 *** 作模式。“彩云”能算是出类拔萃，意味着其垂直网站可能成为突破点，与阿里巴巴争夺“最后一公里”。
当时BAT等大佬还在犹豫，没有大的架势。显然，大家都抛开了这块难啃的骨头。
由于企业拥有房地产行业物业管理的相关资源，因此，产品的突破口恰恰位于物业管理公司、物业管理站和物业管理从业人员。然后根据相关住宅小区的示范点，经过认证产品的可行性分析，扩展产品的应用场景，进行车位信息化管理方式，住宅商家的平台——商家进入住宅小区，根据物业管理服务平台投放广告，展示完善的业主委员会在线管理系统服务平台。产品名称暂命名为“安居乐业”。
在产品设计的一系列准备之后，就要开始搭建APP的产品架构了。
结合之前的市场调研，产品最短路径算法，以及我对O2O的了解，整理出我对社区O2O产品架构的整体规划思路。该密钥由四个选项卡组成:
1.社区:负责连接人。这部分可以考虑邻里之间的交流。你不仅可以在这里发布相关信息寻求帮助或者请求交流，还可以找志同道合的隔壁邻居一起做点事情。包括中后期的业主委员会和社区居委会，都可以在这里显示相关信息。
2.物管:负责连接人和物管。这部分是根据移动互联网，提高小区业主与物业管理的连接效率，从而降低物业管理服务成本，提高效率，也提高小区业主的用户服务质量。
3.附近:负责连接人和O2O服务项目。这部分是第三方O2O(如家政、售后维修服务、社区养老服务、社区教育等)的综合表现阶段。)和电商团购价格。根据资源整合，可以完成各具特色的O2O社区便民服务。
4.我的:部门管理所有与“社区主”相关的信息，如“我的报残”、“我的缴费”、“我的课程”如果社区教育是后期做的话。
o2o社区的产品架构
自然，在准备第一个产品版本号的开发设计时，首先要做好两个部分——“物业管理”和“矿山”。也就是说，如果以物业管理为突破口，首先要做好这一点。在中后期相关住宅小区示范点可行后，我们会立即迭代更新产品，再引入其他功能，让产品越来越丰富多彩。
具体分析的话，应该能看出这里架构的逻辑——连接。
这就涉及到对O2O最实质性的理解。它的本质是什么？本质上，O2O就是利用互联网技术来改善客户和服务商之间的连接，让他们之间的连接以更高的效率和更低的成本越来越高。所以整个产品架构都是紧紧围绕连接来做的课程，连接人与人之间，人与物业管理，人与其他服务项目。而对于用户来说，他们对你产品认知能力的逻辑会非常清晰，每次打开产品都能很容易的找到你想要的东西。
让我们试着做一个小小的总结:
1、做好分类。
就像你前面说的，人天生就有收集整理的习惯，这个习惯也是为了更好更方便的找到自己需要的物品。商场的产品植入也是如此。所有的产品必须按照不同的分类放在不同的存储货架上，并在顶部张贴一个相对的标志，告诉用户这是什么产品区。常见的Windows任务管理器也是一个很好的例子。想象一下，如果我们把自己电脑的所有文本文档放在一个磁盘里，而这个磁盘没有一个文件夹名让你分组管理你的文档。word文本文档，不包括文本文档、ppt文档、pdf文本文档、视频文件格式、照片文件格式等。混合在一起，那么您将很难找到所需的文本文档。多亏了Windows任务管理器，我们可以创建文件夹，并根据它们的名称、修改日期、类型、大小等对文档进行排列和分类。，让大家更容易更方便的找到自己需要的信息和文本文档。
同理，网站或者手机app的应用也是一样的。信息越多，就越需要组织和整理。我们可以根据逻辑习惯收集和整理信息。比如上面的例子，是按照社群的O2O“连接”的逻辑分类的；自然也可以马上研究用户的想法，掌握用户的应用习惯。一个好的产品经理通常是这个领域的杰出人士，或者是这个领域的权威专家。因为只有产品经理本人对自己的领域有很深的了解，才能更准确地击中产品架构的脉搏，有时甚至会击中要害。
2.平衡用户和业务服务。
产品架构的设计方案，一方面是掌握用户的信息需求，另一方面也需要掌握所有产品的商业服务目的地和需求。一般情况下，毫无疑问，用户的总体目标和商业服务的总体目标是有差异的。比如用户不愿意看广告，但是公司期望向用户强烈推荐自己的业务流程和广告。如果一个产品只考虑用户的整体目标，产品自然会感觉很好，但是这个产品不会长久。毕竟公司的最终目的是盈利。
这个时候，如何平衡用户和业务服务，就成为考虑产品经理基本功的重要一环。在这些方面，大家一直在向微信官方学习和培训，手机微信在平衡用户体验和商业服务的总体目标上做得很好。还记得2015年1月微信朋友圈的广告吗？当时一经发布，立刻成为微信朋友圈的热门话题。大家都在广告底部争相关注和评价，仿佛知名品牌突然变成了大家身边的盆友，立刻在微信朋友圈和大家分享故事和内容。以社区O2O为例，大家也谈到了附近商家有业务流程和广告特色的功能，放在后面版本号进行迭代开发，而没有马上尝试产品的商业化，这也是一种平衡的反映。
3、设置快速入口的关键作用。
产品架构要结构清晰，尊重事实，让目标明确的用户快速找到所需信息；总体目标不确定的用户，根据自己的访问和搜索，一点一点建立自己的必要信息；没有目标的用户可以在搜索中激发需求。所以对于后两种用户来说，如果关键功能和常用功能隐藏的太深，很可能会对产品失去兴趣。
为关键功能和常用功能设置快速入口，就像在原有的产品结构上设置了一个“便捷安全的通道”。典型的例子有，手机微信将“购物”放在“发现”列表中，手Q的“购物频道”改为“在京东购物”。COM”。JD.COM和腾讯的官方“联姻”是由手机微信和手机上的qq社交媒体渠道、微信朋友圈、朋友圈等组成的。其推广营销构成了JD.COM商城社交媒体购物的多场景绿色生态，聚集了庞大的社群营销总流量，为JD.COM商城产生了众多新用户，提升了交易量。
自然，快速入口的设置也是一个必须衡量的全过程。必要的快速入口可以提高用户的应用效率，也可以考虑产品某种商业服务的总体目标。但如果快速入口太多(尤其是商业服务的通用目标太多)，产品就会越来越无序，越来越复杂。这时候用户的应用效率就会降低，有点因小失大。所以你可以看到手机微信产品并没有按照快捷录入的方式呈现所有的业务流程，只是在“I-wallet”中显示了其他的第三方服务。这样，这种效应隐藏得如此之深，以至于产品的用户无法轻易感受到微信是一个复杂而令人困惑的产品。
如何为B类产品构建产品架构
To-B产品(一般都是后台管理产品)的设计方案很有意思。因为To-C前台接待产品，大家都已经形成了应用的习惯，对其功能有了一定程度的了解，见过足够多的方式，能够创建一定的产品实体模型，非常容易找到可以效仿的参考。但是对于品类tob的后台管理产品，你基本上很少有竞争对手可以参考和效仿。所以在构建产品架构的情况下，规定产品经理要深谙业务流程，磨练PM的竞争优势——业务流程知识储备、结构化思维和有针对性的抽象工作能力。
简单比较，产品架构的复杂程度就像是从弱到强。
设计或 *** 作以下交通工具:
自行车
汽车
机场
火箭外壳
Tai空航天器...
是不是觉得难度系数越来越大，但是产品结构有多复杂大家都知道？其实还是有配套的方式来进行设计方案的。在构建后台管理产品的产品架构的情况下，通常有两个思路可以参考:
1、按程序模块进行分区。
什么是按计划模块分区？如下图:
按程序模块划分
如果一个后台管理产品的整体目标用户单一，用户的需求是统一的，不存在某个用户必须只应用于其中一个程序模块的情况，功能与功能之间没有太多的逻辑顺序，通常可以尝试应用按程序模块分区的方法。比如百度站长工具的统计分析，它的整体目标用户是互联网公司里的运营人员和产品人员，而绝大多数关注运营和产品的数据和信息是可以通用的，换句话说，用户需求是相对统一的。
2.根据域模型进行分发。
分区的另一个逻辑是根据域模型进行分区。许多企业内部信息智能管理系统都采用这种产品架构来执行设计方案。因为这个产品的整体目标用户通常涉及很多角色，不仅仅是企业的业务员，比如销售市场、市场营销、在线客服、前台接待等。，还包括企业工作部门的人员，如人事部门、会计部门、行政部门等。这个时候，选择程序模块来组织后台管理的产品架构，看起来就不那么可用了。
根据领域模型进行分区，规定产品经理在数据管理平台中思考这个系统软件的有效性解决了哪些问题，然后才更实际——哪些用户解决了哪些问题。这个大的自然环境明确之后，在需求收集和分析的过程中，要按照业务流程人物角色进行相关的工作，然后到了整理产品架构这一步才更得心应手。如下图所示，研发管理的一个子系统匹配了这么多不同角色的不同需求。
最后，以下是一些优秀的后台管理产品，供大家参考和学习:
1.淘宝的商家背景
2.有赞商城后台管理
3.微信公众号的后台管理。
好的产品架构有什么特点？
我之前说过，好的产品架构有很多特点:方便、可靠、可扩展性。
方便可靠不需要用文字表达。我们来讨论一下产品架构的扩展性。
扩展性其实就是传递一个信息，就是规定产品经理在设计产品架构的时候，需要更多的考虑这个产品未来是否会在功能或者内容上有所提升，也就是规定产品经理要有产品整体规划的概念。如果一个新做的产品刚刚发布，网页的信息结构会因为增加的功能而再次调整，相关工作人员会怨声载道，产品的应用用户也会提高产品的认知能力和成本。由此可见，产品架构的扩展性至关重要，产品经理必须根据具体情况和未来可预见的整体规划来进行设计思路，力求产品的维护成本最小化。
Ps:限于文章数量，如何搭建产品架构。这篇文章分为上下两篇，比如一件事的内容里就有大量的想法和建议。热烈欢迎你关注我的微信微信官方账号来和我谈交流。
创作者:易百度(微信公众平台:静修集)，在线教育服务企业产品经理，创业团队负责人。我一直以为自己是文艺迷和极客青年的集合，可以在宅与不宅之间自由转换。参与过几款超重量级产品的产品方案策划设计。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）