无论在哪个行业，数据化在工作中已经成为一种趋势。那么假如我们在一个数据量并不多的环境下工作，或者业务的领导对数据驱动并不了解，我们要怎样开展数据驱动业务呢？一起来看看这篇文章，希望能为你的数据分析工作带来帮助。
最近接了一个读者的咨询，针对他所在的公司老板让他做数据驱动，我最近一年也做过几个关于数据驱动的咨询，发现一些共性问题，这些问题并不包含在之前的内容中，于是乎便有了这篇文章。
如果你目前工作的环境，数据很少，或者说你也想在公司开展数据驱动，毕竟团队建设是俞军老师提出来的一个基本的能力要求，作为旁观者和亲历者那么这都是你需要思考的问题，随着行业逐渐成熟，依赖数据精细化的经营是必然的结果，数据驱动是每个职场人逃不开的宿命。
事情背景老板和我的读者沟通觉得团队目前的工作上缺乏数据知道，大部分的判断都是感觉业务领导的直觉判断。希望可以做到团队使用数据来做经营与运营决策，于是他找到了我。
我自己的调研中发现推动数据驱动的人有一种能力禀赋认为分析力最重要，认为团队没有数据分析能力，所以团队不行。还是我注重数据分析。但是这从商业角度是看团队不能数据驱动不是个严重的问题，商业上最严重的问题还是业务上要命的问题，比如不增长，无论是营收还是业务不增长，才是老大最痛的问题。
事实上一个业务人员素质不高，还能保持高增长其实是非常好的（通常这种情况不会发生）如果真有这个情况我觉得老板多半会很happy，人员素质不高，还能高速增长说明人员可替代度高，成本低，这是好生意。
所以这里引出了第一个点“审题”，审题是非常重要的，就是老板说想数据驱动到底想要什么？
大部分老板说出想要团队数据驱动的时候，其实他们只是想要业务增长，并且大部分的老板本身并不懂数据，也很可能没有经历一个数据驱动的业务，他们认为看清数据就可以指导业务，预期上过分拉高了数据价值，核心问题还是在业务上，所以需要实施组建业务团队的人自己去看下是否团队具备数据驱动的基础。
搞清楚老板想要什么，他是如何看待数据驱动的，他把团队的数据驱动看成是能力建设，还是看成经营策略，在一个没有数据能力的组织里面，数据驱动一开始更多的是能力建设。
因为业务是通过支撑运营业务的组织来推进的，组织如果没有数据分析能力，不认同这个能力，不可能让业务数据驱动起来。不可能只有老板有数据分析能力，或者商业分析部门有分析能力就转起来的业务。
通常推动一个团队数据驱动，需要从：数据基建，工具，工作流程，组织分工，人员绩效等多个方向驱动团队，让整个团队进入到数据化日常工作的方式中，因为单一部门无法调度所有的环节，而任何一个环节做不好，都会影响最终团队是否能够数据驱动。这就是为什么说数据驱动是一把手的事情，是CEO的事情。
通常这些问题都会导致数据驱动最终走向失败，这就是团队数据驱动难的原因，这些问题可以成为，公司内部展开数据驱动或者你想做数据驱动的一个排查表，如果碰到这里面的问题，要不解决它，要么走人。因为这些问题都会导致最终的结果无疾而终。
首先先要思考业务是否具备了团队数据驱动的条件，通常业务要么进入到增长期，要么是进入到相对成熟期比较适合做数据驱动，就是业务本身在增长，团队处于一个奔跑阶段，如果目前业务放缓，那么多半不太适合数据驱动。
因为这是老板和CEO会由于业务压力更加聚焦数据产生的经营策略，但是通常一个业务进入到不增长或者很缓慢他不是经营策略的问题。既然是一个一把手需要去做的事情，我们就核心列出一把手或者说老板常犯的错误。
CEO自身缺乏讲业务转化为指标的能力，以及不知道指标和经营动作之间的关系，会导致：
问题1:给予业务的数据沟通形式化。
他不会用数据口径团队沟通，很多公司为什么数据分析变成走形式化，大多都是一把手不能够进行分析，没有数据感，这会导致他本身不知道数据和指标的价值，也不知道通过数据做经营，以及探察经营方向，逐渐会使得给予数据化的汇报业务形式化，因为没有价值，这种工作方式就很难维持下去，好比一个人运动是为了瘦，他运动了不瘦就很难坚持下去。必须要有正反馈。
问题2：总觉得数据不够看。
因为他洞察不出东西来，就认为需要扩大搜索面积，就觉得当前的数据不够，因为不知道哪些数据可以洞察内容，就会变成一个纯基于业务的数据拆解。要知道最好的状态是使用最小的成本获取够用的数据，够用就好。特别是业务的早期，借用微信和抖音等运营业务，这些工具本身提供了数据就因该支撑起自己对于业务的经营判断。
数据够不够看就好比罗翔老师讲的正义的圆，没有绝对的正义，也没有绝对的数据看清，数据看清本身有开发成本和时间成本，我们都需要在有限的条件下做判断。
问题1:通常老板为了短期利益或者迫于业务压力，会直接把业务压给商分或者数据科学团队，这样会造成几个问题。
第一是真正实施业务运营业务的是业务方，相当于业务方完全独立于业务去经营业务，第二是会造成商分或者数据科学团队被夹在中间，一遍是老板的业务压力，一般是没有参与进来的业务方。第三就是这会直接导致商分从辅助业务的角色变成业务对立面。
详细讲解一下这张图：团队数据驱动整个事情上，真正让业务数据驱动起来是CEO和业务方，必须要真正做一线事情的人开始懂数据，具备数据分析能力才能做。
CEO不知道看哪些数，以及不知道数据代表着什么，他也很难和各个业务方沟通。核心还是CEO和团队去经营，数据分析团队在这里面辅助经营决策，提供数据，降低数据获取成本。
说白了就是业务方懂业务，数据方懂数据，业务方有业务实施的权利，需要互相配合，好的流程是左边的样子，不好的流程是右边的样子，很多老板会把业务压力直接给到商分属于典型的权责利不对等。
第二点是数据驱动是一个短期对业务方有伤害的事情，谁不喜欢摸鱼，大锅饭，你忽然间把所有的业务现状和经营动作都透明化了，滥竽充数就不容易了。
组织变革本身各个部门老大是没有数据能力的。他们也没有很强的改革动力，但是长期看无论从商业角度还是从个人能力角度都是好事情。所以数据驱动要“悄悄的进村”逐步提升强度。就算是CEO直接推进也要逐步提升强度，否则容易造成和业务方对立。
咨询的案例中很多数据驱动都是老大有变革的动力，相关方没有，但是老板由于各种原因没法硬推，抵制的人绕不过去，担心用力猛了团队散了，导致项目最后搁置。这就是为什么多人说数据驱动是一个CEO一把手来做的事情就在于只有CEO通过工作流程和组织流程去驱动业务一线人员参与到这个里面，才能让数据进入到日常的工作中来。
团队数据无法驱动的原因，在团队方向上主要有两点，第一是人员能力模型的缺失。之所以业务不数据化，其实是做业务的人不数据化，业务是被人做出来的，第二是业务方缺乏提升数据能力的方法和策略， 所以单纯的要求很容易导致团队和领导对立。
不要试图通过专项来解决问题，主线路有问题，就改造主线路，临时抱佛脚有用，但是无法持续到主业务当中。工具没有思想不产生分析思路，好比再好额毛笔，主要是不会画画，而不是工具不得手，不要试图通过工具给出分析框架，这不现实。现实中的业务复杂度高得多，如果一个工具框架可以解决分析问题，那么这些所数据分析工具的公司也不会被收购。
数据分析师和商业分析师团队一定要独立于业务线，隶属于CEO，这样他们才能说真话，不然会为了论点找论据，碰到过很多的公司，团队一汇报业务都在涨，但是汇总之后发现大盘没有动静。
既然是能力建设问题，又涉及到很多部门的协调，CEO就要亲自问，亲自追，花时间和精力上去。能力建设就是复杂的，涉及到组织，工作业务流程，中台架构等方方面面，不能跳步，需要一步步拆解。妄图想把事情全权交给一个统筹的人不太现实，权责上他就做不到，既然重要就是看CEO花的时间，时间是CEO最重要的资源。最后讲讲数据驱动到底是什么，该怎么做。
首先说一下数据驱动到底是个什么事情？我试图寻找「数据驱动」的定义。维基百科上的解释说这是一件事情，它整个流程是由数据驱动决策，而不是靠经验和直觉。我们说数据驱动的时候，它的对立面更多的是一种经验，或者是直接的驱动。
数据科学家是比软件工程师更懂统计，但是是比统计分析师更懂编程的人。或者说Data sicentist的基本的素质需要有一定的编程能力。
另外一部分需要理解一定的统计学，当然这是比较窄的视角。其实国内因为互联网的快速崛起，刚刚流行起Data sicentist和business intelligence等职位，相比较产品，运营这些，数据分析是一个相对新兴和工作内容和范围权责不明确的职位。
我觉得这张图能比较代表数据科学到底是什么的。
最上面的最重要的是业务逻辑和业务的理解能力，首先公司是商业经营，任何的动作离不开商业经营。这也就是说数据科学家首先是要深入业务，要否则的话分析是没有目标的，脱离经营就没有结果。
第二个是右下角这边需要有一定的编程语言和数据操作能力，这指能够从复杂的数据里头提炼出需要的数据，然后能做一些分析。
最后一个是科学的方法论，这就包括一些统计的方法和经营分析方法，这个至少能够让我们的分析能有一定的科学性，而不是说瞎分析，这三个领域的一个交集，其实就是现在所谓的数据科学，或者是做商业分析师。
很多地方都说团队数据驱动很难。出了我上面说的CEO是最重要的驱动力之外，通常的问题。
第一是数据，数据的收集往往是不完整和不准确的，比如说某些指标跑出来，可能不同的人给出的结果都不一样，或者说某个实验测完了以后，可能不同的时间，测的这个结果都不一样，反正本身就不太完整或不太准确。
第二是人的天性在做决策的时候，往往都是凭经验和直觉的，不管大家意识到还是不意识到，这就是我们的大脑。大体上就是为了这个来设计的，《思考快与慢》人下意识就会通过直觉做判断。所以说本质上数据驱动，我们说的是基于数据，基于科学的证据。而不是说基于经验和直觉，这个事情本身是一种反直观的事情，做这个事本身是需要能量的。
第三是说建立数据驱动的这种模式。培养一个正常的思维模式，其实需要时间。
第四个是环境，做这件事情需要一定的信任和鼓励讲真话的氛围。通过数据得出结论要有讲出来的环境，而不是先确定结论，然后找数据支持。
第五个其实是平衡，很多时候做数据分析其实是一个速度，实施成本之间的最优解平衡。举个例子，我们要做个决策，我们是不是要AB测试一下，答案是并不是一定的，就说测试有测试的好处，但是它有成本的，很多时候AB实验会把业务节奏减慢，但是它的好处是在一定程度上能够得到一些最优解的结论。所以这是一个速度与成本之间的最优解的问题。
我们希望好的数据驱动是什么样子，团队能力有提升，业务有成长。
它能变成一个成长中的职能，比如说我们这工作回报很高，能够得到强烈的身份认同，这个是很重要的，然后这样的结果就是能力强的员工会更愿意留在这个职能里面，可能就会更加积极努力，更加的主动带来非常强的业务的影响，业务影响就会带来更强的认知认可，就会变成一个正向的循环。
我们希望整个的职能在一个公司中是这么一个状态，但是能实现这么一个状态，其实不是这一个职能部门自己的事情。需要多个部门的配合，它本身不是孤立存在的，就是说和其他的职能一起在工作。这其实也需要各个职能一起去支持和帮助。因为业务他不是孤立运行的。
说这个本质上的问题数据驱动能力建设是漫长的，它在建设的过程中会逐步对业务有提升。
就说我们看中国大的人才市场，数据分析，或者说数据科学，这个职能相较于其他的职能而言，我指的是工程师或者产品经理或UI设计。
数据科学依然是一个非常年轻的角色，其实大家看一看，就是说工程师就不用说了，那好几十年了，产品经理这个角色在这个科技行业至少有20年的积累了，而数据科学可能也就是个最近5，6年，最多这个词的出现都不会超过10年，所以说相对来讲它是一个相对年轻的角色。
这就意味着在整个商业环境里面，其实数据科学是在快速的追赶其他的职能，这个放在国内就尤其明显，数据科学现在还是要比硅谷那边整体的认知要差。我觉得要落后不少，但是这不光是中国的问题，就是即使在硅谷本身，在Facebook或者Google都是在一直探索，数据科学到底在一个公司做什么事情，这是没有定论的。
就是说今天数据分析师和四年前的数据分析师差别是很大的，中国的公司也是在慢慢完善我们自己的认知。逐步探索出数据分析师的商业价值。
第二个打造一个数据驱动的团队需要时间。这个这本质上是个思维模型的问题，这件事情本质上是打造整个全公司对这个数据的认知，然后团队一点点努力，这不是一天一两天能够改变的事情，这需要时间。
第三就是打破现状需要资源努力和耐心，而且需要各方面的配合，本质上推动数据驱动这个事情是文化建设，其实是个认知升级的过程，很多人认为数据驱动或者数据能力是个能力建设，其实不只是那么简单，最主要的其实是参与业务方个认知升级。
到底要怎么才能实现数据驱动？
一般来讲，我们先抛一个框架出来，数据驱动大概有四个阶段，最基本的是第一个阶段，就是说数据首先要能够呈现出发生的事情，客观的呈现，换句话说，比如说昨天一天或者上个月，业务发生了什么事情，有多少订单，多挣了多少钱，有毛利又怎么样？我们体验如何？指标怎么样，我们的业务到底是挣钱还是亏钱，首先我们要能知道我们发生了什么。
我们先不要说洞见，先能够客观地反映现实中发生的事情，这是第一个。能做到这一点，其实已经相当不容易了。很多公司数据指标还都不完备，或者数据指标都不统一的，口径也不统一。所以说经常说要问一个什么事情，大家可能给出的结论都不一样。
第二个阶段，就是说能够被动地支持业务方的决策，我这个业务在这里只是一个宽泛的概念，这里包括产品，包括运营，更多的是指我们这个业务能够被动的能支持这方面的角色。
举个例子，用户买了三件商品和买了一件商品，用优惠券和不用优惠券，以后的留存是不是有影响，这个影响是怎么样的，像这类问题都是客观上业务方面的问题，但是如果这个问题提出来了，作为数据分析师能够被动回答这样一个问题，这至少能做到第二步，就是我能够回答问题。
第三步就非常的进阶了，相当于如果能做到第三步的话，其实已经非常的上道了，数据分析也要能主动地去定义问题，这个怎么去指导业务方主动定义问题，其中包含了一个发现的概念。
就是说因为问题有了就不叫定义了，很多时候要我们主动地去找，要发现什么业务机会，举个例子，假如说没有任何人问的情况下，像数据分析师去给自己问一些问题，用户一次不好的购物体验对长期留存有啥伤害，假如说这个不是业务方洞察的机会，就是我们自己问出的问题，我们可能会考虑怎么分析这个事情，可能有些分析的框架，那更多的是这个问题本身代表什么，代表我们以后能够对不好的购物体验把它能够转换成业务留存，提升业务收益。
第三步的时候，其实就是需要完全不同的能力模型了。这需要问题框架的能力。这个产品经理可能都会有比较深的认识，就是说很大程度上产品做的事情就是框框架一个问题，其实数据分析也是一样。
达到第四步，其实就是说数据可以深入，就是我们平时思维和工作的方方面面都有数据作为辅助，我相信到这个时候，公司不会再没事儿谈数据驱动，因为这个东西已经不用谈了，就相当于深入我们的毛细血管一样，这个时候大家会忽略它的存在，因为已经有随时随刻的这种意识了。我还没有见到任何公司达到这一步。
这个我觉得这东西更多的是给大家一个框架来考虑一下，我们怎么考虑数据的这个进阶过程。
数据科学家要做些什么，我这里列了两个维度，上下维度，上面是洞见，下面是呈现，大家可以想象，一个就是说下面更多的是发生了什么，上面是为什么发生，就是说发生了什么和定位意味着什么，一个更多的去展示，而另外一个是展示之后的一个事情，这是一个维度，左右维度很容易理解了，就是主动和被动的区别。
左下角这个象限，大家去看一下，就说是被动地呈现事情，其实基本上就是取数，最简单的就是取数，还有一些基本的数据报表。
右下角的象限其实是主动的去呈现一些事情，比如说做指标监控异动的监测产品运营，我们的产品做的是指标和dashboard这些是属于相对主动的，但是它还是个呈现层面的事情，还是「发生了什么」没有到「为什么发生」的层面。
左上的一部分，就是说是属于被动的，但是给出洞见，比如说数据驱动的四个阶段，第二个阶段的问题就是我们能够回答问题，但是这个被动的问题，包括回答业务上的问题，包括一些用户分层，分类这样这类的事情，大体上属于这个象限的事情。最上面就是最右上的这个象限，就是最进阶的部分，这属于主动地去提出洞见。
首先将不同，不明确的问题框架化，发现战略的机遇，打造一些可持续的方案。这个就说是比较难的，这是一个越往右上是越偏长期影响，越往左下是越偏短时需求。我们希望把它往右上去牵引，但是这并不是说数据分析，我们只希望做右上角象限的事情，其实四个象限的事情都需要做，这是一个综合的事情，我们需要的是一定平衡，但是不能只做左下角的。
这个就是到了一个关键的地方，我们总说数据分析师要做些什么事情，产生什么洞见，到底要做什么，本质上是我们要增大影响力，回到一个核心问题，叫什么叫影响。
对于分析师而言，做的分析报告也好，洞见也好，其实也是一样，或者说你做一些产品的工作或者运营的工作，不管它是什么，它产生的影响是什么？
影响通常发生在四个方面，往往是我们做了什么分析，然后影响了某个指标，这个是最很常见的一种现象，比如我们研究留存最终提升了留存率。第二个影响产品形态，就是我们做的分析，直接影响到产品经理对产品的一些设计对产品一些定位。
第三个是影响操作流程，这个往往比较常见的是一些跟人相关比较多的，比如说运营它的配券儿的策略，它配券的模式，像这些也是属于影响，比如说我们做了一些系统运营工具导致他和以前不一样了。
第四个是属于打造可以扩展的解决方案，这更多的是影响效率的事情。举个例子，比如说像我们很多时候做模型，做统计模型也好，做预测模型也好，其实本质都属于这么一类，这个模型能够使业务更加有效。
什么是不能被称作影响呢？比如说完成了一项高难度的分析，这个是很多分析师容易掉的一个坑，就是说他容易去追求分析的难度和深度，这个本身没有问题，没有错误，但是到这一步还不能成为影响，关键是做完这个分析难度高也好，高精尖高大上也好，但关键是后面产生了什么事情.
第二个参与了一个成功的项目，如果是看项目成功与否来判定分析师价值，会导致很多人会喜欢挑项目，会觉得哪个项目容易成功，他愿意去哪个项目，本质上这么一个问题是说我们的激励机制是有一定问题的，或者是我对他的理解是有一定问题的。
项目成功与否其实并不表示你的影响，关键是一个非常失败的项目，如果你一个人在这里头，那个项目失败得不那么难看，其实这也是影响，但是一个非常成功的项目，如果你在里头，你说明不了你做的什么事情，使得这个项目变得更成功了一些。其实这也不是影响，换句话说还是我们要产生的，我们要考虑这个增量的问题.
一句话就是，我们认为分析本身是没有什么内在价值的，除非其分其结果影响到什么其他东西，让业务发生了改变最重要。
工作流程中分析师如何参与呢？每一个步骤参与。最左上角就是说一些，求的分析，在我们决定做一个项目之前，其实DS往往就开始参与了。
比如说发现用户的问题，从产品角度讲，就是发现用户的痛点，发现用户的价值，定义机会点，大概看一下这个东西多大天花板，有大的空间可以做，然后是不是值得我们开始下一个功夫，我们要做一些什么样的解决方案，然后要说服这个业务方也好，或者是合作方也好，能做这件事儿。
然后全过程参与，要及时参与埋点的。分析师应该是在一开始在埋点的时候就应该参与埋点，因为最终是这个数据的使用方。所以说分析师应该参与数据的上游和下游配合。
第二个就是考虑我们这个test plant 就是我们到底做什么样的测试，要怎么做？怎么发布测试，标准是什么样的，什么叫做好的结果，什么样的结果是不好的。不好的话要怎么解释，就说整个全产品周期或者不管什么项目周期，其实分析师需要全程参与从一开始到最后，而并不是说只是做AB测或者给个上线结果就完事儿了。
很多开始启动数据分析的团队，会非常迷恋工具，我个人觉得这个东西其实并不那么重要，所有的图纸都是他都是关于怎么做的问题，本质上数据分析重要的是能够思辨，能够想问题，并且能够推动。
对于业务机会洞察，为什么要去做，为什么不去做，因为所有的决策依靠数据，成功的概率会高很多。特质上说，你有很强的主人翁精神，这样的话你就会主动去寻找业务的机会。
第二有很好的框架问题的能力 ，很多的业务其实都不是有明确问题的，就是说很多时候我们自己问出来一些有深度的问题，把业务的问题，框架为一个问题，这个能力其实很难获得的，但是是一个很核心的能力。
第三，就是数据获取能力。这个不多说。
第四，数学，统计有一些统计学的分析背景保证你的分析是有显著性是一个科学的分析。
第五个很重要，要能够讲这样的故事，Good story telling ，因为分析本身是没有任何的内在价值的，你需要能够推动业务方能够给人家说讲明白我们为什么做这东西，为什么有用，为什么你要听我的，这个能力非常重要。
第六就是驱动力 ,很多人做完分析之后，然后过两个月发现没什么效果，或者是没有什么后续。做分析的人其实是要追着业务方的，你要自己对结果负责，分析师不是分析，是分析之后什么东西变了，你要对这个东西负责。
所以做了一个分析，要追的业务访问这分析到底有用没用，要是没用，我做的不对，哪里做得不够，还是说我做错方向了，它没有业务影响没关系，但是我要从中学习到一些东西，以后尽量避免这种事情，或者说为什么业务方不做下一步。
说到这里有机会，为什么我们现在做了一个月要过两个月了，业务方还没有动静，你要去关心。所以说这种推动力是很重要的。常见的背景，数学统计物理计算机都比较适合，但是不一定非要是个统计背景或者怎么样，大家的背景可以五花八门，但是核心是要有足够的思考能力，要有主人翁精神，推动精神都可以。
分析的逻辑性，思维的发散性，这些能能力是一些个其实相对来讲比较难获得的，而那个技术本身它是相对容易获得的。
常见的这个错误或者说陷阱。就是有的人认为数据可以解决所有的问题。
这个其实是不对的，就是数据其实只是提供一种视角，一个决策依据，它不光是数据视角，也不是说唯数据论，比如说产品有产品的视角，设计有设计的视角，工程有工程的视角，数据有数据的视角，说我们最终做一个产品或者一个功能，需要把所有的信息汇总分析，数据是很重要的一部分，但是并不是说数据要要加凌驾于任何其他的方面之上，这是首先要明确的。
第二点也是非常重要的是，数据看到发生了什么并不一定能够解释为什么发生，并不一定能够给出策略，从看到数据到给出有效的策略他是一个过程，不要过分的神话数据能力。很多问题其实并不是一个数据问题。
举个例子比如说像供需问题。基建问题，他并不是通过数据洞察来解决的业务问题，其实辩证本身并不一定是数据问题，数据可以帮助把这个问题框架好了，但这个问题的决策本身其实是个手感问题，就是我们在当今的情况下，我们觉得先做供给，还是先做需求，基建或者供应链投入多少。数据能够帮我们理解这个事情，看清这个事情，但是这个本身并不是一个数据决策。
第三个ABtest必须做，这个大家不用说了，就是说很多东西不是说什么所有都开AB实验，也不是所有的都可以AB实验。其次是AB会降低业务迭代速度，你要等待显著性，这需要时间。
第四比如负向的统计上不显著，所以就全量推功能。其实也不是那么回事儿，很多时候其实它是有负向影响的，只不过我们的样本量也好，测试的方法也好，并没有明确的把它就说测出来，统计上不显著，并不代表没有影响，这首先要比较确定。相反的，就是说这个东西是统计上显著的，所以就是说我们应该上全量，其实也不一定。
举个例子，比如说我们要提高一个东西，假如说提高GMV，我们可能做了一个什么事情，然后GM提高了，比如说0.1%这个提升非常小，但是统计上是显著的，可能也不值得去投入更多资源。并不是所有的问题都是一个数据角色，但是数据能够帮助你框架化问题，并且显示发生了什么。
希望这对你明白如何数据驱动有帮助。
作者：阿润，公众号：阿润的增长研习社（ID：arungrowth365）
本文由 @阿润的增长研习社 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。