重点摘录——【决胜B端：产品经理升级之路】
目录
2.2.2 B端业务调研的目的和分析框架目的：梳理业务现状；总结业务问题
I.概述
1.1 什么是B端产品？
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 功能模块设计
明确了应用架构，以及需要新建或改造的系统之后，我们需要进一步细化，为每个系统设计功能模块。
这个系统应用于哪些业务场景？
用户可能在系统中做的操作有哪些？
通过思考这些问题来抽象出需要具备的功能模块。
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 报表设计
参考：
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：分销业务中 ：“客户”这一对象的状态机图：
状态机有一个开始节点和一个结束节点。
圆角矩形中的内容代表状态值
图示：有4种状态：待审核、已生效、已停用、未通过
D.活动图
活动图（Activity Diagram）是流程图的一种，用来描述一系列过程。
活动图可以描述并发工作的执行过程，而标准流程图的节点必须是顺序执行的，只有判断节点才能引出两条分支。
标准流程图的节点必须是顺序执行的，只有判断节点才能引出两条分支。
E.用例图
用例图（Use Case Diagram）从用户视角来描述系统的操作功能。
描述：某个角色或用户在不同场景下能做什么。用户操作场景的呈现形式。
在实际工作中，产品经理应该尽量使用简单的方式，让别人理解自己的设计和意图。
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文件：
具体交互与系统处理步骤如下：
1.用户设置好查询条件，点击“下载”
2.“下载”按钮会以同步模式调用后台数据查询接口，将前端用户填写的日期作为参数传递给后端服务接口。
3.后端服务拼写SQL查询俞军，执行SQL语句并等待数据库返回结果
4.数据库返回结果后，后端服务接口组装数据，生成CSV文件，并返回给前端浏览器。
（在这个过程中，用户在浏览器端一直处于等待状态（浏览器左下角可能会有提示文字：等待服务器响应））
5.浏览器收到服务器返回的数据文件，弹出窗口，提示用户选择文件的保存位置，并执行文件下操作。
b.异步调用模式
文件查询下载：
1.用户设置好查询条件，点击“下载”按钮
2.前端提示“下载任务已提交，请耐心等待”。
后端的下载任务调度管理程序开始执行，在数据库生成一条状态“处理中”的任务记录
同时 异步调用后端数据查询 服务接口，并提供回调接口。
3.后端服务接口拼写SQL语句并执行，数据库返回结果后，程序将数据处理成CSV格式，保存在服务器，并调用回调接口；
后端服务接口程序执行结束，将任务状态更新为“成功”，并提供数据下载的链接。
4.若后端服务接口长时间没有得到数据库返回结果，超过规定时间后，下载任务调度管理程序会将任务状态更新为“失败”。
4.软件工程“搭积木”设计
软件的设计应该像搭积木那样，通过自由拼接组装来实现复杂的功能模块，这样既能保证系统的灵活性，又能避免重复开发，降低成本。
如果不能将软件分解成像积木那样的小模块，而是焊死的一块铁板，那么系统将彻底丧失灵活性。
软件工程就是在造轮子（服务接口和系统模块），对于功能相同的轮子，大家共用一套就足够了，没有必要针对每个系统重复制造功能相同的轮子。
SOA：（Service OrientedArchitecture，面向服务的架构体系）和微服务
SOA和微服务只是微服务鼓励去中心化。
ESB（Enterprise Service Bus）模块（服务的中心化调度模块）
企业的各个软件或产品并不是独立的、割裂的，而是深度结合、互相支撑的。
架构的理念在高阶的B端产品设计中非常重要，同时B端产品的设计体系和技术架构也有着一脉相承的设计思路。
理解技术架构对设计产品架构大有裨益。
3.2 B端PM与项目管理
3.2.1 为什么需要项目管理
优秀的项目管理是互联网公司在复杂环境下保证软件开发按计划推进、落地的关键，也是保障规模团队的产品研发效率和质量的核心要素。
问题：
1.发生跨端（跨系统）现象：
eg：
①因单个业务方需求，导致多个业务系统都要修改，产生跨端现象。
跨端会带来各种困难，例如难以获得其他团队支持、难以取得整体的排期。
②项目周期长：
当B端项目出现跨端现象，或者涉及流程改造等复杂需求时，都会面临较长的项目周期。而项目周期拉长，就会导致存在各种变数和不确定性，出现项目风险。
如何推进呢？
- ①明确项目收益价值
跨端项目推进的第一步就是明确项目收益价值。
分析清楚收益价值的前提是，对业务的诊断、分析尽可能全面客观，这样才能产生有效的解决方案，并推算出预期的收益和价值。
- ②找到KP并积极游说
这种方式的关键是，产品经理要找到KP（Key Person，关键人物），并积极游说，获得支持。
不论是说服业务团队、产品团队还是研发团队，都需要找到关键人物（决策人员），针对正确的对象采取“攻势”。
- ③保持强的推动力与执行力
所谓强推动力和执行力，其实就是在合适的限度内，强力推动，保证执行效果。
所以，通俗点儿说，强执行力和推动力就是指能够记着事儿，不忘事儿，上着发条追进度，盯过程，要结果。
3.2.1 为什么需要项目管理
B端项目面临的第二个挑战是项目的周期长，复杂度高，变数大，项目进度不好把控。
1.细化工作，明确交付
eg：WBS
在思路正确的大前提下，细化工作就是自顶向下的金字塔思维的实践，由粗到细，从全局到细节，拆解工作的同时既能够产生更深入的思考，也能够随时审视整体方案。
2.通过机制把控进度
- 开展定期会议（例会）
- 日报或周报
3.编写内容清晰的项目日报或周报
- 本周进展
- 项目风险
- 下周计划
- 整体进度
案例-分销产品
分销渠道：商品销售渠道之一，它介于商品的生产者和终端消费者之间。帮助生产者将商品批量推广到下游经销商或终端客户。
分销业务，薄利多销的特点。
分销业务的目标客户是大型的餐饮连锁集团，以及大型生鲜分销商等企业级客户。
母账号：跟账号；是供客户或机构用户使用的最高级别的管理员账号；
子账号一般是分配给具体业务人员使用的个人账号。
L1：调研输出示例
eg：4.5
L2：核心业务流程
eg:5.1
L3：产品定位
分销商城前台（移动端，通过H5实现）：为分销客户提供下单功能。
● 客户管理后台（PC端）：为分销客户提供子账号管理、门店管理及业务辅助功能。
● 运营管理后台（PC端）：为分销业务部门提供客户及商品定价管理的业务支持功能。
L4 :整体应用架构图：
L5：蓝图
L2
L2.1 业务数据建模
多层级组织结构树
- 组织结构对象：
深灰色节点标识，用来描述客户的行政管理层级结构。分销总部位于组织结构树的根节点上。
- 门店对象：
浅灰色节点标识，是下单的目标，是挂在某个结构节点下的收货对象。
在数据结构中称为门店，实际上可能是小门店，或中央仓。
- 账号对象：
白色节点表示，代表系统的用户。
账号也挂在某个机构节点下。在根节点下的账号，是分销管理业务后台的管理员账号，可管理整颗组织机构树中的所有数据，包括所有门店和账号。
每个账号所管理的数据范畴（包括能给哪些门店下单、能查看哪些门店数据等）
通过遍历其所在节点的所有子节点来确定的。
遍历：（traversal），指沿着某条搜索路线，一次对树/图 中的每个节点做一次访问。
访问结点所做的操作依赖于具体的应用问题， 具体的访问操作可能是检查节点的值、更新节点的值等。
ER图：
每个账号或门店对象只能隶属于一个节点；
每个门店下可以维护多个收货人。
梳理对象的关系通过数据建模ER图呈现即可。
ER图：实体-联系图(Entity Relationship Diagram) 描述对象之间关系的规范。
矩形框：表示实体
椭圆或圆角矩形：表示 属性
菱形框：表示 实体间联系
业务数据建模的过程就是将业务对象及其之间的关系抽象出来的过程，ER图呈现了业务数据建模的结果。
L2.2 流程和角色
通过跨职能分系统流程图，可以清晰地看出谁（操作角色）在哪儿（哪个系统）做什么（完成什么工作）。
L2.3 页面流转图
分销业务要开发的页面：
从本质上讲，一套软件系统就是对不同数据对象的增删改查操作的集合，这个特点在业务系统中更加显著。
L2.4 界面设计
3.3 B端产品的运营管理
3.3.1 B端产品运营岗
- saas方向：运营岗位偏销售、BD只能，属于销售管理和客户开发的范畴
- 双边市场的供给端运营方向，
- 针对内部业务系统的产品运营方向
1.B端产品运营岗
对于支持内部业务的B端产品运营岗，工作目标是通过挖掘B端产品的能力（即对现有功能进行推广、协助完成产品的升级优化），帮助企业解决业务问题。
- 产品功能推广培训
B端产品的功能上线后，一方面要在线上进行推广宣传，例如消息推送、公告通知等；
另一方面，针对比较复杂的升级改造，还需要组织业务团队进行现场培训。
- 问题解答处理
对于刚上线的系统或功能，PM可以组建试点用户群或热心用户群，搜集问题并进行快速改善。
比较高效的问题解答，处理机制应该是层层过滤的，
- 需求采集过滤
产品运营人员和一线业务人员接触多，有更多的机会了解一线人员的工作状况、感受，并收集一线业务人员的直接诉求。
- 项目效果分析
般情况下，产品经理要对上线的功能进行持续的数据分析和观察，这个工作也可以委托产品运营人员完成。
- 业务诊断分析
高阶的产品运营人员还要和产品经理、业务团队一起诊断业务，分析问题，提出解决方案，并推动解决方案落地执行。
2.B端业务运营岗
介绍业务运营岗之前，首先要明确一下什么是业务部门。
业务部门一般会分为两部分，一部分是执行具体工作的一线业务单元，往往按地域划分；
另一部分是业务体系内部支撑一线业务单元运作的业务运营部，是整个业务线的管理中枢和支持中心。
3.4 B端产品的迭代与优化
3.4.1 B端产品的需求管理
产品投产后，还需要不断收集、挖掘新的需求，进行持续的升级迭代，以完善系统功能或优化业务流程。
确认需求的优先级、确认迭代工作的计划安排，更能培养对业务的准确判断力。
1.需求的收集
需求收集的要点之一是，通过各种渠道全面、迅速地收集建议，而且，无论是否采纳，都要给出反馈，例如意见是否采纳、预期的解决时间等，这样才能形成持续的良性互动。
收集到需求后，产品经理不应该简单被动地接受、执行，而要识别需求背后的真实问题、判断需求的价值，这很考验产品经理的判断能力。
在日常工作中，产品经理要勤于思考，尽可能地理解业务，以提升自己的判断能力。
2.需求池管理
对于收集到的需求，经过初步判断、过滤后，要放入需求池进行管理跟进。
从记录在案开始，到实施上线，需求要经历完整的研发管理周期。可以通过一套项目管理软件（例如JIRA、Teambition）对需求进行管理，按照公司统一的项目管理规范来实现。
eg：
业务线：
需求类型：
产品需求、产品需求（插入）、技术需求、技术需求（插入）、线上BUG
主题：需求的一句话概述
内容：需求的具体描述
来源：需求的提出者
需求提出日期
优先级：
作为B端产品经理，一定要和业务方在原则上达成一致，客观地定义优先级并作为排期依据，否则非常容易起摩擦。
迭代版本：
业务负责人：
产品经理：
研发负责人：
测试负责人：
状态：
状态用来描述需求的生命周期，状态值可以包括如下选项：
待跟进、需求调研、需求评审、待排期、待开发、开发编码、待测试、测试验证；待验收；待上线；已上线；挂起；拒绝。
计划上线日期
实际上线日期
前端开始日期/结束日期
工期和工时是两个完全不同的概念，工期是指开发时长，工时是指工作量。
例如：
为了开发某功能，安排了2名研发人员，从9月1日开始开发，到9月5日提测，则工期是5天，工时是10人日。
如果这两名研发人员并不是同时介入的，其中一名研发人员是9月1日介入的，另一名在9月3日才介入，到9月7日提测，则整体工期是7天，但工时依然是10人日。
发版计划：
在移动端产品中，需求上线可能涉及发版，即需要发布新的客户端，因此要在表格中记录发版的版本号。
通过需求池统一评判需求优先级，管理并安排迭代计划，是产品经理最重要的日常工作之一。
如果某个需求涉及跨端或跨团队开发，则需要按照子项目将模板进一步细化，例如每个子项目要安排各自的研发负责人、产品负责人，有各自的工时、工期等，然后再填写具体字段。
3.B端产品的迭代管理
收集需求后，产品经理要根据优先级进行需求跟进和方案设计；方案设计完成后，便进入开发、迭代环节。
（1）研发资源管理
在工作中，研发人员、产品经理、业务人员之间总会有这样的争执：为什么没有排期？你们在做什么？人力都铺在哪儿了？
如果有这样一张图来清楚地呈现研发人员的工作安排，就可以避免这些争执。因此，维护好这张研发人力资源安排图，也是对研发人员的一种保护，避免他们“蒙受”工作不饱和的怀疑和指责。
（2）迭代中的技术优化资源分配
软件的代码需要不断地优化。
如果软件升级过程中只做产品功能需求，而不做技术优化，随着功能的鸡肋，软件系统会变得越来越脆弱，运行速度会越来越慢，甚至频繁宕机。
因此，在日常迭代升级中，必须给技术优化预留足够资源。
如何平衡业务需求和技术优化之间的资源分配问题呢？
a.初创阶段
在初创阶段，业务还处于 探索试错期，业务本身不一定能成功。
本阶段重点在于“活下去”。
以只预留10%的资源做技术优化，甚至不做技术优化。只要研发团队的水平靠得住，一套全新的系统在全力运转的状态下对业务支持一年的时间，应该是绰绰有余的，而一年正好是验证业务是否能够存活下去的关键时间点。
b.瓶颈阶段
经过一年探索，证明方向正确，业务取得成功，并继续保持高速发展，会出现“技术债”的问题。
对于产品研发来说，一半的资源被修复Bug和迫在眉睫的技术优化占用，另一半资源被难以维护的老代码拖住。产品研发团队既不能痛快地满足业务需求，也不能爽快地一次性解决系统结构问题。此阶段可能会持续1年到1.5年的时间，可谓整个产品研发团队的“噩梦时期”。
c.重构阶段
对于瓶颈阶段和重构阶段分别持续多久、在什么时候发生，这个问题很难准确回答，取决于业务情况、系统状况、技术团队的话语权等因素。
此外，也有“边开飞机边换引擎”的成功案例，即在不影响业务的情况下，持续升级系统，开发新功能的同时完成系统重构，但难度相对较大。需要结合具体的系统架构和实际情况来判断采取什么方案。
d.稳定阶段
该阶段业务发展稳定，系统运行平稳，Bug少，不宕机。
业务需求依然不停地提出，但此时研发工作显得井井有条。
示例：
典型的双周迭代模式
软件的开发模式既要能够快速响应市场并上线试错，又能保障开发节奏和交付质量。
双周迭代：两周完成一个迭代周期
迭代周期是指从软件开发到上线的时间。
参考：甘特图
双周迭代过程
敏捷迭代模式Scrum模式的变体
1.挑选需求并编写PRD（W1D1-W2-D4）
集中上线，是指将一系列功能点打包并
2.评审（W2D5）
PRD编写完成后，进入迭代1启动前的评审环节。
在Scrum中，评审工作叫Sprint Planning，进入迭代计划的需求清单叫Sprint Backlog。
3.技术方案设计（W2D5-W3D1）
评审结束后，研发人员要根据PRD进行技术方案设计，有的技术方案可能需要讨论几天才能确定下来。同时，产品经理开始做迭代2的准备工作。
4.开发实施与测试（W3D2-W4D4）
评审结束后，研发人员要根据PRD进行技术方案设计，有的技术方案可能需要讨论几天才能确定下来。同时，产品经理开始做迭代2的准备工作。
在这个阶段，产品经理和研发团队每天都要召开简短的站会（Scrum中的Daily Scrum），以同步信息，并快速澄清疑问、进行决策。
5.上线（W4D5）
集中上线：是指将一系列功能点打包并一次性上线，而不是每做完一个功能点就进行一次上线。
迭代1的功能上线的这天，正好是迭代2的评审日，研发人员可能白天要进行迭代2的评审工作，晚上要配合运维人员上线迭代1的功能。
同时产品经理最好和QA一起做线上功能验收，集中打包上线的交付物（在Scrum中叫Potentially Releasable Increment，即在一个Sprint中完成的产品增量）。
一个迭代结束后，Scrum流程中还有Sprint Retrospective，对迭代进行总结。
局限性：
无法保证最小功能集合可以在一个迭代周期内实现
跨端项目协同非常复杂，研发节奏互相依赖
很难准确预估工作量投入
4.选择合适的迭代模式
3.5 B端产品的数据分析
3.5.1 数据分析流程
数据分析的过程：
- 明确主题：焦点；
- 提出假设
- 验证假设
- 产生结论
统计学方面：《深入浅出统计学》。
数据分析思路方面：《深入浅出数据分析》。
3.6 企业级应用架构
建设一个系统或平台，并不是从无到有做一个独立系统，需要考虑如何和公司的其他系统融合，如何搭建系统之间的结构。
企业级应用架构正是指企业的各个软件系统有机集成在一起的方式。
好处：
- 理解企业如何运作
- 理解支撑企业运作的成熟产品方案
例如，客服业务要用到Call Center系统，用户账号体系管理要用到Passport系统，仓储业务要用到WMS，配送业务要用到TMS。
- 理解多个产品如何协作
eg：
产品建设中，往往会出现“孤岛问题”，既包括“应用孤岛”，也包括“信息孤岛”，这些“孤岛”从单一业务线来看可能没有问题，但是放在企业的整体业务中来看，就会造成各种业务问题，例如数据的割裂、流程的中断。
如果你学习过产品架构搭建的知识，就会知道借助主数据的设计思想，构建客户主数据、供应商主数据、商品主数据等，从而方便地解决这些信息孤岛问题。
- 理解应用架构是随业务发展而演变
掌握企业级应用架构的全貌，能够拓宽自己的视野，思考问题时能够跳出自己负责的业务和产品的范围，尝试从企业、行业、产业的视角考虑，尤其是从企业整体经营发展的角度去思考、设计方案，能有效地锻炼并培养自己的大局观。
企业级应用架构设计建议：
- 业务定位和边界要清晰
一套应用系统是为了解决某一类业务问题而存在的，对应某一个业务模块。
如果业务部门本身权责定义混乱，必然导致对应的应用系统定位混乱，进而导致后续的维护、升级、管理困难。
- 系统要实现松耦合、高内聚
业务的需求是在不断变化的，这要求应用系统是灵活、可扩展的。
一个扩展性强的应用系统，对外界来说，应该是简单、易理解的，与外部系统的接口应该简明、可拆解；
在系统内部，各个模块应该是高度聚合的，模块之间要实现松耦合
- 不要让易变的新业务影响现有业务的稳定性
可以考虑新建独立的微小型应用系统来支持新业务，以避免改造成熟核心系统，影响其稳定性和健壮性。
- 系统之间要实现数据的单向流转
系统之间应尽量保证数据单向流转，确保数据流可回溯，这样才能保证数据的一致性和可追溯性。
- 综合考虑架构的合理性和业务发展的需要
应用架构设计的首要目标是支持业务发展。
对于某条产品线的负责人和产品经理来说，也要在架构的合理性和整体的业务需求之间做出权衡。
- 深入思考新系统与旧系统的关系
产品经理则要在自己负责的版块思考类似的问题，识别潜在的系统架构风险，必要时升级汇报问题，避免做出错误决策。
3.7 浅谈企业架构
EA（Enterprise Architecture）
或称为EAF（EnterpriseArchitecture Framework）
在EA模型中，企业架构分为四个主题，分别为业务架构、数据架构、应用架构、技术架构
- 业务架构
（Business Architecture）：关注组织架构、领域模型、业务需求、业务规则、业务流程等要素。
- 数据架构
（Data Architecture）关注数据集成、主数据管理、元数据管理、数据治理、数据安全性等主题。
- 应用架构
（Application Architecture）：，关注软件系统设计与公司经营管理的关系。
应用架构既可以理解成软件系统的设计模式（偏技术），也可以理解成软件系统在应用功能层面的逻辑关系和视图。
- 技术架构
（Technology Architecture）：关注服务器、网络、中间件、操作系统等偏技术层面的要点。