文章图片
小飞象·交流会
所有的人都在努力，并不是只有你满腹委屈。
文章图片
文章图片
内部交流│10期
数据分析中的产品思维
data analysis
●●●●
分享人：马小驴
?
做数据分析离不开要和一些“产品”打交道，如BI报表平台、埋点平台来统计数据，做数据可视化等，更主要的是要让你的数据分析结果有“价值”，能“落地”，那么必须有产品思维，即：用户的痛点是什么（对应数据分析：业务方碰到什么问题）？设计什么样的产品（请记住不是功能）来解决（对应数据分析：你给出什么样的观点或者方案）？怎么让用户接受这个产品（怎么让你观点或者方案落地执行）？
那么，本期邀请了就职于某国企的数据分析师马小驴老师，多年数据分析经验，目前主要带领团队开展公司内部数据应用平台的产品建设和数字化应用相关工作，来为大家分享一下数据分析中的产品思维，来看看数据分析怎样与产品思维结合相关的内容。
将会为大家分享《数据分析中的“产品思维”》的相关内容，分为四部分：
1、数据分析怎样与“产品思维”结合（产品思维相关认识）
2、如何理解用户
3、需求分析相关方法分享
4、产品发布和迭代升级等方面的经验分享
文章图片
（马小驴个人公众号）
为了更好的后面做好小飞象内部交流会，需要您帮忙做两件事情：第一，您想想这次为什么想参加这一期的交流会，以及希望在交流会中希望收获到什么？第二，在交流会结束后，请和我说一下您的收获和感受。（可以在公众号留言交流，小飞象内部交流会往期回顾）
做一个对世界充满好奇的人！在分享之前，我们可以先思考几个问题：
★你认为/了解过什么是产品思维？如何理解用户？
★你结合自身经历，是否在工作中也遇到过“如何做需求分析”么？
★你知道的视觉设计的注意点有哪些？你认为的产品思维如何与数据分析相结合么？
......
在分享的过程中，建议全程认真听，带着思考来听（去看），希望通过本次分享，来给大家做一次系统的数据分析可视化分享，来解答大家对于可视化的疑点，并给做数据分析的人员提供一些思路，有任何问题都可以随时交流哦！
【大数据|数据分析中的“产品思维”经验讲解】正式分享
—▼—
文章图片
▼
本次分享的主题是【数据分析中的产品思维】，也就是介绍分享一些在数据工作中，可能有价值的产品的思维和技巧。而我目前经历是在某国企做数据分析师的工作，不过，也许是国企的数字化转型期间的特殊阶段的原因，总之，其结果就是我这个数据分析师总感觉『不太纯』，从工作范围看，我好像既要做产品，又要做UI设计，既要做数据分析，还要做一部分基础开发。
因此，在这种模式下，我通过各种野路子，摸索到了很多数据分析与产品相结合方面的经验，部分也许在分析中有用的经验技巧也可以在这里与大家分享。
那么，我们首先来了解一下什么是“产品思维”？
文章图片
产品思维，在网上有太多概念，定义非常宽泛，但以我过往经验，我认为的产品思维定义为：
产品思维是用产品化的方法和手段去解决问题的一种思维方式。
而了解了产品思维的定义后，那么，数据分析为什么需要产品思维？也是本次分享的核心思想。也希望大家能在数据工作中也能用产品的思维去思考。
▼
文章图片
作为数据分析师，我们往往需要完成数据监测任务、写SQL满足业务方的取数需求，以及写分析报告、做PPT等汇报材料等，这些日常工作占据了我们的大部分时间。但数据分析为什么需要产品思维？
1）我们做数据分析的产出本身就属于产品。
产品是为用户提供价值的载体。
它的关键是，用户和价值。也就是说，对于服务于用户，并且可以通过满足需求来产生价值的东西，当然可以视为产品。
具体地，根据朝乐门老师的《数据科学理论与实践》书中的介绍，数据产品（Data Product），是能够通过数据来帮助用户实现其某些目标的产品。形式上，包括数据集、文档、知识库、应用系统、硬件系统、服务、洞见、决策及其各种组合。
从层次上，可以包括：
1） 内容，以数据为载体的产品，比如数据库、知识库、语料库等
2） 应用，数据密集型的应用系统，比如App、网站、桌面应用；
3） 服务，数据驱动型的服务，比如咨询报告、解决方案、实施指南等；
4） 决策，以数据为中心的决策，比如战略规划、规章制度、洞见与行动等
那既然我们做出来的东西可以算是数据产品了，当然可以用产品的部分方式方法，去完成我们的数据分析工作，让我们的工作发挥更大的价值。
文章图片
2）运用产品思维可以更好地发挥工作的价值。
我们可能会遇到这样的情况，比如业务方提出了取数需求之后，等到排期给他做完，回来了他们却说拿到的不是需要的东西，你要是说，“怎么不是？你提的需求就是这样的呀”，两边就闹矛盾起来了。
或者，从业务那边说缺少一列数据，拿到数据之前不知道缺少，拿到之后又来不及等下一次排期，结果业务开展就耽误了。
再还有一种情况就是，分析出来的数据并不能在业务上起到作用，业务那边根本不用，或者不认可这些结论，等等。
万一，这种情况发生在我们给上司做的分析上，我们的报告并不是他想要的东西，那问题可能更严重，返工是免不了了，说不定还有更大的问题。
为什么呢？一个可能的原因就是，我们在数据分析工作中，采用的是『任务式』的思维方式，也就是『按要求完成手头任务就行』的思维方式，兵来将挡水来土掩，见招拆招，你让我干啥我就干啥。
文章图片
3）运用产品思维有助于理解big picture（大局）
拥有一定的产品思维可以让我们更好地定位我们的手头工作，知道工作为什么而做，有助于更好地从大局视角去看待问题。也就是所谓的大橘为重。
如果你在工作中会与类似产品经理身份的人员打交道，也可以更好地了解他们的工作思路和思维框架。在个人成长方面，也更有价值。
文章图片
总之，数据分析为什么要有产品思维？
（1）数据分析结果产出本身就是产品
（2）有助于发挥价值
（3）有助于理解大局
—▼—
文章图片
▼
其中，产品我们在前面已经提到了，产品是为用户提供价值的载体。那么，我们要弄清楚的就是，用户是谁？
我们的用户是谁？来看一下案例!
文章图片
赵大忽悠卖拐，把拐卖给了范厨师。这里，拐是产品，范厨师是用户。
那么，我们就来看看用户的概念？
▼
文章图片
（1）用户的概念
我们看俞军老师在《俞军产品方法论》中给出的用户定义：
“从产品经理的视角来看，用户不是自然人，而是需求的集合”。
我们的用户，也不是张三李四王总赵总这样的具体的人，而是各类的需求的集合。
即一个用户会有不止一个需求（用户与需求是一对多的关系），当某个产品完全满足某个用户某个场景下的某类需求时，才可以说此用户是该产品的一个用户，否则该产品就只能说：此用户属于我，但又不完全属于我。
用数据分析的方法来理解就是，我们的产品满足的是几大类用户的需求，而具体的人是这一类用户中的独立个体。
▼
文章图片
（2）用户画像
认知用户的基础方法是用户画像。抽象用户的共同特征。
用户画像需要大量的调研和分析，咱们这里简单来说说可以粗略地认为，首先一个个独立的用户包括年龄、性别、住址、部门、登陆设备、技术背景等很多很多信息，以及一个或者多个需求。那么，我们首先基于需求，来看不同需求的用户有什么相似之处，通过有监督学习相类似的方法形成分类，每一类有一些容易获取的特征，通过这些特征就可以粗略估计用户的需求，并提供对应的产品。这是产品分析用户的一种思维框架。
这样的分析，就比如我们的运检专业师傅和营销客户经理等，都需要基于内网的地图做查询、统计、分析等，这些虽然从人员上各不相同，甚至部门都不一样，但在地图查询方面却有相似的需求，那么他们就可以作为一大类相同的用户群。
相应地，我们如果做某些分析的时候，也会发现虽然用户千差万别，但可能需要的东西却是相似的，这就存在做一个通用产品，来满足共性需求的可能性。
▼
文章图片
（3）用户和客户
不过有个注意点是，用户不一定是客户。比如家长给孩子买玩具。谁是客户？谁是用户？这就要看玩具给谁用，孩子玩玩具，家长只是买，并不玩，所以很明显，家长是客户，孩子是用户。
用户：使用者
客户：付费者、购买者，是代理人和中间人，将产品与使用者关联起来。
同样的方法，我们分析网上经常能看到的 “怎样卖梳子给和尚”。
如果我们将梳子视为产品，那么将和尚定义为用户，就不容易完成推广。但是如果和尚只是客户，或者直接看做中间人的话，或许就能找到突破口了，这就是一种找到解决方案的思维框架，比如将梳子用作寺庙上香的回馈开光平安梳之类的。
明确了用户和客户的差异之后，我们就不难理解为什么很多时候公司采购的系统或者软件那么难用——因为做决定的人或许根本就不用……那么，如果放在我们的话题上，我们的数据需求，其『用户』不一定是『客户』。
文章图片
所以，我们应该是，以用户为中心，还是以客户为中心？假设我们需要分析产品销售情况，那么这个点可能就是需要参考的点了。
文章图片
（业务部门做的也不一定是老板想要的）他们需要的也不一定是解决业务问题需要的；如果你所在的岗位，数据和具体用户之间存在『二传手』，比如产品或者什么人，那就需要注意当前的服务对象是谁，满足的是什么。这种情况双方一般是协作的关系，但如果能友好交流的话……
这里还涉及一个博弈问题，是多做多次简单的东西拿到奖金，还是做有价值的东西。比如我们之前有些阶段是按照工单数量来计算业绩，那样的话，数据分析师这边就完全不在乎返工次数，反正每次重新提交需求都是新的工单，还可以拿钱，有何不可，结果这样搞下去，反而导致全流程的整体工作效率大幅下降。这些通常是组织模式上的问题，这个，就不在讨论范围内了。
—▼—
文章图片
▼
产品的另一个关键词是价值，价值是什么？能够满足需求的东西就有价值。所以我们要关注于要满足什么需求。
“需求”这个词我们熟啊！作为数据分析师我们经常与需求打交道，比如在数据这边，做个什么分析结论，或者要为业务人员SQL取到A数据库的B字段，或者要C系统的D数据等等。而数据团队通常也是按照这个方式，排期，写好SQL，数据导出或者挂到数据平台上，给用户使用。
需要增加对需求这个词的解释。 因为数据分析中的需求有可能含义不一样。因为有需求，所以我们有行动。需求定位准确，可以让我们的方向更加准确。
（1）需求，是什么！
文章图片
需求的本质，对用户来说，目标和现状之间存在差距，想要消除这个差距，就会产生需求。
所以，我们为了理解需求，首先要知道什么是目标，什么是现状。但是，需求方，比如我们的业务人员，或者很多上司，在他们的需求表述中，不一定直接表达了这两个重要因素。这种情况下，一旦没有思考这次要做的事情，说不定就掉到坑里了。
举个例子：一只帅气的大猩猩，他说想要飞起来，让你帮他。
这个如果作为任务去处理的话，我们或许就是做一个飞行器，一个竹蜻蜓，或者做了个火箭之类的，这样猩猩就飞起来了。（消失在天际）
然后，可能就惹猩猩不高兴，接着就挨揍了。为啥呢？这就涉及用户提出需求的一个很常见的点：
他提出的不一定是需求，甚至往往是『他以为的』解决方案。而这个『他以为的解决方案』，既没有表达出现状，又没有说清楚目标，这种时候我们盲目去完成『他以为的解决方案』的时候，往往并不能解决他的问题。
也就是说，回到刚才的案例中，如果我们去问一下这位猩猩先生，这位giegie，您为什么要飞呢？他可能说，啊，老夫要飞起来去那个树上摘香蕉吃。这样调查之后，我们知道，哦，原来目标是摘香蕉吃，而现状不是不能飞，而是吃不到。也有可能他说，我想要飞起来显得帅气，这样可以帮我追猩猩妹子。
这样我们的解决方案就可以从做飞行器，调整为帮他解决吃香蕉的问题了（或者是变得帅气，从而追妹子），不仅方法会变得多起来，而且成效也更容易保证。
再一个就是非常经典的案例：用户说想要更快的马，实际上他想要更快到达目的地，所以，可以提供更快的车来满足他的需求。
这在需求分析中，叫做『Want』和『Need』。
文章图片
这些看似简单的小问题其实在工作中经常遇到。比如前不久，我在和营销人员沟通的时候，他们就说给数据提出的取数需求，等到结果跑出来了，才发现少了一列，结果耽误事了。如果这种情况，数据团队真的去了解业务人员拿这些数据想要解决什么问题的话，说不定这个事情就可以避免。
（2）表面需求和深层需求
表层需求：短期的，半衰期短的，
深层需求：稳定的，长期的，根本的。
文章图片
（3）真需求和伪需求
文章图片
▼
文章图片
那么，有没有简单的小技巧可以快速准确地分析出实际需求呢？当然有，从刚才的分析中其实已经体现出了这种分析的模式，也就是“多问几个为什么”。
（1）面对面用户访谈
在不把用户搞烦的前提下，尽量多问一些为什么，来了解到背后的原因
从形式上来说，我们的沟通需要较多的来往，所以尽量不要用微信或者短信之类的工具，而是在面对面的情况下沟通，最差也要通过电话去沟通，这样可以问得更加清楚。
?用户故事
有一种好工具，叫做用户故事，是一种描述需求的好办法，一些业务分析师应该也会用到。把需求描述清楚了往往可以帮助我们精准定位需求，或者发现当前没有很好地理解的需求。
文章图片
什么叫用户故事呢？
用户故事、验收标准；好用户故事INVEST法则，如图：
文章图片
?对比分析
和现有解决方案比较法。
简化版竞品分析，这里的目的，不是为了超过竞品或者吸引客户之类的，而是核心目的是更好地了解需求，引导用户去清晰地表达需求。
?（胡乱）猜测法：
你做XX（客观行动），是因为你XXX吗（猜测）？
一种问法。借鉴了非暴力沟通的表达方式。
（2）问卷调查
问卷调查适合于短时间大量收集信息。是面对面调查的有效补充方法。
文章图片
—▼—
文章图片
接下来是关于数据产品发布、迭代、升级方面的一些分享。
用户价值 = 新体验 – 旧体验 – 替换成本，所以，我们的优化工作可以包括
（1） 优化新体验
（2） 降低替换成本
▼
文章图片
（1）争取相关人员（专业方面）的支持。
还记不记得前文提到的『用户』和『客户』？如果你的产品得不到『客户』的认可，说不定连触达用户的机会都没有。
举例说明，比如我们公司在运检部的工作票分析产品，因为得到业务负责人的支持，推广应用就很成功；而我们的移动端缺陷管理产品，虽然员工很需要，但是业务负责人不认可，这件事就没有推广起来。
所以，我们有必要快速精准地概述我们的产品，这里常用的方法是『电梯演讲』。电梯演讲这种架构可以让我们快速说清楚正在做的产品或者项目。如下图：
文章图片
文章图片
（2）渠道要简单
简化入口，优化体验这个就涉及按照用户的使用习惯去优化产品的表达形式了。图片、图表、交互，或者文字。
用户切换产品有代价。除非一定要用我们的产品不可，否则用户切换产品，就要考虑切换成本。对年纪大的用户，找到产品在哪就影响很大。
简单的渠道可以降低替换成本。
▼
文章图片
（1）功能要合理
用户体验最重要的事情在于做出分层，区分哪些是可用性，哪些是易用性，哪些又是用户的稳定性诉求。—— 刘飞《产品思维》
功能点，通过前文的用户故事可以一层一层地梳理得到。包括功能优先级的梳理：HML方法（高中低）、MSCW方法、KANO方法等。
通过KANO模型，来分析并提供意料之外的惊喜。
文章图片
（2）视觉要协调
一些视觉方面的技巧，如下：
①文字统一
文章图片
②排版统一（包括圆角、对齐等）
文章图片
③颜色协调
文章图片
（3）重视反馈
让用户反馈得容易、反馈得及时、反馈得准确。
文章图片
比如，在每个报表上面都加上超链接，一键提交反馈意见，或者像win10磁贴，右键即可快速反馈意见。相比之下很多安卓应用想要反馈，就比较困难。
比如，建立微信群，随时沟通；
比如，标注计算标准，或者自动上传日志等。
文章图片
—▼—
文章图片
总结
以上就是本次分享的全部内容！
1、数据分析中的产品思维
?产品思维是什么
产品思维，即用产品化的方法和手段去解决问题的一种思维方式
?数据为什么要有产品思维
（1）产出本身就是产品
（2）有助于发挥价值
（3）有助于理解大局
2、理解用户
?我们的用户是谁
（1）用户的概念
（2）用户画像
?用户和客户
（1）用户不一定是客户
（2）以用户还是客户为中心
3、如何分析需求
?需求是什么
（1）需求的本质
（2）表面需求和深层需求
（3）真需求和伪需求
?怎样分析需求
（1）面对面用户访谈
（2）问卷调查
4、发布和迭代升级
用户价值 = 新体验 – 旧体验 – 替换成本
?降低替换成本：
（1）争取相关人员的支持
（2）渠道要简单化
?优化使用体验
（1）功能要合理：kano等分析模型
（2）视觉要协调：字体简明、排版统一、颜色合理
（3）反馈要舒适：反馈得容易、及时、准确
文章图片
文章图片
总之，数据分析的核心并不在于数据本身，而在于设计有意义、有价值的数据指标，通过科学有效的手段去分析，进而发现问题优化迭代。并且，在数据分析的工作中我们应该利用产品思维来总结自己的痛点、核心指标体系、分析方法论等，然后提出相应的产品需求，发现问题，分析问题，解决问题，让自己有精力往更上层去思考。并在日常工作中，时刻需要考虑，这个可以标准化吗？可以产品化吗？需要整合到一起去吗？当然，不是一次分享能全部了解的，仅一家之言，供参考。
最后，相信大家通过不断的学习和实操，认识到产品思维在数据分析中的应用以及价值所在。学贵在行，需要我们在以后的学习工作中不断地积累经验掌握工具，学以致用。能站在多方角度，发现问题，分析问题，解决问题，总结问题。
后期小飞象会继续为邀请各业的精英分享数据领域的内容。祝愿大家都能在自己所在的领域内，用数据思维，成就更好的自己，在可预见的未来，遇到更好的自己。谢谢大家！
文章图片
······
敬请期待下一期
本次分享到此结束，再次感谢大家的收听，我们下期再会！
（本文由木兮整理，可能与演讲时略有遗漏，但整体思路精华都在）
? ……
图片来源于网络
若好的建议和想法，欢迎在下方留言
我们将尽其所能打造数据分析交流的理想之地
文章图片
推荐阅读
- 大数据|《数据分析思维》（分析方法与业务知识）
- Python实战教程|30天Python入门（第二天（深入了解Python中的变量和内置函数））
- OpenCV|多边形点测试
- Python|OpenCV简单应用（三、边缘检测及轮廓检测）
- 人工智能|10 个开源 Python OpenCV 小项目，YouTube热门
- Spark|基于Spark封装的二次开发工程edata-base，介绍
- python|编译安装 Python
- DRF 中的模型序列化到底该怎么用（）
- 微软|告赢了！程序员拒绝春节带电脑回家工作被开除，判决获赔19.4万！