重点摘录——【决胜B端：产品经理升级之路】

目录

I.概述

1.1 什么是B端产品/p>

1.1.1 B端产品简介

1.1.2 业务平台方向

II.设计篇 

从业务诊断到形成方案

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

2.1.1 B端产品总体建设流程

2.1.2 B端&C端产品建设流程区别

2.2 B端业务调研流程

2.2.1 B端调研流程

2.2.2 B端业务调研的目的和分析框架目的：梳理业务现状；总结业务问题

2.2.3 

2.3 B端产品的整体方案设计

        2.3.1  核心业务流程

        2.3.2 产品定位

        2.3.3 应用架构设计

        2.3.4 功能模块设计

        2.3.5 演进蓝图设计

2.4 B端产品的细节方案设计

        2.4.1  业务数据建模

        2.4.2  流程和角色

        2.4.3  界面设计

        2.4.4  表设计

        2.4.5  数据埋点

        2.4.6  权限设计

        2.4.7  文档编写与管理

        2.4.8  UML和常用图表

III.管理篇 

产品落地并生长

3.1 B端PM与技术

3.2 B端PM与项目管理

3.2.1 为什么需要项目管理

3.2.1 为什么需要项目管理

案例-分销产品

3.3 B端产品的运营管理

3.3.1 B端产品运营岗

3.4 B端产品的迭代与优化

3.4.1 B端产品的需求管理

3.5 B端产品的数据分析

3.5.1 数据分析流程

3.6 企业级应用架构

3.7 浅谈企业架构

---

I.概述

1.1 什么是B端产品/h2>

B端产品也叫2B（to Business）产品，使用对象是企业或组织。

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

一个业务的开展可能只需要1个C端产品研发团队；但为了支撑其运作，可能还需要好几个同等规模的B端产品研发团队。

1.1.1 B端产品简介

B端产品特点：

• 强调抽象和逻辑
• 收益难以量化
• 目标用户是一个群体
• 效能第一  体验第二

B端产品部署方式：

不同盈利模式对不同产品方向的诉求：

1.1.2 业务平台方向

 根据服务对象，B端产品方向：

1.业务平台方向

a.垂直业务线

 b.基础服务业务线

 c.交易平台产品线

 2.其他

 

II.设计篇 

从业务诊断到形成方案

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

• 业务还未开展，只讨论了初步可行性，需要设计最低成本的试错方案。

不需要设计完整的产品，只需要设计一个方案，让业务以最低成本做初步尝试，论证可行后再考虑产品化支持。

• 业务已通过线下的初步验证，现需系统支持，实现线上化，全面推进业务。

需要做全面的产品化支持工作。

2.1.1 B端产品总体建设流程

 1.业务调研

1.信息收集

对内，对外，业务负责人，一线业务人员等角色进行访谈，获取全面信息。

通过业务调研找到关键业务问题，设计产品解决方案的核心前提。

2.产品整体方案设计

B端产品整体方案设计讲究体系性、结构性。

• 核心业务流程

梳理整个业务主干流程，并确定其中哪些环节需要由该产品实现线上化。

• 产品定位

明确该产品有哪些子系统，分别支持哪些业务流程和业务版块

• 应用架构

考虑改产品和公司现有系统的融合关系

• 功能模块

基于对业务理解，抽象出该产品的具体功能模块

• 演进蓝图

根据业务优先级与发展策略，置顶实现各功能模块的计划和节奏

3.产品细节方案设计

细节方案是基于蓝图，逐一分析业务细节，设计产品的具体功能。

数据建模——也叫业务建模或领域建模。

角色与流程设计会设计业务团队的组织架构和岗位编制。

界面与 表是业务用户直接看到的部分。

4.技术方案设计

需要技术人员做技术方案设计，保证软件系统在正确的技术选型和合理的技术架构下进行编码开发工作。

5.项目管理与实施

B端产品往往涉及多个业务部门，需要多个业务系统的跨端配合，如何推进跨端项目何保证项目如期高质量交付好项目管理是关键：

6.运营迭代

B端产品都存在对应的业务方，而业务部门都会设立业务运营团队。

在B端产品领域，产品经理、产品运营、业务运营三者的工作职责往往有所重叠，各自的工作内容该怎样分配作关系该怎样处理理好这些问题会让你的工作事半功倍。

2.1.2 B端&C端产品建设流程区别

B端产品是为了解决业务而设计的，设计的起点是进行业务调研，研究业务问题。

C端是要实现公司商业模式的落地。

1.MVP思路不同

B端产品要支持业务整体运作，在选取最小功能集合时，即使再简化，也要保证一个核心业务流程的运转。

C端需要解决用户痛点，聚焦核心，C端MVP可能只包含一两个功能点。

2.细节设计不同

B端产品面临复杂的业务场景和用户场景，因此进行细节设计时，必须关注建模、抽象、角色、权限等问题。

C端产品面临的场景相对单一，并且使用者是相对独立的单个用户

3.对运营的依赖程度不同

B端产品上线后，要进行全员宣导培训，产品运营工作相对简单。

2.2 B端业务调研流程

2.2.1 B端调研流程

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

目的：梳理业务现状；总结业务问题

例-业务分析框架：

 A.战略层

业务的战略定位和战略目标

B.战术层

对战略层的认知进一步具象化的层级，可从经营策略、管控模式来分析。

（1）经营策略

业务调研的目的之一是理解公司的经营策略，确保对产品的定位、形态做出准确判断。

经营策略，通俗来讲就是做买卖的思路，包括客群定位、定价策略、营销策略、渠道管理策略、供应链管理策略等，这其中的每一个主题都涉及庞大的知识体系，

（2）管控模式

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

C.执行层

执行层包含比战术层更具体的执行策略，包括管理层和运营层两方面。

• 管理层

梳理组织架构关系，对组织架构优化。

• 运营层

明确具体业务流程、绩效管理、风险控制等更加细节的规则，以便在实际运营中推进上层策略的落地。

2.2.3 

2.3 B端产品的整体方案设计

2.3.1  核心业务流程

从核心业务流程切入产品设计，是开展整个设计工作的非常好的起点。

核心业务流程代表业务的主干脉络，需要思考业务的各个参与方、涉及的系统。

2.3.2 产品定位

产品定位是对产品概要性的总结和陈述，简明扼要地描述产品对业务的支持范围，或总体的功能目标。

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

2.3.3 应用架构设计

所谓应用架构，是指公司所有产品和系统的整体结构和布局，

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

2.3.4 功能模块设计

明确了应用架构，以及需要新建或改造的系统之后，我们需要进一步细化，为每个系统设计功能模块。

这个系统应用于哪些业务场景/p>

用户可能在系统中做的操作有哪些/p>

通过思考这些问题来抽象出需要具备的功能模块。

2.3.5 演进蓝图设计

通过绘制系统的功能模块图，可以明确业务和系统的规划脉络。将能想到的功能集合都列出来，这是一个做加法的过程。

但是我们不可能一次实现全部功能，而要根据业务优先级，拆分成几期来完成，

所以接下来需要做减法：确认产品的功能规划与实现节奏，就是常说的演进蓝图（Roadmap）。

原则：

分期实现：按不同色块来区分。

一期项目——聚焦解决最基本的业务流程线上化问题及核心痛点。

（凡是可以手工处理和解决的问题，都暂时不做系统支持）

二期项目——聚焦于解决部分特殊业务刚需的诉求。

三期项目——聚焦风险控制，并强化运营功能。（当业务达到一定规模时，则必须引入系统风控机制，实现事前、事中、事后的风险控制）。

功能模块图和演进蓝图代表的是概要性方案，指明了整体的产品方向，是后续细化设计的指引和准则。

设计软件产品时必须遵循自顶向下的设计思路，

在互联 产品圈中很流行的用户体验五要素及其提出的五个设计层次，也是一种自顶向下、由粗到细的设计思路，

• 表现层
• 框架层
• 结构层
• 范围层
• 战略层

2.4 B端产品的细节方案设计

B端产品的细节方案设计包括业务数据建模、页面流转设计、界面设计、权限设计等，这些都是产品经理的必修课。

2.4.1  业务数据建模

业务数据建模，这是对业务进行抽象的过程，合理的建模会让后续的功能设计水到渠成，而不合理的建模会导致后续设计重复返工。

因为软件系统的模块和功能实际上就是对现实世界的对象和规则的抽象。

（一定要在设计细节方案之初就进行业务数据建模。）

业务数据建模也叫实体建模、领域建模，或业务对象建模，是指针对业务特点，归纳并设计对应的底层数据模型的过程。

①进行业务数据模型——②基于流程确定页面流转图——③每个页面的具体设计（需提前规划好系统用户角色）——④权限设计

2.4.2  流程和角色

流程合理、角色清晰是系统正确设计的前提和保障。

遵循自顶向下的设计思路：设计主干流程—设计页面流转图——最后完成页面细节设计。

• （1）关键路径（roadmap），里程碑
• （2）模块
• （3）功能清单细化
• （4）涉及到的逻辑流程图——关键点

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

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

有一点需要注意：不是所有的页面都来自页面流转图，因为有些页面是独立于总体流程之外的，例如 表页、对账查询页等，这些页面源自对功能模块设计的思考。

2.4.3  界面设计

1.流程：

• 绘制线框图原型，表达软件中每个页面的设计需求
• UE设计-协助PM完善交互体验，制作交互原型
• UI基于交互原型进行美工设计，生成切图文件。
• 前端工程师进行前端开发

2.尼尔森十大可用性原则

A.反馈原则（visibility of sysytem status）

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

eg：

安装程序时，显示进度条，并预估还需多久结束。

上传文件时，显示进度条，并提示预估剩余时间。

提交表单时，如果校验失败，则在填写有误的内容旁边提示错误原因。

b.隐喻原则（match between system and  the real world）

系统要采用用户熟悉的语句、短语、符 来表达意思。

遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受。

C.回退原则（User control and freedom）

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

eg：提供 撤销 、重做了、反悔的功能

电商平台允许在一定的规则下取消订单。

D.一致原则（Consistency and standards）

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

E.一防错原则（Error prevention）

系统要避免错误发生，这好过出错后再给提示。

F.记忆原则Recognition rather than recall

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

eg：常用、搜过 等等搜索场景

G.容错原则

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

H.帮助原则

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

B端产品——操作文档必要性。

2.4.4  表设计

参考：

FineReport 表  

登录 – 思迈特软件统一登录平台   

tableau

百度统计

GA：https://analytics.google.com/analytics/web/

易分析：http://www.yeefx.cn/demo.show.php

学习数据仓库知识，推荐阅读韩家玮教授的经典著作《数据挖掘概念与技术》

2.4.5  数据埋点

2.4.6  权限设计

一般包含2部分

• 功能权限

各个角色可以操作的界面、按钮等

• 数据权限

各个角色在各页面中能看到的数据范围

A.功能权限设计

设计页面的功能时，要考虑页面中的各个功能点是否要做权限控制。

2.4.7  文档编写与管理

• BRD（BusinessRequirement Document，商业需求文档）
• PRD（Product Requirement Document，产品需求文档）
• MRD（Market Requirement Document，市场需求文档）

区别：

 对于B端产品，尤其是业务系统，业务方一般都有需求管理团队，负责调研、整理业务需求，提交给产品经理。

产品经理首先需要对需求进行判断，如果发现需求质量不高，就需要和业务方反复讨论，判断需求的真实性。

文档管理、存档管理、在线化等。

2.4.8  UML和常用图表

统一建模语言UML（Unified ModelingLanguage）

A.ER图

ER（Entity Relationship）图是一种描述实体对象（Entity）之间关联关系（Relationship）的经典图表。

ER图：实体-联系图(Entity Relationship Diagram) 描述对象之间关系的规范。

矩形框：表示实体

椭圆或圆角矩形：表示 属性

菱形框：表示 实体间联系

eg：机构对象有一个字段“上级机构”，最下面表示对象所具备的函数。

两个对象间用实线连接，实线两端标上数字，描述之间的对应关系。

图：一个机构节点可对应0个到多个门店（0..* 的含义）。

 

B.跨部门流程图

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

C.状态机图 

状态机图（State Machine Diagram）也叫有限状态机图（Finite State Machine Diagram），

是一种描述所有状态及状态之间流转规则的图形。

任何对象都有状态。

设计状态的注意事项：

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

eg：订单状态：“待发货”、“待评价”，但不能是“发货中”、“评价中”。

通过研究状态之间所有可能的流转规则和逻辑，能够识别状态设计的合理性，并梳理清楚业务规则。

eg：分销业务中 ：“客户”这一对象的状态机图：

状态机有一个开始节点和一个结束节点。

圆角矩形中的内容代表状态值

D.活动图

活动图（Activity Diagram）是流程图的一种，用来描述一系列过程。

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

标准流程图的节点必须是顺序执行的，只有判断节点才能引出两条分支。

 E.用例图

用例图（Use Case Diagram）从用户视角来描述系统的操作功能。

描述：某个角色或用户在不同场景下能做什么。用户操作场景的呈现形式。

 在实际工作中，产品经理应该尽量使用简单的方式，让别人理解自己的设计和意图。

https://www.uml-diagrams.org/

III.管理篇 

产品落地并生长

3.1 B端PM与技术

1.PM懂技术的好处

• 避免产品过度设计

所谓产品过度设计，是指设计的某些产品功能价值不大，甚至没有意义，但是开发工作却很复杂、很耗时。

考虑背后实现逻辑的复杂性。

• 避免技术过度设计

所谓技术过度设计，是指技术人员设计了没有必要的代码灵活性和复杂性，而后续的业务根本用不到这些特性，宝贵的时间和资源被浪费。

• 与技术人员沟通顺畅

所谓技术过度设计，是指技术人员设计了没有必要的代码灵活性和复杂性，而后续的业务根本用不到这些特性，宝贵的时间和资源被浪费。

• 预判需求的可行性

如果产品经理具备足够多的技术知识及经验，在接到一个需求后就可以很快地判断技术实现的可行性和成本，并根据业务诉求快速给出可行的解决方案。

• 评估工时合理性

完成产品方案设计后，在和开发人员沟通时，产品经理要站在业务人员的角度，和开发人员讨论工时评估是否合理。

2.PM是否要关注技术方案

• 技术方案和产品方案相互影响
• 技术方案可能导致项目风险

例如，有些工程师喜欢尝试新技术，选用一些非常小众或新颖的技术框架。遇到这种情况，产品经理一定要严肃地和工程师、领导进行沟通确认。

B端产品要支持业务运转，追求稳定和可持续，对新技术的诉求不高。

3.PM技术知识的要求

• 理解一门编程语言
• 掌握并使用SQL

SQL（Structured Query Language）是经典的关系型数据库处理语言。

• 了解 络通信等计算机常识

例如 络与通信原理、操作系统原理、微机原理等，至少要理解TCP/IP协议、UDP协议分别是什么，二进制、十六进制的运算法则，字节和字的长度概念，对称密钥密码体系和非对称密钥密码体系的区别，等等。

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

 www.sqlteaching.com 

www.w3school.com.cn/sql

 

• 了解程序设计的MVC范式

MVC是Modeling、View、Controller的缩写，代表软件设计的分层理念。

Modeling指数据模型，View指前端交互视图，Controller指业务逻辑，

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

不论是BS架构的系统（例如通过浏览器访问的管理后台），还是CS架构的系统（例如App应用）

 （1）前端交互层

负责绘制程序界面，完成前端程序和用户的交互互动，并实现一些简单的业务逻辑，

eg：数据校验

绘制界面的编程语言有 java script /html5/php

（2）业务逻辑层

业务逻辑层负责处理业务逻辑；

业务逻辑层是MVC结构中最复杂的部分。

eg：在分销运营管理后台的门店列表页，点击“关联账 ”按钮，前端交互层把指令发送给业务逻辑层，业务逻辑层要判断门店状态是否能够关联账 、是否有空闲账 可以进行关联等。

（3）数据层

数据存储操作一般由程序来完成，例如通过程序对关系型数据库的数据进行增删改查处理。

• 熟悉接口与调用模式

所谓接口，是指两个对象进行通信的方式和协议。

软件领域的接口和硬件设备的接口类似：

eg：USB接口、耳机接口等

每种接口都有约定的格式和规范，只要在设计时遵循了约定和规范，就能进行信息交换。

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

• 同步调用模式：

在同步调用模式下，接口的调用方会一直等待被调用方返回执行结果，除非调用超时。

同步调用是最常见的接口调用形式。

•  异步调用模式

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

 一般耗时比较长的处理工作会采用异步调用模式，调用方会给被调用方提供一个回调接口，

means:你处理时间比较长，等你处理完后，再调用这个回调接口，通知我结果。

举例：

a.同步调用模式

采用同步调用模式的数据文件查询下载页面的设计案例：

在该页面，用户查询并下载CSV文件：

 具体交互与系统处理步骤如下：