做了几年产品的你，知道如何搭建产品架构吗（下）
通过之前的《如何搭建产品架构－上篇》，我们已经知道了什么是产品架构，以及比较常见的几种产品架构模型。接下来，我们就要进入到实战阶段，通过具体的案例来解析一下。
to c 类的产品如何搭建产品架构
先简单介绍下业务背景：
2014年开始变热的O2O行业，已经迅速从表层变革进入深水区，很多O2O相关商业模式被验证错误或者迅速发展壮大，这个过程无数创业公司创立和倒下。除了商场、吃喝玩乐商户、线下服务商户等成为O2O热点之外，到家模式也成为一个新热点，美甲的、按摩的、泡脚的手艺人很多都变成了流动作业（典型如河狸家），如果说吃喝玩乐等希望辐射的是商圈流量，那到家服务无非希望搞定社区这块“富矿”。15年初，当时公司正好也看中社区O2O这个行业（当然是老板有相关资源，又觉得市场前景广阔），而做社区O2O，有个绕不开的门槛——物业，如果有谁愿意费力气去啃物业这块儿硬骨头，就能有机会赢得未来。
于是我们就组建了一个小团队，先去做了一番市场调研，看一下市面上的这些社区O2O产品都做了哪些连接社区居民的服务，得出了这么一份竞品分析报告：
竞品分析报告
把玩了几十款APP后，我们发现只有少数几家公司的产品做了向业主提供在线支付物业费、停车费的服务，更别谈业主可以在线报修，呼叫安保等服务。
总的来说，当时的社区O2O还不算是一片红海，仍然有机会进行切入。以开发背景来说无非是两类APP，一类是“叮咚小区”“小区无忧”为代表的第三方创业公司，一类便是开发商自有的“住这儿”“彩之云”等应用。
第一类像“叮咚小区”这种平台模式，没有用户基础，只靠烧投资人的钱来铺地面工作，当时来看是圈了不少小区，但是由于没有根基，用户随时会被抢走，想要做到成规模的应用不知道要烧多少年。目前好像已经倒闭了，估计钱也烧的差不多了吧。
第二类应用大都停留在试水阶段，扮演配合物业的角色，还没找到完整的盈利模式。“彩之云”可以算得上其中的优秀代表了，其垂直电商模式或许可以成为一个突破口，同阿里争夺“最后一公里”。
而当时的BAT等巨头还都持观望态度，没有太大动作。很明显，大家都把这款难啃的骨头放在了一边。
由于公司在房地产物业这块有相关资源，所以，我们将产品的切入点定位在了物业公司，物业服务站和物业从业人员这里。而后，通过相关小区的试点，验证产品可行性后，再将产品的使用场景拓展到进行车位信息化管理、社区商户平台——商户通过物业平台入驻小区并投放广告、为成熟的业委会提供在线管理平台等等。产品的名字暂时就命名为“乐业安居”。
经过一系列的产品设计准备工作，就要开始搭建APP的产品架构了。
结合之前的市场调研及产品路径规划，以及对O2O的理解，梳理了一下我对社区O2O产品架构的规划思考，主要由4个tab组成：
1、社区：负责连接人与人，这个部分可以满足邻里之间人与人的交流沟通，你既可以在这里发布相关信息寻求帮助或需求交换，也可以在这里找到志趣相投的邻居一起去做一件事情。包括后期的业委会、居委会等等，都可以在这里展示相关信息。
2、物业：负责连接人与物业，这个部分就是通过移动互联网来改善业主和物业的连接效率，让物业的服务成本降低，效率提高，也提升业主的用户满意度。
3、周边：负责连接人与O2O服务，这个部分就是第三方O2O（如家政服务、维修服务、养老服务、社区教育等）、电商团购的综合展示舞台，通过整合资源可实现有自己特色的O2O社区服务。
4、我的：负责管理与”业主“有关的所有信息，如”我的报修“、”我的缴费“、若后面做了社区教育，则还可能有”我的课程“等等。
社区o2o的产品架构
当然，第一个产品版本的开发，打算就先做2个部分——”物业“和”我的“，既然是从物业作为切入点，就先把这个点做好，后期在相关小区试点可行后，立即迭代产品，再引入其他功能让产品变得更加丰富起来。
如果你仔细分析，应该可以看出这里面的框架逻辑——连接。
这里就涉及到对O2O最本质的理解，它的本质是什么？O2O本质其实就是用互联网去改善消费者和服务提供者的连接，让他们之间的连接变得效率更高、成本更低。所以整个产品架构都是围绕着连接去做的功课，连接人与人，人与物业服务、人与其他服务，这样对于用户来说，他们对你产品的认知逻辑就会非常清晰，每一次打开产品的时候，都能够轻松地找到自己想要的东西。
我们尝试着来做一点总结：
1、做好分类
前面我们就已经说过一点，人类天生就有分类整理的习惯，有这个习惯也是为了更方便地找到自己所需要的东西。超市里的商品摆放也是如此，所有的商品需要按照不同的分类，摆放在不同的货架上，并且上面还要贴上相应的指示牌，告诉用户这是什么商品区域。我们常用的Windows 资源管理器也是一个极佳的例子，试想一下，如果我们将自己电脑上的所有文档都归存在一个盘里，而且这个盘并没有文件夹的形式让你分类管理你的文件，word文档、excle文档、ppt文档、pdf文档、视频文件、图片格式文件等都混杂在一起，那你想要找到自己需要的文档也则太难了。幸好在Windows 资源管理器模式下，我们可以创建文件夹，并且可以按照文件的名称、修改日期、类型、大小等进行排序和分组，这样才方便了我们更加快捷地找到自己所需的信息和文档。
同理，网站或者移动APP应用也是如此，信息越多，就越需要组织和整理。我们可以根据逻辑习惯来对信息进行分类整理，如上面所举的例子，就是根据社区O2O“连接”的逻辑进行分类的；当然，也可以直接去探究用户的想法，了解用户的使用习惯。一个好的产品经理，往往也是这个行业的资深人士，或者称为行业专家。因为只有产品经理自己本身对所处行业有极深的理解，他才能更准确地命中产品架构的脉门，有时候甚至是一击而中。
2、平衡用户与商业
对产品架构的设计，一方面是要了解用户的信息需求，另一方面也要了解整个产品的商业目的和诉求。一般情况下，用户目标和商业目标之间肯定存在着矛盾，比如用户都不想看广告，但企业又希望能够把自己的业务和广告推荐给用户。如果一个产品只满足用户的目标，产品体验当然会不错，但这个产品也很难走的长远，毕竟企业的终极目标是要盈利的。
这个时候，如何平衡用户与商业，就成为考量产品经理的功底的重要一环了。在这方面，我们向微信团队进行学习，微信在平衡用户体验和商业目标这一块做的非常好。还记得2015年1月份的朋友圈广告么，当时一经推出，便立刻成为了朋友圈的热门话题，大家都争相在广告底部进行点赞和评论，仿佛品牌一下子就成为了我们身边的朋友一样，在朋友圈直接与我们分享故事和内容。而在社区O2O这个案例中，我们也讲周边这种带有业务、广告性质的功能，放在了后面的版本进行迭代开发，并没有立即尝试进行产品的商业化，这也是一种平衡的体现。
微信广告
3、重要的功能设置快捷入口
产品架构应该是结构清晰、合乎逻辑的，让有明确目标的用户能够快速找到所需信息；有不确定目标的用户，通过浏览和寻找，一点点地明确自己需要的信息；没有目标的用户，则可以在探索中激发需求。所以，对于后两者用户来说，如果重要功能和常用功能隐藏地太深，则很有可能会让他们对产品丧失兴趣。
为重要功能和常用功能设置快捷入口，就好比在原有的产品架构上搭了一个“快捷通道”，典型如微信将“购物”放在了“发现”这个菜单里，手Q的“购物”入口改成了“京东购物”，京东和腾讯的“联姻”，由微信和手机QQ社交应用入口、朋友圈、朋友群、公众号、广点通，以及线下推广共同组成了多场景的京东社交购物生态，汇聚了庞大的社群流量，为京东带来了不少的新用户和成交增长。
当然，快捷入口的设置也是一个需要权衡的过程。必要的快捷入口可以提高用户的使用效率，也能满足产品一定的商业目标，但是如果快捷入口过多（尤其是参杂太多商业目标的快捷入口），产品也会变得混乱和复杂，这个时候就会让用户的使用效率下降，有点得不偿失了。所以你会看到，微信这款产品，并没有把所有的业务都通过快捷入口的方式展现出来，而是通过在“我－－钱包”里面，展示其他的第三方服务。这么一来，这些功能隐藏地如此之深，产品的用户就不会觉得微信是一款复杂而混乱的产品了。
京东微信手机QQ购物两周年庆典
to b 类产品如何搭建产品架构
to b 类产品（通常都是后台产品）的设计非常具有挑战性，因为to c 类的前台产品，大家都已经培养起了使用习惯，对功能有一定程度的理解，见过的模式足够多，能够建立起一定的产品模型，也容易找到参照物去模仿。但是to b 类的后台产品，你几乎没有什么竞品可以参照和模仿，所以在搭建产品架构的时候则要求产品经理非常懂业务，非常考验PM的核心竞争力——业务知识储备、结构化思维和系统性抽象能力。
稍微简单类比一下，产品架构复杂程度的感觉由弱到强是这样的。
设计或者操控以下交通工具：
自行车
汽车
飞机
火箭
宇宙飞船……
是不是感觉到难度越来越大了，不过我们也算是了解了复杂产品的架构是怎么样的了，其实依然还是有对应的方法去进行设计的。在对后台产品搭建产品架构的时候，往往有两种思路可供参考：
1、按功能模块来进行划分
什么叫按功能模块来进行划分？如下图：
按功能模块来划分
如果一个后台产品的目标用户比较单一，且用户需求也比较统一，并没有出现说某个用户只需要使用其中某一个功能模块的时候，且功能和功能之间并没有太多的逻辑关系，往往可以尝试使用按功能模块来进行划分的方式。比如百度移动统计，它的目标用户就是互联网公司内部的运营人员、产品人员，且运营和产品关注的数据绝大部分是可以通用的，也就是说用户需求还是比较统一的。
2、按业务逻辑来进行划分
另一个划分逻辑，是按业务逻辑来进行划分。很多公司内部的信息管理系统，都是采用这种产品架构来进行设计的，因为这个产品的目标用户往往涉及到多方角色，既有公司的业务人员，如市场、销售、客服、前台等，又有公司的职能部门人员，如人事、财务、行政等。这个时候再采用功能模块来进行后台的产品架构梳理，则显得不是那么适用了。
按业务逻辑来进行划分，则要求产品经理在规划系统时要思考这个系统的作用到底是解决了什么问题，再具体一点就是——解决了哪些用户的哪些问题。在这个大的环境下确定了之后，在需求的收集和分析的阶段，就应该按照业务角色来进行相关的工作，而后到了梳理产品架构这一步才能更得心应手一些。如下图所示，一个研发管理的子系统，就对应了这么多不同角色人员的不同需求。
按业务逻辑来划分
最后，这里提供几个优秀的后台产品供大家参考和研习：
1、淘宝的商家后台
2、有赞微商城的后台
3、微信公众平台后台
好的产品架构具有怎样的特性
之前就说过，好的产品架构要具备的几个特征：易用性、稳定性、可扩展性。
易用性和稳定性，就不需再多用文字解释了，我们来看看产品架构的可扩展性。
可扩展性其实是在传达一个信息，就是要求产品经理在设计产品架构的时候，就要去多思考未来这个产品是否会新增加功能或者内容，也就要求产品经理要有产品规划的意识。如果一个新做的产品刚上线没多久，因为要新增功能，导致页面的信息架构重新调整，相关人员怨声载道，产品的使用用户也会增加对产品的认知成本。可见，产品架构的可扩展性是有多重要，产品经理需要根据实际情况及未来可预见的规划进行构思，争取将产品的维护成本降到最低。
