《决胜B端》概念画布.pdf
需积分: 48 48 浏览量
2020-11-25
17:02:35
上传
评论 3
收藏 8.58MB PDF 举报
B端产品设计流程B端产品设计流程
B端产品设计流程
B端产品设计流程
CRM
客户关系管理
SCM
供应链管理
WMS
仓储管理系统
TMS
运输管理系统
ERP
企业资源计划
CallCenter
呼叫中心
Passport
账号管理体系
MDM
主数据管理
Auth
权限管理平台
Org
组织架构管理
Msg
消息服务
SSO
单点登录服务
垂直业务线 为每一个具体的垂直业务单元提供基础服务支持
基础服务业务线 为所有下游产品提供服务和支持
OA
办公自动化
IM
内部沟通工具
HRM
人资管理系统
FMS
财务管理系统
办公协同 支持企业内部办公管理高效运转的业务系统
结合个人实践，
这里列出的需求
字段和原书有少
许不同，实际上
需求字段可以根
据每个产品经理
面对的实际情况
有所调整
RBAC权限模型
RBAC（Role Based Access Control）模型，描述了一套用户、角色、权限组的设计理念，在业务系
统设计中被广泛采用。
对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集
合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操
作权限。这样做的好处是，不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即
可，而且角色的权限变更比用户的权限变更要少得多，这样将简化用户的权限管理，减少系统的开销。
RBAC模型可以简单地抽象为ER图，即
每个用户都要被赋予一个或多个系统角
色 ，每 个 系 统 角 色 都 对 应 一 个 明 确 的 权 限
集 合 ，包 括 对 菜 单 、页 面 元 素 等 资 源 的 访 问
和操作权限。
R B A C 模 型 中 还 引 入 了 用 户 组 的 概 念 ，即
如果用户较多，可以对用户进行分组，将角
色和用户组 进行关联。当有新用户时，只需
要设 置其所在的用户组，就会将用户组关
联的权限赋予新用户。如果用户角色需要批
量调整，只需要调整用户组和角色的关联关
系，而不用重新变更每一个用户和角色的对
应关系。
UML统一建模语言
在软件设计中，有很多抽象的概念、思想很难用文字表达
清楚，通过图形、图表来描述却很容易让人理解。诞生于20世
纪90年代的统一建模语言UML（Unified Modeling
Language）就是一种常用的图形化语言，经过多年发展，目前
已经是一套成熟的规范和标准，是软件工程师做抽象设计时的
有力工具。
知识地图
可视化
PDF
PDF
俞军产品方法论
概念地图
- 贴 吧之父产品大神 的
产品心法
- 全书的重点概念提
炼和 视觉化呈现！
- 俞军老师本人认可的
思维导图
Felix的
产品经理地图
- 产品知识全景图，
一页纸产品工具书。
- 备受同行好评的Mini
版产品百科。
- 全矢量、杂志级的概
念 可 视 呈 现 ，轻 松 阅
读！
关注公众号learninglab，获取更多地图
微 信 加 好 友 ，请 注 明 “ 产品”
*建议使用iPad或在桌面端使用Chro m e浏览器打开获得较好查看效果
知识地图
可视化
FELIX
ZHOU
Created By
更多产品相关地图，关注公众号...
VERSION 1.0
《决胜B端》概念画布
《决 胜 B 端》概 念 画 布
微信 ideasigner
本文档基于《决胜B端—产品经理升级之路》，
作者杨堃是VIPKID产品总监，在企业数字化转型、
应用架构设计、业务中台建设、CRM建设、数据仓库
与BI建设方面均有丰富经验。
本文档主要的目标是将原书中提到的各种B端
产品概念和流程在完整统一的视图中展示出来，以
帮助读者从整体的视角快速回顾各个知识点。
本文档包括了原书中的设计篇和管理篇部分，
暂未包含进阶篇的内容，计划在下一个版本加入进
来。
《决胜B端——产品经理升级之路》试图提炼了互
联网B端产品设计和管理的通用思路和方法，本书一共
分为4篇。“概述篇”描述互联网行业的盈利模式及发展趋
势，让读者对互联网产品领域建立全面认知，并阐明市场
对B端产品经理的需求将持续旺盛。“设计篇”详细讲述B
端产品的设计，按照产品设计的实际流程，依次讲述业务
调研、架构设计、功能模块设计、演进蓝图设计、业务数
据建模、流程和角色设计、权限设计等一系列关键环节。
“管理篇”讲述B端产品的管理，包括B端产品的项目管
理 、运 营 管 理 、迭 代 优 化 和 数 据 分 析 ，阐 述 了 B 端 产 品 实
施和运作过程中面临的一系列问题，包括复杂项目的推
进、产品经理和业务团队的合作、需求和迭代的计划编
排等。“进阶篇”讲述企业级应用架构，从前面的单一产品
建设扩展到体系化产品建设，旨在帮助读者从更宏观的
角度思考产品，站在企业经营管理和发展的视角，重新
审视互联网产品体系架构的设计原则和方法论。
全书贯穿了一个实践性很强的案例：在“设计篇”和
“管理篇”中，我们为一家成熟的集团企业搭建了一套完
整的分销业务平台，带领读者逐步设计、实现一个B端产
品；在“进阶篇”中，讲述了这家集团企业是如何从小门店
一步步发展起来的，重点分析企业的应用架构体系随业
务发展的演进规律。
本书面向0到10岁的B端产品经理，以及所有对B端
产品建设感兴趣的读者。
执行并优化解决方案
业务问题诊断
业务调研
产品整体方案设计
产品细节方案设计
技术方案/实施/运营迭代
设计解决方案
总结业务问题
梳理业务现状
项目背景和计划
核心流程
产品定位
应用架构
功能模块
演进蓝图
数据建模
流程角色
界面报表
数据埋点
权限管理
文档编写
技术方案
项目管理与实施
运营管理
迭代优化
数据分析
业务调研
业务调研
业务调研
业务调研
案例背景
案例背景
案例背景
案例背景
工作计划
工作计划
工作计划
工作计划
梳理业务现状
梳理业务现状
梳理业务现状
梳理业务现状
业务调研方法流程 业务调研目的和分析框架
案 例 ：M 电 商 公 司 的 渠 道 分 销 产 品 设 计
关于本文档 原书简介
组织架构 业务流程 具体数据指标
关键业务问题梳理 问题解决思路
总结业务问题
总结业务问题
总结业务问题
总结业务问题
B端产品
设计流程
*以M公司为例
基于业务调研和业务现状，
得到结论并提出解决思路
业务数据
建模
业务数据
建模
业务数据
建模
业务数据
建模
业务数据建模也叫
实体建模、领域建
模 ，或 业 务 对 象 建
模 ，是 指 针 对 业 务 特
点 ，归 纳 并 设 计 对 应
的底层数据模型的
过程
·生鲜实时变价，每次下单要根据折扣表手工计算价 格，效率低，
易出错。
·不能及时控制账期客户的回款进度和账期风险。
·对账和开票工作复杂，需要处理大量数据表，容易出错。
·因为没有实现客户的子母账号管理体系，所以无法实现客户总部
集采、大区集采、城市集采、门店自采等混合采购模式。
·因为无法标识特殊客户的特殊订单，因此不支持特殊分拣、配送
要求，例如做不到针对某些特殊客户的订单提供蔬菜预加工和
加急配送。
· 实 现 客 户 自 主 下 单（ 高 优 ）。
·实现系统自动定价（高优）。
·支 持 客 户 多 门 店 分 别 定 价 与 下 单（ 高 优 ）。
·实现对账报表（高优）。
·运营人员聚焦参 数设置、审核和异常问题跟 进（高优）。
·将运营工作下放到各城市分 部（中优）。
·支 持 账 期 和 预 付 款 模 式（ 低 优 ）。
·系统实现账期风控（低优）。
流程和角色
流程和角色
流程和角色
流程和角色
流 程 合 理 、角 色 清 晰 是
系统正确设计的前提和
保障。
遵循自顶向下的设计思
路 ，我 们 首 先 设 计 主 干 流
程 ，在 这 个 过 程 中 可 以
进一步明确系统角色 及
业务岗位的安排
细化到每个操作需
要 访 问 哪 些 页 面 、总
共 有 哪 些 页 面 ，为 每
个页面 设计具 体 的交
互功能
界面设计
界面设计
界面设计
界面设计
报表设计
报表设计
报表设计
报表设计
任何业务的开展和运转
都需报表，报表是业务管
理中不可缺少的工具。
业务报表的核心价值是
掌 握 事 实 、发 现 问 题 、分
析 原 因 、产 生 对 策 。
数据埋点
数据埋点
数据埋点
数据埋点
数据埋点设计是产品
交互设计过程中必须
同 时 进 行 的 工 作 ，数
据埋点是考核产品 使
用程度的一个重要依
据 ，也 是 业 务 用 户 行 为
分 析 、产 品 分 析 、产 品
改善的重要参考数据
来源。
权限管理
权限管理
权限管理
权限管理
权限设计是业务系统设计
中 一 个 非 常 重 要 的 环 节 ，它
反映了设计人员对整 个业务
体系中岗位 和 流 程 的 理
解。
权限设计的前提是合理的
角色设计，在此基础上，只
需要明确不同角色能访问
哪些页面、能看到哪些数据
以 及 能做什么操 作即可。
文档编写
文档编写
文档编写
文档编写
产品设计工作会涉及一些文档，
主要包括BRD（Business
Requirement Document，商业
需求文档）、PRD（Product
Requirement Document，产品
需 求 文 档 ）和 M R D（ M a r k e t
Requirement Document，市场
需 求 文 档 ），三 者 的 编 写 时 间 、
受众、编写目的和重点各不相同
技术方案
技术方案
技术方案
技术方案
产 品 经 理 要 懂 技 术 ，这 样
可以设计出更好的产品方
案，尤其是B端产品经
理 ，更 需 要 理 解 技 术 体 系
架构，因为B端产品的结
构设计不仅 和业务有关，
还 和 技 术架构有关。
项目管理
项目管理
项目管理
项目管理
B 端 项 目 往 往 牵 涉 面 广，经
常 出 现 跨 端 现 象 ，面 对 这
些 复 杂 项 目 管 理 情 况 ，需 要
项目负责人 对项目管理体系
有 全 面 的 了 解 ，并 掌 握 项 目
推进的要点和技巧
运营管理
运营管理
运营管理
运营管理
B 端 产 品 上 线 后 ，需 要 开 展
运营推广工作。B端产品经
理 、产 品 运 营 人 员 、业 务 运
营人员三者的工作职责往
往 有 很 多 交 叉 和 重 叠 ，这
就 可 能 导 致 冲 突 ，影 响 工
作 效 率 。产 品 经 理 需 要 深
刻理 解三 者的工作目标 、
工 作 方 式 ，处 理 好 协 作 关
系 ，这 样 才 能 保 证 工 作 顺
利开展。
背景
M集团是一家经营了十几年的成功企业，旗下拥有
零售连锁超市、生鲜电商、金融理财多条业务线，业
务发展良好，系统建设成熟。M公司是M集团下属的
电商公司，成立5年，主营生鲜商品，以C端客户为
主，业务稳定。M公司在三个月前尝试开展分销业
务，成立销售团队，开发分销商合作伙伴。分销业务
的目标客户是大型的餐饮连锁集团，以及大型生鲜
分销商等企业级客户。业务试点在北京、上海开展，
三个月以来业务发展迅速。目前分销业务月流水50
万元，以每月20%的增幅快速发展。但是，在高速发
展中，若干流程、管理、风险问题越来越突出。
诉求
由于分销业务发展迅速，现急需配套的软件系统来
提升业务效率，控制经营风险。
评估
经管理层评估，公司决定投入研发资源建设软件系
统，支撑分销业务发展。项目期间CTO全力提供资
源支持。
目标
在2～3个月的时间内搭建一套分销业务平台，至少
支撑分销业务在未来2年内的高速发展，有效地提
升效率、控制经营风险。以上就是案例的大概背景。
之所以选择一家集团企业下属电商公司的分销业务
作为案例，是因为它非常有代表性：
·首先，M集团是一家成熟集团，拥有完善的应用架构，
大家可以了解如何将新设计的产品与公司现有产品架
构融合。
· 其 次 ，分 销 业 务 场 景 具 备 足 够 的 复 杂 性 ，既 要 支 持 公
司对客户的运营管理，又要支持客户的自主管理，涉及
的系统具 备比 较 全面的功能。
· 最 后 ，分 销 业 务 模 式 涉 及 复 杂 的 多 层 级 子 母 账 号 管
理和组织机构管理，这是B端产品设计中的典型问题，
也是设计的难点。
业务调研方法
产品经理深入一线，
直接体验一线业务人
员 的 具 体 工 作 ，这 是
深入了解业务的最好
方法。
轮岗实习
战略定位和目标
通过对M公司高层的访谈，确定M公
司 对 分 销 业 务 的 战 略 定 位 是 ，扩 充 并
尝试新销售渠道，发展高端零售的分
销通路；战略目标是在3年内打入主
要 一 二 线 城 市 高 端 零 售 分 销 市 场 ，并
站 稳 脚 跟 ，形 成 初 步 竞 争 力 。
经营策略
通 过 对 业 务 负 责 人 的 访 谈 ，我 们
了解到M公司对分销业务给出的
经 营 策 略 是 ，目 标 客 户 群 体 是 大
型的餐饮连锁集团，以及大型生
鲜分销商等企业级大客户；
定价策略是能够基本覆盖采购、
仓配成本加运营管理成本，不追
求利润率，甚至可以在一定范围
内略微亏损，以快速占领市场；供
应链采用当前C端供应链体系，即
现有的仓配服务。
线上的调研问卷是比较灵活的
调 研 手 段 ，既 可 以 进 行 定 性 分
析，也可以进行定量分析，并且
很 容 易 推 广。
重点：
■ 激励用户完成填写
■ 控制好开放式和封闭式
问题
■ 避免诱导性问题
■ 谨防“幸存者偏差”
调研问卷
ER图
分销业务的组织机构树
简化的分销业务的组织机构树
深度访谈
调研时，有必要掌握业务的关
键过程指标和结果指标。
对于分销业务来说，过程指标
包括新 客 户 开 户 时 长 、订 单 处
理时长、分拣配送时长、销售
拜访量、新销售线索进量、销
售线索转化率等；结果指标包
括 订 单 量 、客 单 价 、收 入 、成
本 、利 润 率 等。
产品经理要像业务经理那样
关 心 业 务 运 行 的 各 项 数 据 ，这
样才能了解业务现状，并进行
业务诊断。
数据分析
虽然B端产品和业务的竞品
调 研 比 较 难 做 ，但 行 业 研 究
依然要尽力而行，收集的信
息越多，帮助越大。行业研
究可采用如下方式：
■ 研究针对业务相关领
域的经典管理案例”
■ 研究市面上同类业务
的商业软件特点
行业研究 B端产品与C端产品
业务调研的区别
应用架构
应用架构
应用架构
应用架构
核心流程
核心流程
核心流程
核心流程
功能模块
功能模块
功能模块
功能模块
分销商城前台的功能模块图
分销客户管理后台的功能模块图
分销运营管理后台的功能模块图
演进蓝图
演进蓝图
演进蓝图
演进蓝图
一期项目聚焦解决最基本的业务流程线
上化问题及核心痛点（例如对账功能），在图
5-7中用白色矩形表示。一期项目要实现哪
些功能？有一个原则可以参考：凡是可以手
工处理和解决的问题，都暂时不做系统支
持。例如，报表管理功能可以通过定期运行
SQL语句实现；价格系数设置功能的使用频
率低，可以由RD在后台改数据库完成；缺少
搜索、推荐功能并不会对客户下单的效率产
生明显影响，因为根据调研，目前每个客户
维护的SKU数量最多也不过20个。
二期项目聚焦于解决部分特殊业务刚需
的诉求。对于M公司的分销业务，需要支持
预付款模式、账期模式、发票管理，如果时
间 允 许 ，还 可 以 实 现 报 表 查 询 的 若 干 功 能 。
在图5-7中用浅灰色矩形表示。
三期项目聚焦风险控制，并强化运营功
能，在图5-7中用深灰色矩形表示。一般来
讲，很多互联网公司初期都会聚焦于业务本
身，提升GMV（成交总额）、验证可行性，不
会太在意成本和风险控制。当业务达到一定
规模时，则必须引入系统风控机制，实现事
前 、事 中 、事 后 的 风 险 控 制 。
产品定位
产品定位
产品定位
产品定位
产品定位是对产品概要性的总结和
陈述，简明扼要地描述产品对业务的
支持范围，或总体的功能目标。产品
定位要说清楚产品针对谁提供什么
支持。
根据分析，将分销系统拆分为三个独
立系统，每个系统的定位不同：
· 分 销 商 城 前 台（ 移 动 端 ，通 过 H 5 实
现 ）：为 分 销 客 户 提 供 下 单 功 能 。
·客户管理后台（P C 端）：为分销客户
提供子账号管理、门店管理及业务辅
助功能。
· 运 营 管 理 后 台（ P C 端 ）：为 分 销 业 务
部门提供客户及商品定价管理的业务
支持功能。
管控模式
通过对业务负责人的
访 谈 ，我 们 了 解 到 M 公
司对下属部门采取了
事权下放的管控模式，
下属部门在遵守基本
规则的前提下拥有售
卖 定 价 权 、运 营 管 理 权
等权利
理想的分销业务客户模型
多层级组织机构树，树中存在三种对象：
·组织机构对象，图 中 用 深 灰 色 节 点 表 示 ，
用来描述客户的行政管理层级结构。分 销
总部位于组织机构树的根节点上。
·门店对象，图 中 用 浅 灰 色 节 点 表 示 ，是下单
的目标，是挂在某个机构节点下的收货对
象。在数据结构中称其为门店，实际上有可
能是小门店，也可能是中央仓。
·账号对象，图 中 用 白 色 节 点 表 示 ，代表系统
的用户。账号也挂在某个机构节点下。在“分
销总部”根节点下的账号，是分销业务后台
的管理员账号，可以管理整棵组织机构树
中的所有数据，包括所有的门店和账号。每
个账号所管理的数据范畴（包括能给哪些
门店下单、能查看哪些门店的数据等），是
通过遍历其所在节点的所有子节点来确定
的。
https://baike.baidu.com/item/E-R%E5%9B%BE
百度百科 (点击链接直达)
https://baike.baidu.com/item/%E7%BB%9F%E4%B8%80%E5%BB%BA%E6%A8%A1%E8%AF%AD%E8%A8%80
百度百科 (点击链接直达)
ER图
将 几 种 对象的关系通 过 数据 建 模 E R 图
将 几 种 对象的关系通 过 数据 建 模 E R 图将 几 种 对象的关系通 过 数据 建 模 E R 图
简化模型的ER图
将 几 种 对象的关系通 过 数据 建 模 E R 图
将 几 种 对象的关系通 过 数据 建 模 E R 图将 几 种 对象的关系通 过 数据 建 模 E R 图
简化的分销业务客户模型
客户模型简化
完整的组织机构树的开发复
杂 度 很 高 。产 品 经 理 和 业 务
人员及客户沟通 后确认，一
期暂不用支持复杂的行政层
级管理，只需要为客户实现
若干子账号，可以管理若干
门店即可。
分销业务在M公司内部包含如下几个角色：
·分销–销售人员：M公司分销业务的销售人
员，负责完成客户开发与合约签订（目前
继续采取线下作业的方式）。
·分销–管理员：M公司分销业务总部的管
理人员，主要负责审核分公司提交的创建
客户的申请，核查各分公司维护的价 格系
数表，并进行毛利核算。
·分销–运营人员：M公司分销业务总部的业
务运营人员，负责具体的客户创建、维护、
报价单维护等事务性工作。分销业务客户
包含 如下几 个角色。
·客户–管理员：分 销客户的管理员，维护并
管 理 客 户 公 司 内 的 所 有 子 账 号 、门 店 。
·客户–采购员：分销客户的采购人员，负责
给门店下采购单、补货。
业务角色
在 团 队 分 工 明 确 、 人 力 储 备 充 足 的 情 况 下 ，在 开
发一套全新的B端业务系统时，界面设计的流程
一 般 如下：
1. 产品经理绘制线框图原型，表达软件
中每 个页面的 设计需求 。
2. UE设计师协助产品经理完善交互体
验 ，并 制 作 交 互 原 型 。
3. UI设计师基于交互原型进行美工设计，
生成切图文件。
4. 前端工程师拿到切图文件，进行前端
开发，包括实现交互、动效等。
界面设计流程
数据埋点流程 埋点工具的数据分析
B端产品与C端产品数据埋点的区别
功能权限设计
懂技术的产品经理在设计产品方案时，能够在一定程
度上预估技术实现的可行性和实现成本，或至少能具
备基本的认知，知道什么时候、什么情况下需要和技
术人员提前沟通讨论，从而保证产品设计合理可行，
既 能 提 升 合 作 效 率 ，也 能 赢 得 技 术 人 员 的 尊 重 和 信
任。
产品经理懂技术有以下明显的好处：
1. 避免产品过度设计
2. 避免技术过度设计
3. 与技术人员沟通顺畅
4. 预判需求的可行性
5. 评估工时合理性
产品经理懂技术的好处
优秀的项目管理是互联网公司在复杂环境下保证软件开发按计
划推进、落地的关键，也是保障规模团队的产品研发效率和质
量的核心要素。
为什么需要项目管理
功能权限指各个角色可以操作的界面、按钮等，例如管理员可以进行新增、删除、修
改等操作；运营人员在同样的页面上只能使用各种筛选条件查看数据，无法做更改
数据权限设计
商 业 需 求 文 档（ B R D ）的 管 理 产品需求文档（PRD）的编写
数据权限指各个角色在各页面中能看到的数据范围（所谓能查到
的数据范围，不是指能看到的数据字段，而是指能查出来的数据
集合），例如分公司管理员在订单查询页能看到分公司的所有订
单，而区域主管在订单查询页只能看到所在区域的订单
B端产品，尤其是业务系统，往往借助埋点观察并研究用户对各项产品功能
的接受程度、使用情况，以及用户的操作习惯等，从而进一步评估功能设计
是否合理，是否帮用户提高了效率等，为持续优化提供依据。
C端产品通过数据埋点来持续优化设计。C端产品对交互设计要求高，非常重
视用户体验。因此C端产品经理和运营人员要想尽办法持续优化功能，而优
化的前提是细致、全面的数据埋点和分析，这样优化方向才是明确的。
B端产品多为PC端Web站点，在Web埋点工作中，很多时候只需要分析页面
级别的流量和行为就足够了
C端产品多为移动端App版本，用户的操作都在屏幕的方寸之间完成，保证良
好的用户体验非常重要，因此C端产品对各种点击、交互行为的监控非常严
格，会对所有交互行为做细致的埋点，以便全面掌握用户的动作，并进行准确
优 化 ，工 作 量 会 大 很 多 。
无论是 B 端产品埋
点还是C端产品埋
点 ，无 论 是 W e b 端
埋点还是移动端
埋 点 ，都 要 遵 循 公
司统一的埋点格
式 要 求 。所 谓 埋
点 格 式 ，是 指 在
埋点过程中需要
记录的扩展字
段。
要求需求管理团队以正式BRD的形式提交需求，可以在一定程度
上提高需求的质量，并且可以作为正式备档文件留存，帮助项目组
提高协作效率。
一份典型的B端产品PRD模板，包括背景描述、收益分析、异常处
理 、权 限 管 理 等 版 块 。
产品经理不必急于写PRD，而要完成模型设计、流程设计、界面设
计、权限设计等工作后，再编写PRD。否则，如果方案还没有理清就
开始编写文档，会思绪混乱，不断返工。
文档编写与管理
在B端产品领域，
BRD一般由需求方填写，用于提交需求；
PRD由产品经理编写；
MRD在B端产品中鲜有涉及。
数据权限设计方案：通过组织机构树控制
该方案根据账号所在组织机构树中的节点位置，来判断能够查询的数据范围。这种
方式最复杂，但最灵活，能够支持各种复杂的业务数据权限诉求。
问题：
对于“账号4”，你能否判断出它能查看哪些门店的订单数据呢？
设计页面的功能时，要考虑
页面中的各个功能点是否要
做权限控制。
相应地，在每个页面的设计
文档中，除了描述页面功能
本身，还需要描述系统中不
同角色对页面中的各个功能
点 的 访 问 权 限 。我 们 通 常 用
权限表来描述权限、角色的
配 置 关 系 ，这 张 表 在 产 品 设
计阶段就需要准备好
报表引擎线框图的绘制
业务流程图
基于定义的角色更新 泳 道 流 程图，描 述各 个角色的用例
从本质上讲，一套软件系统就是对不
同数据对象的增删改查操作的集合
从本质上讲，一套软件系统就是对不
同数据对象的增删改查操作的集合
分销业务的页面流转图
分 销 业 务 要 开 发 的 页 面（ 部 分 ）
页面流 转图描 述用户完 成 某项工作需要访问的页面及页面跳 转顺 序。
https://baike.baidu.com/item/E-R%E5%9B%BE
尼尔森十大可用性原则
百度百科 (点击链接直达)
交互原则 描述
原则一：状态可见原则（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）
即使系统不使用帮助文档是最好的，但我们也应该提供一份帮助文档。任何帮助信息都应
该可以方便的搜索到，以用户的任务为核心，列出相应的步骤，但文字不要太多。
我个人的习惯是将线框图
直接整合到页面流转图
中 ，提 供 给 开 发 和 设 计 一
个全局的界面和流程文档
书中给出了各个方案的优
缺 点 ，建 议 对 照 原 书 查
阅。
SQL内容比较多，建议自行
学习
UML是对于产品经理建立
架构思维很有帮助的工具，
个人推荐《大象 Thinking
in UML》这本书
概 念 ：E R ( 实 体 / 关 系 ) 图
以高校学生选课系统为例
m
1
n
1
n
n
1
n
教授
属于
管理
学号
课程成绩
姓名 性别 入学时间 ...
编号 姓名 性别
课程编号
名称
任课教师
...
班号
班主任
...
入职时间 ...
学生
教师
课程
学习
班级
实体
属性
关系
构建分析体系之前，首先要明确分析目的，即需要
通 过 分 析 发 现 哪 些 方 面 的 问 题 ；然 后 思 考 该 采 用 什
么 方 法 来 识 别 、诊 断 这 些 问 题 ，其 中 可 能 的 困 难 是
什么。构建分析体系必须建立在对业务的深刻、准
确理解之 上，并且要和一线管理团队多沟通，可能
很多问题的分析框架和思路已经被一线工作者发现
并有效实践了，一定要善于发掘并参考、借鉴
确 定 观 察 指 标 ，设 计 具 备 明 确 业 务 含 义 的
指标来考量业务。一般会先从大的方面拆
分出几方面的观察指标，然后考虑是否将
指标进一步拆解为二级指标，甚至三级指
标，从而在更精细的维度观察、分析业
务，更准确地反映业务特征。
报表设计与应用流程
确 定 了 观 察 指 标 后 ，我 们 要 思 考 以 什 么
形 式 呈 现 这 些 指 标 ，以 便 用 户 能 够 准 确 、
快速地理解、掌握指标以及变化特征。
例 如 ，是 采 用 数 据 表 格 还 是 柱 状 图 呢 ？
在这个环节，产品经理要和实际用户多
讨论，寻找最佳的呈现方式。
如 果 指 标 发 生 了 明 显 的 波 动 ，需 要 跟
进分析波动的原因，分析工作可以由
数据分析师完成。业务团队最好每
周 分 析 上 周 数 据 走 势 、变 化 背 后 的 原
因 ，以 便 及 时 、准 确 地 掌 握 业 务 变 化
情况及原因。
管理要用数据说话，报表数据就是诊断和决策的依据。
管理人员要认真对待、分析报表中各种数字的变化、波
动 。如 果 只 是 走 马 观 花 地 浏 览 报 表 ，看 不 出 任 何 问 题 ，
报表就失去了意义。作为一名管理人员，必须对数字非常
敏感，能够快速地感知并解读数字背后的变化和问题，
这是出色的管理 人员必须具备的素质。
分 析 出 问 题 后 ，下 一 步 当 然 是 给 相
关 部 门 或 人 员 安 排 工 作 ，解 决 问
题，这也是报表设计的初衷
国内使用比较多的
■ Web端埋点工具：Google Analyt-ics（GA）、百度统计
■ 移动端埋点工具：GrowingIO、诸葛IO、神策
表：分销运营管理后台功能权限配置表
答 案 ：账 号 4 可 访 问 门 店
2 、3 、4 、5 的 订 单
B端产品经理的技术知识要求
理 解 程 序 设 计 的 基 本 逻 辑 ，例 如 什 么 是 函 数 、返 回 值 、循 环 、编
译、发布等。学习的重点不是编写出能执行的程序，而是理解程
序设计的基本原理
1. 理解一门编程语言
理解数据库及表结构；从数据库导出数据来分析；对于复杂的
数据处理逻辑，用SQL语句进行预处理
2. 掌握并使用SQL
例如网络与通信原理、操作系统原理、微机原理等，至少要理解
TCP/IP协议、UDP协议分别是什么，二进制、十六进制的运算法
则，字节和字的长度概念，对称密钥密码体系和非对称密钥密
码 体 系 的 区 别 ，等 等 。
3. 了解网络通信等计算机常识
公司发展到一定规模后，就需要制订项目管理制度并严格执
行。PMO或产品负责人要结合公司的实际情况，设计符合公
司诉求的项目管理制度
项目经理要保障大中型项目的成功落地，就必须理解业务，
这样才能在大中型项目管理中准确理解整体方案，以及各个
团队负责的工作范围。
互联网项目管理的工作重点
1. 设计并优化项目管理制度
2. 负责大中型项目的立项实施
B端产品运营岗的工作内容
B端产品的功能上线后，一方面要在线上进行推广宣传，例
如消息推送、公告通知等；另一方面，针对比较复杂的升级
改造，还需要组织业务团队进行现场培训。
1. 产品功能推广培训
产品运营人员需要在线上对问题进行答疑处理，帮助用户
解决问题。
2. 问题解答处理
优秀的产品运营人员能够识别并挖掘好需求（真正会产生
影响的需求），和产品经理一起持续优化产品
3. 需求采集过滤
公司会直接安排产品运营人员作为中立方，独立考核项目效
果和收益，给出客观分析
4. 项目效果分析
高阶的产品运营人员还要和产品经理、业务团队一起诊断业
务，分析问题，提出解决方案，并推动解决方案落地执行。
5. 业务诊断分析
B端业务运营岗的工作内容
在业务工作开展中，会有审批、核对、检验这类工作诉求，这些事务性工作
非常繁杂，是业务运营岗的重要工作内容。
1. 业务支持
业务部门内部的流程机制、业务部门与其他部门之间的流程机制，都需要
不断地优化、调整，以适应最新的业务安排。业务运营部要负责流程的设
计、执行、监督、优化，保证分支机构管理的规范性和可控性
2. 流程管理
业务部门有时需要制订策略，例如促销策略、定价策略、供应商返点策略、
仓储排班策略等，这些工作一般会交由其下属的业务运营部完成。
3. 策略制订
由管理人员根据业务情况、业务规划，给出方向性的规定或调整思路，由
业务运营人员细化方案并进行预测，最终由业务负责人确认后实施执行。
4. 绩效考核制度制订
公司及业务部门的制度、政策、活动的宣贯传达，以及新人的培训等工作，
需要由专门的培训部负责。
5. 培训考核
业务部门还需要负责业务系统相关的新功能落地、推广，系统使
用的问题解答、问题收集、提出优化建议等工作。为此，业务部门
常常会设立自己的产品运营岗，也叫系统运营岗
6. 系统运营
对于业务部门发起的业务项目或产研项目，业务运营部可能会安
排专门的项目经理进行项目管理，推进项目落地。
7. 项目管理
业务部门下属的业务运营部常常会设置质检或品控团队，负责内
部的监察和治理。销售人员恶意挖客户、采购人员收回扣、客服人
员话术不规范，这些都可能在管辖范围之内。
8. 合规质检
业务部门下属的业务运营部常常会安排专门的数据分析团队制
作手工报表，定时发送给相关的领导或业务群。之所以不直接制
作线上报表，是因为业务领导要看的指标往往是灵活多变的，需
要根据领导的要求制作实时数据报表。此外，数据分析团队还会
做一些专题性的业务分析工作。
9. 数据分析
迭代优化
迭代优化
迭代优化
迭代优化
产品 上 线 并 进 行了全 面 推
广，对 业 务 产 生 了 明 显 帮
助，产品经理会感到满满的
成就感。但是产品经理的
工作还没有结束，还需要
不断挖掘新需求，并对产
品进行持续的迭代升级，
让 产 品 变 得 更 加 成 熟 、强
大。
B端产品的需求管理
数据分析的流程 数据分析的流程数据分析的要点
B端产品的迭代管理
迭代中的研发资源管理
产品经理、产品运营人员、业务运营人员如何高效协作
需求的收集和管理是产品经理的一项基本工作内
容。不要轻视看似烦琐的需求管理工作，对业务
和产品的理解正是在这些工作中逐渐形成的；而
确认需求的优先级、确认迭代工作的计划安排，
更能培养对业务的准确判断力
1. 需求的收集
对 于 收 集 到 的 需 求 ，经 过 初 步 判 断 、过
滤 后 ，要 放 入 需 求 池 进 行 管 理 跟 进 。
2. 需求池管理
■ 无法保证最小功能集合可以在一个迭代周期内实现
■ 跨端项目协同非常复杂，研发节奏互相依赖
■ 很难准确预估工作量投入
双周模式的局限性
■ 传统软件产品非常复杂
■ 传统企业没有快速迭代的诉求
■ 瀑布模式的核心环节是“需求分析”“方案设计”“开发编码”“验收上
线”，这几个环节是软件工程的必经环节，任何模式都难以绕过
瀑布模式的历史背景
敏捷开发的核心思路是将复杂需求分解成小块需求，采用较短的开发
周 期 ，按 节 奏 开 发 ，按 需 发 布 ，逐 步 迭 代 实 现 ，因 而 非 常 适 合 在 互 联 网 公
司推广。本质上讲，敏捷模式是容纳并拥抱新时期快速变化的市场环境
和商业特征的一种理念。只有认可敏捷模式的理念，才能很好地实践
它。
敏捷开发是一种理念
无论是敏捷开发，还是瀑布开发，都有自身的优点和缺点。找到这两种
模式的恰当结合点，设计适合自己团队的模式、流程，帮助产品研发团
队 提 升 效 率 、支 持 业 务 是 关 键 。
合适的才是最好的
使用研发人力资源安排图，通过该图可以清晰地
看出每个研发人员在不同需求、项目上的时间投
入 规 划 ，并 据 此 安 排 后 续 的 工 作 。
迭代中的技术优化资源分配
应该投入多少资源做技术优化？这个问题在产品经理和研发
负责人之间似乎很难达成一致。研发负责人想多投入一些资
源优化系统，而产品经理则认为应该首先解决业务需求。如
何平衡业务需求和技术优化之间的资源分配问题呢？
数据分析
数据分析
数据分析
数据分析
通 过 数 据 支 持 决 策 ，是 互
联网企业 在激烈的市场竞
争 中 快 速 试 错 、纠 正 方 向 、
取 得 成 功 的 不 二 法 门 ，互
联网人必须具备以数据驱
动业务决策的意识和习
惯。对于产品经理来说，无
论 是 业 务 问 题 诊 断 ，还 是
项 目 效 果 分 析 ，都 需 要 通
过数据分析来进行论证和
判 断 ，因 而 数 据 分 析 能 力
是产品经理的必备技能之
一。
在团队规模小时，一个研发团队管理了所有的系统，或
者所有的模块都在一个系统里，很少出现跨端现象。
随着系统复杂度增加，子系统越来越多，分工越来越
细，各个团队负责各个业务线的不同系统。这种情况
下，公司发起的跨端任务自然会引起跨端现象；更常见
的是，因为单个业务方的需求，导致多个业务系统都需
要修改，产生跨端现象。跨端会带来各种困难，例如难
以获得其他团队的支持、难以取得整体的排期等
当B端项目出现跨端现象，或者涉及流程改造等复杂
需求时，都会面临较长的项目周期。而项目周期拉长，
就会导致存在各种变数和不确定性，出现项目风险。
B端项目管理面临的挑战
1. 容易发生跨端（跨系统）现象
2. 项目周期长
跨端项目推进的第一步就是明确项目收益价值。分析
清楚收益价值的前提是，对业务的诊断、分析尽可能
全面客观，这样才能产生有效的解决方案，并推算出
预期的收益和价值。
不论是说服业务团队、产品团队还是研发团队，都需
要找到关键人物（决策人员），针对正确的对象采取
“ 攻 势”。
协调并推动跨端协作
1. 明确项目收益价值
2. 找到KP并积极游说
产 品 经 理 要 负 责 推 进 整 个 项 目 ，在 面 对 困 难 和 挫 折
时，要不气馁、不放弃，像“小强”一般战斗力十足。所谓
强推动力和执行力，其实就是在合适的限度内，强力
推动，保证执行效果。
3. 保持强的推动力与执行力
工作分解结构（WBS，Work Breakdown Structure）
将工作细致拆解，并明确每一个细化事项的责任人、
交 付 物 、时 间 点 。
在项目开展的各种问题和意外，例如需求变更、方案
调整、人员流失等。如果想及时发现并解决问题，就需
要设定一些项目机制，对项目进行监控和约束，确保
项目有序推进。
定 期 会 议（ 例 会 ）
定期 将项目的各方参
与人员聚在一 起，回
顾上一次会议以来的
进 展 、遇 到 的 困 难 、
下一次会议之前的计
划 ，这 非 常 有 必 要
每日站会
站 会是敏捷开发中经
典的工作方式，对于
软 件 研 发 项 目 ，在 团
队内部开每日站会的
确是非常有效的工作
机 制 。（ 例 会 ）
日报或周报
项目日报 和 周 报 并发
给 项目的所有相关人
员 。除 了 通 报 进 度 、
进 展 情 况 ，项 目 日 报
可 以 警 示 风 险 ，让 相
关 人 员 知 晓 ，并 推 动
责任人去解决问题
把控项目进度
1. 细化工作，明确交付
2. 通过机制把控进度
编写内容清晰的项目日报或周报
项目经理要利用项目日报或周报来争取关注度和资源，解决项目中遇到
的问题，下面以项目周报为例来介绍编写思路和要点：
·本周进 展：
简明罗列本周的重要进展。
·项目风险：
一般会用红色加粗文字罗列遇到的项目风险和可能的解决
方案，可以@相关人员强调某些要求。对近期已经解除的风
险，可以保留描述，但用删除线划掉。
·下 周 计 划 ：
简明罗列下周重点工作，以及每项工作的负责人和要求完
成时间。
·整体进度：
通过“甘特图”或其他形式说明整体项目计划和关键里程
碑 ，并 标 记 目 前 项 目 完 成 度 。
MVC是Modeling、View、Controller的缩写，代表软件设
计的分层理念。Modeling指数据模型，View指前端交互
视图，Controller指业务逻辑
程序设计的MVC范式
任何一套软件系统运作的本质都是相同
的：用户在前端交互层操作后，系统通过
业务逻辑层处理数据层的数据。
任何一套软件系统运作的本质都是相同
的：用户在前端交互层操作后，系统通过
业务逻辑层处理数据层的数据。
M
V
C
熟悉接口与调用模式
1. 同步调用模式 2. 异步调用模式
接口是指两个对象进行通信的方式和协议。
在软件设计领域，小到一个软件模块，大到一个软件系统，都
会有若干接口，实现不同模块、不同系统之间的通信。一般来
讲，每个接口都应该实现一个具体的功能，接口需要有明确的
输入，以及明确的输出（有的时候输出结果为空）。例如，调用
客户姓名查询接口时，需要传入客户ID，执行后返回客户姓名。
接口之间的调用模式分为同步调用模式和异步调用模式两
种：
接口调用方给被调用方发出指
令，但不会等待结果，等待对
方完成后调用回调接口
接口的调用方会一直等待被
调 用 方 返 回 执 行 结 果 ，除 非 调
用超时
www.sqlteaching.com
www.w3school.com.cn/sql
软 件 工 程 ：模 块 化 掌握数据库与SQL
企业的各个软件或产品
并 不 是 独 立 的 、割 裂 的 ，
而 是 深 度 结 合 、互 相 支 撑
的。
架构的理念在高阶的B端
产 品 设 计 中 非 常 重 要 ，同
时B端产品的设计体系和
技术架构也有着一脉相
承的设计思路。
理解技术架构对设计产
品架构大有裨益。
企业的各个软件或产品
并 不 是 独 立 的 、割 裂 的 ，
而 是 深 度 结 合 、互 相 支 撑
的。
架构的理念在高阶的B端
产 品 设 计 中 非 常 重 要 ，同
时B端产品的设计体系和
技术架构也有着一脉相
承的设计思路。
理解技术架构对设计产
品架构大有裨益。
产品经理如果了解一些数
据库的基本知识，对于设
计正确的ER图很有帮助。
通 过 各 种 渠 道 全 面 、迅 速
地 收 集 建 议 ，而 且 ，无 论 是
否采纳，都要给出反馈，例
如 意 见 是 否 采 纳 、预 期 的
解决时间等，这样才能形
成持续的良性互动。
需求反馈
·这个需求背后的真正问题
是什么？
·这个问题是否有简单快速
的解法？
·这个问题的影响面有多
大？如果只是个案，是否值
得投入精力去研究解决？
· 如 果 是 共 性 问 题 ，优 先 级
和紧急程度如何？
B端产品的需求来源十分广
泛 ，包 括 一 线 用 户 、产 品 运
营 人 员 、业 务 运 营 人 员 、业
务领导等的反馈；
需求内容也非常丰富，包括
交互体验优化、业务调整要
求 、业 务 管 理 要 求 等 ；
而能采集需求的手段也丰富
多样，包括一对一面谈、问
卷 调 研 、轮 岗 实 习 ，等 等 。
产品经 理初评
将需求放入需求池中统一
维护管理
需求池
需求来源
数据需求
品牌需求
运营需求
技术需求
其他...
业务需求
功能需求
需求主题 需求状态
需求描述
业务模块
需求收益
优先级
需求来源
人员安排
产品经理
该需求涉及的业务线或业务模块
该需求涉及的业务线或
业务模块
一句话描述需求
需求来源方的优先级评估，
供产品经理判断 该需求对提
出方的重要程度
描述了产品经理 对该需求
重要程度的评价
常 用 状 态 包 括 ：待 跟 进 、需 求 调 研 、P R D 编
写 、待 P R D 评 审 、待 技 术 评 审 、待 排 期 、待
开发、开发编码、待测试、测试验证、待
验收、待上线、已上线、挂起、拒绝。
描述了开发人员对于的实
现该需求难度和工作量
的评估
P3P2P1P0
实现成本
C3C2C1C0
计划
来源优先级
研发负责人
设计负责人
业务负责人
计划上线日期
工时评估
发版计划
实际上线日期
测试负责人
需求记录日期
接收到该需求的日期
需求调研
答案 >
产品运营
产品经理
业务运营
产品部和业务部平级，产品经理和产品运营人员统一归产
品部管理。其中，A业务部下属的业务运营部下面，还设置
了系统运营部。
产品运营部向A业务线产品部直接汇报。这种管理架构是
互联网公司里比较常见的组织架构，产品经理和产品运营
人员同属一个部门，且产品运营人员汇报给对应业务线的
产品负责人。
1
方案
产品运营部和系统运营部被合并为产品运营部，统一归
属到业务运营部下面。
产品运营部的首要职能是落地、推广产品以及答疑解
惑，而这也是业务运营部支持业务团队的核心工作之
一。将产品运营部划归业务运营部，在业务模式较重的
创业公司很常见。
2
方案
业务线产品部被划归到相应业务部下面，业务线产品经
理直接向业务部的负责人汇报。这种组织架构在成熟的
纯互联网公司中比较少见，但是在业务模式较重的创业公
司或独角兽公司中正在被尝试。
产品经理向业务部的负责人汇报，估计多数产品经理都会
对此感到诧异，然而这却是一种缓解产研和业务矛盾、发
挥产品能力的可能方案。
3
方案
产品运营部被划为A业务线产品部下面的三级部门，产品
运营人员从业务运营部抽出，直接向产品经理汇报。这
种安排相当于业务线进一步给产品经理授权，将系统相
关的工作全部交给产品经理来管理
4
方案
调整组织架构改善合作关系：
产品经理、业务运营人员、产品运营人员相关的组织架构设计有多种方案可选，各有优缺点，不同的方案适用于不同的公司文化和发展阶段
A业务线产品部需要做双线汇报，实线汇报给相应业务
部 ，虚 线 汇 报 给 产 品 部 示 。
方案五还有一种变体，即A业务线产品部实线汇报给产品
部，虚线汇报给相应业务部。但这种情况下，业务线的产
品运营人员就不可能向产品经理汇报了，这就又和方案二
相差无几，因此不对其做赘述。
5
方案
C端和B端的需求
的产生背景和动
机 完 全 不 同 ，前 者
是为了解 决 用户 痛
点 ，而 后 者 是 为 了
解决业务问题。
C端和B端的需求
的产生背景和动
机 完 全 不 同 ，前 者
是为了解 决 用户 痛
点 ，而 后 者 是 为 了
解决业务问题。
典型的双周迭代模式
软件的开发模式既要能够快速响应市场并上线试错，又能保
障开发节奏和交付质量。敏捷开发的理念和方法论在一定程
度上满足了以上诉求。
在实践中，多数公司和团队都会结合瀑布模式对敏捷模式做
一些调整，来进行研发管理，而不是严格按照敏捷方法论管
理项目。其中使用最广泛的模式就是双周迭代模式
选择合适的迭代模式
方法工具
业务知识
细心耐心
没有头绪 效率降低
半途而废
有效分析
提 出 论 点 ：报 告 的 开 篇 要 简 明 介 绍 背 景 ，以 及 分 析
的结论，让人产生兴趣并继续关注下去。如果一开
始就介绍分析的细节，估计阅读的人或听众都会摸
不着头脑，一会儿就昏昏欲睡。
进行论证：论证过程要有数据支撑，并
且数据的呈现一定要专业又易读。人们
都 喜 欢 看 简 明 易 懂 的 数 据 图 表 ，而 不 喜
欢读复杂的数学推演。因此，配有丰富、
清晰图表的报告读起来会给人生动有趣
感，讲解起来也容易吸引人的注意
明确的主题是整个数据分析过程的焦点。数据分
析过程本身就是一次脑洞大开的探索，很有可能在
分析过程中发现很多新的有趣的主题，以及值得深
入探索的话题。
经过反复地提出假设、验证并修正假设，我们会逐
渐 发 现 现 象 背 后 的 真 正 原 因 ，得 出 可 靠 的 结 论 便 是
水到渠成的事。
陈述总结：再次阐述并强调结论，加深阅读者或听
众的印象
数据分析的过程就是不停地提出假设、验证并
修 正 假 设 ，最 终 获 取 真 相 的 过 程 。不 要 担 心 提 出
的假设是错误的，这远好过没有假设，因为没有
假设就没有切入点，分析工作会更加束手无策，
理不出头绪。
案例：M公司零售业务销售额下降的数据分析
本节中提到的两个报表引擎的
d e m o 地 址 如下：
进一步学习材料：
推荐阅读韩家玮教授的经典著
作《数据挖掘概念与技术》
1. 明细报表
2. 汇总报表
3. 动态仪表盘
4. 套打报表
1. 基本分析
2. 桑基图
3. Cohort分析图
4. 访客分析
5. 热力图
报表设计建议
1. 聚焦业务本身
2. 不要急于线上化
3. 上线后不要基于推广
4. 理解掌握数据仓库原理
http://demo.finereport.com
http://demo.smartbi.com.cn
软件的设计应该像搭积木那样，通过自由拼接组装来实现复杂的功能模块，这样既能保证系统
的 灵 活 性 ，又 能 避 免 重 复 开 发 ，降 低 成 本 。
如果不能将软件分解成像积木那样的小模块，而是焊死的一块铁板，那么系统将彻底丧失灵活
性。
1. 数据库表设计
2. SQL查询语句
BRD
商业需求文档
PRD
产品需求文档
诉求不同
方案不同
评论0