🌟《决胜B端》

概述篇

第一章：互联网产品领域探秘

产品经理发展历程

互联网行业的产品方向

什么是B端产品

1.B端产品的特点

• 目标是是一个群体

• 效能第一体验第二

  B端产品的目标是解决组织的某类业务问 题，因此聚焦于流程，提升业务效能是最重要的，打磨交互体验则处于 次要地位。例如，产品设计时并不会过多地考虑UI设计，也不会为了几个按钮的摆放位置花费太多时间，即便某个功能的交互设计不太符合常理，业务人员为了完成工作也还是会使用软件（但这并不意味着B端产品经理可以无视交互体验）。

• 强调抽象和逻辑

• 收益难以量化

2.B端产品部署方式

• 私有化部署
• 云部署

3.B端产品的技术构架
B/S构架：浏览器/服务器模式
C/S构架：客户端/服务器模式（每次软件升级都需要更新客户端，现在很少使用，除了原声代码编写的移动端App）
B端产品分类

4.对企业内部的B端产品

• 核心业务系统：例如仓储系统、CRM系统
• 办公协同系统：OA系统、HRM系统

5.对企业外部的B端产品

• 后台系统

什么是数据与策略产品

BI产品，对企业内外部数据挖掘并利用的产品，产出报表、可视化内容；重点在于指标体系，内在逻辑是否合理，而不在于可视化效果是否炫酷。
产品经理工作方向：

• 数据仓库建设
• 报表设计
• 算法策略输出
• 数据监控

分类

• 对内：可视化报表或策略算法输出
• 对外：将企业数据或算法或报表工具提供给企业内部使用

什么是商业变现产品

将流量转化为收入的产品

• 搜索引擎营销
• 广告投放平台
• 在线广告联盟
• 增值服务

什么是AI产品

利用人工智能技术的产品

互联网公司的盈利模式

1. 广告变现
2. 增值服务
3. 佣金提成

4. 买卖差价

   第二章：B端产品概述

   互联网行业的发展趋势

5. 流量变得珍贵，竞争激烈——需要深入介入线下

6. 线下业务渗透程度越来越高
7. 业务模式越来越重
8. 运营效率成为核心竞争力
9. 产业互联网成为新的蓝海

以上的这些特征都表明企业需要B端产品助力

从事B端产品方向的优势

B端产品需要涉足软件设计和业务运营领域，有机会深入理解企业运作机制。

B端的机会

1. 业务模式创新需要更多的B端产品经理 （案例：美团和今日头条端对比）

   对个人的好处

2. 全面的能力培养

   1. 逻辑思维与抽象能力
   2. 技术知识储备
   3. 复杂项目管理能力
   4. 业务与经营管理知识
3. 广阔的职业发展空间
   1. 产品设计
   2. 业务运营
   3. 咨询顾问

4. 具壁垒性的专业经验

   B端产品有哪些方向

   以下分类并不严格，只是为了形成宏观的感受
   

   如何转型B端产品方向

5. C端产品经理

6. 数据与策略产品经理
7. 商业变现产品经理
8. AI产品经理

9. 技术人员

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

10. 传统IT人

设计篇

第三章：B端产品建设概述

B端产品的总体建设流程

• 业务还未开展，只讨论了初步的可行性，需要设计最低成本的试错方案。 （只需要试错方案）
• 业务已经通过线下的初步验证，现在需要系统支持，实现线上化，全面推进业务。（全面产品化的支持工作）

业务调研

全面研究并理解业务的现状和规划，找到关键业务问题。
尽可能的用各种手段和工具收集业务关键信息，包括访谈问卷之类，可以邀请技术负责人一起参与业务调研，确保对业务的理解是一致的。

产品整体方案设计

1. 核心业务流程：梳理整个业务流程主干流程
2. 产品定位：明确该产品有哪些子系统，分别支持哪些业务流程和业务模块
3. 应用架构：考虑该产品和公司现有系统的融合关系
4. 功能模块：基于对业务的理解，抽象出该产品的具体功能模块
5. 演进蓝图：根据业务优先级与发展策略，制定实现各功能模块的计划和节奏

在这一阶段，所有参与者需要通过讨论得出一致认可的结果

产品细节方案设计

1. 数据建模
2. 角色与流程设计
3. 界面与报表，最好系统可以体验的交互界面

   技术方案设计

   项目管理与实施

   运营迭代

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

• B端先做业务调研，C端做市场分析和用户分析（如果是saas系统，卖产品给客户，那么和C端一样，做市场分析和用户分析）
• B端MVP（最小可行产品）也很复杂，但是C端可能只需要解决1、2个核心痛点。思路一致，先做加法，穷举所有可能性，再做减法，选核心需求点设计方案然后落地，最后进行迭代。
• B端细节上关注建模、抽象、角色、权限等问题。C端关注交互设计
• C端相对B端更加依赖运营

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

案例背景和目标

搭建分销业务平台，支撑公司快速发展端分销业务

制定工作计划

进行倒逼排期

第四章：B端产品业务调研

B端业务调研的流程

明确调研目标

选取调研对象

B端业务调研，一般包括业务高管、业务经理、一线业务人员、合作伙伴高管、合作伙伴经理、合作伙伴一线人员等。

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

确认调研方法

调研方法包括定性分析法和定量分析法，具体包括访谈、轮岗实习、问卷调研等方法。

执行调研计划

调研结束后需要整理素材或资料，保证获取等所有信息都能被及时准确等记录下来。

总结归纳输出

需要注意，设计良好的B端系统能够规范流程、提升效率，但这不代表所有的业务问题、管理问题都可以通过软件系统来解决。
在梳理问题时就要做出判断，哪些问题可以用软件系统提效，哪些问题 和软件系统无关，更适合用线下方式处理。

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

战略层🔖

战略定位和战略目标

研究公司战略的五力模型

分析外部环境的PEST模型

1. 政策 Political
2. 经济 Economic
3. 社会 Social
4. 技术 Technological

分析内部业务的波士顿矩阵

战术层

经营策略：包括客群定位、定价策略、营销策略、渠道管理策略、供应链管理策略等
管控模式

执行层

管理层
运营层

B端业务调研的方法

深度访谈

1. 准备好访谈大纲：思路、大纲、问题，想要通过访谈了解什么
2. 从高级别人员开始访谈，从整体到局部，先抓住关键问题
3. 提前研究访谈对象
4. 和访谈对象保持联系

轮岗实习

直接深入一线，实习一两周

调研问卷

1. 激励用户完成填写：告知问卷设计目的，预计占用时间
2. 控制好开放式和封闭式问题：建议大部分选用封闭式问题，可以留1-2个开放式问题
3. 避免诱导性问题
4. 谨防“幸存者偏差”

数据分析

调研时，有必要掌握业务的关键过程指标和结果指标

行业研究

1. 研究针对业务相关领域的经典管理案例
2. 研究市面上同类业务的商业软件特点

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

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

业务现状梳理

经营策略

管控模式
事权下放的管控模式：下属部门在遵守基本规则的前提下拥有售卖定价权、运营管理权等权利。

组织架构

业务流程
使用管道图

业务问题总结

关键业务问题梳理

1. 生鲜实时变价，每次下单要根据折扣表手工计算价格，效率低，易出错。
2. 不能及时控制账期客户的回款进度和账期风险。
3. 对账和开票工作复杂，需要处理大量数据表，容易出错。
4. 因为没有实现客户的子母账号管理体系，所以无法实现客户总部集采、大区集采、城市集采、门店自采等混合采购模式。
5. 因为无法标识特殊客户的特殊订单，因此不支持特殊分拣、配送要求，例如做不到针对某些特殊客户的订单提供蔬菜预加工和加急配送

解决方式

1. 实现客户自主下单（高优）。
2. 实现系统自动定价（高优）。
3. 支持客户多门店分别定价与下单（高优）。
4. 实现对账报表（高优）。
5. 运营人员聚焦参数设置、审核和异常问题跟进（高优）。
6. 将运营工作下放到各城市分部（中优）。
7. 支持账期和预付款模式（低优）。
8. 系统实现账期风控（低优）。

第五章：B端产品整体方案设计

核心业务流程

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

产品定位

• 首先在分销业务中，客户需要一个快速下单的工具，可以提供一个手机版商城C端。考虑到投入产出比，公司决定通过H5来实现，而不是App。H5所写的网站具有独立域名，外网可访问。
• 其次，需要为客户提供一套方便操作的管理后台，因为涉及大量的商品定价编辑、处理，账号、门店管理等功能，所以考虑PC版本实现，暂不支持手机版。
• 最后，考虑到客户管理员和M公司管理人员的管理诉求不同，操作功能和页面差异较大，所以决定将管理后台拆解为两个独立的系统：给客户管理员使用的客户管理后台具备独立域名，外网可访问；给M公司管理人员（和运营人员）使用的运营管理后台也具备独立域名，但仅限内网访问。

最后拆分为三个独立系统

• 分销商城前台（移动端，通过H5实现）：为分销客户提供下单功能。
• 客户管理后台（PC端）：为分销客户提供子账号管理、门店管理及业务辅助功能。

• 运营管理后台（PC端）：为分销业务部门提供客户及商品定价管理的业务支持功能。

  应用架构设计

  第十二章开始详细描述
  在设计一套新系统时，必须考虑如何和公司现有系统架构融合，不同系统的模块之间如何衔接。

• 有现有系统或模块时，是否可以复用现有的系统或模块？

• 如何维护、管理客户数据？
• 如何管理客户账号体系
• 如何连接订单和仓配系统
• 后端系统的权限管理

与公司现有架构的融合

功能模块设计

分销前台功能模块

分销后台功能模块

分销运营管理后台的功能模块图

演进蓝图设计

设计软件产品时遵循自顶向下的设计思路，互联网的用户体验五要素，也是一种自顶向下，由粗到细的设计思路

第六章：B端产品细节方案设计

构建业务数据模型——基于流程确定页面流转图——每个页面具体设计

业务数据建模

业务数据建模的时候需要注意可扩展性

设计理想版的分销业务客户模型

我们首先会设计一套理想版的客户模型结构，该模型实现了B端常见的比较复杂的组织架构设计。但是理想版客户模型的开发成本很高，为了降低开发的复杂度，我们会进一步演示如何在既满足业务诉求，又并保证模型灵活性和扩展性的前提下，对模型进行精简，得到一套简化版的客户模型结构。 :::info 之前做的铁塔项目也是如此，我虽然做了一版自己理想化，所谓注重用户体验的模型结构，但是实际开发难度很高被否决了，为了降低开发复杂度，最后用的是最简单的维护。 :::

设计简化版的分销业务客户模型

组织机构对象、门店对象、账号对象

ER：描述对象之间关系的图（1:N还是N:1）

简化版的分销业务组织

简化版的客户模型ER图 :::info 最后使用的是简化版的模型，随时也可以升级成高级的客户模型（理想化客户模型） :::

理清了账号、门店、机构和收货人之间的关系，实际上已经把分销业务中最独特、最复杂的逻辑和规则都梳理清楚了，接下来进行页面和功能设计时便会胸有成竹。

业务数据建模错误会导致灾难

如果是1对多，实际业务扩展之后，可能变成多对多，那么改变是非常大的，很多功能性代码可能都要重写。但是也不能所有的内容都是多对多，比如确定的内容，一个订单只能到一个门店提交，这种必须是1对多。
理清ER关系图，确定业务数据底层结构，并且这个底层结构最好不要变动，变动带来的开发难度将非常大。

流程和角色

细化业务流程图

在粗粒度流程图的基础上，画出细粒度流程图
区分不同的角色，描述不同角色在不同子系统中需要完成的具体工作。

绘制页面流转图

绘制页面流转图可以帮设计人员审视、思考系统中的页面设计方案，包括系统中总共需要哪些页面，哪些页面可以重复使用，哪些页面需要定制化开发。

界面设计

界面设计流程

1. 产品经理绘制线框图原型，表达软件中每个页面的设计需求。
2. UE设计师协助产品经理完善交互体验，并制作交互原型。
3. UI设计师基于交互原型进行美工设计，生成切图文件。
4. 前端工程师拿到切图文件，进行前端开发，包括实现交互、动效等。

   线框图绘制

   

   尼尔森十大可用性原则（交互设计理论）

• 反馈原则（Visibility of system status）

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

• 隐喻原则（Match between system and the real world）

系统要采用用户熟悉的语句、短语、符号来表达意思。遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受。

• 回退原则（User control and freedom）

用户经常会不小心操作错误，需要有一个简单的功能，让程序迅速恢复到错误发生之前的状态。

• 一致原则（Consistency and standards）

同样的情景、环境下，用户进行相同的操作，结果应该一致；系统或平台的风格、体验也应该保持一致。

• 防错原则（Error prevention）

系统要避免错误发生，这好过出错后再给提示。例如，有些时候，为了防止用户重复提交或重复点击，第一次点击按钮后就将按钮置灰，直到处理完成才恢复。

• 记忆原则（Recognition rather than recall）

让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担。

• 灵活易用原则（Flexibility and efficiency of use）

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

• 简约设计原则（Aesthetic and minimalist design）

对话中不应该包含无关的或没必要的信息；增加或强化一些信息就意味着弱化另一些信息。重点太多，相当于没有重点。

• 容错原则（Help users recognize， diagnose， and recover from errors）

错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码；提示错误信息时要给出解决建议。

• 帮助原则（Help and documentation）

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

列表页经典设计方案

• 选择显示哪些筛选项
• 筛选项的默认值
• 筛选结果的列显示

列表页设计Bug“找茬儿”🔖

界面设计的建议

• 借鉴成熟软件
• 善于使用模版
• 采用标准控件

很多产品新人喜欢在界面设计或交互设计上做太多的创新，实际上大可不必，因为B端产品的用户需要的是解决业务问题、提高效率，交互体验并不是他们最在意的，而且复杂的界面和交互设计会增加研发的工作量。

报表设计

报表设计与应用流程

• 构建分析体系

首先要明确分析目的，即需要通过分析发现哪些方面的问题；然后思考该采用什么方法来识别、诊断这些问题，其中可能的困难是什么。

• 定义观察指标
• 设计呈现形式

很多倾向的是将具体数值直接显示，而不是使用折线图之类的内容，折线图之类的内容，数据难免会有折叠显示

• 跟踪指标变化
• 分析变动原因
• 跟进处理问题

报表引擎

一句话总结，什么视觉酷炫交互不重要，强烈建议采用成熟报表引擎。
作者推荐的报表引擎

但是以上的软件都是付费的，所以可能要去和公司申请，看具体使用哪个合适，不然可能因为成本问题而搁置

二维表格设计要点

• 数字右对齐
• 千分符，全球商务界通用
• 保持小数点后位数的统一
• 去除不必要的小数位
• 使用占位符

报表设计的建议

• 聚焦业务分析本身，不要把太多精力投入到交互体验设计上
• 不要急于线上化

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

• 上线后不要急于推广

需要将线上系统计算的结果和线下计算的数据对比，分析其中原因，但并不能认为线下手工计算的、长期使用的数据就一定是正确的。

• 理解掌握数据仓库原理

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

推荐阅读

数据埋点

对用户的操作步骤、网站流量进行监控

常见B端埋点工具

埋点工具的数据分析

• 桑基图
• cohort分析图
• 热力图

B端产品与C端产品数据埋点端区别

B端：验证是否帮助用户提高了效率，功能设计是否合理
C端：持续优化设计与用户体验，提高留存

权限设计

功能权限设计

这里要点是门店详情和门店创建页面是点击按钮跳转的，但是仍然需要进行页面级别的权限控制，否则用户只用url仍然可以访问该页面。

RBAC权限模型

Ravi Sandhu提出的RBAC（Role Based Access Control）模型，描述了一套用户、角色、权限组的设计理念

用户组的概念，有新员工时只需加入用户组，相关的权限就会分配给对应的人。
操作者只需修改用户组与权限的关系、用户组与用户的关系，而不需要一个改变，一个一个对对象进行关联和修改。

相关知识：RBAC96体系

数据权限设计

针对数据权限的控制，常见的实现方案如下。

• 方案一，通过组织机构树控制。该方案根据账号所在组织机构树中的节点位置，来判断能够查询的数据范围。这种方式最复杂，但最灵活，能够支持各种复杂的业务数据权限诉求。
• 方案二，通过客户地区控制。该方案根据账号所在区域来判断允许查看的数据范围。这种方式简单、容易实现，但灵活性差，只能满足非常初级的数据权限管理诉求。

文档编写与管理

商业需求文档（BRD）

产品需求文档（PRD

还要强调一点，产品经理不必急于写PRD，而要完成模型设计、流程设计、界面设计、权限设计等工作后，再编写PRD。否则，如果方案还没有理清就开始编写文档，会思绪混乱，不断返工。

文档管理要点

命名规范
公司缩写+事业部+文档名称+版本号
例如，
M公司分销业务运营管理后台PRDv1.0.docx
或者
M公司分销业务_运营管理后台PRD_v20190513.docx

UML与常用图表

常用软件：visio（windows），omnigraffle（macos），processon（在线）

ER图

表示可以对应0个到多个

表示可以对应1个到多个，至少对应一个

跨部门流程图

也就是泳道流程图

状态机图

• 状态值必须是有限的集合，状态的所有枚举值（即状态值）必须能够涵盖所有实际可能的情况。
• 状态值之间要互斥，不能出现二义性。
• 为了更准确细致地描述事物，状态还可以具备子状态，比如订单状态“已取消”，可以定义对应的子状态“客户取消”“商家取消”“系统取消”。
• 状态应该是能持续一定时长的，而不应该是很快就会结束的瞬时态。例如，订单的状态可以是“待发货”“待评价”，但不能是“发货中”“评价中”。

活动图

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

用例图

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

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

两段有趣的对话

懂技术的产品经理和不懂技术的产品经理的区别

产品经理是否要懂技术

懂技术将大有裨益

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

两种情况下需要关注

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

• 技术方案可能导致项目风险。

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

  具备基本的技术知识体系

• 理解一门编程语言C++/JAVA

• 掌握并使用SQL
• 网络通信计算机常识 | 推荐资料 | 《编码——隐秘在计算机软硬件背后的语言》 | | —- | —- |

我们常用的鉴权有四种：
1、HTTP Basic Authentication
2、session-cookie
3、Token 验证
4、OAuth(开放授权)

了解程序设计MVC范式

熟悉接口与调用模式

1. 同步调用（常见）
2. 异步调用

理解软件工程的“搭积木”设计

在技术体系中，有两个非常重要的概念在支撑着接口化、服务化的设计理念的落地，即SOA（Service Oriented Architecture，面向服务的架构体系）和微服务。SOA和微服务从本质上讲区别不大，只是微服务鼓励去中心化，例如，图7-13中间一层是“服务编排管理”，在传统企业的SOA落地方案中，这是很重要的ESB（Enterprise Service Bus）模块（服务的中心化调度模块），而按照微服务理念设计的方案中则不会有这一层。

掌握并使用SQL

我们所说的数据库主要是指关系型数据库
数据库表

• 每个数据库表都有一个唯一标识id
• 一对多的关系：我们让表7-1中的ORG_ID字段与表7-2的ID字段一一对应，这样两张表就被联系起来了，就可以描述一对多的关系了。

管理篇

第八章：B端产品的项目管理与实施工作

为什么需要项目管理

公司发展到一定程度，需要项目管理进行规范，提升效率

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

• 设立并优化项目管理制度

• 负责大中型项目的立项实施

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

  面临的挑战

• 跨端

• 跨段导致的项目周期长

  如何协调并推动跨端协作

• 公司级：领导重视

• 非公司级：

  • 明确项目收益价值
  • 游说KP（key person 关键人物）
  • 催进度（每天催）

    如何把控项目进度

• 细化工作，明确交付

• 通过机制把控进度
  • 定期例会
  • 日报周报
• 有责任心

  第九章：B端产品的运营管理

  B端产品运营岗

  B端主要是针对内部业务系统的产品运营方向

  主要工作内容

  产品功能推广培训
  问题解答处理
  需求采集过滤
  项目效果分析
  业务诊断分析

B端业务运营岗

管理模式

一线的业务运营岗和中央管理的业务运营部

工作内容

• 业务支持
• 流程管理
• 策略制定
• 绩效考核制度制定
• 培训考核
• 系统运营
• 项目管理
• 合规质检
• 数据分析

产品经理、产品运营、业务运营如何协作

调整、尝试不同的组织架构

第十章：B端产品的迭代优化

B端产品端需求管理

需求的收集

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

C端的kano模型并不适用

需求池管理

B端产品的迭代管理

研发资源管理

技术优化资源分配

初创阶段：做好业务，活下来
瓶颈阶段： “技术债”问题出现：曾经的设计缺陷、硬编码、架构不合理等问题逐渐凸显出来，同时还有业务问题，开始还债。
重构阶段：必须重构系统，包括代码解耦、拆库拆表、中间件升级、接口化、服务化等。80%时间优化
稳定阶段：10%时间优化

典型的双周迭代模式

不同颜色代表不同迭代周期，每个周期包含以下步骤

1. 挑选需求并编写PRD
2. 评审
3. 技术方案设计
4. 开发实施与测试
5. 上线

双周迭代模式的局限性

• 无法保证最小功能集合可以在一个迭代周期内实现
• 跨端项目协同非常复杂，研发节奏互相依赖
• 很难准确预估工作量投入

  选择合适的迭代模式

  瀑布模式
  敏捷开发

第十一章：B端产品端数据分析

数据分析的流程

明确主题

主题不能太宽泛，如果太宽泛需要细化

提出假设、验证假设

实际上，数据分析的过程就是不停地提出假设、验证并修正假设，最终获取真相的过程。不要担心提出的假设是错误的，这远好过没有假设，因为没有假设就没有切入点，分析工作会更加束手无策，理不出头绪。

得出结论

案例

数据分析的要点

需要方法工具、业务知识、细心耐心

• 统计学：掌握基本统计学常识，帮助自己判断、认识数据特点。例如，要理解方差、均值、中位数、众数等概念。
• Excel：Excel具备各种强大功能，足以作为初级、中级数据分析工作者的首选甚至唯一工具。
• SQL：掌握SQL可以快速提取原始数据，并完成数据预处理。
• 数据可视化：在工作实践中，多数情况下都是通过观察图表来发现、识别问题的，采用合适的图表形式，可以让分析更直观、高效，例如通过瀑布图、直方图、桑基图等观察数据特征和变化情况。
• 计算机数据基础：有的时候我们需要对原始数据进行一些编码处理，这就需要理解一些编码基础知识，例如什么是ASCII、UTF-8、UTF-16、Unicode，如何通过UltraEdit等软件进行编码处理（例如，有时在Linux环境下运行SQL语句，导出的数据需要进行编码转换才能在Windows环境下使用，如果自己不会处理，就需要每次都求助于人）；此外还要了解计算机常见的数据存储格式，例如CSV、JSON、XML等。
• 正则表达式（Regular Expression）：正则表达式是一种非常巧妙的、用来处理文本的逻辑公式，在某些时刻，使用正则表达式可以解燃眉之急。
• 数据分析方法论：基于不同的分析诉求，有很多成熟且经典的数据分析方法论，例如分析C端产品的获客增长模型AARRR、分析客户消费行为特征的RFM模型、分析留存率的COHORT模型，这些方法论中蕴含了成熟的分析思路和手段，是针对各种确定的分析场景的最佳实践。

更高阶的数据分析技能和知识还包括Python、SPSS、ETL、数据仓库等，适合专业的数据分析师学习。

推荐书籍

数据分析报告

报告编写思路

• 提出论点：介绍背景以及分析的结论
• 进行论证：要有数据支持，数据要专业易读，最好配丰富、清晰的图表
• 陈述总结：加深阅读者和听众印象。

报告排版美化

资源推荐

进阶篇

第十二章：企业级应用架构概述

什么是企业级应用架构

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

• 加深对业务和产品设计的理解
• 培养大局观
• 获得更好的职业发展

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

第十三章：传统企业的应用架构演变

小微型企业的应用架构

小门店：使用excel管理

小超市：使用erp系统

中等规模超市：CRM系统

中型企业的应用架构

组织架构

建立DW和BI

数据仓库和bi报表进行数据分析

建设OCRM系统

销售人员专用的crm系统

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

集团企业的应用架构

互联网化管理

开启线上业务，需要想要的技术支持

信息孤岛问题解决办法：主数据管理（MDM）

主数据管理通过应用架构的拓扑结构设计，配合相应的管理手段，帮助企业存储、识别唯一的关键数据，避免企业内部关键数据的冗余和不一致问题。

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

将通用功能抽象成基础服务

将通用功能接口化、服务化，可以不同地方进行调用

强健的基础服务支持新业务快速搭建

集团强化中台能力建设

第十五章：通用的企业级应用架构设计

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

包括数据底层、基础服务、业务应用、C端应用模块

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

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

• 业务定位和边界要清晰
• 系统要实现松耦合、高内聚
• 不要让易变的新业务影响现有业务的稳定性
• 系统之间要实现数据的单向流转
• 综合考虑架构的合理性和业务发展的需要
• 深入思考新系统与旧系统的关系

  浅谈企业架构（EA模型）