团队数据驱动需求六个进程-亚洲ca88官方网站

  或许许多人都会有一个困惑：做运营是注重增加战略的学习仍是埋点的学习？本文以此为起点，讨论增加的战略。本文总结了团队数据驱动需求的六个进程，期望对你有所协助。

  这让我想到了许多作业你深度考虑后的出来作用和群众认知往往是不一样的。一般咱们以为增加的战略是十分重要的。

  俞军教师讲过稀缺度的问题，找产品司理是找逻辑紧密的，由于逻辑紧密是比较稀缺的。

  相比较根底的产品常识是好学的。所以相同的逻辑咱们面试时分多半会找懂运营战略和剖析的。由于这样的人愈加稀缺。

  可是这儿面有一个隐含的假定：获取数据环境也很好。所以有了很好的增加战略运营，你只需不断的获取数据，不断的剖析就能够继续的发生十分好的战略。

  许多办理者以为招聘到好的战略剖析者（自身他们很稀缺）就以为能够做数据驱动了。可是任何作业都是团队来完结的。好的剖析者仅仅冰山一角。只需整个安排链条都开端数据驱动化，不断赋能事务人员，才干确保有继续的战略产出。

  由于我最近咨询的公司都或多或少由于这些要素无法数据驱动。一般构成这种阻力的原因：他们都只看到了无法数据驱动的某个切片问题，或许某个节点问题。可是依照我上一篇文章写的大处着眼小处着手。

  往往找到的解法都是头疼医头，脚疼医脚的计划。假如真的想把团队转化为一个数据驱动的团队，就要从全体收拾清楚阻止团队无法数据驱动的点有哪些。这个进程十分像解开一堆十分乱的线头，你要先从全体收拾好，然后再一个一个解开。除此之外别无方法。

  其次任何团队的变革都是一个按部就班的进程，这儿面抛开利益联系的问题，团队成员才干模型，作业流程，作业习气都是需求逐渐引导的。轻率大动都会导致集体排异（假如咱们把安排看作一个有机体）

  所以我会给到您一个查验清单依照这个逻辑，找到冰山以下「水面下」影响增加驱动的要素。

  数据获取是整个团队和多个体系继续向事务赋能，一般咱们只能看到数据剖析师。

  美国科学家做过一个思维试验：把魔方打乱，交由一个瞎子恢复，假定瞎子永生且不需求歇息，每秒滚动一次，理论上他需求多久才干将魔方恢复？

  答案是一百几十亿年，也便是从世界大爆炸到现在，还需求再等几十亿年才干完结。

  假如参加一个变量——每滚动一次魔方，就有人向他反响一个信息，告知他是更挨近方针了，仍是更远离方针了，请问瞎子需求多久才干把魔方恢复？答案是两分半！

  咱们做数据化便是为了让咱们全部的战略变得可视，能够看到作用的量化，就意味着每次滚动魔方知道是转对了仍是转错了，就能够进步迭代的速度。

  数据驱动便是让作用能够被量化，全体的事务能够被量化，数据只能告知你现状，比方病人去医院治病，医师告知你高血压，他不能给你开降压药，假如咱们把人的身体比作事务，数据驱动只能告知你其时你的事务状况，他并不能告知你构成这个状况的原因。

  当然假如你的数据基数十分大的时分，这种状况下你经过做一些战略，一些修正迭代找到战略和作用的相关度便是能够的。可是咱们仍然不鼓舞这么做，最好仍是需求你做数据驱动，还需求做用户调研和需求剖析。

  事实上咱们的事务比滚动魔方要杂乱的多，由于滚动魔方包含的隐含下设是：过错和正确的信息反响自身就包含了战略处理计划。即你不向着过错的方向旋转魔方，你就必定向着正确的方向旋转他。

  可是大多数实际状况，实际的状况反响不会直接给到你处理计划。（这种边的改变量杂乱度，我会再写一篇文章。）

  咱们终究的诉求是把作业做正确，可是这并不是数据驱动事务必定的作用，数据驱动事务是做正确的作业的根底。

  在发动数据驱动前，还需求了解的是那么就需求去考虑三个问题看下看你的事务是否能够数据驱动。

  第二个问题，你的事务是否用户量和商业价值十分大，数据驱动价值能够支撑团队本钱。

  许多老板以为其时事务不增加，我去找增加类的人才，是不是就处理了这个问题了。这便是我说的头疼医头，脚疼医脚。

  首要你要想的是这个职业是否在增加。你把张小龙放到教育职业他也很难让他增加。甭说张小龙便是李小龙来了，李显龙来了，都没有用。

  所以增加的最底层是你的事务原本能够在现有的途径下增加，或许寻觅新的途径把用户转化过来。

  原本便是用户有需求没有发现途径，或许说外部环境使得用户会变得越来越多。增加的榜首层天花板便是商场的用户究竟有多少。可是许多老板大逻辑没有想清楚。就去找人去获客。以为只需我有战略就会有用户。

  第2问：你的事务是否用户量和商业价值十分大，数据驱动价值能够支撑团队本钱？

  接着榜首条解说，便是你预估这个职业有多少用户量，越大的用户量，你做优化发生的价值越大，能够供应的薪资和职位就会多。

  事务体量决议安排结构，你们用户量每天千万，你做个数据驱动的算法和战略才有价值，你进步个百分之一ARPU值，你用户基数这么大。一年下来你发明的价值满意养活你们这些算法工程师了，或许他们发明的收益还远远大于他们的薪酬（一般事务体量大的公司必定是这样的）。假如你的事务天花板很小，不会有很许多用户的或许，那么你就不需求做数据驱动，由于这个团队，这些人才，他们发明不了这个价值，也就意味着这个事务也养活不起这样的团队。

  假如还有疑问能够看这篇文章：哪类公司合适无埋点剖析东西 Growing IO

  src=数据一直在服务商业：传统企业用财务数据，长周期的事务作用数据做商业剖析，也是数据服务于商业。所以从这视点看事务并不能说传统企业不是数据驱动的。

  互联网事务的实质是线上化：今日互联网事务的数据驱动，根本改变在于事务发生的主体进程线上化了，事务动作线上化了，衍生出来快速迭代和注重流量等新的特色。由于用户全部的行为都「线上闭环」的。其次最好支撑你的事务的体系都是线上化的这样便利你把事务切分红独立闭环。刨除用户量你还需求考虑三个要素：

  SKU量大：SKU量大说白了便是内容分发，战略引荐，假如你事务的内容十分少，那么关于内容。你就比较难找到数据化的含义，首要是经过数据化过高效的促成买卖发生杠杆，要知道内容也是契合幂律散布的。品类办理和内容供应是「增加黑客」中很重要的一部分。

  买卖高频：买卖单价和买卖频次是成反比的。越是价格高，买卖的人也越少，频次也越低。越是依托出售团队。买卖频次越高，就意味着用户的反响越多。真实用户价值=活泼用户数*账户均匀买卖量。

  供应出产端反响周期短：也便是说关于需求的供应也必定要能够快速迭代，由于供应链的迭代速度决议了你能够供应的「内容」以及用户价值。这样才干够快速迭代发生更大的价值。

  全体上咱们会从数据，作业流程，产品架构，安排分工，安排发动这五个方历来做逐渐的解说能够让你做到数据驱动。咱们会先讲怎样把你的事务短期需求数据驱动。会触及几个事务方。

  假如读者们觉得一起推动几个事务方没有话语权，我会再讲怎样把内部团队做到数据驱动。

  由于你的事务能够被拆分红多个独立迭代的小闭环，也就意味着你的中心目标能够被区分红许多独立的小目标，下发给各个团队。这便是一个恢复论的逻辑，我的大体系能够被拆分红小体系。我的小体系能够加总等于我的大体系，假如我的小体系增加了， 那么我的大体系就增加了。

  src=Facebook把自己的事务拆分红了200多个独立闭环迭代的团队

  拆分到单一目标后，给这个目标装备团队，这个团队大面上不依托外部迭代起来，考虑到软件开发有些体系不是这些工程师开发的。

  可是一个需求的独立承受肯定是能够的。咱们看这个目标下包含了，数据剖析师，工程师，产品司理，规划师，所以他们接了需求便是能够自己做需求评价，或许自己做需求迭代。而不依托「外部资源」。只需包含越多的支撑方，你数据驱动失利的或许性就会越大。

  留意这儿说的是岗位，由于当目标多的时分，不必定会有满意的自然人，可是岗位有必要要依照目标来规划。假如你事务满意大，每个目标都能够养活一个团队，那么每个岗位下都有一个。

  或许看到这儿您不太了解怎样区分，您只需知道能够依照目标横向建立分工人物，纵向进行办理即可。切分还有许多种计划，咱们在后续的文章中再去回答。

  不管您再怎样想做数据驱动上面说的小团队里边的人是不能或缺的。找对人后就能把一个方向或许部分的事务做好。究竟办理者不能亲身撸起袖子去做全部的事儿。在繁琐的日常中活活累死。所以找对人是十分重要的。其次仍是我昨日说的。

  这些问题要想清楚。所以已然找替身是榜首重要的作业，我所以咱们先从找人说起。

  咱们觉得招聘人员来做数据驱动作业。那么招聘来的人，要做什么呢，咱们总结了以下六个方向的作业。从数据，作业流程，产品架构，安排分工，只需把这四个方向都做好了才干做到数据驱动。

  数据可获取才干是数据驱动的根底，任何事务维度，假如咱们连数据都无法获取，那么这个事务维度就无法做到数据驱动。一般状况职业管这个团队叫做数仓团队。数仓团队中心聚集于「数据驱动决议计划赋能」「数据驱动产品增加」这两个部分。

  数据获取的才干绝非简略的读取与展现，它是一个体系获取数据的架构。许多办理者想当然的以为我找一个会写SQL的人来获取数据不就行了。

  可是这样会导致未来某个时刻段你的数据获取遇到瓶颈，你事务开展速度越快，这个瓶颈越快的降临。我的主张最好仍是有专人担任数据存储体系的建立和前期轻量化的数据提取作业。

  就算是初始发动期也要有相应的数据架构来满意获取数据的需求。从「数据收集」「传输」「存储」「处理」「运用」六个维度来考虑终究赋能事务方。有一个初始团队数据赋能的架构，后续从这六个维度上来逐渐丰厚整个数据赋能的架构。

  大部分咱们觉得数据剖析本钱过高，很大程度上都是冰山理论事实上是水面下的数据获取架构做的不可，不能够供应低本钱的获取数据的计划。

  事务的初始时分，咱们更多的是以报表的方法来供应，比方说你的数仓团队刚刚建立的时分，事务也在开端的开展也在继续的一个开展初期，你的人员的构成都归于在一个磨合期，这事务其实也是在一个相当于一个探究期，所以在这儿边其实数仓团队更多的是你供应报表。

  比方说其实咱们最开端咱们或许只需求注重的是流量数据和事务数据，以及他们之间的相关先把流量和留存两部分相关起来即知道流量的价值，也知道其时产品留存的状况，比及事务方开展到必定的阶段，咱们渐渐就开端做安全体会相关的数据建造。

  其实它是跟着事务的开展而逐渐迭代的，还有一个整个重心的改变，数仓整个建造也会逐渐迭代。所以你要去注重你的要害事务，在某个阶段，它的要害事务是什么？

  对应的便是咱们的要害数据源，由于你知道你需求什么，才知道说你去收集什么，比方产品和研制有上万张表，咱们不或许什么把全部的表都能够收集到「数仓」里边，所以你要有必定的便是相对要有必定的规模，所以在这儿边其实便是经过要害事务为抓手，往来不断做对应的要害数据源的收集。

  在这时分咱们一起要做元数据的一个标准化的办理，数仓产出一张表，表的comment(每个字段阐明)是空的，或许说不精确的，你的表的特征它也是禁绝的。所以当数据剖析师去用的时分，或许说相关同学去用的时分，就发现你做这个作业，你做这个产出物是没有什么太大的价值。

  由于整个的数据不是很标准，咱们也不了解。比方下单，又有许多种命名，许多的事务线都有记载，许多的表上都有这个字段的称号。有五六种其实咱们不知道究竟哪个是下单的字段。其实这个便是一个很痛的点，所以元数据的标准化，在数仓的一个初始阶段就要去做，

  事务图谱，关于数仓团队，他首要要去了解事务，才干去做对应的数据建造，还有目标化的建造。所以咱们最开端比方说做订单的时分，咱们就会先去做整个买卖主链路的流程，从开端他的发单和接单到整个链路付出完结，咱们是把整个的主链路去收拾出来，然后针关于每个主链路，它里边详细的一些事务进程是什么，其实这个便是数仓团队在整个事务图中怎样去收拾出来，在这儿面咱们才干提炼出哪些要害的点。

  所以这个便是事务统筹，其实也是经过这个层面来让数仓的同学更好地去了解事务，愈加站在事务的视角，用户的视角去了解数据能去做什么。

  咱们会讲烟囱式的建造，其实烟囱式建造要两面性来看，不是烟囱式建造就欠好，特别是在事务开展初期，它的验证式建造，其实它能快速的去迭代去开展，假如你的整个标准性，你的许多流程其实OK的。

  其实烟囱式建造其实仍是在一个可控的规模内了，但在这个层面咱们就要做全体的需求把控，其实是做一些恰当的冗余是OK的，由于在这个时分，其实咱们的相关的数据的口径是不确认的，其实事务也不清楚说咱们的口径究竟是什么样，其实也是在一个探究的进程。

  这就要讲到一个共同的目标体系，共同的目标体系是全部的数据团队，或许说咱们对用户都是一个十分痛的点，其实咱们后边会讲一下。

  所以在这个初始阶段，中心的注重是这些内容比及了开展阶段，保藏团队开展阶段，其时咱们保藏团队让那个看的是人的才干，还有整个团队的协同，现已有了必定的默契，然后一起呢事务的开展咱们也有必定的沉积和堆集，所以在这个里边咱们会协助用户去做对应的一些剖析跟运用运用型的一些产品。

  所以在这个层面上，比方咱们初始阶段更多是协助用户快速的看数据去去做决议计划，所以这儿面更多的是以中心的报表和看板为主，比及你的开展阶段的时分，用户要做一些精细化的运营，所以在这儿面咱们要供应一些相关的一些剖析类的产品。啊，还有一些战略确诊类的行为，或许评价类的一些产品。

  假如咱们有了获取数据的才干，具有对用户，买卖，获客途径的根本剖析，咱们就要针对事务进行目标拆解。途径端做到每个途径流量数据明晰，包含每个途径带来的事务数据，例如GMV等等。能够评价途径价值的数据。

  买卖侧能够看清留存，激活，关于活泼的构成，买卖的品类，关于用户侧能够看清高价值用户。

  这个进程需求一个能够拆解事务目标的人，有拆解才干的。可是主张中心办理层都要测验拆解一下。或许还有才干快速了解这个拆解逻辑。拆解目标首要是为了对中心事务的首要影响要素有一个理性的数据上，「剂量」上的认知，而不是理性的，例如我知道它的影响很大。

  这能够给到领导侧便利领导侧看清事务。一起我自己作业的阅历发现许多领导要看数，事实上是上一个环节没有搞懂，便是他自己关于要看哪些目标他们反响了什么并不是很清楚。导致每次给到他们数据，他们仍是觉得数据不行。可是丰厚哪些又说不出来。

  终究一个逻辑是你有了数据，就能够评价大约一个功用的转化率。就能够测算收益，以及数据评价能够预估这个需求的用户，有了收益预估，又有了用户价值你就能够权衡需求的优先级。所以就具有了根本的数据驱动的环境。

  全部从源头开端，互联网公司大部分中心价值是经过线上产品或许软件产品把价值传达给用户的。那么需求的量化办理是数据驱动真实的开端。

  假如说之前的两步：获取数据才干，以及拆解数据才干是清扫家门，那么从量化需求开端数据驱动，则真实做到了迎候客人。

  即后续的新增需求都会依照量化权衡优先级的方法来判别先开发哪些功用，后开发哪些功用。就能够真实做到数据驱动，有用经过量化来权衡优先级，逐渐开释事务压力。

  src=一起能够很大程度上鼓励开发人员，反向办理事务方，在这儿我要证明一下为什么要事务方提需求写需求文档，我之前也在小的公司作业过，这些公司许多时分都是一句话需求，和真实完善的需求文档也是有不同的，不同不在字数上，而是要把问题讲了解。咱们以为编撰文档有如下优点：

  有利于事务方收拾需求内容。写作自身是一种考虑和反向输出，所以在写的进程中就助于收拾事务方的思路。需求布景，针对的用户，现状，痛点，因而要做哪些功用，处理的问题，预估收益都有一个很好的收拾考虑。

  有利于事务方圈定需求规模。一般事务方会频发的改需求，除了上面没有收拾好自己的想要什么之外，一般的状况是两边并没有针对需求达到规模。事务方和产品关于处理计划的功用规模认知存在误差。所以写出来流程和大体规矩与功用有助于产品司理和事务方在认知上快速达到共同。

  有利于产品司理了解事务方需求。就算是事务方自己确认要什么，跟着时刻的推移或许也会发生误差。以及假如是口述的需求需求被逼产品司理记住。这样的交流是十分低效的。

  文档存在自身便是有价值的。不管经过的，仍是没有经过的需求。关于经过的需求后续的产品司理接手后知道在之前什么状况下迭代了什么需求。一起需求方也能够了解，哪些用户的需求做到什么样了。新来的人知道曩昔哪些需求被否定过了，为什么被否定了，是不是现在条件还不建立，那就不必再次浪费时刻提出了。或许说条件有改变了，也能够在本来被驳回的需求上考虑。

  许多人会辩驳说事务方都很忙没有时刻写需求文档，我的观点是一个需求发动后，要阅历产品，规划，研制，测验，数据等等多种人员的环节，要花费这些人员的时刻，相比较这些人员的本钱来说，把需求描绘明晰，量化了反而是一个进步功率的方法。

  有一种说法是提过错需求的人还不如不提需求，由于它还占用了资源。关于这种人发薪酬什么都不做，都好过这些人提需求。

  其次一个需求假如不值得写，根本上它并不值得开发。由于每个节点的编撰量是成倍增加的，从需求文档，到产品需求文档，再到代码。

  终究也不主张上来就让事务方量化提需求文档，最好是有产品和数据剖析师辅佐，留意是辅佐而不是带写。在产品和数据剖析师充沛了解需求后能够在固定的文档格局上给予事务方一些编撰主张，包含数据提取，哪些数据辅证需求的一些主张。终究方针都是为了能够让事务方独立完结数据提取的求证以及独立编撰需求文档。

  假如前三项根本满意那么第四项是一个逻辑必定推导的作用，假如你的需求方能够量化的提需求，你能够量化的评价需求，评价往后就要有产品和开发能够完结需求，一起也能够做好这些需求的数据监控。

  所以说假如想做到数据驱动，最好对安排结构做相应的改造，中心的思路是让运营和事务类需求和长时刻用户价值的需求走两个仓库。逐渐完结研制侧逐渐小闭环分工化。

  咱们以为目标，功用，以及对应的开发是有相关度的。当然并不是肯定的。可是尽量咱们要做到能够切分红独立的闭环（虽然或许存在藕断丝连的状况）可是大体趋势上是独立的。

  全体的切开逻辑在3.1章节中心逻辑是矩阵式分工那节现已进行了解说，我这儿做别的一个视点的陈说便是大体思路能够把倾向营销的如落地页东西，运营引擎，投进引擎，音讯触达中心等等这些归于倾向与运营和出售类的功用并拢到增加产品方研制团队，别的一类会倾向于用户价值长时刻建造，咱们以电商举例比方类目，品类，商铺办理，倾向于中心价值的作为别的一个研制团队担任的内容。

  当然这个进程最重要的便是和研制leader和产品leader规划好产品的架构图，由于有了架构图才干知道哪些功用能够兼并给到类似的开发和产品团队。

  从数据驱动的视点上讲优先把事务方需求量化和需求上线后的作用量化是中心，由于事务需求方一般触及到的需求规模是有限的。

  当然他们也会提出倾向长时刻用户价值侧的需求，在《运营之光：我的互联网运营方法论与自白》一书里作者谈道：产品团队担任界定和供应长时刻用户价值；而运营团队担任发明短期用户价值和协助产品完善长时刻价值。在团队区分上根本上事务方短期迭代的需求会高许多。

  前四项假如满意的话，事务方也乐意用数据量化的提需求，产品研制也乐意承受这些需求。那么剩余的问题便是需求怎样从头到尾的经过体系传导到需求同步需求的状况，团队之间怎样同步信息。就这触及到团队协同作业的东西，这些东西包含但不限于以下：

  需求办理东西：首要是担任记载事务方提出的需求文档。包含需求后续发动后的状况。

  IM东西，邮件东西，研制需求跟进东西，测验办理东西等等我就不在这儿赘述了，总归办理东西要遵从的便是最小可用准则。其次是团队尽或许的运用类似的体系来进行交流，能够兼并就进行兼并，这样能够最大程度上下降信息传达的门槛。

  我之前作业过的一家中型公司会发现公司有些人习气用QQ，有些人习气用钉钉，有些人习气用微信，导致团队互相找不到对方。需求UI保护在tower上，产品有些人保护在Excel，有些人保护在禅道上。需求是涣散的，当然就无法做到共同的评定。

  所以数据驱动能够尽量让咱们的信息共同，一起需求的量化和一个好的评定流程能够让团队作业功率进步，咱们千万不要觉得这种流程化方法是低效的，远不如事务方直接拉着产品和研制开发高效。可是这个流程能够确保有价值的需求能够继续的优先被开发。

  终究咱们会发现推动数据驱动团队需求从需求方到产品，UI，研制，数据工程师，剖析师的合作。所以逻辑顺下来，依照矩阵式的办理方法，咱们会发现这个人要能够影响或许办理：需求方到产品，UI，研制，数据工程师，剖析师等许多部分，这也便是说职级越高越简单推动这个作业。

  src=由于它能够针对每个总监下面的组能够独立出部分人员来针对增加或许事务方构成独立的小闭环才干做这个作业。

  下面咱们说一下假如你没有这么大的行政权力，又想影响你的团队去做数据驱动，或许咱们说的直白点，你想做的专业一些，让自己最少数据量化一起来，进步一下职场身价，你只需求两个人的支撑，或许只需求一个人。

  src=那么你只需求一个工程师来承受你量化的需求，以及一个数据剖析师来帮你提取数据就能够了。

  不过这个环境是否可行，极大程度上，取决于你和团队的联系以及，团队的办理是否有这样的空间。极点的状况在没有数据剖析师的状况下，假如工程师很合作的话，他也是能够帮你获取一些事务数据的，可是这样的问题是，由于这样拉新的需求由于没有投进的追寻东西，你仍是没有方法量化。

  可是你能够先把产品上的用户进行剖析。一起考虑到没有埋点东西你或许也无法剖析行为和事务数据之间的联系。这种状况最好的方法便是学会数据剖析才干，以及经过这个小团队做出一些作用，赶快换一家老练的公司。

  终究咱们总结一下团队无法数据驱动的六个原因，他们是有逻辑联系的，假如你的公司团队无法数据驱动，并不是找一个增加官或许找一个剖析师就能够让您的团队数据驱动，他是一个体系的问题，只需每个环节都向数据赋能才干够让终究的事务进入到数据的轨迹上来。

  这个流程恰似拆线团，需求你从全体上看清问题的症结，然后了解先解开哪个线头，后解开哪个线头，直接上剪刀或许解开最大的线头（数据驱动最大的卡点）是没有用的！

  难点在于规划途径，逐渐拆解，要信任每个果都是因发生的，那么这个因又是由它上一个因发生的，逐层找因，逐渐处理才行。所以咱们依照逻辑在顺以下怎样数据驱动：

  榜首步：你要有数据，能够看到数据，这是数据驱动的根底。你需求一个数据仓的同学来继续保护数据的收集到可视化的赋能。

  第二步：有了数据，你就需求逐渐了解看哪些数据，他们的改变意味着什么，他们互相之间的联系是什么。这些前期能够经过增加产品司理，或许产品担任人代为拆解，后期由剖析师继续保护，当然假如你一开端就有了数据剖析师那也很好，可是必定要在数据仓根本建立结束，再请数据剖析师，不然他也没有什么数据能够获取。

  第三步：你就要让需求逐渐量化，上线后的作用逐渐量化，经过量化评价需求的优先级，经过量化需求调度资源。所以你需求会集评定需求，办理需求。

  第四步：依据需求评定经往后要快速呼应事务方，就需求一个独自的仓库来处理事务方的需求。这样能够快速得完结需求的量化，作用量化。其次究竟事务方辛苦的写完文档，告知他要等排期会极大的冲击全体驱动的动力。

  第五步：这个进程中咱们怎样作业你需求在发动需求之前铺设好咱们协同信息的东西，包含需求从头到尾办理的东西。这五步完结今后根本上你能够从事务方那里承受到量化的需求了。

  可是这些都要建立在一个根底上便是领导的确意识到数据量化的重要度，乐意自上而下推动这个作业。由于触及到部分太多所以自上而下的推动是最快的。

  这五步便是逻辑上因果推演下来的。每一个下一层要处理的需求，是由于上一层的逻辑导致的。这像不像拆线团。只需都处理了，才干够让那个数据驱动起来。

  假如两辆速度为光速的车迎面开来，那么依据相对速度他们应该是2倍的光速，可是任何速度不会超越光速，那么只需时刻变变了这个才建立。

  引证这个考虑是想阐明，逻辑上作业推理的必定也是一种令人愉悦的作业。做团队的数据驱动要做好逻辑上的推导，对，便是拆线团。

  作者：阿润，大众号：阿润的增加研习社（ID：arungrowth365）

上一篇：常州推出“常个贷”信誉融资线上产品 下一篇：檀结庆代表：主张赶快发动立法清晰数据收集及运用的流程和权限