产品经理常用3个思维模型+10个技能+3类工具

最近部门有一些新人产品经理加入，在与其交流的过程中发现其产品基础知识不够扎实，故整理以下内容希望能够对其有所帮助。

产品经理是一个产品的总体负责人（原则上如此，但在实际 *** 作中很多产品都是功能性产品，但不管如何我们还是希望给自己一个更高的定位），通过价值分析、需求分析、项目管理以及产品运营等方法使得产品能够为客户提供价值，从而为公司的战略目标的实现提供载体。产品经理需要贯穿整个产品的生命周期，并能够在各个阶段做出正确的决策，保障产品目标的达成。在执行层面产品经理需要能够完成产品开发所需要的各种资料、文档，我们能够把需求通过一定的技术手段转化为可开发的系统功能；在管理层面，我们能够对所有的需求进行优先级的划分，能够更具团队的资源情况制定产品实施计划，能够协调团队中的所有资源为产品目标的实现而努力；在领导层面，我们可以通过专业的分析方法，判断产品价值的真伪，把握整体的产品方向，我们还要能够创造开开放、交流、价值优先的团队氛围，能够让整个团队良性运转。

产品经理是一个离CEO很近的角色，即使我们没有那么高的薪资、权力，但我们需要有CEO的视角去思考产品的问题。产品经理应该是整个团队的中场，产品实现的过程中我们会有很多的任务，每个任务就是一个球，我们能够通过合理的组合、协调把球射进门解决掉，最终让我们的球队赢得比赛；产品经理也是整个产品的第一背锅者，任何产品瑕疵、错误产品经理均需要能够负起责任，并能够直面这种问题，找到方案解决它。

MVP即最小可行性产品，互联网行业是一个高速发展的行业，一起以用户为中心，在这个背景下要求我们能够快速且低成本的识别哪些客户的需求能够大范围推广并获得用户认可。而MVP即是这样一种思维，MVP讲究的是最小可行性，我们需要为用户提供可用的产品，但产品可以是很初级的功能，例如：微信一开始只有文字或语言发消息的功能、滴滴一开始只提供一种打车的模式、淘宝最开始也只有浏览商品并下单的功能。我们在落地MVP思维的时候最怕就是在需求上没有闭环，例如：我们做微信只考虑了发文字、发语音，而没有考虑发消息和接受消息的用户之间的关系，虽然用户最核心的需求只是要一个工具，但是如果我们不考虑这种熟人之间关系的背后逻辑，那么微信也就不可能非常清晰的定位为熟人社交工具；同样滴滴如果只考虑了乘客找车的需求，而没有考虑司机接单和分成模式的话，那么也不可能把完整的打车需求实现闭环。正如网上流传的一张图：

MVP思维中最难的是对“最小”进行准确的定义，很多的产品说是在做MVP，实际实在做一个一个的轮子。

其次，我们要讲下敏捷思维，敏捷是一种开发的思维，其核心是要求团队能够不断的交付价值，并能够快速的应对由于不确定性而引起的需求范围的调整。在开发实施的过程中，我们能够让团队成员充分的理解我们产品的目标、形成良好的沟通氛围还要能够充分的调动成员的积极性使其能够自发的思考自己如何为产品目标的实现做出贡献。一个标准的敏捷开发的工作流程

强调敏捷思维还有一个原因是范围、进度、质量之间的矛盾关系，由于在不确定的环境之下需求范围是不断变化的，而我们在这种不确定性中最好的做法就是在较短的时间能能够不断的交付有价值的产品功能，所以我们使用敏捷开发方式，以固定的时间周期为基准，在团队能够相对固定的情况下，选取最优价值的需求进行开发，以求最大价值的交付。

最后我们要讨论下系统思维，系统思维要求我们在考虑产品设计是需要从结构性、一致性和可扩展性等角度考虑功能的设计，优秀的系统一定是要能够具备演化能力的。人是一个复杂的系统，人体的结构大概可分为如下几个部分：细胞——组织——器官——系统——人体。人体的这种结构能够让复杂的系统得以很清晰的展现，让复杂得以控制，让我们对这种复杂系统进行知识输出时能够条理更清晰，更好的进行知识的传递，也让我们在发现问题时能够快速的找到原因并提供针对性的解决方案。其次我们要让同一个层级的内容保持一致性，混乱制造麻烦，让事物看起来不那么美观，看下如下两种图：

秩序产生美，我们在做产品设计时同样要保证我们功能、交互、视觉以及文案上的一致性，而这种一致性会给用户带来专业以及美的感受，让用户能够感受到我们作为产品设计者的诚意。我们在设计系统时还需要考虑它的扩展性，任何一个系统一定要具备可演化性，在功能设计上我们需要进行业务抽象，能够让我们设计的功能满足更多的业务模式，例如：我们在设计商品模块时把分类、属性、商品、SKU分别进行抽象，商品对象中只保留定义商品所需的最小属性集合，而把不同业务所需的属性设计为单独的分类、属性模块。除了在功能上我们需要预留扩展性外，我们在交互的层面统一需要预留扩展性，多用竖向导航而少用横向导航，属性导航可用空间扩展性更好；列表采用固定高度、固定列以及动态表头的设计，可以很好的满足各种极端情况以及用户需求。系统思维还要求我们能够从局部推导出整体、也能够从整体分割出局部，我们要能够理解在这种局部和整体之间还存在一些其它要素需要进行管理。

聊完了产品经理最重要的一些思维方式后，我们在说下产品经理需要具备的一些关键技能。

在产品经理的日常工作中，我们通过需求调研收集来的需求往往是这样的：

1、我们需要一个小程序，能够在上面卖货

2、我们想要一个好用的电商系统

3、客户在我们平台上下单需要上传一定的资质

4、我们需要在平台上提供账期支付的功能

拿到这些需求之后我们需要进行两步 *** 作：价值分析和需求分析。需求分析，保障我们能够把需求转化成具体的系统功能；价值分析，能够让我们理清楚需求真实的意义或目标。需求分析是不分需求大小均需要进行，而价值分析往往是在项目初始阶段且需求实现所需投入的成本较大时才进行。下面我们先从需求分析开始讲起。

1、需求分析

在需求分析的过程中，我们经常会涉及到以下几个步骤：业务流程分析、用例分析、业务模型分析、功能结构设计、页面跳转逻辑以及页面原型和规则设计。

11 业务流程

业务流程分析主要的目的是弄清楚我们需求中涉及的业务是怎样的，我们需要明确涉及到哪些角色，每个角色在流程中承担什么职责，需要什么要的输入并输出什么东西，还需要理清楚角色之间的关系，常见的业务流程图如下：

一般我们会用泳道的列表示角色，行表示业务的阶段，在这个阶段我们不必考虑系统功能 *** 作是如何完成的，我们关注的核心是业务（业务即指人们为了交付价值或提供服务而开展的工作）

12 用例图

用例分析是我们对角色职责的细化，并能够对角色的职责进行功能化，能够让我们对所需要设计的系统有一个全面的评估，常见的用例图如下：

用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，是从外部使用者的角度看的一种系统蓝图。

13 业务对象分析

对业务我们还需要进行抽象建模，我们能够对业务中涉及的对象进行抽象，并能够描述清楚各个对象的关键属性和对象与对象之间关系，业务建模我们一般从业务需求中抽取名词作为对象，而有些对象则需要我们自己通过逻辑推理设计出来，常见的业务模型分析图如下：

14 功能结构

通过我们对用例和业务模型的分析，我们对整个系统有一个比较宏观的概念，但用例、业务模型都还是一些比较抽象且呈点状功能描述，我们需要把这种点状的描述串联起来，这时候我们就需要对整个系统的功能进行结构化分析，我们一般把以业务对象为核心组织功能，而功能则来源于各个角色的用例，进行分类整理后我们可输出整体的功能结构图，如下：

15 页面跳转逻辑

在有了功能结构图之后，我们需要站在使用我们系统的用户角度考虑，每一个页面、d框是怎样的，以及他们之间的跳转关系，表达这种内容的文档我们称之为页面跳转逻辑图，如下：

在制作页面跳转逻辑时，我们要以使用者的角度出发，能够清楚的知道哪些页面是用户可以可以直接进入的，哪些是过程中必须出现的页面，这张图就是我们用户使用产品的地图。

16 产品原型

最终我们需要输出的是呈结构的产品原型文档，我们需要对每个页面、d框进行详细的设计，我们定义每一个可见的页面中的元素，以及用户 *** 作这个页面或d框之后对系统的影响，我们也需要考虑各个页面的极端情况，例如：无数据、有数据、无网络、 *** 作异常等。我们需要对页面中的每一个元素、用户与系统的每一次交互进行定义并把业务规则梳理清楚

需求分析其核心目的是能够让我们准确、详细的表达我们想要设计的产品，我们需要对我们产品需要完成的目标进行整体的分析，也许对完成目标的过程中的工作步骤进行说明，还需要对过程中的基础条件、限制规则、异常情况处理方式进行全面的考虑，只有如此才能保障我们设计出来的产品可运行良好。

说完需求分析，我们还需要讨论下产品的价值分析，价值分析主要是保障我们目标的正确性，严格来说我们应该是先完成价值分析，在进行需求分析，但价值分析往往属于产品经理较为高阶的技能，所以我们放在后面进行说明。

2、价值分析

任何产品我们都需要投入资源进行开发，那为了保障我们资源投入的产出，我们需要保障我们产品目标的正确性，价值分析就是让我们通过严谨的分析保障我们目标的正确性。

价值分析中我们主要介绍以下几个工具：SWOT、商业画布、竞品分析（商业角度的竞品分析、功能角度的竞品分析）、行业分析（波特五力分析）。

21 SWOT

SWOT是我们做价值分析的一个最常用的工具，我们能够通过SWOT对企业、产品进行全面的分析，SWOT主要从内部的优势、劣势，外部的机会、威胁四个角度对事务进行研究。

优势 ，是组织机构的内部因素，具体包括：有利的竞争态势；充足的财政来源；良好的企业形象；技术力量；规模经济；产品质量；市场份额；成本优势；广告攻势等。

劣势 ，也是组织机构的内部因素，具体包括：设备老化；管理混乱；缺少关键技术；研究开发落后；资金短缺；经营不善；产品积压；竞争力差等。

机会 ，是组织机构的外部因素，具体包括：新产品；新市场；新需求；外国市场壁垒解除；竞争对手失误等。

威胁 ，也是组织机构的外部因素，具体包括：新的竞争对手；替代产品增多；市场紧缩；行业政策变化；经济衰退；客户偏好改变；突发事件等。

22 商业画布

商业画布是创业者创业的一个商业模式设计工具，能够从价值、客户、渠道、财务、资源等能不同方面考虑如何设计商业模式，我们虽然不需要进行商业模式的设计，但商业画布还是可以成为我们理解自己所在公司商业模式的一个非常实用的工具，我们在公司内部能够更好使用商业画布进行分析，通过对公司商业模式的分析我们能够理清公司整体的业务脉络，能够清楚的知道那条业务线重要、那个部门是核心部门、公司产品和核心客群是谁，而这些都是我们在做产品决策时的重要依据。常见的商业画布如下图

包含了九个要素：重要伙伴、关键业务、核心资源、价值主张、客户关系、渠道通路、客户细分、成本结构、收入来源。我们根据所在公司实际业务的情况填入就可对整体的商业模式有一个初步的评估。

23 竞品分析

竞品分析一定是产品经理最常做的工作之一，但竞品分析也是最难做的工作之一。产品经理常做的竞品分析分为两大类：商业角度的竞品分析和功能角度的竞品分析。商业角度的竞品分析能够帮助我们理解竞争对手公司的战略，并找到与竞争对手竞争的策略。我们需要从竞对的发展过程、产品形态、商业模式、核心客群、财务情况等方面进行全方面的研究，而这些研究的资料主要的来源渠道可以是百度、企业网站、企业财报以及第三方研报机构（提一下鲸准是个很好的第三方机构），最终我们能够清楚的了解竞争对手它发展的每个阶段所采取的策略、重点打造的产品以及获得的收益。而功能角度的竞品分析则是我们大部分产品必备的技能之一，互联网或软件行业发展了这么多年，基本上很难再有巨大的功能创新，更多的是功能的改良，所以我们自己在设计产品时如果对需求把握不准，那么做一次功能角度的竞品分析一定能够让我们找到很多灵感。而这种竞品分析需要我们直接使用竞品的产品功能，完全把自己当作竞争对手的客户去使用产品，我们需要理解这个产品功能实现的目的、逻辑、效果以及用户使用的心态，而且我们需要同时使用多个竞争对手相似的产品功能，只有通过这种大量的体验、对比才能加强我们的产品感，让我们能够设计跟符合用户使用体验的产品。

24 行业分析

最后我们再简单聊下行业分析，通过行业分析能够让我们清楚的了解所在企业的定位，也能够清楚的知道企业未来发展的前景如何，是否能够设计一些创新的产品帮助企业获得提升。行业指的是能够提供相似的产品服务的机构及业务的总称，同一个行业中的企业生产的产品、服务具有很强的替代性。所以我们可以从自己所在企业提供的产品、服务的角度定义所要分析的行业。然后我们需要对整个行业的发展过程进行梳理，能够清楚的知道当前这个行业所处的阶段，一般一个行业主要分为如下四个阶段：创业期、成长期、平台期、衰退期。在不同的时期我们需要使用不同的竞争策略。同时我们还需要清楚我们所处的行业的特性，对于不同特征的行业也会影响我们的竞争策略。

对行业的分析还有一个使用特别广泛的工具：波特五力分析，这个模型认为，所有的竞争的规则都包括在五种竞争力量内， 这五种竞争力就是企业间的竞争、潜在新竞争者的进入、潜在替代品的开发、供应商的议价能力、购买者的议价能力。这五种竞争力量决定了企业的盈利能力和水平。

脑图工具是一种帮助思维结构化的工具（又称思维导图），脑图工具天然具有层级性，能够帮我们快速的理清事物的结构。在确定一个主体或问题后，我们可以从不同的维度对其进行分解，常用的维度划分方法有：时间/步骤、相同性质的分类、人物/角色、系统结构或其他常用的分析模型。脑图工具用途十分广泛，以下我们主要介绍脑图工具在产品工作中的使用场景。

产品的功能结构分析，任何一个产品它都是成结构性的，从上往下依次可分为：产品-模块-菜单-页面-功能（字段），这种结构天然适合使用脑图进行表达。脑图除了能够提供结构性的表达方式，在这个工具中还提供了很多的关联、标签、注解等功能，能够让我们不局限于一个维度的结构梳理，而可以进行跳跃式、多维度的结构梳理。常见的脑图工具有：xmind、幕布、百度脑图、MindManager、亿图等，现在也有很多综合性的工具能够提供脑图功能，例如：印象笔记、ProcessOn、石墨文档、语雀等

流程图工具一定是产品经理最常用的工具之一，通过这一类的工具我们能够会支持业务流程图、用例图、业务模型图等，流程图工具一般都提供

原型工具没什么好说的，使用最广泛的一定是axure，其功能之强大亦不须我在多言语，而近些年对于移动端的产品原型设计也有许多特定工具，例如：墨刀、xiaopiu等，其体验也是愈来愈好了，简单容易上手，但对于较复杂的系统（企业级）还是使用axure更好。

至于其它的像是word、excel、PPT等文档工具自然不必多说，特别是PPT的使用是我们通往更高阶产品的必备技能。总体来说工具是为了提高我们的效率，我们千万不要让工具限制我们的想象力，也不能因为工具而影响我们的产出。工具如果影响我们的工作效率，那么我们还不如放弃使用工具，转而使用最原始的纸和笔。

在最后，还需要着重强调作为一个产品经理我们必须要具备良好的沟通表达能力、快速的学习能力以及自主调节心态的能力。这三种能力是产品经理最底层的能力，若不具备这三种素质基本上是不可能在产品岗位做的长久、拔尖的，而大部分时候这三种能力是不可习得的。

以上是我们对产品经理需要掌握的技能的一个汇总，产品经理是一个复合型岗位，其门槛之低、上线之高是绝大部分岗位不能比拟的，但是在产品经理发展到当前这个时期也基本上处于一个平台期，竞争相当激烈，阶层也逐渐固化，低阶的产品经理想要突破上升的通道越来越窄，而顶尖的产品经理会有更多的资源让其做出更伟大的产品。

您好，根据我们的开发经验，想要搭建直播平台，有很多种办法，可以借助直播源码实现、可以召集人马自主开发、可以外包定制开发，不同的解决方案所需资金是不同的。

1、目前较为常用的直播平台搭建方法是借助直播源码进行搭建，这种方法的优势是节约时间和资金，成品的直播系统源码可以被直接搭建部署到服务器上进行运营，也可以通过二次开发增减功能和改变机制，是性价比较高的搭建方式，通常直播源码只需8w即可拿下。

2、如果资金充足，也可以委托外包公司进行直播软件纯定制开发工作，这种方法的优点是每一个细节都尽在运营方的掌控之中，缺点是对接需求麻烦、价格昂贵，15-40w都有可能

3、第三种方法是自主开发直播平台，这需要召集一些技术，起码有后台、IOS和Android三端技术、还要召集产品经理、测试人员和运维人员，这些人员可以借助国内服务商提供的互动直播服务及各功能SDK服务，自行搭建直播系统，这能够大大缩短工期，但这种方法的缺点在于，这些服务往往会有“捆绑”要求，比如用某家的直播服务就必须用他家的CDN等，从长期运营的角度来看，这种方法并不划算。

以上就是我对本问题做出的解答，有需要的话可以继续追问我

在IT公司里，大数据部门的成员，一般可分为4种：（以房子为例）

先用一张图，帮助大家理解一下～～
出道题目，我们公司的大数据部门，目前有这些岗位，你能一一推测出他们的所在位置吗？
数据应用工程师、数据可视化工程师、数据可视化设计师、数据平台工程师、算法工程师、数据分析师

建房子地基（埋在地下）的那群人
他们就是 平台组/架构组 的那群人，他们负责搭建一套大数据的平台架构体系。一般你肉眼看不到他们的产出，但是当某一堵墙壁歪了的时候，或者你进屋打水但水龙头却流不出来水的时候，你就会意识到他们工作的重要性。
平台组的常见发展路径 ：
平台初期，很多公司会用自己的服务器搭一个 私有集群 ，将数据维护起来，开始构建数据平台的第一步。这个，也是原始的大数据平台。（当然，现在有很多公司也是直接上云服务器）
当平台进入高速发展期，考虑到不断扩充的数据量和服务器的维护成本上升，很多公司会迁移平台到 云服务 上，比如阿里云，华为云。云服务的选择要解决的是选择平台所提供的服务，成本，数据通道的维护。我们公司目前正处于这一阶段，选择了云服务。当前，经过考量也正在由阿里云迁移到华为云
还有一个阶段，你发现云服务的费用太高，虽然省了你很多事，或者是考虑到敏感数据的安全问题（当然，私有集群也不是百分百安全），然后又开始往 私有集群 迁移。这时候，鉴于数据规模，你大概需要一个靠谱的团队，设计网络布局、设计运维规范、架设监控、建立机房，值班团队走起724小时随时准备出台。
至此，产生了平台组，真的大数据平台来了 。

建屋子（砌墙盖瓦）的那群人 ：
应用组 的那群人，他们负责建设各类系统/应用。他们搬砖砌墙，建好房子，还要铺设各类管道线路，把地基里面的数据抽出来，放在房子里，让用户们推开门就可以享用。
应用组，有哪些应用？ ：
这块不太好讲。不过，为了尽量让大家看懂，用 从大到小的思路 尝试下：
在整个社会层面，大数据已应用于各行各业，比如：金融行业/地产行业/零售行业/医疗行业/农业/物流行业/城市管理等等……有哪一个行业，可以脱离数据而生存？有哪一个行业可以不依赖数据而发展？
那么，在一个企业中，数据必然是无法避免的会应用到，不管是1个员工的皮包公司，还是10万员工的跨国集团。so，我们来讲讲具体有哪些应用呢？
一般而言，数据应用分为3类：分别是面向企业内部， 面向企业外部以及面向用户这三种。

这里，鉴于今天的主题，我们只讲 面向企业内部 的大数据应用。
进入正题了：
企业内部产品中，可以从2个角度来看待具体有哪些应用：

策略类 的方向较多，常见的有：

这些有时候会有部分或全部不划在大数据部门下面，但都需要比较规范的数据基础，以及着重与利用数据分析调整产品策略。

做企业内部的大数据应用产品，常常有些心酸的地方：

屋子里面的人 ：
产品组 的那群人，主要是一群产品经理（我们公司，目前就半个，由一个分析师兼职着，所以，我们公司没有产品组哦），负责数据类的应用产品设计。他们和上面建房子的工程师们，是紧密的团队关系。鉴于上面对数据应用产品已做了很多阐述，关于他们工作产出的应用具体有哪些，这里就不再赘述。
讲一讲， 数据产品经理 的从业人员得有几个素质：

屋子外面的人 ：
分析组 的那群人，一般会有3类：数据分析师、算法工程师 （类似数据挖掘） 、数据科学家 （我们公司没有） 。他们工作的日常：为你提取一份EXCEL数据、制作一张报表数据、用算法模型分析一个问题、训练出一套算法模型等等工作，但不局限于此。
他们常常需要与各个部门打交道，接待很多业务的数据需求，与业务关系紧密。在一些公司，分析组不一定都设置在大数据部门下，他们可能分散在不同的业务部门，为各自部门服务。但是，他们终究也是需要从大数据平台来获取所需的业务数据，做分析处理，得到相关结论～
据我所知，我们公司的业务部门，（好像）也是有自己的分析人员。
简单概括一下这些职位的特点：
数据分析师
业务线，负责通过数据分析手段发现和分析业务问题，为决策作支持。
算法工程师/数据挖掘工程师
偏技术线，负责通过建立模型、算法、预测等提供一些通用的解决方案，当然也有针对某业务的。
数据科学家
数据科学家是使用专业知识构建机器学习模型，再以此做出预测并对关键业务问题进行解答的专家。数据科学家仍然需要对数据进行清洗、分析以及可视化处理，这一点和数据分析师是一致的。不过数据科学家在专业技能方面有者更深的研究，涉猎范围也更广，同时他们也能够对机器学习模型进行训练与优化。

至此，整篇文章，已经讲差不多了。
最后总结下，本质上，围绕房子的这4拨人，做的是同一件事情： 提供数据服务 。

完结～

如何开发APP

一、APP开发的基本步骤：

1、APP项目筹备期

作为企业或者创业者项目筹备需要解决的问题是：做一个什么样的手机APP？为什么要做手机APP？手机APP解决的问题是什么？手机APP面向的服务对象、人群是谁？。筹备期要把做APP的初衷明确到位，并切要结合自身的资源和优势，以免盲目的扩大APP的需求，最终导致项目上线后运行困难。总之项目筹备期明确自身的优势确定APP解决的问题和面对的对象。

2、APP项目需求文档

项目筹备期后就可以做项目需求文档了，项目需求文档是指用通俗的语言把你想要实现的事情说明白，例如：做个手机APP商城，商户和消费者可以在我的手机App平台上交易购物，特色或者和其他平台差异的地方详细的阐述明白即可；企业或者创业者在写需求文档时应该注意的是要明确你需要实现的功能，并且明确你自己创造性的部分，有了基本的需求后就可以和专业的产品经理交流分析，最终会形成详细的App需求分析。

筹备期和需求文档由需求企业或创业者独自完成。如果这两项未完成和确定时，我们建议不要联系App开发公司，做为App开发公司主要的职能和作用是通过专业的技术帮你实现你的想法，他是没法帮助你创造想法的，我作为铭讯软件多年的APP开发产品经理这点很了解。

3、APP项目分析

做为企业或创业者以上两步完成后就可以联系你所信赖的开发公司详细的交流项目了，做为专业的app开发公司拿到你的需求后，会结合以往开发项目的经验给你提出一些开发建议，比如在开发中用什么样的开发方式实现、如何提高用户的体验度、如何让用户最简单会使用，在开发方式上如何能做到流程最简洁，包括未来项目开发中遇到的问题也会给你提出，在拿到需求分析时开发公司会评估技术实现难度和开发周期，预估开发需要的费用，包括前期你需要准备的资料。App项目分析主要解决的问题就是你的需求结合开发公司的实力和经验为您初步诊断项目、开发难度、开发周期和评估开发费用，一般有经验的开发公司会给你更多的项目指导。

4、APP项目流程图

在项目开发公司项目分析完成后，会根据你的项目需求来绘制详细的项目流程图也叫思维导图，此步骤的主要目的是对项目所有流程的详细剖析，此流程完成后会明确两个问题，第一项目开发方是否对你的项目需求有准确的了解，第二项目需求方也会明确你预想的流程是否合理。此流程开发方和需求方会经过多次的沟通最终确定双方理解正确的流程。项目流程图建立完成后需要注意的几个方面：需求方必须充分了解项目的流程和各个交互环节是否在流程图上表达清楚，开发方必须根据以往的经验结合项目和用户体验做出最优化的流程。一般在开发中此步骤双方交流的时间比较长。也是项目开发初期至关重要的一步，铭讯软件APP产品经理的建议此步骤不明确时不要盲目进行下一步骤。

5、APP项目原型图

在流程图确定后，做为开发方就要开始绘制原型图了，原型图是项目需求图形化的第一步，原型图的目的是：第一简易的图形化帮助需求方来了解未来手机App的布局和结构；第二交互的确定，因为手机APP是一个完整的流程，每个流程如何到下一步，下一步后如何返回上一步，异常流程时如何提示，这些都在原型图中会展现出来，会帮助需求者再次确定流程的完整性。原型图完成后开发方会和需求方深度的沟通交流，因为在交互步骤每个人的认知和习惯是不一样的，每个受众群体也不一样的；在此步骤做为经验丰富的开发者也会考虑到，此步骤需要开发方产品经理和需求方负责人员多次交流沟通最终确定。此步骤需要的时间也是很多的。

6、APP项目效果图

在原型图确定后，恭喜你，项目开发已经完成20%的工作量了，接下来开发方的UI设计部门会根据原型图和流程图来制作图文并茂的效果图了，效果图是最接近项目完成时的形态的，效果图的制作会根据项目的需求、项目的LOGO、项目的人群来选择主色调，例如：京东APP是红色、淘宝APP是橘红色、政务APP是蓝色等，不同的选色会给项目APP带来不同的效果。一般项目开发方的UI设计部门会第一时间完成项目首页的效果图，首页效果图完成后会和需求方讨论，主要讨论色调，一般大型的企业客户会有标准的企业用色，但是做为创业者可能前期没有标准的企业VI设计，需要根据项目和需求喜好最终确定项目主色。此步骤开发公司会把所有的页面根据原型图的设计完成。此步骤完成后项目的视觉部分基本完成。

7、APP项目开发（页面APP标注适配、项目后台接口开发、项目数据库设计）

在效果图完成后，经过需求方确定后项目就进行程序开发和数据库设计环节了，但是做为App开发还有一个重要的环节就是页面标注和手机适配，此环节也是App开发独有的环节，很多客户就不能理解为什么还有标注和适配，我重点给大家讲解一下。

71、页面APP标注和手机适配

智能手机做为新时代的产物已经不仅仅是完成手机的基础打电话、发短信功能了，还具备了电脑、相机、定位的特性，伴随的时代的发展手机也逐步的发展由起初的小屏幕低配置到现在多样化；屏幕区分：全面屏手机、页眉手机屏、1080屏、真彩屏等；手机 *** 作系统区分：安卓系统（20-100版本）、IOS系统、塞班系统（Symbian）、微软（WindowsPhone）等系统；手机厂家区分：苹果手机、华为手机、小米手机、联想手机、vivo手机、OPPO手机等；其他配置区分：前置摄像头、后置摄像头、指纹识别、GPS定位、北斗定位、内置陀螺等；所有大家会看到很多手机的型号和 *** 作系统版本，为了让开发的APP能在各个手机上都能最好的显示和正常使用，开发人员要进行大量的适配工作，这也是在开发环节中很重要的部分，也是体现一个手机APP开发公司实力和经验的重要部分，此步骤的完成质量直接会影响到未来项目上线后用户使用体验。

72、数据库设计和后台系统开发

数据库的设计是专业数据库工程师或者项目负责工程师的工作，数据库通俗讲就是数据存储的一个盒子，会存储所有的数据库包括会员姓名、产品资料、交易数据等，在这个存储的盒子里面又根据存储的数据库类型分成了若干个‘货架’，条理的按照类别和使用频率存放在‘货架’上，这样在使用到时系统会最快、最准确的取到和存放。数据库结构的合理会大大提高系统工作时所需要的时间、效率和储存量，这也就是很多项目在运行中期为什么有的运行很快有的运行很慢，甚至有的还会出现计算错误的原因。所以在设计数据库时工程师会充分考虑。

系统后台开发通俗的理解是系统运行中作为集中管理的一个地方，包括了数据查看、数据发布、数据统计等重要工作。也是日常处理系统数据的重要地方，后台设计的功能一般是根据项目的需求功能确定的，比如商城类APP后台要有产品发布、产品管理、会员管理、产品订单等。

安卓和ios工程师根据标注效果图和原型图设计前端程序。

APP项目开发完成后，此项目的开发基本完成了70%工作量。

8、APP项目初稿测试

APP开发公司完成项目开发后的一个内部测试环节，一般的App开发公司是有多人多部门多岗位联合开发一个项目，做到了专人专岗的分配，也会保障项目在最快时间开发完成，所以项目多部门合作开发完成后需要进行开发公司内部的测试，开发公司会有专门的岗位叫测试工程师，一般测试内容分为：流程测试、体验测试、功能测试、性能测试等几部分；

首先进行的是流程测试，测试项目的流程是不是按照项目需求、项目流程图、项目原型图进行的，在测试期间除了测试系统流程的准确性之外，测试工程师还会根据自己以往的经验对项目流程进行测试，一来拟补设计时的一些不确定因素，还会更加完善项目。

体验测试是对项目整体用户 *** 作体验进行测试，包括交互的顺畅程度、交互体验感、交互是否顺畅等。

功能测试是测试工程师对项目的功能，进行系统性测试保证功能开发的完整性和可用性。同时对功能提出更优化的建议和见解。

性能测试是对系统的稳定性、安全性和承载能力做的系统性测试，包括多终端的测试，手机的适配测试，不同手机和系统版本进行的测试，做到系统兼容性强；承载能力是指系统数据处理能力和反映时间的测试，详细测试项目软件的并发数量和对服务器环境的要求，做到高并发大数据集中处理的能力。

9、APP内测

经过开发公司内部测试完成后，就可以联网进行系统内测，参与人员包括项目需求方和开发公司测试人员，可以下载并安装测试版本，此流程的测试包含系统后台使用培训环节，开发方会培训需求方后台使用方法，系统参数设置方法，需求方可以根据实际测试和内部运行的情况给出测试报告，包括实际使用中数据统计部分和 *** 作习惯部分的优化建议。前端可以多邀请一些内部人员进行测试，充分优化和测试系统的体验度和稳定性。此部分完成也代表着整个项目的开发接近尾声。

10、APP正上线

经过研发公司内测和需求公司的内测后系统通过后，项目基本具备上线运行的条件，根据需求方时间安排时间可以选择时间正式上线。期间需要租用正式的云服务器做为运行的环境。

11、APP项目技术运维

很多企业或者创业者经常谈到的一个问题，APP开发完成后需要多少后期运维人员，商城APP举例：一般一个项目的正常的运行需要的人员有财务人员、产品管理、产品售后、产品物流等人员。技术运维人员有系统BUG修复安卓、ios、后台等各一人，一般一个好的系统开发公司会跟踪项目的运维一段时间。

手机APP开发需要多少人、多少个岗位配合？

1、APP项目产品经理

产品经理是项目需求方和软件开发工程师之间的一个纽带，他既要根据产品需求方的需求文档做出相应的项目分析和项目诊断，还要为项目的后期开发提供项目流程图和项目原型图，以至于开发过中才能最节省时间，同时保证开发人员能按照客户的需求进行开发，以防项目开发过程中理解错误问题，同时项目经理会根据项目的需求结合自身的经验给企业或创业者更多开发建议。

2、APP项目后台、数据库工程师

此岗位人员会严格按照产品经理的分析和规划完成程序代码部分的书写，包括数据库的设计。一般工程师类型为Jav或PHP工程师。

3、APP项目安卓工程师

安卓前端开发工程师，主要完成项目的前端逻辑部分的代码书写，多版本手机的适配工作。

4、APP项目IOS（苹果）工程师

IOS前端开发工程师，主要完成项目的前端逻辑部分的代码书写，多版本手机的适配工作。

5、APP项目测试工程师

项目的测试和bug的发现。保证项目上线前的完成和测试工作。

6、云服务搭建和安全工程师

负责项目服务器的安全和搭建工作，一个项目完成后肯定要有一个容器来承载项目的程序和数据库，采用云服务有很多独特的优势，前期采用云服务器整体投资比例比较低是前期项目服务器部署的首选。

APP开发中常用的接口或服务申请

项目开发过程中会用到很多第三方软件的接口，可以做到多平台的融合，同时会提升用户体验感。一般前期会根据项目需求在项目开前期就着手准备接口的申请，常用到的接口如下：

1、微信开放平台

微信不言而喻是目前社交软件使用群体比较多的软件，同时微信提供了强大的传播功能，例如微信授权登录、微信支付、微信分享等。

2、支付宝开放平台

支付作为国内知名的支付平台，可以提供支付宝支付。

3、推送接口（极光推送、友盟推送等）

很多APP项目为了随时提供给客户数据变化或者消息通知都要推送给客户一些信息（也称手机任务栏消息），目前借助第三方的推送可以实现后台进程关闭推送，低延时、低功耗。支持手机广泛。

4、手机短信验证码接口

做为会员注册时必选的一个选项，目的是验证手机号码的可用性，包括重要信息修改时的验证工作，例如：修改登录密码二次验证工作、修改支付密码的验证工作，可以做到安全的数据提供。

5、阿里云服务器租赁

伴随着云服务的兴起，很多大平台都开放了云服务，做为项目前期选择云服务是比较合算的部署，云服务d性计算随用随付费，可以有效的管理支出，同时现在云服务上提供综合的云产品，包括高效的CND分发、负载均衡、云安全、国外云资源等，目前我们推荐项目使用最多的是阿里云和腾讯云。

6、其他使用的接口（身份z验证、身份z识别、人脸识别、即时消息等）

根据实际需要更多的接口可以申请，比如身份识别的身份z验证、活体识别的人脸识别等，目前技术成熟使用方便，按需付费。

云服务器的选择

1、阿里云服务

2、腾讯云服务

3、百度云服务

4、其他云服务（京东云服务、亚马逊云服务等）

五、APP项目首期开发后，如果发生了需求变更如何处理？

一般项目开发完成时，会根据项目实际投入市场后的运行情况进行结构或者流程的调整，这些都是在所难免的，前期策划再周全也难免后期的调整和改动，一般一个项目的成熟大改需要半年的时间，所以在开发前期要做好充足的准备，我们铭讯软件一贯的做法是负责项目一年左右的基础功能运维工作，还可以通过付月维护费来签署战略合作伙伴，这是会为客户提供每月的技术升级技术改造服务，充分让客户把经历投入到市场推广和项目运作中。

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

---