决战B端-产品经理升级之路

笔者根据《决胜B端》这本书梳理了一套知识体系或者学习笔记，它介绍了B端产品设计的一套完整流程，给了处在产研开发流程极不规范的业务中的我极多的信息补充。一些方法和流程是在实际工作开展中能实际上手应用的。对于尚不能熟练应用的你我他，应该要常读多读反复读这本书，多应用，勤复盘。希望能对你有所帮助！

决战B端

设计解决方案

产品整体方案设计

核心流程

产品定位

产品定位是对产品概要性的总结和陈述，简明扼要地描述产品对业务的支持范围，或总体的功能目标。产品定位要说清楚产品针对谁提供什么支持。

根据分析，将分销系统拆分为三个独立系统，每个系统的定位不同：

分销商城前台（移动端，通过H5实现）：为分销客户提供下单功能。

客户管理后台（PC端）：为分销客户提供子账号管理、门店管理及业务辅助功能。

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

应用架构

功能模块

分销商城前台的功能模块图

分销客户管理后台的功能模块图

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

演进蓝图

一期项目聚焦解决最基本的业务流程线上化问题及核心痛点（例如对账功能），在图5-7中用白色矩形表示。一期项目要实现哪些功能？有一个原则可参考：凡是可以手工处理和解决的问题，都暂时不做系统支持。例如，报表管理功能可以通过定期运行SQL语句实现；价格系数设置功能的使用频率低，可以由RD在后台改数据库完成；缺少搜索、推荐功能并不会对客户下单的效率产生明显影响，因为根据调研，目前每个客户维护的SKU数量最多也不过20个。

二期项目聚焦于解决部分特殊业务刚需的诉求。对于M公司的分销业务，需要支持预付款模式、账期模式、发票管理，如果时间允许，还可以实现报表查询的若干功能。在图5-7中用浅灰色矩形表示。

三期项目聚焦风险控制，并强化运营功能，在图5-7中用深灰色矩形表示。一般来讲，很多互联网公司初期都会聚焦于业务本身，提升GMV（成交总额）、验证可行性，不会太在意成本和风险控制。当业务达到一定规模时，则必须引入系统风控机制，实现事前、事中、事后的风险控制。

产品细节方案设计

数据建模

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

理想的分销业务客户模型

分销业务的组织机构树

多层级组织机构树，树中存在三种对象：

·组织机构对象，图中用深灰色节点表示，用来描述客户的行政管理层级结构。分销总部位于组织机构树的根节点上。

·门店对象，图中用浅灰色节点表示， 是下单的目标，是挂在某个机构节点下的收货对象。在数据结构中称其为门店，实际上有可能是小门店，也可能是中央仓。

·账号对象，图中用白色节点表示，代表系统的用户。账号也挂在某个机构节点下。在“分销总部”根节点下的账号，是分销业务后台的管理员账号，可以管理整棵组织机构树中的所有数据，包括所有的门店和账号。每个账号所管理的数据范畴（包括能给哪些门店下单、能查看哪些门店的数据等），是通过遍历其所在节点的所有子节点来确定的。

概要

将几种对象的关系通过数据建模ER图

简化的分销业务客户模型

简化的分销业务的组织机构树

概要

将几种对象的关系通过数据建模ER图

产品经理如果了解一些数据库的基本知识，对于设计正确的ER图很有帮助。

流程角色

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

业务角色

分销业务在M公司内部包含如下几个角色：

·分销–销售人员：M公司分销业务的销售人员，负责完成客户开发与合约签订（目前继续采取线下作业的方式）。

·分销–管理员：M公司分销业务总部的管理人员，主要负责审核分公司提交的创建客户的申请，核查各分公司维护的价格系数表，并进行毛利核算。

·分销–运营人员：M公司分销业务总部的业务运营人员，负责具体的客户创建、维护、报价单维护等事务性工作。分销业务客户包含如下几个角色。

·客户–管理员：分销客户的管理员，维护并管理客户公司内的所有子账号、门店。

·客户–采购员：分销客户的采购人员，负责给门店下采购单、补货。

业务流程图

基于定义的角色更新泳道流程图，描述各个角色的用例

分销业务的页面流转图

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

分销业务要开发的页面（部分）

概要

从本质上讲，一套软件系统就是对不同数据对象的增删改查操作的集合

界面报表

界面设计

细化到每个操作需要访问哪些页面、总共有哪些页面，为每个页面设计具体的交互功能

界面设计流程

在团队分工明确、人力储备充足的情况下，在开发一套全新的B端业务系统时，界面设计的流程一般如下：

1. 产品经理绘制线框图原型，表达软件中每个页面的设计需求。

2. UE设计师协助产品经理完善交互体验，并制作交互原型。

3. UI设计师基于交互原型进行美工设计，生成切图文件。

4. 前端工程师拿到切图文件，进行前端开发，包括实现交互、动效等。

线框图的绘制

报表设计

任何业务的开展和运转都需报表，报表是业务管理中不可缺少的工具。业务报表的核心价值是掌握事实、发现问题、分析原因、产生对策。

报表设计与应用流程

构建分析体系

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

定义观察指标

确定观察指标，设计具备明确业务含义的指标来考量业务。一般会先从大的方面拆分出几方面的观察指标，然后考虑是否将指标进一步拆解为二级指标，甚至三级指标，从而在更精细的维度观察、分析业务，更准确地反映业务特征。

设计呈现形式

确定了观察指标后，我们要思考以什么形式呈现这些指标，以便用户能够准确、快速地理解、掌握指标以及变化特征。例如，是采用数据表格还是柱状图呢？在这个环节，产品经理要和实际用户多讨论，寻找最佳的呈现方式。

跟踪指标变化

管理要用数据说话，报表数据就是诊断和决策的依据。管理人员要认真对待、分析报表中各种数字的变化、波动。如果只是走马观花地浏览报表，看不出任何问题，报表就失去了意义。作为一名管理人员，必须对数字非常敏感，能够快速地感知并解读数字背后的变化和问题，这是出色的管理人员必须具备的素质。

分析变动原因

如果指标发生了明显的波动，需要跟进分析波动的原因，分析工作可以由数据分析师完成。业务团队最好每周分析上周数据走势、变化背后的原因，以便及时、准确地掌握业务变化情况及原因

跟进处理问题

分析出问题后，下一步当然是给相关部门或人员安排工作，解决问题，这也是报表设计的初衷

概要

报表引擎

1. 明细报表

2. 汇总报表

3. 动态仪表盘

4. 套打报表

概要

本节中提到的两个报表引擎的

demo地址如下：

http://demo.finereport.com

http://demo.smartbi.com.cn

报表设计建议

1. 聚焦业务本身

2. 不要急于线上化

3. 上线后不要基于推广

4. 理解掌握数据仓库原理

推荐阅读韩家玮教授的经典著作《数据挖掘概念与技术》

数据埋点

数据埋点设计是产品交互设计过程中必须同时进行的工作，数据埋点是考核产品使用程度的一个重要依据，改善的重要参考数据来源。

数据埋点流程

国内使用比较多的

■ Web端埋点工具：Google Analyt-ics（GA）、百度统计

■ 移动端埋点工具：GrowingIO、诸葛IO、神策

埋点工具的数据分析

1. 基本分析

2. 桑基图

3. Cohort分析图

4. 访客分析

5. 热力图

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

诉求不同

B端产品，尤其是业务系统，往往借助埋点观察并研究用户对各项产品功能的接受程度、使用情况，以及用户的操作习惯等，从而进一步评估功能设计是否合理，是否帮用户提高了效率等，为持续优化提供依据。

C端产品通过数据埋点来持续优化设计。C端产品对交互设计要求高，非常重视用户体验。因此C端产品经理和运营人员要想尽办法持续优化功能，而优化的前提是细致、全面的数据埋点和分析，这样优化方向才是明确的

方案不同

B端产品多为PC端Web站点，在Web埋点工作中，很多时候只需要分析页面级别的流量和行为就足够了

C端产品多为移动端App版本，用户的操作都在屏幕的方寸之间完成，保证良好的用户体验非常重要，因此C端产品对各种点击、交互行为的监控非常严格，会对所有交互行为做细致的埋点，以便全面掌握用户的动作，并进行准确优化，工作量会大很多。

概要

无论是B端产品埋点还是C端产品埋点，无论是Web端埋点还是移动端埋点，都要遵循公司统一的埋点格式要求。所谓埋点格式，是指在埋点过程中需要记录的扩展字段

权限管理

权限设计是业务系统设计中一个非常重要的环节，它反映了设计人员对整个业务体系中岗位和流程的理解。

权限设计的前提是合理的角色设计，在此基础上，只需要明确不同角色能访问哪些页面、能看到哪些数据以及能做什么操作即可。

功能权限设计

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

表：分销运营管理后台功能权限配置

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

相应地，在每个页面的设计文档中，除了描述页面功能本身，还需要描述系统中不同角色对页面中的各个功能点的访问权限。我们通常用权限表来描述权限、角色的配置关系，这张表在产品设计阶段就需要准备好

数据权限设计

数据权限指各个角色在各页面中能看到的数据范围（所谓能查到的数据范围，不是指能看到的数据字段，而是指能查出来的数据集合），例如分公司管理员在订单查询页能看到分公司的所有订单，而区域主管在订单查询页只能看到所在区域的订单

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

问题：对于“账号4”，你能否判断出它能查看哪些门店的订单数据呢？

答案：账号4可访问门店 2、3、4、5的订单

概要

RBAC权限模型

RBAC（Role Based Access Control）模型，描述了一套用户、角色、权限组的设计理念，在业务系统设计中被广泛采用。

对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。

RBAC模型可以简单地抽象为ER图，即每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素等资源的访问和操作权限。

RBAC模型中还引入了用户组的概念，即如果用户较多，可以对用户进行分组，将角色和用户组进行关联。当有新用户时，只需要设置其所在的用户组，就会将用户组关联的权限赋予新用户。如果用户角色需要批量调整，只需要调整用户组和角色的关联关系，而不用重新变更每一个用户和角色的对应关系

文档编写

产品设计工作会涉及一些文档，主要包括BRD（Business Requirement Document，商业需求文档）、PRD（Product Requirement Document，产品需求文档）和MRD（Market Requirement Document，市场需求文档），三者的编写时间、受众、编写目的和重点各不相同

文档编写与管理

在B端产品领域，BRD一般由需求方填写，用于提交需求；PRD由产品经理编写；MRD在B端产品中鲜有涉及

商业需求文档（BRD）的管理

要求需求管理团队以正式BRD的形式提交需求，可以在一定程度上提高需求的质量，并且可以作为正式备档文件留存，帮助项目组提高协作效率。

产品需求文档（PRD）的编写

一份典型的B端产品PRD模板，包括背景描述、收益分析、异常处理、权限管理等版块。

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

概要

UML统一建模语言

在软件设计中，有很多抽象的概念、思想很难用文字表达清楚，通过图形、图表来描述却很容易让人理解。诞生于20世纪90年代的统一建模语言UML（Unified Modeling Language）就是一种常用的图形化语言，经过多年发展，目前已经是一套成熟的规范和标准，是软件工程师做抽象设计时的有力工具

百度百科 (点击链接直达)https://baike.baidu.com/item/%E7%BB%9F%E4%B8%80%E5%BB%BA%E6%A8%A1%E8%AF%AD%E8%A8%80

UML是对于产品经理建立架构思维很有帮助的工具，个人推荐《大象 Thinking in UML》这本书

业务问题诊断

项目背景和计划

案例背景

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

背景

M集团是一家经营了十几年的成功企业，旗下拥有零售连锁超市、生鲜电商、金融理财多条业务线，业务发展良好，系统建设成熟。M公司是M集团下属的电商公司，成立5年，主营生鲜商品，以C端客户为主，业务稳定。M公司在三个月前尝试开展分销业务，成立销售团队，开发分销商合作伙伴。分销业务的目标客户是大型的餐饮连锁集团，以及大型生鲜分销商等企业级客户。业务试点在北京、上海开展，三个月以来业务发展迅速。目前分销业务月流水50万元，以每月20%的增幅快速发展。但是，在高速发展中，若干流程、管理、风险问题越来越突出。

诉求

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

评估

经管理层评估，公司决定投入研发资源建设软件系统，支撑分销业务发展。项目期间CTO全力提供资源支持。

目标

在2～3个月的时间内搭建一套分销业务平台，至少支撑分销业务在未来2年内的高速发展，有效地提升效率、控制经营风险。以上就是案例的大概背景。之所以选择一家集团企业下属电商公司的分销业务作为案例，是因为它非常有代表性：

·首先，M集团是一家成熟集团，拥有完善的应用架构，大家可以了解如何将新设计的产品与公司现有产品架构融合。

·其次，分销业务场景具备足够的复杂性，既要支持公司对客户的运营管理，又要支持客户的自主管理，涉及的系统具备比较全面的功能。

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

工作计划

业务调研

梳理业务现状

总结业务问题

执行并优化解决方案

技术方案

项目管理与实施

运营管理

迭代优化

数据分析

数据分析的流程

提出主题

明确的主题是整个数据分析过程的焦点。数据分析过程本身就是一次脑洞大开的探索，很有可能在分析过程中发现很多新的有趣的主题，以及值得深入探索的话题

验证假设

产生假设

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

明确结论

经过反复地提出假设、验证并修正假设，我们会逐渐发现现象背后的真正原因，得出可靠的结论便是水到渠成的事

概要

案例：M公司零售业务销售额下降的数据分析

数据分析的要点

方法工具

耐心细心

业务知识

概要

数据分析的流程

提出论点

提出论点：报告的开篇要简明介绍背景，以及分析的结论，让人产生兴趣并继续关注下去。如果一开始就介绍分析的细节，估计阅读的人或听众都会摸不着头脑，一会儿就昏昏欲睡

进行论证

进行论证：论证过程要有数据支撑，并且数据的呈现一定要专业又易读。人们都喜欢看简明易懂的数据图表，而不喜欢读复杂的数学推演。因此，配有丰富、清晰图表的报告读起来会给人生动有趣感，讲解起来也容易吸引人的注意

陈述总结

陈述总结：再次阐述并强调结论，加深阅读者或听众的印象

概要