标签 - 人人都是产品经理
本文以笔者亲历的一次需求跟进经历为题，分析了其中关键环节、不当之处以及相应的改进策略。
这是我第二次跟进比较大的项目，由于涉及到官网首页的改版，领导断然不会交给我这个新人去全权负责的，所以我是在另一个产品经理画好前端原型图并提交给设计切图之后才开始接手这个项目的。
准确来说，是等我接手这个项目的时候，设计图也已经出来了。那么我的任务首先便是去找画原型的产品经理弄清楚原型里各个模块的意义、交互、规则。然后写需求文档、开评审会及开发。
这次在整个需求跟进的过程中同样也犯了一些错误，因此写下这篇复盘文档，完整回忆项目的整个过程，并对于每一个自己不满意的地方进行深刻反思，避免再犯。
一、 需求获取阶段
需求获取阶段是产品的第一步，对于需求的理解程度直接影响了后面每个环节和干系人的扯皮次数。
所以在接手这个项目之后，我第一件事就是找原来的产品经理确认需求，等到她把她说的都说完了之后，我又自己过了一遍原型，边过边思考需求，然后做了一些小的修改。
其中一个修改就是取消了在【XXX人与你一同学习】旁边显示学员头像，因为从当前数据来看，很少有学员会选择修改自己的头像，学员登录网站基本上都是学习课程，很少会去修改个人信息。所以如果显示多个头像的话，基本上都是显示网站提供的默认头像，一模一样的头像齐刷刷地叠在一起，那还不如不显示。
另外，在这个阶段里，让我受到启发的是对于【最热】、【最新】、【推荐】标签的思考。
以后在设计功能时，不仅仅要考虑如何实现功能，还要考虑如何用最低成本实现功能，以及是否会让用户对功能产生误解。
二、 需求文档撰写阶段
我的需求文档可读性还挺差的，每次读都能发现新的问题。
我现在经历过的项目还太少，对于前后端具体工作还不是非常了解、分得清，所以在这种情况下，我其实不应该在文档里按照自己的理解将前端、后端分开来写，这样容易划分错误，给开发人员造成困扰。（其实我分开写的初衷是希望开发可以少看点文字，帮助他们提高效率，可惜自己太菜了，反而弄巧成拙了TT）
另外，文档是开发人员工作的依据，开发人员需要理解文档之后才能着手开发，因此文档应该越详细、越确定越好。比如没有内容时显示什么、每轮轮播停留时长是多久之类的都要考虑到，都需要在文档中写出来，绝对不能把问题抛给开发。开发只会依据文档和设计稿来工作，文档和设计稿上面没有的内容，开发一定都还会找产品进行反复确认的。所以，与其后面反反复复地确认，不如下笔
作者从中间商出发，对常见的几种跨界形式进行了梳理分析，并对跨界需要满足的条件进行了总结，与大家分享。
由来已久的“中间商”
在谈跨界之前，我们先聊聊各行各业都会碰到的一个特殊角色——中间商。
在范文澜的《中国通史》记载：“牙人招揽买卖，协议物价，官府与商人交涉，有时也使牙人出面”。这里的“牙人”是唐朝对中间商的称呼，在明清时期，随着商品经济的进一步发展，牙商人数大量增加，形成了一个专门的行业叫牙行。其实，再往前倒推至西周时期，这种中间商称为“质人”。可以毫不夸张的说自从有了商品经济开始，就诞生了中间商。
为什么会出现中间商呢？因为在古代信息获取的渠道是极其有限的，掌握了交易两端信息的“牙人”在商业交易中起着重要的角色，信息互通比撮合交易更有价值。中间商解决的问题归根到底是信息不对称的问题。
自从互联网出现了，一切都不一样了，中间商的时代即将终结。很多平台型公司，首先想到的是解决某一个行业交易两端信息互通的问题，“干掉那个中间商”成了很多互联网公司高喊的口号。
互联网的出现多多少少似乎有取缔存在了几千年“中间商”的意思。瓜子二手车的slogan则更加直白“没有中间商赚差价”。
那是不是这个时代，中间商就不存在了呢？
实际上，现在很多行业还充斥中间商，在广告行业尤为明显。广告主投放广告基本都是通过广告公司或者代理公司开展投放业务。由“广告中间商”来合作投放的好处有两点：更专业的优化和更高效的成本控制。
当然，“广告中间商”的作用主要是发挥在主流广告平台的投放中。如果特定渠道的投放，如垂类媒体投放，则直接和平台方合作更为合理。
干掉那个“中间商”
在产品受众较广且有充足预算的情况下，“中间商”才有十足的价值。
产品上线初期预算不够怎么做用户增长？垂直人群产品如何做产品推广？相信大部分做流量增长的运营也我一样遇到过这类问题。
这个时候“跨界”合作将是做增长的一个不错的选择。
按照百度百科对“跨界”的解释是：是让原本毫不相干的元素，相互渗透相互融合，从而给品牌一种立体感和纵深感。
实际上，这个诠释有点笼统，在我看来，跨界合作是两个平台之间沟通好合作意向前提下寻找到有效的方式等量满足双向需求。打个比方，我是卖水果的，A是卖坚果的，我拿出一个摊位售卖A的坚果，A拿出一个同样大小的摊位售卖我的水果，一个“跨界”合作就成功达成。
回归到商业最初的形态——以物易物，中间商就失去了存在的价值。交易双方将本着契约精神，用
在流量红利逐渐消散的时代，做好用户增长不只是要从源头挖掘更多用户，还需要对现有用户精耕细作，精细化运营。
商机商机商机，是悬在所有市场人头上挥之不去的阴影。似乎线索永远都是不够的，以至于我时常会疑惑：市场上真的有那么多用户吗？
当流量成本不断走高的今天，我们不光需要增加“量”，更要对不同渠道的线索进行精细化培育，才能保障转化率，完成商机转出、业绩增长的目标。
改变增长思维，就是从刀耕火种走向精耕细作。
01 质和量——商机的增长瓶颈
ToB 公司销售业绩增速放缓的时候，销售老大对市场老大说的最多的两句话是什么？
最近线索量不够，得加大线索量啊！最近线索质量不行，成单率很低啊！如果非要有第三句，那可能就是：最近线索又不够，质量又不行，怎么办？
如何解决线索问题？市场同学加班加点做了以下工作：
把获客活动从一月一次变成了一月两次；扩充更多投放词；内容营销的发文频率翻倍；甚至各种托关系，买到了有效线索的联系方式；……预算多花了十几万，流量也随之翻倍，加班加点总算完成了新的 KPI 。然后销售/ SDR同学电话跟进，发现线索不愿意沟通，刚打通电话就被挂断、对方说没需求等等。成单转化率直线下降。
为了提升ROI（投入产出比），让花出去的1块钱，赚回来2块，又开始控制投入、砍预算，转化率回到了之前的水平，但流量也同样回到之前的水平。
这种模式下流量规模与转化率顾此失彼，最终的销售结果维持了原来的状态。这也是我们很多公司遇到的“增长瓶颈”。
02 用户认知思维
那么，是否有办法找到流量和转化的平衡点呢？
有的！
首先我们要解释一件事——用户认知。用户画像相似的情况下，有些人一听产品价值，马上愿意见面或试用。另外一些则嫌弃地说不需要，然后快速挂了电话。
这是因为，线索对产品的认知存在天壤之别。这款产品是什么、有什么用、能不能解决我们的问题，了解程度各不相同。这就引出了另一个概念：认知培育——用户在了解任何一款产品的时候，都需要经过一个理解不断加深、认知不断深入的过程。
在购买决策前，他们会经历这样的阶段：
无意识-有意识-感兴趣-选型-购买
无意识阶段：用户对产品没有任何了解；有意识阶段：用户对产品价值有了一定的理解；感兴趣阶段：用户了解产品价值，并愿意深入对接；选型：用户基于产品价值产生了需求，开始比对、选型，愿意接受demo或进行试用；购买；
市场上，已经对产品价值感兴趣的用户数量比例是很少的。销售/SDR 打电话
现在流量越来越贵，人力成本越高，越来越多公司专注于增长，在当下成立一个独立增长团队的必要性显而易见，那么组建一只高战斗力的增长团队有几大必备核心因素？从自己的一些经验和理解和大家分享，希望对你有用。
一、产品
首先组建增长团队之前，要看看产品能够提供用户愿意买单的核心价值，并且达到了PMF状态（市场契合度），如果产品核心服务还在打磨，核心价值尚未捕捉/未体现，盲目的追求增长是没有任何意义。因为来的用户再多也留不住，所以再厉害的增长团队也修不好一个“漏水的桶”。
盲目追求增长
健康增长曲线
如何快速找到并验证PMF有以下3种方法：
1. 精益画布
精益画布是《精益创业实战》根据商业模式画布方法改良而来，可以快速帮助创新产品快速找到PMF（市场契合度），将商业模式划分为9个互相独立的部分，填充完内容后就形成了一套完整的解决方案。
画布内容包含：
最需要解决的三个问题；产品提供的解决方案；产品功能需考核的关键指标；产品独特卖点；竞争对手无法复制的优势；找到用户的渠道；目标用户群体分类；成本分析；收入分析。
2. MVP（最小化可行产品）
最小化可行产品核心思想是在市场上快速投入一个极简版本的产品，然后快速迭代适应市场。最小化可行产品是一个最小、最基本的功能组合，可能有人会担心，“怎么能把次品流入市场，这不是伤害早期用户吗？”
最小化可行产品的主要对象并不是所有目标用户，而是产品早期的创新者，如果产品能解决核心问题，而创新者有一个典型表现就是“他们对当前问题非常困扰，非常渴望解决”。所以他们有更高的容忍度，解决他们当下痛点，创新者还愿意通过互动反馈来改进产品，得到更好的使用体验。
3. 设计冲刺
设计冲刺和最小化可行产品（MVP）是两种不一样的核心思想，设计冲刺的理念是“5天内验证产品是否符合市场需求”，其中5天对应工作可以模糊分解为：
描述并挑出主要问题核心；列出所有解决方案；选出合适可落地方案；制作交互原型；挑选用户进行原型测试。如果短期内产品方向无太大头绪，不妨可以使用“设计冲刺”，毕竟相对于漫长的调研上线测试，“设计冲刺”只需要“一周”就能得出结论。
二、文化
增长团队是倡导数据和实验驱动的文化，不再依赖主观意识以及避免最高领导权来拍板。打破了原有传统功能型团队的界限，团队成员之间更加紧密协作，但紧密协作的同时，如果没有领导层的支持时可能感觉“步步维艰”，增长文化最好有相关领导理解并认可，由实际行动
继上文讲到的互联网保险产品设计那点事（二）：保险理赔后，笔者继续从理算引擎角度入手做进一步深入分析。
01 前言
作为一个深耕互联网保险领域的产品经理，随着不断深入的接触保险业，会时常听到【XX引擎】这类名词。那么在互联网保险中，常见的有哪几类业务处理引擎呢？
核保业务处理引擎理算业务处理引擎核赔风控决策引擎…本章承接上一章保险理赔的内容，具体介绍一下在什么是理算业务处理引擎，以及理算引擎的业务主流程及产品难点。
理算：核赔的关键环节之一，指保险人在核赔过程中按照法律规定和保险合同的相关规定、根据保险事故的实际情况计算并确认理赔金额的一个过程。它作为理赔过程中最关键的环节一方面要维护了保险公司的利益，另一方面也要兼顾被保险人的利益，做到公平、合法、事实求实，遵循保险利益原则、最大诚信原则以及补偿原则等基本原则。
02 理算业务流程
如同上面的概念介绍的一样，理算就是根据保险合同的相关规则，将被保险人提供的消费凭证与报销证明进行一一校验，并计算出合理的理赔金额的过程。而互联网保险的产品价值，就是将这一复杂的校验和计算过程通过互联网的方式降低人力成本，提高核赔准确率。本文，通过健康险中的团险，简单讲一下理算流程。
在健康险中，团险的大多应用场景为企业为员工购买企业补充医疗险或商业保险。险种包含如下几类：「门急诊医疗」「住院医疗」「住院津贴」「女性生育」「意外医疗」「疾病医疗」「XX伤残」「XX身故」等等。以上几类在团险健康险的理赔中，出险频次最高的主要为「门急诊医疗」「住院医疗」「住院津贴」，可以说业务量占比超50%是稳稳的。
上图是我归纳设计的健康险的理算流程（此处PS：各家对于理赔理算的流程并不相同，此处PM需结合具体的业务特点进行整理设计。本文介绍的流程仅为抛转引玉的作用）
赔案数据导入：主要在理赔的录入环节中实现，将赔案所需理算的各个数据字段导入到理算引擎中。预计赔付理算：通过保险合同的理赔规则，通过赔案数据计算出预计赔付金额。实际赔付理算：通过保险合同的剩余保额和保额的扣减规则，通过预计赔付金额计算出实际赔付金额。结案：赔案理算流程结束，输出结案通知书于被保险人和承保人。本章主要针对上面四个流程中的【预计赔付理算】这个环节进行简单分享。
03 预计赔付理算流程
3.1 赔案数据拆单
在理算实际业务场景中，一份理赔案件中大多会包含多张发票，而理算师需要将每张发票对应的理赔金额一一算出后
好气噢，又看到有老师讲裂变，我兴高采烈的买了，内容竟然就是把人家做活动的步骤写出来了然后做个漂亮的排版，人家说这就叫案例干货……所以我给自己磕了个头，让自己加把劲儿总结点能用的上的来安抚自己……
呐，这基本就是做一次裂变的主要步骤了。我们经常接触到的裂变活动大概有：群裂变、任务宝、分销、打卡、测试、红包、拼团、带音效H5页面、灰产，基本上都是这么一个裂变流程图。
不管你是学习到的，还是工作中得到的这样一个流程的概念，你知道这个流程，并不能提升你的转化率，因为这仅仅算是个标准的工作流程规范。而且10月底微信就出新政策打击外链了，你11月了还给我看这个套路？？？
10月底微信出的新政策大概是这样的：
- 打击利诱分享/关注/跳转/下载。
- 打击违规拼团类内容。
- 打击H5游戏、测试类。
- 打击欺诈类内容。
- 打击违法经营及可疑服务类内容。
- 打击谣言类内容。
- 打击骚扰信息、广告信息及垃圾信息。
- 打击题文不符、内容低俗的信息。
- 打击非法获取和使用用户数据、信息的行为。
- 打击侵害他人权利的内容。
- 打击“宗教性捐献”及相关信息。
- 打击付费投票内容。
- 打击干扰正常使用、强制跳转类内容。
- 打击与微信相似功能服务类的内容。
- 打击特殊识别码、口令类信息。
- 打击违反国家法律法规的内容。
- 打击恶意违规及对抗行为。
- 你违反我规定我就采用阶梯处罚规则，封你链接、封你域名、封你IP、封你公号、限制你公号内容、封你接口……
在这个制度里，我们要注意的关键词是：外链、利诱、违法违规、强制、干扰、骚扰……所以我们做裂变到底会受到怎样的影响，我们以后要怎么做裂变？
一次完整的裂变包括的要素有：
- 裂变诱饵；
- 目标群体和渠道；
- 裂变规则。
接下来我就从这三个方面分享下我的看法。
一、成功的裂变诱饵应该是一个好产品。
裂变诱饵的选择
我们通常接触到的裂变都是有干货的裂变。有货的裂变最大的好处就是：用户精准。
比如：你送的是UI设计课程或者尿不湿，那参加你活动的用户一定是对UI课程感兴趣，或者需要尿不湿的群体。当然了，送实物要涉及到羊毛党的筛选，所以现在送资料或者送到店体验的活动更多一些。送资料的边际成本无限低，到店体验的转化率相对高。我们要根据用户需求和行业特性来选择合适的诱饵进行投放。
无论什么行业，做裂变最常见的诱饵就是内容，是资料。送资料最显著的好处就是，如果你的内容质量真的还可以，能对用户起到一定的帮助作用，那用户的忠诚度就会一下就建立起来，这就是内容自带的权威性。
你想一下，
对于大型商家来说，与各平台的合作错综复杂，需要一个逻辑清晰的自营订单系统进行管理，笔者在本文分析了自营订单系统的业务逻辑。
当前各大电商平台竞争不断，各有各的标准，各有各的玩法，这对于供货的商家来说其实是一个很大的挑战。
当然，对于一些小的商家（例如在淘宝开一个淘宝店）而言，工作人员也就几个人，工作并未细致分工，内部运营还是比较好管理的。
但是对于一些大型的商家来说，往往不单单与一个平台合作，而是与各大平台皆有合作，且体量庞大，内部人员众多，分工细致明确。这样就需要依附于各大平台搭建起自己内部的管理系统，便于内部运营管理。
对于这类因为入驻各大电商平台搭建起来的运营管理系统，其实分为很多域。例如，与各大电商平台供应相关对应的：商品系统，库存系统，价格系统，营销系统；与各大电商交易相关对应的：订单系统，客服系统，财务系统，结算系统。当然，这些系统可能不单单用于对接各大电商平台，有可能还服务于商家自主的线下平台，或者其他销售渠道。
今天分享的是，订单中心，或者称之为“自营订单（区别于各大电商平台的平台销售订单）”，是商家与各电商平台交易的核心纽带，是商家交易后运营的起点与枢纽。其结构大致如下，这里分为三块来简单分析：信息翻译，正向业务，逆向业务。
信息翻译
“自营订单”是商家交易后运营的起点与枢纽，而“信息翻译”则是自营订单的起点。
为什么单独列出这一项，主要有两个原因：
各平台语言不一致，内部与外部的语言不一致，人员适应需要成本；各平台语言不一致，内部与外部的语言不一致，后续系统适应需要成本。信息翻译涉及的内容很多，基本包含交易履约环节的所有信息。
正向业务：分为拉取与推送
（拉取）订单相关信息：订单基本信息，会员信息，支付信息，商品信息，收货信息，优惠信息等；（拉取）结算相关信息：销售平台分账信息，优惠分账信息，支付平台分账信息等；（推送）履约相关信息：发货信息，物流明细等；（拉取）履约相关信息：确认收货信息。逆向业务：分为拉取与推送
（拉取）请求相关信息：退货请求，换货请求，仅退款请求等；（拉取/推送）请求调度信息：同意退货，拒绝退货，同意退款，拒绝退款，顾客寄货/上门揽件，投诉制裁等；（拉取）结算相关信息：退款结算信息等。这些信息多种多样，并且各平台语言不一，所需要耗费的工作繁复复杂。虽说看上去并没有什么业务价值，却是后续所有业务流转的源头。
正向业务
我将正向业务分为了两个大的模块；
正向
喝八宝粥是不是曾经面临勺子太短够不到的尴尬境地？你最后是怎么解决的？笔者从这个问题，衍生了一些产品思考，和大家分享。
本篇内容来自朋友在深夜的灵魂发问，八宝粥的勺子为什么这么短？这个问题一出，引发了广泛的共鸣。
上篇正好讨论过类似问题：产品经理面试题：井盖为什么是圆的？
之前高德总监面试被问到过一个题目：你见过哪些用户体验差的实体产品？当时并没有回答得很好，大抵还是平时得积累不够。
作为一个产品经理，无论是互联网产品还是实体产品，都需要积极的去思考诸如以下的问题：
为什么这么做？为什么不像我想到的那样做？还有没有更好的方式？因此，由于八宝粥勺子过短且明显短于瓶身，导致作为用户来说产品体验较差（在吃不到和弄脏手之间疯狂试探）因而引发了周日早上一系列的思考。
首先回答主要问题：八宝粥的勺子为什么这么短？
用用户场景需求框架来考虑的话，八宝粥的勺子主要有以下两个使用场景：一是折叠起来运输，一是到了消费者手中打开用于喝八宝粥。
使用场景一：运输
先讨论运输的场景。
虽然最终我们拿到八宝粥的时候只会考虑勺子好不好用，但事实上，运输场景也是产品设计过程中需要认真考虑的一个环节，因为它和你的钱包直接挂钩。刚好之前在得到上面听过贾伟老师的设计课程，我举个简单的例子你就明白了。
下图这个是宜家的一款杯子，虽然和普通的圆柱形马克杯相比稍显得有些不一样，且手柄靠上有点不方便拿的样子，但它用产品设计解决了很重要的成本问题。
（深谙设计之道的宜家——图片来自得到文稿）
因为每一个产品的售价不仅仅包含本身原材料的成本，还有生产成本和物流成本。这款杯子上宽下窄可以一个套一个叠放，背身高度刚好严丝合缝装满集装箱，因此这个杯子将运输效率大大提高。运输效率提高的背后，物流成本降低了60%。
虽然看起来好像用户体验变差了，但是这样的设计仍然很受到市场的欢迎。这是因为用户体验可以拆分为产品可用性、易用性和好用性。
尽管修改了设计，但不影响最本质的产品可用性，它依旧是个能喝水的杯子，这是最核心的用户需求。因此虽然一定程度上影响了易用性和好用性（这个较为主观，因人而异）；但由于售价大大降低，对于大部分用户来说依旧是不错的选择。
说完杯子，我们说回八宝粥。从运输成本角度来考虑，我们就很好解释这样的设计了。因为目前的产品设计是将勺子折叠隐藏进入瓶盖中，这样无疑能提升运输效率，降低成本，毕竟产品的售价是实体产品竞争力很重要的一环。
虽然也有朋友找到
转岗产品经理，第一点需要评估的就是抗压能力是否足够强，其次才是是否有良好的学习能力、决策能力、沟通和协调能力。
我经常会被问到：
设计师转做产品经理难不难?运营转产品可以吗?程序员是不是可以转产品？我周围的产品经理也确实有设计师、运营、程序员转做产品的，相当一部分也做得特别好。原先的岗位经验也对产品工作有颇多益处，比如原来是设计师的，审美特别好，做的产品会比较美观；比如原来是开发的，与开发交流的时候，省却不少麻烦。
老实说，产品经理基础的技能点很好学，在网上看下技能树，系统了解一下、学习一下，问题其实并不大。后续的进阶，需要在实操中，不断累积经验，不断进步。
这个成长路径，不仅产品经理是这样，所有的岗位都是这样。
所以，设计师、运营、程序员转做产品经理，无论是理论上，还是实际上，都是可行的。可行是可行，但是要不要转呢？
首先还是得评估下自己和这个岗位的匹配度。
具体来说，是指评估你个人和这个工作所需要的能力和特质是不是匹配。如果匹配，整个过程或许会稍微轻松点；如果不匹配，可能会有些痛苦。
那产品经理需要具备哪些特质呢？
一、抗压能力
产品经理的压力是一个系统性的压力，来自各个方面。
设计师面临的压力是设计任务的压力，这个页面的完成情况，是否符合产品的需求，界面是否符合用户体验。在一定的时间内，经过修改，需要交付一个令人满意的设计作品。
程序员面临的压力可能是工程压力，程序是否完善，代码是否优美，逻辑是否完整。
运营面临的压力可能是产品的拉新、促活、留存、转化等数据上的压力。
互联网，每一个岗位都压力巨大。
而产品经理面临的压力差不多是这些的总和。
产品上线前，我们要对交付负责；产品上线后，要对数据负责。
首先是需求阶段，需求的收集、整理、判断、决策，需求文档的书写，需求的评审等，需要对接的是用户、上级、相关的同事等。
这个阶段面临的压力是质疑。无论是需求的判断和决策，还是具体的需求的评审，你将面临各方的质疑。这个阶段也需要较强的心理素质，扛得住这些质疑，并且要通过市场/数据/用户需求/用户体验/用户场景这些角度，把质疑声一一消灭。
其次是设计阶段，这个阶段不仅仅是设计师的事情。前期产品经理需要把需求和期望的风格给设计师说清楚，设计中也要多次沟通，争取设计完一个页面，就评审一个页面。不要全部都设计完了，才给设计师说不行。
和设计师沟通的时候，也要掌握技巧，要说明，为什么要改，怎么修改，而不是直接说丑。如果面
本文介绍了数据产品经理需要懂的常用图表设计，并针对19种图表的定义、适用场景、优缺点，进行了分析说明。
概述
数据产品经理在日常产品设计时经常需要设计一些图表来对数据进行更好的展现，也能方便用户更好的从数据中获得有价值的信息。图表是将数据进行可视化展现的图，用来方便理解大量数据以及数据间的关系。数据产品经理在进行图表设计时首先进行需求的分析，熟悉数据并且明确数据要展现出来的信息，然后选用合适的图表来进行数据的展现。
常用图表
常用的图表有很多，在进行数据产品设计时需要根据数据选用合适的图表展现来把数据的信息传达给用户，因此，我们需要熟悉每种图表的定义、适用场景、优缺点，这样才能快速选择合适的图表。
1. 柱状图
定义：柱状图是一种以长方形的长度为变量的统计图表。长条图用来比较两个或以上的价值（不同时间或者不同条件），只有一个变量，通常利用于较小的数据集分析。
适用场景：数据集不大时数据比较
优点：直观表达各组数据差异性，强调个体与个体之间的比较。
缺点：不适合大量的数据集数据展现；不适合表示趋势。
2. 折线图
定义：用于显示数据在一个连续的时间间隔或者时间跨度上的变化，它的特点是反映事物随时间或有序类别而变化的趋势。折线图分为直线折线图和曲线折线图。折线图可以清晰的反映数据是递增还是递减、增减的速率、增减的规律（周期性、螺旋性等）、峰值等特征。
适用场景：反映变化趋势
优点：直观反映数据变化趋势
缺点：数据集太小时显示不直观
3. 条形图
定义：条形图是用宽度相同的条形的高度或长短来表示数据多少的图形。条形图能够使人们一眼看出各个数据的大小，易于比较数据之间的差别。
适用场景：适用于数据规模不大的数据展现
优点：直观展现数据的差别
缺点：不适用数据集较大展现
4. 饼图
定义：用于表示不同分类的占比情况，通过弧度大小来对比各种分类。饼图通过将一个圆饼按照分类的占比划分成多个区块，整个圆饼代表数据的总量，每个圆弧所在的块表示该分类占总体的比例大小，所有圆弧所在的块组成的圆饼等于 100%。可以很好地帮助用户快速了解数据的占比分配。
适用场景：对一个对象和整体之间的关系进行比较
优点：直观反映比例关系，了解数据的分布情况
缺点：分类过多，则扇形越小，无法展现图表；无法直观进行各个数据的比较，难以直接对数据大小进行排序。
5. 散点图
定义：数据点在直角坐标系平面上的分布图，表示因变量随自变量而变化的大致趋势。
适用场景：