做团队数据驱动的经验复盘

602次阅读

没有评论

数据驱动，在团队中很重要，那么该如何做呢？作者结合自己过去的经历，总结了一些对数据驱动的思考以及自己接手这家公司数据驱动前段时间的复盘、如何找到数据驱动的人才、最终如何执行KPI指标。一起来看吧。

做团队数据驱动的经验复盘

再讲一篇团队如何做数据驱动的经验复盘，有些内容是因为上次没有讲到所以进行的补充，有些内容是我最近的咨询又有了新的感触和复盘。所以就有了这篇文章。

虽然我扮演的是咨询建议的工作，但是假如您是在团队内部，你有足够的管理权力做组织数据驱动，那么您可以按照这个维度去思考。

本篇文章会分为三个部分。我对启动数据驱动的思考，以及自己接手这家公司数据驱动前段时间的复盘。第二是如何找到数据驱动的人才，第三是最终如何执行KPI指标。我们会把组织分工和人员招募以及管理KPI，这三部分再细化的讲一讲。

因为上次有一些角度并没有讲到，这很重要，不然我也不至于再写一篇文章。注意这不是重复，是一个新的角度。当然这些角度有些可以用在持续数据驱动中。

在这里也感谢一下snow和Vincent两位老师给了我一个实践的机会，不然就没有后续的文章了。

也让我理解了交易中信任对于交易可行度的影响。端午节看了naval写的《纳瓦尔宝典》里面提到了「构建者」和「第四种运气」以及「责任与名声」这是三观点。我对它们影响深刻。

到了我现在的工作阅历，我会有意识的抽离出来看待工作，毕竟一个人能力再强，还是需要依靠团队来完成商业行为，所以我管这个叫做「做局」，或者叫「做势」只要环境对了，环境孵化的业务会慢慢变好（前提是你在一个好的赛道里）我相信通过组织结构，权责激励，以及工作流程等的优化，远比个人上去蛮干要来的业务增长巨大。

当然这并不是说你只需要关注制定方向目标，调整组织结构，梳理工作这三个方向就足够了，而是说你需要去考虑投入产出，考虑到哪些事情你可能需要下去抓一下，哪些事情则需要培养组织内的人才，哪些事情你通过调整组织结构就可以影响，不是说「构建者」你只需要做大的结构调整就可以了，这中间的权衡取舍，边界确定，模型调整是需要实践的。

或者说可能随着我的工作深入，我会逐步总结方法论。目前我总计会有一个参考系来评判决策，它来自于产品经理的权衡体系。底层万物归于一。

所以从19年，我就有意向所谓的组织增长方向靠拢。系统让业务增长。就是naval在《纳瓦尔宝典》中提到的「构建者」，他认为能够完成复杂系统交付的人更为稀缺。所以感谢snow和Vincent给了我亲自操盘的机会，尽管可能他们没有理解到我有多么感激。

顺便说一下，有想咨询组织增长的可以随时联系我，文章底部有我的微信号。

第二就是naval在书中提到的「第四种运气」，即如果你在一个领域有了名气，可以提供一项别人都无法提供的技能，那么就会有额外的好运气找到你，他举的例子是，你是潜水深度最深的潜水员，如果一个打捞机构发现了一个只能你下潜到的宝藏沉船，那么等于你也可以分到一杯羹，因为他们必须依靠你来打捞。

第三点就是信任，对于组织的变革，中间会有一些领导者暂时看不清的地方，但是snow和Vincent的愿意相信我，毕竟我和Vincent是3年多的朋友了，不至于为了这个事情，搞臭我自己的名声，当然这也是我每次对外分享不会讲重复内容的原因，要对得起听众。回到正题。

因为最近帮助这家公司启动数据驱动，我自己也复盘之前的一个判断不太准确的地方。这里面有组织的问题，也有我的问题。让我重新审视了这三件事情。

一、启动数据驱动的时机

我们什么时候启动数据驱动这样的工作流程的时机或者说启动的条件，首先我们要清楚的是在哪里启动。第一个是高频的日常工作需要启动，包括了需求实现流程，运营策略，市场投放策略等。第二个是规划或者是年度的规划等中低频的工作，第三是每个员工的目标和自己的to do list这些也是需要数据驱动的。

下面我们说下启动数据驱动的时机，如果你是以上的流程都已经有固化的流程且内容清晰，已经将这些内容都抽象为了模板，那么你就可以立即启动数据驱动这件事儿。注意，为了同步流程固化和什么是一个标准的流程，我这里提供了一个版本供大家参考。

做团队数据驱动的经验复盘

第二种情况是这些流程本身就没有，或者做的并不是非常标准和清晰明了，那么第一件事儿先把流程走通，并且建立模板，让大家先熟悉模板内容，以及模板的逻辑。

先以方向或者OKR去做牵引，先不要上数据量化，只做目标和OKR的牵引，说白了你先有目标和OKR定性，不对这些目标做定量，然后再逐步数据化。通常这种情况人员的能力模型当前是有些吃力的。上这么大的强度，又要搞流程和又要搞数据，团队成员吃不消，那么就会抵触。每次迭代只做一个目标，团队也清晰。

总结一下，你如果需求实现流程有了，比如我提供的这种流程，有明确的需求评审，产品内审，等环节，可以做到固化和稳定运行的情况下，那么你就可以直接在流程上推行数据化了。如果没有先做流程再逐步启动数据驱动。

1. 产品实行数据化是基础

首先互联网公司的业务都是希望通过产品来实施或者逐渐自动化的，控制了产品部门的需求量化，就等于控制了接近半数业务的数据化驱动。其次是产品下游众多，ROI非常高，他们涉及到产品部自己的产品设计，UI设计，研发和测试，控制了上游的需求，等于一下子提升了下游所有环节的效率。控制需求实现流程核心就是黄色的两个框，需要控制需求评审和产品内部审核。

其次就是产品部开始审核需求，就可以要求业务方逐步的数据驱动化，当然这是一个逐渐磨合的过程，我知道很多公司的业务方都具备产品思维，也无法从产品角度来讲一个需求，这时候就需要产品经理去介入，先去沟通需求，辅助业务方撰写需求文档。

做团队数据驱动的经验复盘

所以无论是业务方还是产品经理写需求文档，这个环节肯定是不能少的，只不过是谁做的问题，考虑到能力模型一开始启动这个环节可以先由产品来实施。这个环节的目的有如下几个方面：

明确业务方的需求包括需求背景，用户人群。
明确业务方需求的功能范围。
明确业务方向达到的目标。

第一项为了让产品经理理解why 或者说业务方的原始诉求，其中用户人群是不能不去分析的。这相当于我曾经讲过的 segment ，分层行为，你的到底对哪个用户群体做功。第二项为了划定边界，一个功能可以很大也可以很小，最后一个是和业务方达成目标，很多时候业务方不一定明确知道自己的目标。一旦目标明确了就知道是不是有商业价值或者用户价值。

好的产品经理至少50%的时间应该花在问题发现和需求权衡上，我甚至觉得花80%的时间都不为过。另外20%~50%的精力花在需求实现上。

不好的产品经理80%的时间用在产品需求实现上，可能只有10%花在问题洞察发现和需求权衡上。

因为如果你无法权衡优先级，你要做的内容就会变得特别多，你就有特别多的事情来忙，来做产品设计，你忙，你的下游就都会忙起来，因为一个需求需要下游四个环节去实现。

那么长期团队就会迷失在这种为了做而做的过程中，不能针对业务目标逐步释放业务压力，就会导致业务方和研发方矛盾加剧，业务方认为我现在需求这么多都忙不过来，研发方认为每次都要的很急，做了没有结果。其实就是没有把一个需求完整的按照流程去实施，一开始没有讲清楚对业务的影响，上线后没有数据反馈。长期下去团队就陷入到这种为了忙而忙的状态。

正如俞军老师所说，很多在知乎上问产品经理会不会被淘汰的都是那些只做需求实现的。对于产品来说需求实现是基本功，更难的其实是一个不可见的需求权衡。产品经理最难的是权衡模型。所以找到当前最重要（洞察）最紧急（权衡）才是需要练习了。但是大部分初创公司其实不太注重这块。业务方也会说：权衡你妹啊！赶紧做啊！业务这么紧急！而事实上他们自己也不明确到底做到什么程度，到底这个需求对业务哪些方向有提升。

2. 流程的标准有助于管理

流程标准和数据驱动，有四大好处，第一个是数据驱动如图业务同步的部分，通常公司都会省去，这其实是一个不能省去的环节，当然也不定要业务方来执行也可以来让产品经理来做，就是一个功能上线了，他的结果怎么样，有没有后续的数据变化，这才是一个功能最终上线的闭环。

做团队数据驱动的经验复盘

第二个好处有了这事情，你就能逐步缓解产研和业务方的矛盾，以及逐步提升产品和业务的影响力。因为好的结果会激励产研团队，明确他们的工作价值。

第三个好处是可以长期评估需求提出方的业务能力。这也就是说明了为什么需求文档要细化到具体的需求提出人，我知道很多公司业务方是提不了需求的，或者他们会通过业务老大代提需求，但是这个需求靠谱不靠谱，最终是需求原来提出人的问题，因为需求的来源是需求提出人提出的。如果需求来源都标记业务方老大，就没有办法分析和评估长期他们需求提出能力。

All data in aggregate is crap ，segment or die———Google analytics Avinash Kaushik

所有加总数据都是没有意义的，要么做拆分，还要么就去死。

第四个好处是只有所有的内容白盒化，才能极大地降低新人准入的门槛。新的产品准入后就可以接需求，他可以快速了解到需求的背景，人群，目标进而方便他权衡和设计等等。

3. 我对咨询服务公司的复盘

最后就我咨询这家公司我复盘自己的和对方的问题，如果你想把自己的公司数据驱动，也需要做这个check list。当然如果你是CEO，你也需要做这个check list，但是CEO主要职责也是要从怎么干想到让谁干，然而不是我亲自下场怎么干。

我主要的工作就是负责这家公司的组织架构和工作流程做到数据驱动，现在复盘一下之前工作循序上的混乱点。

公司背景部分：

公司的业务流程是怎么样的。
公司的组织结构和人员分工是怎么样的。
公司的产品结构是怎么样的。
产品细节流程是怎么样的，包括核心主要的用户流程。
当前人员工作流程和协同工具是什么。

数据部分：

当前是否有已经将业务拆解为相关的指标。
流量来源统计追踪是否已经完成。
整体上是否具备数据指标可以获取的能力，哪些数据指标还是不具备的。
当前的数据情况是怎么样的，后续如何迭代，是否有迭代流程。
各个部门同步数据流程和机制是什么样的。

实施落地部分：

如果数据驱动需要组织中哪些人参与。
我和这些人如何配合，工作边界在哪里。
当前的组织架构，人员角色支持不支持我去做。
当前的工作流程是否需要针对数据驱动优化。
组织驱动的实现路径是怎样的，大概要经历几个阶段，每个阶段的目标是什么。

如果你是个不懂业务的完全局外人，那么你开始做数据驱动至少需要从这几个方向去思考，第一部分主要是公司背景，因为我们是把当前的公司做到一个可以数据驱动状态，你可以抽象的看成从A点（出发点）到B点（最终点），那么了解当前现状是很重要的。其次就是数据的驱动的部分，就是从数据获取到分发到组织各个角色是怎么做的。如何去做。第三是实施落地。如何通过杠杆通过驱动几个关键角色把任务铺下去。

我在实践中犯下的错误：

过分的乐观估计了干系方的支持力度。

刚开始接手，直接进入到了第六步执行，就是直接拆解业务，把业务拆分成各个指标，当时想有了指标就可以做数据提取。在这个过程中，有产品经理来辅助讲解业务流程和产品细节流程，全程都是口头讲述。我拆分完毕后发现三个问题。

第一个问题是这个数据看板没人实现，因为研发数据人员忙着接需求，第二是由于我的角色是咨询我也不知道找谁来确认是否是需求方需要的数据指标，第三个问题是很多公司的组织上没有对应的职位。所以指标也不知道给谁看。

名不正则言不顺，言不顺则事难成。

我的核心定位还是咨询，就是定方向和目标，找对应的人来做，以及把控他们做的流程和结果。整体上数据驱动一个系统的事情，需要从需求上游到产品都进行数据驱动，产品的下游主要是执行工作，数据驱动的不那么强。这就涉及到多个业务干系方。

一开始在梳理部门工作时候，一些基础流程从ROI上来说还是由每个部门的负责人和我对接比较容易推进，但是由于我当时的头衔没有确定导致很难驱动他们做事情。或者一些公司的部门内部由于快速发展，还没有明确负责人导致这些和我对接的人也很难推动内部。

不知道如何通过提问获取想要的内容，以及由于分工问题我也不知道找谁去问这些问题。

有一个问题就是我自己不知道如何把这些大的需要我了解的部分，如何快速拆分转化为问题来对业务方提问。这显然是一个技术活，而且我还需要让对方的人员理解我要这些内容的目的是什么，和我让他们这么做的目的和意义是什么，毕竟他们已经习惯了当前的工作方法。change ，改变习惯通常是非常难的。

过分乐观评估组织与人员。

最开始的规划是先逐步搭建数据获取可视化体系，然后直接推进组织工作数据化，现在发现比较困难，摸底了产品部发现人员没有目标理解和数据提取洞察能力，甚至需求流程还是比较粗放的。况且按照薪资来说产品相比较市场和运营是相对薪资较高的职位。

如果产品没有目标驱动感，其他部门很难有目标驱动感。这就使得可能原来一步到位的流程要拆分为两步，我们属于没有建立起工作流程的阶段，先让组织理解自己的事情和目标的关系，先做OKR引导，再逐步数据量化。

合作方的问题：

工作内容信息不支持数据驱动。

很遗憾我去的时候公司是没有这种人能够了解到全貌的业务，从工作分工上讲也不应该是CEO来给我讲，所以不了解组织结构和业务分工的背景，这会导致我变成了《魔兽争霸》状态，每走一步，才能看见后面的几步，每次了解一些情况发现还有后续的情况。当然这样也有对方的问题就是没有很好的文档沉淀。

对方的组织架构还不支持数据驱动。

从组织和角色上还偏向于传统软件开发公司，其次就是各个部门缺少负责人，当然我从推进上来说，效率上也不太可能我直接推动各个部门的人，所以需要完善组织结构，人员决策，以及负责人。

流程环境不支持数据驱动。

没有一个数据支撑团队可以持续的将业务方的数据提取需求转化为数据看板。因为数据提取是一件系统的工程，所以他需要团队长期赋能，当然你开始的时候可以头疼医头脚疼医脚，但是如果你是一个数据驱动的业务，早点考虑系统的数据搭建，持续的降低数据获取成本总是好事情。

人员模型也不支持数据驱动。

目前摸底了一下产品部门，整体上还是以做事情为导向，就是为了做而做，还不具备说能说清做的事情对于业务和目标的影响。更不要说找各种影响进行数据化的量化分析。并且相关的工作流程还不标准。以及没有这种意识，好在团队中总会有一两个人有这种意识，只要有意识的人能做出样板来，模仿对于这些人是容易的，但是从0到1自己摸索是困难的。

二、如何培养团队的数据思维

首先我觉得任何一家公司当前能招聘到的人才，就是当前能招聘到的最好的人才，我觉得当前服务的这家公司产品负责人打的比方是非常贴切的。

当前我们还没有一个体系去持续赋能业务提供数据，缺少工作流程和一些组织角色。打个比方就是餐馆没有很好的炊具，高端的刀具，也没有高端大厨习惯的烹饪流程等等。

这时候你找一个高端厨师来了，我们可以把一切的雇佣关系比作交易，这时候高端厨师来了他想获得什么，一定是说锻炼自己的专业厨艺，你让他来了先买炊具和磨刀，这时候一旦餐厅垮了，他这些经验是没法在新公司用的，因为大的餐厅是提供良好的烹饪环境的，厨师只需要花精力做饭。

所以不要在特别小的时候找一些特别高端的人，无法匹配。因为他来了也发挥不出来，你在搭建烹饪环境，他要求好好锻炼厨艺。读者们不要拿蔡崇信来反驳我，况且咱们也不是马云。正如我自我介绍说的那样，以概率论来解释这个世界，马云是小概率事件。

第二是好的人才很容易被其他offer吸引走，我本人曾经在一家400人左右规模的公司工作，那个时候你招人也不好招，你发出去的offer，一线大厂一个offer人就被节流了。

我现在在大厂是一样的，我始终想表达的就是一点，你招聘到的人就是你当前能招聘到的最好的人，大厂一样有困扰，我们每次发offer都害怕阿里和腾讯以及字节跳动发offer，只有抖音，Tik Tok ，微信等产品他们不太害怕自己发出去的offer会没有人接。

第三我当时在的互金公司工作的同事最后都找到了快手，携程，京东，百度等工作，还有人做了O2O业务的产品总监。所以我现在的反思就是到底是这些人不行，还是公司不行，同样一批人为啥都去了更好的公司，证明他们是没有问题的，可以培养成为大厂的骨干。

那么当时为啥领导对他们都不满意呢，我认为还是公司不行，公司没有培养人的环境，人只要过了某个阈值以后，其实很大程度上能力受到公司环境的影响。当然人的基本素质要突破一个阈值。

总结一下企业招聘人员不要妄图招聘到一个特别厉害的人，从交易的角度上来说这种人你得支付远高于市场价才能来，你支付多个30%，考虑到项目失败风险等隐性成本，他是不会来的。你只有让业务走到下个层级，获得下个层级的影响力，你就可以招聘到下个层级可以吸收的人才。

这让我想起松下幸之助的一句话，松下最重要的工作是育人。因为任何业务都是人做的，要对人培养好人，业务自然的走到下个环节，就会有更好的人才涌现，况且大部分情况，人员的发展速度是快过公司的。这也解释了为啥我们互金公司产品人员都去大的公司。

额外的分享一些人员成长的看法，我之前非常不喜欢公司里面一个领导，因为他毫无原则的保护组内的人，我认为毫无原则的袒护是一种对于组内人员的溺爱。当然这是管理理念的不同。但是一次他的行为让我对他改善了很多，就是他组织自己部门的人学习。

要知道一般的公司不会对公司人员的成长花费成本的。这种成长培养是一种长期投入，太多的公司觉得划不来，他们只是把员工作为一种耗材。但是如果你所在的公司，他们还愿意培养你，那么证明你所在的公司为你的长远至少有打算，你应该感谢它们，因为这样的公司真心不多。

通常人员的成长，最基础的是业务增速，这只是基础。但是人员能不能随着业务长起来，要看他的成长速度。成长速度第一奥义是动机，第二奥义是方法。动机就包含了你想成为什么样的职场人，你想针对业务做怎样的变化。而方法就是你要有很好的思维模型。

你大概知道一个事情比较专业的做法是怎么样的。所以大量的工作量是一个人成长的必要条件。而不是充要条件。他需要阅读到专业的方法论，用专业方式来做事情，其次在实践过程中，消化吸收，不断思考。所以俞军说阅读，思考，实践，三者最低的环节确定了你的上限。

做团队数据驱动的经验复盘

我最近咨询的两家公司都出现了人员非常忙，但是他们都没有什么提高的情况。就是他们反复的在低等的维度训练，关键的是他们不知道什么是更高的维度，不知道自己不知道，这个才是可怕的。有兴趣的可以读我的另外一个文章：掌握更好的思维模型，在职场脱颖而出

比如一个产品经理，一开始只是实现需求好似没有问题的，但是如果持续的只是做实现需求就会没价值。他做的事情就算堆满了他也没有价值。

因为更加有价值的事情是权衡需求的优先级，知道哪些先做，哪些后做，在这之后就是做需求规划，知道未来要做什么，在规划的基础上就是做落地，知道一个规划如何实施。这就需要一个产品经理不断地提升自己的工作难度和复杂度。

同理可以说明一切行业，如果一个产品经理只是反复做需求，完成基本的需求实现，他是没有成长的。有时候特别忙，没有方法并不是好事儿。

需要说明的一点，这里的阅读毕竟不是看书，而是指一起获得专业方法，提升思维模型的渠道，与高手聊天也是可以的，但是有一些人没有这样的资源。比如俞军老师曾经说高阶大佬为什么成长快，就是因为他可以和各行各业的高手沟通学习，他自然成长快。但是低阶小弟不是有这个样的机会，他们没有机会和高手聊天，但是可以和高手写的书学习。