《决胜B端》

:::info 💡 根据 遗忘曲线：如果没有记录和回顾，6天后便会忘记75%的内容
读书笔记正是帮助你记录和回顾的工具，不必拘泥于形式，其核心是：记录、翻看、思考 :::

思维导图

用思维导图，结构化记录本书的核心观点。

书摘

概述篇 走近互联网B端

识别市场机会，诊断业务问题，通过软件产品帮助企业增加收入、提高效率、降低成本、控制风险。

第01章 互联网产品领域探秘

产品经理和项目经理有啥区别？到底在干啥？”

不同方向产品经理的技能诉求、职业发展路径差别非常大

1.1 产品经理岗位的发展历程

最早的产品经理要做的就是，聚焦公司售卖的产品和服务，帮助公司分析市场，识别需求，负责产品的设计、包装、宣传、推广和持续改进，提升公司销售额和利润。

业务分析师（Business Analyst，BA）的岗位，负责承接并管理软件开发项目

需要懂技术、懂商业、强执行力的人才，来负责软件产品的设计、运营、迭代和流量变现。在这个背景下，互联网产品经理应运而生。

他们是一群聪明、创新、自驱、有激情、懂技术的人，通过软件与互联网帮助企业实现业务创新、变现，提升企业经营管理效率。

1.2 互联网行业的产品方向

根据产品的属性和目标，业界习惯将互联网产品分为C端产品、B端产品、数据与策略产品、商业变现产品和AI产品

一名产品经理入行后，要在某个方向持续学习、发展、沉淀，成为某个领域的产品专家，这样才能保证很强的职场竞争力。

C端产品也叫2C（to Customer）产品，是面向终端用户或消费者的产品，往往承担流量获取和转化的重任。

运营决定存亡：对于C端产品来说，产品运营和产品设计同样重要，共同决定了产品的成败

B端产品也叫2B（to Business）产品，使用对象是企业或组织。B端产品帮助企业或组织通过协同办公，解决某类经营管理问题，承担着为企业或组织提高收入、提升效率、降低成本、控制风险的重任。

效能第一体验第二：B端产品的目标是解决组织的某类业务问题，因此聚焦于流程，提升业务效能是最重要的，打磨交互体验则处于次要地位。

收益难以量化：

业务支撑类产品：支持企业经营管理或核心业务的开展，例如仓配系统、CRM系统。[插图] 办公协同类产品：支持企业内部办公协同，例如OA系统、HRM系统。

从事数据与策略产品建设，一定要认识到数据的挖掘、探查、分析和价值输出才是产品的“灵魂”，而报表、可视化工具只是产品的“表面”。

互联网企业往往手握巨大的流量，最常见的变现方式就是广告售卖，具体产品形态包括搜索引擎营销、广告投放平台、在线广告联盟，

AI产品的核心是数据、算法和应用场景的结合。

1.3 互联网公司的盈利模式

常见互联网公司的盈利模式可以概括为四类，分别是广告变现、增值服务、佣金提成、买卖差价

互联网巨头都拥有庞大且成熟的商业广告产品体系，例如百度的百度推广、阿里的阿里妈妈、腾讯的广点通，都结合自身企业的产品布局、产品特点，提供了一站式的广告投放解决方案，包括关键词竞价排名（百度凤巢、淘宝直通车）、定向投放管理（百度网盟、阿里钻石展位、腾讯多端投放管理）、人群画像数据平台（阿里达摩盘、腾讯广点通数据平台）等广告创意管理与投放工具。

广告变现模式下的互联网企业，既需要创新的C端产品保证流量，又需要稳定的商业产品持续变现，还需要强大的CRM、呼叫中心等B端产品支持业务运作。

佣金提成模式下的互联网企业，需要各种产品支持业务开展：需要负责获客与流量经营的C端产品，需要管理地推、销售、门店与内部业务团队的B端系统，还需要大量促成交易的策略产品，以及强大的帮助入驻商家进行经营分析的数据产品。

对于赚取差价来营收的互联网公司，从线上运作到线下团队管理，需要C端、B端、数据与策略等产品全面支撑业务的发展。

表1-1 不同盈利模式对不同产品方向的诉求

第02章 B端产品概述

随着互联网线上红利的消失，越来越多的互联网企业尝试开展线下业务，寻找新的业务突破点和增长点。

2.1 互联网行业的发展趋势

在这个过程中，线上线下的边界变得越来越模糊，互联网思维被不断提起，互联网+的概念被不断放大，线上公司摩拳擦掌欲闯关线下，搅个天翻地覆；线下公司跃跃欲试想转型线上，搞个绝地反击。

人们能够支配的闲暇时间毕竟是有限的，当互联网能够榨取的时间达到上限时，互联网能获取的总流量就达到了巅峰。于是各个公司开始了对流量的抢夺，也就是对网民时间的抢占。

无论以平台形式还是自营形式介入线下模式，复杂的业务运作流程与庞大的线下业务团队管理都将是不可避免的，而这必须依靠B端产品助力。

当企业发展到一定阶段时，B端产品（指内部业务团队使用的业务系统）对企业的高效管理和运营发挥着不可替代的作用。

互联网巨头布局2B/2G领域，必须要有一批B端产品的精兵强将，帮助其实现战略意图。

2.2 从事B端产品方向的优势

从事B端产品方向的优势

B端产品经理既要涉足软件设计领域，又要涉足业务运营领域，有机会接触并深入理解企业运作机制，而我们知道，无论商业模式如何创新，企业的运作机制都是相通的。可以说，B端产品经理是懂技术、产品、业务的复合型人才，是企业在任何浪潮中都不可或缺的人才。

美团代表重业务模式（有大量的线下团队需要管理）的互联网公司，今日头条代表线上运作的轻模式（线上广告业务，不考虑销售团队）互联网公司

在B端产品线中，业务支持方向占比最大，包括供应链管理、CRM、配送管理等方向；其次是供给端管理方向，主要是供商户、商家使用的产品；在数据及策略产品中，报表类和策略类产品各占一半，报表类产品包括报表工具、可视化分析产品及业务分析产品。

逻辑思维与抽象能力设计B端产品的一个特有挑战是，如何基于对业务的透彻理解，把现实世界的复杂场景抽象成结构性的系统和模块，将现实世界的抽象运转机制提炼成规律，这对需求把握能力、方案设计能力提出了很高的挑战，能够很好地锻炼产品经理的逻辑思维与抽象能力。

作为一名B端产品经理，如果想在某个细分领域深耕，需要做到如下几点。● 掌握该领域的所有方法论和专业知识。● 对该领域的业务运营特点和难点有深刻的认知和总结。

● 掌握该领域的所有方法论和专业知识。● 对该领域的业务运营特点和难点有深刻的认知和总结。● 对市面上所有该领域的商业化软件产品如数家珍，优缺点了然于心。● 了解市场上所有类似业务模式公司的业务特点、产品特点。● 认识行业内的相关专家，形成圈子，经常聚会探讨行业的案例和变化。● 理解公司的业务现状、痛点，知道如何将行业最佳实践结合公司特点进行规划落地。

2.3 B端产品有哪些方向

2.3 B端产品有哪些方向

根据服务的对象，大体上可以将B端产品划分为三个方向：支持业务团队的业务平台方向、支持员工内部协同的办公协同方向，以及平台业务模式中支持供给方的商家管理方向，这三个方向覆盖了企业对内、对外所有的经营管理与业务运营工作。

在软件体系搭建过程中，有必要将各个系统都需要的、功能重复的软件模块抽象出来，统一建设维护，所提供的服务叫作基础服务。

交易平台的概念比较宽泛，大体上包括支付模块、商品管理模块、营销管理模块、订单管理模块等，有的公司将C端的收银台和支付页也纳入交易平台的范畴。

OA：Office Automation，办公自动化。主要提供资料查询、单据审批等功能，是最基本、最常用的办公软件。

我们的重点在于从整体上理解B端产品的范围，形成宏观的感受，而不必给每个产品贴上一个严格的类别标签。

2.4 如何转型B端产品方向

如果具备DMP经验，可以考虑从Marketing CRM方向切入。

产品经理要具备商业、用户体验、技术这三方面的经验

技术人员喜欢做确定的事情，但产品经理做的都是不确定的事情，所以心态要调整，学会灵活变通。

你都需要清楚自己的兴趣、优势、劣势，当然，也需要了解B端产品这一领域。

产品经理是一个需要沉淀和积累的工作，在一个方向沉下心，长期坚持，成为新分领域的专家，你的竞争力就会越来越强。相信只要目标明确，足够努力，所有的经历和沉淀都会成为宝贵的财富。

产品经理是一个需要沉淀和积累的工作，在一个方向沉下心，长期坚持，成为新分领域的专家，你的竞争力就会越来越强

设计篇 从业务诊断到形成方案

如何从零开始构建一套B端产品，来支持一条业务线。这其实是相当有挑战的，设计人员要完成业务梳理、流程设计、组织架构设计、数据建模、界面设计、权限设计等一系列工作，既要有对宏观的把控能力，又要有对细节的专注力。

第03章 B端产品建设概述

B端产品往往涉及复杂的业务关系和场景，该如何设计并实施一套B端产品呢？其实是有规律可循的，遵循标准的流程逐步开展工作，可以提升效率、少走弯路。

3.1 B端产品的总体建设流程

B端产品的总体建设流程需要借鉴软件工程自顶向下的设计思路，从抽象到具体逐步展开工作，大体上可分为业务问题诊断、设计解决方案（包括整体方案和细节方案）、执行并优化解决方案（又分为设计技术方案、实施、迭代）三大阶段

● 核心业务流程：梳理整个业务主干流程，并确定其中哪些环节需要由该产品实现线上化。● 产品定位：明确该产品有哪些子系统，分别支持哪些业务流程和业务版块。● 应用架构：考虑该产品和公司现有系统的融合关系。● 功能模块：基于对业务的理解，抽象出该产品的具体功能模块。● 演进蓝图：根据业务优先级与发展策略，制订实现各功能模块的计划和节奏。

运营迭代
新系统上线后，产品经理要和业务人员一起参与产品的运营迭代工作，包括宣传、推广、使用效果分析、问题和反馈意见的收集，以及持续的迭代优化。

3.2 B端产品与C端产品建设流程的区别

● B端产品是为了解决业务问题而设计的，设计的起点是进行业务调研，研究业务问题。
● C端产品要实现公司商业模式的落地，承载着公司的商业目标，设计的起点是对商业模式本身的分析与研究，包括市场分析、客户群分析等。

在建设B端和C端产品时，大的原则是类似的，都是先做加法，即充分讨论、穷举所有需求和可能性；然后再做减法，选出最核心的需求点；最后设计具体方案并将其落地，用最短的时间和最低的成本支持业务启动。

3.3 案例：M电商公司的渠道分销产品设计

案例：M电商公司的渠道分销产品设计

由于分销业务发展迅速，现急需配套的软件系统来提升业务效率，控制经营风险。

分销业务模式涉及复杂的多层级子母账号[插图]管理和组织机构管理，这是B端产品设计中的典型问题，也是设计的难点。

当我们接手一件比较复杂的工作时，制订明确的工作计划是一种良好的工作习惯。

第04章 B端产品的业务调研

对于B端产品来说，通过业务调研，能够从经营思路、管理模式等多个维度全面透彻地梳理业务，总结业务面临的问题，是掌握业务情况的有效手段。

4.1 B端业务调研的流程

针对高管，可以了解业务战略定位、战略目标等信息；针对经理或负责人，可以了解业务的管理思路、经营思路等信息；对于一线业务人员，可以获取作业过程、操作细节等信息。

业务调研的主要目的是掌握业务情况、诊断业务问题。调研结束后，要产出一份详细的调研报告，总结业务现状和问题，并确定各个问题的优先级，以便为后续的方案设计和实施路径提供决策支持。

4.2 B端业务调研的目的和分析框架

一般来讲，业务调研有两个重要目的，一是梳理业务现状，二是总结业务问题。

经营策略，通俗来讲就是做买卖的思路，包括客群定位、定价策略、营销策略、渠道管理策略、供应链管理策略等

管控模式是指集团对下属企业的集权、分权管理策略，也可以指总公司对分公司的运营管理策略。

还要留意一点，流程规范化是一把双刃剑，一方面可以规范管理，另一方面可能导致僵化死板，在梳理、设计互联网公司的业务流程时要把握好尺度。

4.3 B端业务调研的方法

B端业务调研的常用方法包括深度访谈、轮岗实习、调研问卷、数据分析、行业研究。

轮岗实习是指，产品经理深入一线，直接体验一线业务人员的具体工作，这是深入了解业务的最好方法。

深入一线是产品经理有别于传统需求分析师的重要特征之一。如果不能深入一线，而只是被动地接受需求，产品经理的价值就会大打折扣，产品经理的成就感和积极性也会越来越弱。只有投身于一线，才能深刻地理解业务，做出正确的决策。产品经理要当一个冲在前线的人，而不是在后方拍脑袋的人。

产品经理要像业务经理那样关心业务运行的各项数据，这样才能了解业务现状，并进行业务诊断。

如果研究CRM，可以试用Sales Force、销售易等；如果研究电商ERP，可以试用管家婆、商派等；如果研究报表可视化，可以试用Oracle BIEE、IBM Cognos、Tableau、百度指数等。

4.4 B端产品与C端产品业务调研的区别

业务调研，在B端产品领域一般就叫业务调研，在C端产品领域叫用户研究，因为C端产品面向的是终端用户，需要更多地从用户体验的角度进行调研分析，一般由用户研究团队负责，不一定由产品经理执行。

B端产品的竞品分析则是选做的，因为不同公司的业务流程、模式都不一样，需要的系统也不同。并且如果真的做，难度比较大，因为我们很难从公开渠道获取、分析竞争对手的业务运营管理机制。

4.5 案例：M公司分销业务调研总结

M公司分销业务调研总结

业务调研可以分为两种情况：一种是对新业务（打算开展，尚未开展）的业务调研，调研重点在于市场分析、行业分析、竞品分析等；第二种是对于已有业务（已经在开展）的业务调研，调研重点在于梳理当前的现状和问题。

通过梳理组织架构图可以理解人员结构和岗位设计，为系统的权限管理设计做好准备。

图表采用了经典的泳道流程图，横轴代表相关的业务部门，纵轴代表涉及的业务系统。

我们通过数据分析，整理当前的关键业务指标和全年的业务目标，作为了解业务运作情况和预期的一个重要补充资料

我们将业务主流程优化确定为高优诉求，将小众功能、风控功能列为低优诉求，经过探讨和业务人员达成一致，产品一期将聚焦高优诉求的实现。

第05章 B端产品的整体方案设计

B端产品的整体方案设计需要遵循自顶向下的设计思路，可以依次设计核心业务流程、产品定位、应用架构、功能模块、演进蓝图，从抽象到具体，逐步勾勒出B端产品的轮廓。

5.1 核心业务流程

从核心业务流程切入产品设计，是开展整个设计工作的非常好的起点。核心业务流程代表业务的主干脉络，需要思考业务的各个参与方、涉及的系统。

通过对核心流程的梳理，以及明确其中哪些环节需要线上化支持，分销系统的轮廓初现。

5.2 产品定位

产品定位要说清楚产品针对谁提供什么支持。

设计业务系统时的常见问题是，为了省事，或者由于业务部门之间边界模糊、权责界定不清晰，导致很多本应该独立的功能被糅合到一个系统中，这样会造成将来管理的混乱，尤其是系统维护的混乱。理想情况下，独立的业务部门应该由独立系统来支持工作。

5.3 应用架构设计

在设计一套新系统时，必须考虑如何和公司现有系统架构融合，不同系统的模块之间如何衔接。

5.4 功能模块设计

这个系统应用于哪些业务场景？用户可能在系统中做的操作有哪些？通过思考这些问题来抽象出需要具备的功能模块。产品经理设计的功能模块代表了其对业务本质诉求的理解和提炼，蕴含了他对业务、系统未来发展的期望。

分销客户管理后台是给分销客户管理员使用的管理后台，主要用来管理下属门店和子账号；还需要随时了解下属门店和子账号的经营情况，因而需要查询所有下属门店和子账号的数据；此外还需要进行统一的财务管理。

典型的电商管理后台需要具备商品定价管理、财务管理、风控管理、运营管理、客户管理、报表管理几大模块

5.5 演进蓝图设计

一期项目要实现哪些功能？有一个原则可以参考：凡是可以手工处理和解决的问题，都暂时不做系统支持。

在互联网产品圈中很流行的用户体验五要素及其提出的五个设计层次（表现层、框架层、结构层、范围层、战略层），也是一种自顶向下、由粗到细的设计思路

第06章 B端产品的细节方案设计

B端产品的细节方案设计

B端产品的细节方案设计包括业务数据建模、页面流转设计、界面设计、权限设计等，这些都是产品经理的必修课，即便没有经历从0到1的设计过程，也会在日常的迭代工作中经常接触。

6.1 业务数据建模

B端产品进行细节设计的常见流程是，首先构建业务数据模型，然后基于流程确定页面流转图，再着手每个页面的具体设计，同时提前规划好系统用户角色，最后完成权限设计。

企业往往有多层级管理的需求，需要软件系统支持多层级业务体系。多层级机构管理通常使用组织机构树呈现

业务数据建模的过程就是将业务对象及其之间的关系抽象出来的过程，ER图呈现了业务数据建模的结果。

这样的设计将导致账号无法对不同层级的门店进行灵活管理（像图6-1中那样），但是会让代码开发简单很多，因为工程师不需要处理一棵层级复杂的树形结构，也就不需要编写大量的递归算法，这大大降低了开发难度。

业务调整的灵活性取决于软件系统的灵活性，而软件系统的灵活性取决于业务数据模型的可扩展性。

业务数据建模能力体现的是设计人员对客观世界的抽象描述能力，只有对业务本质理解透彻，再结合积累的软件设计经验，才能抽象并构建出合理的业务数据模型。

6.2 流程和角色

流程合理、角色清晰是系统正确设计的前提和保障。遵循自顶向下的设计思路，我们首先设计主干流程，在这个过程中可以进一步明确系统角色及业务岗位的安排，然后基于主干流程图设计页面流转图，最终完成页面细节设计。

图6-7 创建维护客户与下单操作的流程图

通过跨职能分系统流程图，可以清晰地看出谁（操作角色）在哪儿（哪个系统）做什么（完成什么工作）

页面流转图描述的是，用户完成某项工作需要访问的页面及页面跳转顺序。

一般来讲，我们绘制页面流转图时，都是针对某个单一角色绘制某个特定场景下的页面访问和跳转逻辑，从用户的视角来梳理一遍所有相关页面，每到一个新页面时，都要思考：需要新做一个页面，还是可以复用原有页面？最终整理出系统涉及的所有页面的初稿。

管理人员可以对每一条客户信息进行查看明细、审核、删除的操作，而运营人员只能查看客户信息的明细，可见二者查询客户列表的诉求是类似的，只是操作的功能点不同，这样的差异点完全可以通过权限配置实现（见6.6节），而没必要开发两套客户列表页。

从本质上讲，一套软件系统就是对不同数据对象的增删改查操作的集合，这个特点在业务系统中更加显著。

6.3 界面设计

在团队分工明确、人力储备充足的情况下，在开发一套全新的B端业务系统时，界面设计的流程一般如下：
1．产品经理绘制线框图原型，表达软件中每个页面的设计需求。
2．UE设计师协助产品经理完善交互体验，并制作交互原型。
3．UI设计师基于交互原型进行美工设计，生成切图文件。
4．前端工程师拿到切图文件，进行前端开发，包括实现交互、动效等。

线框图的重点在于说清楚界面上的交互功能设计，而非UI效果。

反馈原则（Visibility of system status）系统应该在合理的时间、用正确的方式，向用户提示或反馈目前系统在做什么、发生了什么。

隐喻原则（Match between system and the real world）系统要采用用户熟悉的语句、短语、符号来表达意思。遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受。

回退原则（User control and freedom）
用户经常会不小心操作错误，需要有一个简单的功能，让程序迅速恢复到错误发生之前的状态。

防错原则（Error prevention）系统要避免错误发生，这好过出错后再给提示。

灵活易用原则（Flexibility and efficiency of use）
系统的用户中，中级用户往往最多，初级和高级用户相对较少。系统应为大多数人设计，同时兼顾少数人的需求，做到灵活易用。

简约设计原则（Aesthetic and minimalist design）对话中不应该包含无关的或没必要的信息；增加或强化一些信息就意味着弱化另一些信息。

容错原则（Help users recognize, diagnose, andrecover from errors）错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码；提示错误信息时要给出解决建议。

帮助原则（Help and documentation）对于一个设计良好的系统，用户往往不需要经过培训就能轻松上手使用，但是提供帮助文档依然是很有必要的。帮助信息应该易于检索，通过明确的步骤引导用户解决问题，并且不能太复杂。

列表页是B端产品中最重要、最常见、最基本的元素，并且列表页的设计非常讲究技巧

我们可以对列表页进行高度抽象，因为在所有列表页上实现的不外乎增删改查操作。观察成熟的列表页，可以发现其上面的元素主要包括检索条件区域、结果列表区域、分页器（控制页码的小组件）等有限的类型，因此只要实现一套高度灵活的前端控件，能够自定义配置所有内容，就可以实现列表页的灵活定制。虽然实现这样一套灵活控件的周期比较长，但是长远来看非常必要。

首先，用户可以设置任意的查询条件。

设计批量操作功能时，很重要的一点是帮助用户快速选择操作对象

列表页设计Bug“找茬儿”

列表页的显示字段要和搜索条件匹配，这是一个基本的设计要求，却很容易被忽视。

网上有很多免费试用的系统可供学习，比如Google Analytics、百度统计、管家婆云ERP、Udesk、Sales Force等。

什么叫标准的控件呢？Visio或Axure里提供的可以绘制的控件就是标准控件。不必创造这些标准控件以外的控件！

6.4 报表设计

业务报表的核心价值是掌握事实、发现问题、分析原因、产生对策

构建分析体系之前，首先要明确分析目的，即需要通过分析发现哪些方面的问题；然后思考该采用什么方法来识别、诊断这些问题，其中可能的困难是什么。构建分析体系必须建立在对业务的深刻、准确理解之上，并且要和一线管理团队多沟通，可能很多问题的分析框架和思路已经被一线工作者发现并有效实践了，一定要善于发掘并参考、借鉴。

直到后来，自己有了一段创业并管理业务的经历，每天要看各种报表，才体会到，作为一名业务管理人员，各种核心数据都是了然于心的，看一眼当天的数字，就知道有什么异常。管理人员需要的只是干净的界面和能够实时更新的准确数字，其他炫酷的交互效果并不需要。

更常用的方案是使用成熟的报表引擎，这是一种现成的报表软件产品解决方案。后端工程师准备好数据[插图]后，产品经理只需要指定数据源，写好SQL语句，定义好报表样式和基本交互方式（例如搜索选项、分页器等），报表引擎就可以完成接下来的数据呈现工作了。

本节中的图表都是从商业报表引擎软件Smart BI和Fine Report提供的demo中截取的

动态仪表盘也叫管理驾驶舱，是BI中的概念，在业务系统中也经常采用

套打功能具备一定的技术复杂性，如果从零开发，效率会非常低，因此也建议采用成熟的报表引擎，一套良好的报表引擎可以完美地支持套打诉求。

本节中提到的两个报表引擎的demo地址如下：http://demo.finereport.comhttp://demo.smartbi.com.cn

数字没有右对齐，这会导致用户无法直接看出数字之间的大小关系，因为无法通过长度来判断两个数字的量级差异。

聚焦业务分析本身
业务分析思路才是报表设计的核心，产品经理要尽量参与分析体系构建的过程，这是帮助自己进一步理解业务运行和管理机制的非常好的机会，不要把太多的精力投入在交互体验设计上。

等新的报表在线下试用的过程中调试好各种问题后，再实现线上化，是一个更好的选择。

B端产品经理需要了解数据仓库的基本概念，包括掌握数据体系的逻辑架构，理解数据集市、星形模型、数据立方体等基础概念，这对报表设计十分有帮助。

6.5 数据埋点

对于B端产品来讲，数据埋点是考核产品使用程度的一个重要依据，也是业务用户行为分析、产品分析、产品改善的重要参考数据来源。

这些在网站中注入分析工具提供的代码片段，以便网站分析工具能够准确捕捉用户行为的工作，就叫数据埋点。

目前国内使用比较多的Web端埋点工具有Google Analytics（GA）、百度统计，移动端埋点工具有Growing IO、诸葛IO、神策。

如果不考虑数据安全性问题，建议Web版的B端产品部署百度统计，因为接入简单方便，而且足够做基本的统计分析。对于移动端的埋点软件，区别不大，根据偏好自行选用即可。

桑基图（Sankey Diagram）也叫能量分流图，可以通过桑基图方便地观察流量的流转情况

访问以下链接，可以直接体验GA以及易分析的demo账号。GA：https://analytics.google.com/analytics/web/易分析：[http://www.yeefx.cn/demo.show.php](http://www.yeefx.cn/demo.show.php)

埋点格式，是指在埋点过程中需要记录的扩展字段

6.6 权限设计

功能权限，指各个角色可以操作的界面、按钮等，例如管理员可以进行新增、删除、修改等操作；运营人员在同样的页面上只能使用各种筛选条件查看数据，无法做更改。

我们通常用权限表来描述权限、角色的配置关系，这张表在产品设计阶段就需要准备好。

关于完整的功能权限设计，最经典的理论是1995年由计算机科学家Ravi Sandhu提出的RBAC（Role Based Access Control）模型，描述了一套用户、角色、权限组的设计理念，在业务系统设计中被广泛采用。如果产品经理需要设计功能权限管理系统或模块，就必须理解RBAC权限管理模型。

针对数据权限的控制，常见的实现方案如下。● 方案一，通过组织机构树控制。该方案根据账号所在组织机构树中的节点位置，来判断能够查询的数据范围。这种方式最复杂，但最灵活，能够支持各种复杂的业务数据权限诉求。

其中“客户-采购员1”能够查询用户当前所在节点及其所有子节点上的数据，“客户-采购员2”只能查询用户当前所在节点上的数据。

图6-45 分销业务的组织机构树

“账号5”属于“广州”节点的子节点，被赋予“客户-采购员2”的角色，该角色和其他角色不同，数据权限范围是“当前节点”，因此“账号5”在订单页面只能查看同级别的门店订单，即“门店2”和“门店3”的订单，但是看不到所在节点子节点下的门店订单，即看不到“天河”节点下的“门店4”“门店5”的订单。

通过组织机构树来管理数据权限，是业务系统设计中的常见做法，大家务必理解其设计原理和设计思想。

6.7 文档编写与管理

如果没有一些机制或手段，让需求提交者经过全面思考后再提交需求，则可能会造成需求泛滥，需求质量低下，进而导致产品经理需要耗费很多精力去鉴别这些需求的真实性和价值。

1．项目背景
详细描述项目背景，包括业务现状、面临的问题、解决思路等，需要有数据支持。
无论需求有多么简单，都要填写此项，这是为了让当前或以后的文档阅读者理解此项目的背景。

任何项目都有业务价值，都要填写项目收益目标。对于B端产品，有时不容易直接衡量业务价值收益，可以考量功能的使用情况、满意度

8.1. 产品框架概述简述此产品的功能：● 系统框架图● 数据模型图● 业务流程图● 业务用例图● 状态机图（参见6.8节）

一般来讲，我们常常按如下格式对文档进行命名：公司缩写 + 事业部 + 文档名称 + 版本号

如果你要将某个修改后的文档发给别人，那么一定要给文档标记版本。如果没有标识清楚，多次收到修订文件的同事会分不清哪个文档是最新的，极有可能搞错版本，造成工作错误，引起很多不必要的麻烦。

文档的版本也可以按照修订日期来标识，例如v20190503、v20190521。

在互联网公司，产品经理和研发工程师习惯将每一个版本的文档都上传到Wiki系统中，实现文档的线上化存储，这是一种非常好的工作习惯。

6.8 UML和常用图表

产品经理常用的UML图包括ER图（UML中的类图）、跨部门流程图（使用频率最高）、状态机图；可能用到的UML图包括活动图、用例图

对象的对应关系，是一对多还是多对多，这实际上就用到了ER模型。

跨部门流程图是一种相对复杂的流程图，可以清晰准确地描述分角色、跨系统的业务流程，

状态机图（State Machine Diagram）也叫有限状态机图（Finite StateMachine Diagram），是一种描述所有状态及状态之间流转规则的图形。

活动图（Activity Diagram）是流程图的一种，用来描述一系列过程。活动图和流程图最大的区别是，活动图可以描述并发工作的执行过程，而标准流程图的节点必须是顺序执行的，只有判断节点才能引出两条分支。

用例图（Use Case Diagram）从用户视角来描述系统的操作功能。简单来讲就是某个角色或用户在不同场景下能做什么。

多看UML实例可以快速准确地理解各类图表。推荐学习网站www.uml-diagrams.org，该网站对UML进行了详细讲解，并且提供了丰富的案例，是非常好的学习资源。

第07章 B端产品经理与技术方案

尤其是B端产品经理，更需要理解技术体系架构，因为B端产品的结构设计不仅和业务有关，还和技术架构有关。

学习数据库表设计，可以帮助产品经理更加深刻地理解软件设计的核心要点。

7.1 两段有趣的对话

首先实现热词配置表需要设计数据库表结构，然后要做各种代码读写数据库的处理，还有，前端要实现完整的增删改查操作，交互点非常多，编辑按钮、删除按钮、调整位置，这些都要处理！”

通过以上情景对话，我们模拟了针对同一个业务需求，不同产品经理和研发人员的不同沟通过程。相信通过这个案例，大家对产品经理是否需要懂技术有了感性的认识。下一节将更具体地分析产品经理懂技术的好处。

7.2 产品经理是否要懂技术

和C端产品相比，B端产品更重视业务逻辑的抽象过程，产品设计方案和技术方案的相关性更强，甚至有时候产品设计方案本身就是技术方案，例如SDK产品、基础服务产品、消息中间件产品等的设计方案。

如果产品经理懂技术，则可以感觉出有问题；否则，工时评估对产品经理来说就是一个纯黑盒操作，无法进行判断和把控。

7.3 产品经理是否要关注技术方案

技术方案和产品方案相互影响：有些技术选型问题会直接影响产品方案设计，或者产品方案直接决定了技术方案，此时产品经理要和技术负责人讨论清楚。

7.4 B端产品经理的技术知识要求

B端产品经理可以通过学习一门编程语言，来理解程序设计的基本逻辑，例如什么是函数、返回值、循环、编译、发布等。学习的重点不是编写出能执行的程序，而是理解程序设计的基本原理。

Charles Petzold的伟大著作《编码——隐秘在计算机软硬件背后的语言》

任何一套软件系统运作的本质都是相同的：用户在前端交互层操作后，系统通过业务逻辑层处理数据层的数据。

开发人员应该尽量将复杂的校验、判断、业务规则都封装在业务逻辑层，这样可以让前端交互层的负担更轻，更容易扩展，因此业务逻辑层是MVC结构中最复杂的部分。

数据层代表底层的数据存储。数据包括结构化数据和非结构化数据，既可以存储在数据库中，也可以存储在文本文件中。

接口之间的调用模式分为同步调用模式和异步调用模式两种

在异步调用模式下，接口调用方给被调用方发出指令，但不会等待结果

一般耗时比较长的处理工作会采用异步调用模式，调用方会给被调用方提供一个回调接口，意思是“你处理时间比较长，等你处理完以后，再调用这个回调接口，通知我结果吧！”

如果不能将软件分解成像积木那样的小模块，而是焊死的一块铁板，那么系统将彻底丧失灵活性。

合理的做法是对第一版系统业务逻辑层的核心功能进行服务化处理，即针对“注册账号”“禁用账号”“重置密码”“更新数据”等每一个目标很清晰的功能，将它们抽象成接口，以便于给任何系统提供支持。

至此你应该感受到了软件工程“搭积木”的设计特点，一个个服务接口就像积木块，通过对这些积木块的重复组合利用，可以搭建组装出各种新的功能和服务。我们常说软件工程就是在造轮子（服务接口和系统模块），对于功能相同的轮子，大家共用一套就足够了，没有必要针对每个系统重复制造功能相同的轮子。

在技术体系中，有两个非常重要的概念在支撑着接口化、服务化的设计理念的落地，即SOA（Service Oriented Architecture，面向服务的架构体系）和微服务

常见的关系型数据库包括IBM的DB2、微软的SQL Server、甲骨文的Oracle，以及被甲骨文收购并开源的My SQL，每一种关系型数据库产品都有自己的SQL规范，但核心的语法规范是相同的。

STATUS字段：每个账号的状态。状态类的字段一般不会存储具体的状态文字描述，而是会存储一个代码。要理解代码的含义，需要查看数据字典（针对数据库表结构的说明文档，包括字段的说明以及字段值的解释），或代码表（简称码表，有的系统会设计）

在关系型数据库中，工程师在创建表时，需要给表中的每个字段定义数据类型，例如在表7-1中，ID、ORG_ID和STATUS字段是数字类型，NAME字段是字符串类型，CREATETIME字段是日期类型。

如果你能够理解ER图代表的数据建模思路、以上数据库表结构是如何将数据模型落地的，以及表结构中的数据所体现出的树形结构（图7-15），那么说明你已经理解了业务系统设计中核心且复杂的内容。

针对SQL的学习，推荐以下两个学习资源。● www.sqlteaching.com：该网站是目前我接触过的最好的SQL学习资源。

管理篇 让产品落地并不断生长

产品经理很像一个大管家，不仅要负责产品功能设计，还要统筹协调各种资源，确保一系列工作都能同步开展，最终拿到希望的结果，产生业务价值。

8.1 为什么需要项目管理

优秀的项目管理是互联网公司在复杂环境下保证软件开发按计划推进、落地的关键，也是保障规模团队的产品研发效率和质量的核心要素。

8.2 互联网项目管理的工作重点

工作重点主要包括设计并优化项目管理制度和负责大中型项目的立项实施

需要专业的项目管理团队结合公司的业务特点和企业文化，对业界最佳实践做调整，制订符合公司特色的项目管理制度，这也是项目管理制度建设的难点和要点。

合理的规范制度应该既能约束产品研发团队的行为，也能保护产品研发团队的权益。

项目经理要保障大中型项目的成功落地，就必须理解业务，这样才能在大中型项目管理中准确理解整体方案，以及各个团队负责的工作范围

8.3 如何对B端产品做好项目管理与实施工作

容易发生跨端（跨系统）现象

如何协调并推动跨端协作

所以，通俗点儿说，强执行力和推动力就是指能够记着事儿，不忘事儿，上着发条追进度，盯过程，要结果。

● 开展定期会议（例会）

开每日站会：站会是敏捷开发中经典的工作方式，对于软件研发项目，在团队内部开每日站会的确是非常有效的工作机制。

项目经理要利用项目日报或周报来争取关注度和资源，解决项目中遇到的问题。

发出的周报可能无法清晰有效地呈现风险；即使呈现出风险，相关人员可能没有仔细阅读并识别问题；即使识别出了问题，可能没有人站出来追问并解决问题。

总之，在项目管理中，合理拆解并细化工作，制订良好的项目执行机制，再加上足够的责任心，就可以对项目进度有较好的控制和掌握。

在项目管理中，合理拆解并细化工作，制订良好的项目执行机制，再加上足够的责任心，就可以对项目进度有较好的控制和掌握。

第09章 B端产品的运营管理

B端产品经理、产品运营人员、业务运营人员三者的工作职责往往有很多交叉和重叠，这就可能导致冲突，影响工作效率

9.1 B端的产品运营岗

B端产品运营岗位的工作内容主要包括产品功能推广培训、问题解答处理、需求采集过滤、项目效果分析、业务诊断分析几个方面，我们来分别介绍。

比较高效的问题解答、处理机制应该是层层过滤的：一线业务人员反馈问题后，首先由产品运营人员及时响应和跟进；如果发现是系统问题，则提交给产品经理，请他再次核实；如果确认是系统Bug，则由产品经理提交给研发人员。这样可以避免一线用户直接找研发人员，影响研发工作。

高阶的产品运营人员还要和产品经理、业务团队一起诊断业务，分析问题，提出解决方案，并推动解决方案落地执行。

工作目标不同：B端产品运营通过挖掘B端产品能力，帮助业务线提升管理效能、改善核心指标（不同业务线的考核指标不同，例如，销售线可能是销售额，采购线可能是采购成本，配送线可能是配送效率）；C端产品运营帮助C端产品提升核心指标，常常包括用户量、活跃度、转化率和收入等。

9.2 B端的业务运营岗

B端业务运营岗的管理模式

在一个典型的、成熟的公司组织架构中，类似财务、法务、人力这些支持部门，常常被归类为职能部门或中后台部门，主要目的是保证企业的行政运转；而销售部、仓配部、采购部、客服部等部门，需要围绕核心业务开展工作，直接承担企业经营的业务目标，被称为业务部门。

业务支持
在业务工作开展中，会有审批、核对、检验这类工作诉求，这些事务性工作非常繁杂，是业务运营岗的重要工作内容。

9.3 产品经理、产品运营人员、业务运营人员如何高效协作

产品经理、产品运营人员、业务运营人员如何高效协作

组织架构决定了汇报关系，进而决定了绩效考核方式。汇报关系、绩效考核方式会影响人做事的动机、行事的方式，以及个人和团队的利益。

产品部和业务部平级，产品经理和产品运营人员统一归产品部管理。

有利于从企业利益出发考虑问题：虽然业务线产品经理要为业务服务，但因为产品部是独立团队，所以产品经理有权利和义务在某些时刻跳出业务线，从客户利益或公司整体利益出发，对业务部说“不”，必要时将问题升级到CEO级别去处理。

之前的产品运营部和系统运营部被合并为产品运营部，统一归属到业务运营部下面

图9-4 产研业务组织架构（方案二）

产品部的权利被弱化：产品运营人员不再归属产品部，那么推广产品、收集需求、反馈常见问题和一线声音等工作，就不再是产品负责人能够直接安排的了，并且产品经理也无法得到最及时高效的信息反馈了。

方案五中的A业务线产品部需要做双线汇报，实线汇报给相应业务部，虚线汇报给产品部

互联网公司取得成功的诀窍之一就是，频繁地调整组织结构，尝试各种安排，在各种调整中很可能实现破局，或者产生“鲶鱼效应”。

10.1 B端产品的需求管理

产品投产后，还需要不断收集、挖掘新的需求，进行持续的升级迭代，以完善系统功能或优化业务流程

确认需求的优先级、确认迭代工作的计划安排，更能培养对业务的准确判断力。

● 这个需求背后的真正问题是什么？● 这个问题是否有简单快速的解法？● 这个问题的影响面有多大？如果只是个案，是否值得投入精力去研究解决？● 如果是共性问题，优先级和紧急程度如何？

从记录在案开始，到实施上线，需求要经历完整的研发管理周期。可以通过一套项目管理软件（例如JIRA、Teambition）对需求进行管理，按照公司统一的项目管理规范来实现。

不论是合并管理还是分开管理，主要目的都是实现清晰准确的需求管理、迭代计划管理，并做到项目进度透明。

需求类型包括以下可选项：
产品需求、产品需求（插入）、技术需求、技术需求（插入）、线上Bug

优先级是管理需求迭代计划的重要判断依据。优先级应该是一个客观的评估，可以和业务人员一起商定一个都认同的标准，作为优先级的判断依据。

状态用来描述需求的生命周期，状态值可以包括如下选项：
待跟进、需求调研、PRD编写、待PRD评审、待技术评审、待排期、待开发、开发编码、待测试、测试验证、待验收、待上线、已上线、挂起、拒绝。

工期和工时是两个完全不同的概念，工期是指开发时长，工时是指工作量

10.2 B端产品的迭代管理

广义上的迭代管理是指软件的持续优化、升级计划；狭义的迭代管理是敏捷开发中的一种模式。

在迭代优化过程中，产品经理要充分调动并利用研发资源，通过对人员的合理调配，保障不同项目之间无缝衔接，避免因为时间窗口不匹配导致研发资源闲置。

因此，维护好这张研发人力资源安排图，也是对研发人员的一种保护，避免他们“蒙受”工作不饱和的怀疑和指责。

结合业务发展周期，我们将系统建设归纳为四个阶段，分别是初创阶段、瓶颈阶段、重构阶段、稳定阶段。

所谓双周迭代，即两周完成一个迭代周期，其中，一个迭代周期是指从软件开发到上线的时间。

找到瀑布模式和敏捷模式的恰当结合点，设计适合自己的模式、流程，从而提高效率。

瀑布模式的核心环节是“需求分析”“方案设计”“开发编码”“验收上线”，这几个环节是软件工程的必经环节，任何模式都难以绕过。

本质上讲，敏捷模式是容纳并拥抱新时期快速变化的市场环境和商业特征的一种理念。

敏捷模式试错速度快，试错成本低，在步骤1和步骤2就已经可以判断方案是否有效

第11章 B端产品的数据分析

互联网人必须具备以数据驱动业务决策的意识和习惯

11.1 数据分析的流程

数据分析的方法论很多，从本质上讲，可以将数据分析的过程抽象为四个步骤（如图11-1所示），分别是明确主题、提出假设、验证假设、产生结论，其中提出假设、验证假设是数据分析工作中最复杂的部分，需要反复进行，才能得到正确的结论。

基于假设去观察、研究数据，判断、验证假设是否正确，在此过程中便会对数据的洞察越来越深刻，产生更加清晰的想法和思路，提出新的假设，从而进一步探查数据，如此往复，离问题真相越来越近。

通过这个简单的数据分析案例，希望读者对数据分析中提出假设、验证假设的过程有了初步的认识。在分析过程中，我们不断地从各个维度（时间、地区、品类）对数据进行观察，在需要的时候进行数据下钻（例子中从区域下钻到销售品类，也可能进一步对蔬菜品类下钻到具体的二级品类）。通过Excel数据透视功能，并结合对数据的可视化处理（数据条），可以让分析工作变得直观、高效、灵活，如图11-5所示。

一套BI软件产品的重要功能之一，就是实现类似Excel数据透视表的功能，可以让分析人员从各个维度探查数据。而数据仓库（Data Warehouse）要做的事情，就是对各种明细数据提前按照各种维度加工计算好，等待BI的多维度探查和展示。

11.2 数据分析的要点

做好数据分析工作需要三个核心要素，分别是方法工具、业务知识、细心耐心，三者缺一不可。

数据分析方法论：基于不同的分析诉求，有很多成熟且经典的数据分析方法论，例如分析C端产品的获客增长模型AARRR、分析客户消费行为特征的RFM模型、分析留存率的COHORT模型，这些方法论中蕴含了成熟的分析思路和手段，是针对各种确定的分析场景的最佳实践。

产品经理还需要补充各种业务知识，例如销售知识、供应链知识、仓储知识等，需要产品经理根据所处行业选择并学习。

[插图]

统计学方面：《深入浅出统计学》。统计学作为一门专业性很强的课程，一般的教材往往很枯燥，而本书通俗易懂，趣味性强，且内容丰富。

11.3 数据分析报告

如果因为报告太粗糙而掩盖了数据分析的价值，岂不十分遗憾！

数据分析报告的常见结构和逻辑论证的结构相似，一般按照“总分总”的形式编写，包括提出论点、进行论证、陈述总结三部分

标明数据来源可以体现数据的合理性、合规性、合法性。

这里推荐国内Excel图表制作专家刘万祥的著作《Excel图表之道》

进阶篇 支撑企业运转的整套产品体系

所谓企业级应用架构，是指企业的所有软件系统设计、集成的方式。

第12章 企业级应用架构概述

如果你想更加深刻地理解自己负责的业务线，更好地把握架构级别的方案设计，并追寻更广阔的职业发展空间，就必须学习企业级应用架构的搭建

12.1 什么是企业级应用架构

企业级应用架构正是指企业的各个软件系统有机集成在一起的方式

图12-1 典型的企业级应用架构图

12.2 学习企业级应用架构的益处

学习企业级应用架构的益处

学习企业级应用架构，最直接的好处是让你对业务的理解变得全面且深刻。

在学习企业级应用架构的过程中，产品经理必然要理解企业的组织架构、职能部门的设计；理解企业在不同阶段、不同的业务情况下，部门之间的权责分工、组织架构的演进等，从而对企业是如何运作的形成清晰的理解。

如果你学习过产品架构搭建的知识，就会知道借助主数据的设计思想，构建客户主数据、供应商主数据、商品主数据等，从而方便地解决这些信息孤岛问题

理解应用架构的设计是随着业务发展的，是循序渐进地演变的，不是一蹴而就的。

尝试从企业、行业、产业的视角考虑，尤其是从企业整体经营发展的角度去思考、设计方案，能有效地锻炼并培养自己的大局观。

12.3 案例：M集团的应用架构演变之路

学习、理解企业级应用架构最有效的方式，莫过于沿着一个企业从小到大的发展脉络，研究应用架构是如何演进、发展，最终形成一套成熟的体系架构的。

13.1 小微型企业的应用架构

越来越多的小微型企业认识到信息化能力的重要性，这也给各家Saa S公司带来了更多的机会，同时也是产业互联网的一个分支。

13.1.1 小门店的Excel管理之路

实际上，所有的软件系统从本质上讲都是对数据的增删改查操作的集合，可以说，如果使用得当，Excel也可以做出一套小型的软件系统。

利用沉淀的数据进行各种经营分析，对定价、促销、爆品、库存的把握都十分准确

ERP（Enterprise Resource Planning，企业资源计划）软件

传统的ERP软件相当于集合了典型电商公司的后台模块、财务系统、仓储系统、配送系统、采购系统。比较典型的ERP软件产品厂商有SAP、Oracle、用友、金蝶。

核心的客户信息资产模块都在CRM系统中实现，CRM系统中内置了营销中心以及消息推送服务Msg模块，包括SMS（Short Message Service）、EDM（Email Direct Marketing）和微信消息推送。

请注意，这里已经产生了应用架构设计的概念，公众号、ERP和CRM，这其中的每个系统都是为了解决某一大类的业务问题而存在的，各自有清晰的定位、分工和目标用户；每个系统内置若干模块，每个模块都是为了该大类业务问题下的某一小类问题而设计的。几个系统相对独立又互相关联。

13.2 中型企业的应用架构

本节所讲的中型企业是指，员工数量在百人左右、具备现代企业经营所需的所有职能单元（如人力、财务、法务部门）、组织制度规范的企业。

当企业规模达到一定复杂程度以后，必须有一整套软件系统来支撑其经营运转，否则管理会失控、混乱。

为了有效地管理团队，并且让内部流程更加顺畅，钟先生邀请专业的IT咨询公司帮助重新梳理了公司的业务目标、组织架构、运营流程，通过引入OA、HRM以及重构ERP等手段，对不合理的制度、低效的流程进行了改造，如下

软件本身并不能解决企业的问题，还需要配套的架构、流程、制度，以及人员认识的提升，才能发挥软件的功效。

建设OCRM系统支持企业客户业务

所谓OCRM，是指供销售人员使用的CRM系统，主要负责客户资料管理和销售过程管理。

第14章 多元化业务带来的应用架构演变

良好的应用架构体系会成为企业持续快速发展的助推器；而混乱的应用架构体系会成为企业成长的绊脚石。

将基础功能模块抽象出来，构建一套基础支撑体系——这也是近几年广受关注的中台建设思路。

14.1 集团企业的应用架构

集团企业依托于一个稳定的主营业务做支撑，探索并发展多元化的业务形态。集团企业可能有全资子公司、控股子公司、分公司等多种公司类型，经营多个品牌，拥有多条业务线、多个业务团队，企业管理制度复杂，这些都给应用架构的建设提出了更高的要求。

图14-1 成立电商部之后的组织架构图

电商总监设计的应用架构体系包括PC端和移动端的前端应用，以及完整的后端系统，包括订单、售后、客户信息、会员、营销、账号的管理系统和CMS。此外，仓储、财务业务直接复用现有ERP中的模块，配送业务则直接与第三方配送服务商系统对接。

解决信息孤岛问题的思路很简单，就是只保留一份客户信息库。这份客户信息库只保存最核心的、与业务单元无关的客户属性和资料；至于积分、会员等扩展属性依然由各个应用系统维护管理。

解决信息孤岛问题的经典方法就是进行主数据管理（MDM），主数据管理通过应用架构的拓扑结构设计，配合相应的管理手段，帮助企业存储、识别唯一的关键数据，避免企业内部关键数据的冗余和不一致问题。常见的主数据有客户主数据、供应商主数据、商品主数据等。

14.2 加强基础服务建设，为新业务赋能

应用架构体系发展到一定程度后，各个系统都要用到的模块会被抽象出来，改造为公用的基础模块。

加强数据团队建设，设立数据挖掘与策略输出模块，丰富客户画像，加强经营分析能力，产生更多的数据策略输出。数据策略输出不仅能给在线商城提供更强劲的推荐策略，也能为CRM、运营人员提供更丰富的策略运营、精准定向活动推送支持。

架构设计既要支持业务在短期内快速发展，又要保证架构主体正确，适应未来的变化和扩展需要。

Passport系统和客户数据库是两个完全不同的概念，因为客户账号和客户数据是完全不同的：

14.3 集团强化中台能力建设

集团希望总部能够成为各业务线的大后方，提供各种支援工作；将各业务线调整为自负盈亏的独立业务单元，对它们充分授权，以便它们能够聚焦业务发展，快速响应市场变化。

在升级改造中遵循的设计思路是相同的：对通用的、重复的东西进行抽象、合并、下沉，对外统一提供支持和服务。

设立平台产品部，负责集团所有公共服务，如Msg、Auth、Pay、Passport、MDM等产品的建设工作，为所有下游业务系统提供基础产品能力支持。

只有理解企业组织架构设计、管理模式设计和产品研发设计的总体思路，才能在应用架构设计、产品方案设计上做出合理的选择，并成功地推进落地。

15.1 抽象出通用的企业级应用架构

抽象出通用的企业级应用架构

图15-1 通用的企业级应用架构图

第五层是基础服务支持系统。信息化建设达到一定程度后，企业有必要将通用功能服务化、平台化，以提升服务效率，保证应用架构的合理性。这类系统主要给其他应用系统提供基础服务能力支持。目前非常火热的中台理念，实际上就是类似的思想。

15.2 不同发展阶段的互联网企业的应用架构畅想

不同发展阶段的互联网企业的应用架构畅想

图15-2 初创企业的应用架构畅想

因为业务模式以广告投放为变现手段，因此后端系统可能没有交易类后端复杂，但基本的CMS和风控（反垃圾、反作弊、合法合规）模块必然是有的。

图15-3 成长型企业的应用架构畅想

O2O业务需要管理大量线下门店，因此GIS（Geographic Information System）不可或缺，对于实力较强的公司，可能还会开发独立的POI（Point of Information）管理系统（也有可能是GIS中的模块）。

图15-4 成熟企业的应用架构畅想

15.3 企业级应用架构设计的建议

企业级应用架构设计的建议

系统要实现松耦合、高内聚

综合考虑架构的合理性和业务发展的需要

15.4 浅谈企业架构（EA）

在EA模型中，企业架构分为四个主题，分别为业务架构、数据架构、应用架构、技术架构

后记

作为B端产品经理，应该把帮助企业解决问题作为核心目标。一方面，产品经理要善于利用软件产品解决问题，发挥软件产品的价值和优势；另一方面，也要认识到软件产品的局限性，能够跳出产品的范畴，从业务管理的视角去思考、分析问题，寻找解法。只有这样，产品经理才能不断突破自我，实现提升。

相关资料

可通过“⌘+K”插入引用链接，或使用“本地文件”引入源文件。