数据分析在驱动管理和运营在公司运营中占据越来越重要的作用。

滴滴是成长非常迅速的公司之一，到目前为止可以说是中国做得最好的一个打车软件，现在已经不叫打车软件了，叫滴滴出行。

接下来就由滴滴的项目经理团队高级经理易芹芹给大家来分享，在滴滴内部是如何做好他们的管理的。

我是来自于滴滴工程生产力部的易芹芹，我们部门简称EP，今天我会带着大家去看一下，滴滴在高速发展的背后，我们都遇到了什么样的挑战，我们是怎么解决的？

其实管理方法肯定有很多，但是我今天想跟大家讲的是滴滴最有特色的，而且行之有效的一种方法，数据驱动的管理。

1.认识滴滴：现状·挑战·方案

我们重新认识一下滴滴，这个页面大家都非常熟悉吧，每天打开手机端准备叫车的时候，看到的就是这个页面，我们看一下，这些是我们已经发布的产品，除了我们手机端能看到的那七个（巴士、顺风车、快车、出租车、专车、代驾、试驾），还有企业和国际化，国际化是最新发布的太平洋的产品。

2015年9月9号，滴滴打车品牌升级成了滴滴出行，为什么呢？

因为我们要打造一站式的出行平台，在2014年之前，只有出租车的时候，我们发现无论我们怎么努力，我们在高峰期的叫车应答率只有40%。所以我们很快就认识到，这个主要的瓶颈就是道路资源的缺失，而仔细想一想，其实每一个私家车、出租车、巴士上的座位，其实都是一个一个的运力。滴滴要解决的问题是什么？就是如何把这些运力调动起来，利用起来。

在打造一站式出行平台的背后，滴滴发生了什么样的变化呢？

业务线的条数从一条到九条，我们的交易规模从原来的极少量到现在的千万量，我们滴滴已经成为了中国互联网上的交易规模第二大的交易平台，仅次于淘宝。我们的员工人数在一年内，仅仅一年的时间从一千涨到了五千。而我们涉及的领域从原来的出租车的领域到现在整个出行领域，从国内走向了国际。

这些都是巨大的变化，在这些变化的背后，我们遇到了什么样的挑战？

1、变化背后的挑战

首先业务线的增多，最重要的一个问题，我们怎么保证每个业务线之间的用户体现一致性呢，把用户至上当成滴滴要素呢？

我们的交易规模增大，怎么保证我们的稳定性，不知道在座的各位有没有突然之间打不了车或者使用不了滴滴的情况，如果有，我们的稳定性确实还是有待提高，我们也在朝这方面努力。

我们的员工人数急剧的增长，怎么保证员工的目标和文化的传递一致性呢？我们的团队规模增长到这么快，怎么保证我们五千人的团队还像以前那样那么有战斗力，怎么激发每个人的战斗力呢？其实这些都是在高速发展的公司面临的挑战，滴滴是怎么做的？

2.滴滴是怎么应对的

大家所知道的滴滴，在以前大家只认为滴滴是营销驱动的公司，滴滴在营销方面确实是非常厉害。

不知道大家还记不记得橘色星期一的活动，当时在快车和顺风车上线的时候，我们发起了橘色星期一的活动，因为这个活动单量在一个月内都达到了百万。再往前推，2014年年底，滴滴和快滴之间的补贴大战，双方确实奠定了市场的定位，好在我们后来合并了，现在成为相亲相爱的一家人。再追溯到创业的阶段，当时滴滴的品牌并不是很好，也没有那么多流量，我们的地推铁军一天在西客站拉来一万个司机，这些都是营销驱动，我们公司在体验、技术、效率、团队方面，其实也是一直在努力，齐头并进的。

体验，没有一家公司不会把用户体验至上做成最重要的事情，所以我们要重视用户、重视体验。

技术，我们有这么好的大数据的基础，其实我们会持续的加大在核心期上面的投入，因为我们要让技术成为拉动业务增长的引擎，只有一个公司在核心技术上超前于时代，才不会被这个市场所淘汰。

效率，我们一直在提升我的效率，降低我们的成本，团队夯实，因为团队就是一个公司的基础，所以我们现在有些手段在团队上面。

所以滴滴是一个数据驱动的公司，我们同事讲了一下如何用数据驱动去驱动产品的角色，而实际上滴滴在管理方面也是有数据驱动的，这种管理模式存在的。

今天我会给大家介绍，滴滴的团队形式是什么样子的，因为毕竟团队是一个公司的基础，还会带着大家看一下，数据驱动的管理在体验和技术方面是如何应用的。

3.数据驱动管理是什么

我们一起先看一下，我们说的这个数据驱动管理是什么？

我们是一个管理者一般都会经历三个阶段。第一个阶段，自己干，第二个阶段，我带着别人干，我带着团队一起往前冲，第三个阶段，我盯好目标，让团队的成员能够自驱的往前走，这是一个管理者要考虑的事情。这个管理者他应该首先要考虑的是，我的组织形态应该是什么样子的？

我的团队成员，到底扁平结构还是说我也有层级，再划分团队，我的团队划分到底职能性的还是其他的？因为一个团队形式，它是基础，盯好团队形式之后，最重要的事情就是定目标、定指标，我们这边是建议定明确的指标。有了明确的指标之后，是比数据。我们要把数据透明化，并且排名，大家一起看一下我们所有人的数据，在这个指标下是什么样子的，有的人可能就会有疑问，定指标和比数据不就是KPI吗？所以我这里特别想强调的就是，首先我们一定是要把所有人的数据都透明出来，并且排名，有一些趣味性的东西。

第四点最重要的，管理者一定要考虑建一个完整的生态，这什么意思呢？我们不要让这个团队成为这个团队管理者的团队，而是大家的团队。所以对管理者的要求就是，他如何营造一个环境，能让所有人都在这里面受益，如何让所有的人能在这里面走到成长。这个是非常重要的，也就是说我们的思路通过指标，把我们团队的文化、工具、平台、机制，一一都给它迁出来，这才是一个完整的生态。

二、团队夯实：场景·FT组织架构·FT落地
接下来，我们先看一下滴滴的组织形态，在这里先讲一个场景，大家感受一下，我说这边有一个很好的需求，上线了之后一定会给公司带来很大的收益，我们希望马上上线，PM把这个需求拿回来了，他先会去找市场和运营，还原一下需求，摸清需求的背景。我们再把这个需求写出来，写成PRD的形式，再拿RD进行评审，RD等排期，因为当前做一个很重要的版本，有些内容还没有做完，只能等到下一个版本，好不容易等到RD做完了，QA又来了，我还要等QA测试，这是一个很典型的场景。

更复杂一点的，这个需求它又一个人完成不了，通常一个需求的上线涉及到司机端、乘客端、API端等等。对于司机端，他可能还分前端、后端，如果再复杂一点，一个需求可能还要跨业务部。所以就会用的人越来越多。这个场景，我不知道大家有没有觉得似曾相识呢？

其实滴滴是存在这样的场景的，这个就是我刚才说的。我们无法及时响应这个场景，我们当然是期望任何一个需求都是快速响应的，同时这种类似的场景，团队中可能遇到的问题还有哪些呢？

首先责任缺失，一个需求，一个功能可能很多业务线都在做，但是我不知道明确的责任人是谁？责权利不一致，期望责权利一致。我们的团队越来越大，层级越来越多，这样决策路径会越来越长，这也会导致上面的那个慢的问题，所以我们期望加速整体的决策。公共或者重点的事情推动慢，组织人力资源本身就是一件很麻烦的事情，我们期望集中精力攻坚，这些场景也是滴滴之前遇到过的，我们的解决方法是什么？

先是滴滴转成featureTeam，大家应该不会很陌生，我们滴滴认为的featureTeam是什么？

首先它是一个为完整用户价值负责的态度，这个团队里的人有共同的目标、共同的考核标准，为结果负责。

其次，它是一个全功能的团队，我刚才说到，一个需求端到端的涉及到所有的团队，所有的角色，它应该都是在这里面的。

第三，团队里面的人一定要专注，专注在做这个团队里面的事情，而不是并行很多个事务在处理，如果原来职能性的团队存在这个问题，并行的版本或者功能特别多。

第四，团队的人一定要坐在一起，这个非常重要，其实我刚才也说，featureTeam并不是一个很新鲜的概念，我们想一想，每一个公司在创业的初期，它是不是就是一个featureTeam？因为它为结果负责。它是一个全功能的团队，所有的角色都有，运营、市场等等。他们很专注的就在做当前的产品，他们也坐在一起。

当一个公司越来越大之后，一个公司拆成了很多业务线和事业部，事业部的初期是不是也是一个featureTeam？也是满足这些要素的？

再举一个例子，全栈工程师。工程的提出，设计、UI的设计、测试等等都是这一个人来完成，他就是为结果负责的。所以一个公司和一个全站工程师就是FT的两端，所以我们在滴滴推荐的这个FT，十个人左右的团队，FT的优点改变快速响应，用户价值导向，能激发创新，有助于能力成长。

我们常使用的这个功能，像接送机和快车的拼车，在我们公司就是完整的FT，它包含司机端、API、策略、MIS、所有的。同时，每个角色RD、QA、PM甚至域名和市场都会进来，这是业务功能角度划分的FT，有些人说看不见的功能怎么划分FT，也是一样的。在我们公司，像支付、信用体系，只要涉及到这种功能的相关的人，都会组成一个团队，他们会持续的去打磨这个产品的体验。

组织结构，因为说到组织形式一定要知道，公司的组织结构到底是什么样子的，这就是我们的组织形态，我们也只有专业线的，大家说了职能线，我们职能线的人主要负责专业人员能力的培养，还有专业规范的制定和落地，为FT提供人力和资源，FT就是一个纵向的，它是全功能的团队坐在一起，一定要注意我们的FT一定要实体坐在一起，它不是一个小黑屋的形式，我们刚才也提到了小黑屋的形式，小黑屋的形式它只是短暂的，而我们说的团队是要长期的坐在一起。

他们为同一个目标负责，当一个部门非常大的时候，划分出来的FT越来越多，这时候一些FT凑在一起成为FT的集群，FT集群的领导保证整体的战略方向是一致的，并且指导FT相关的实践。

举个例子，我们EP部门，有项目经理团队、有配置管理团队，从职能线来说，还有RD工具组的团队，这个工具组的团队还有各种各样的角色，有RD和UI、还有FE等等。但是我们EP划分成七八个FT，每一个FT为一个具体的工具或者平台负责的它是纵向的，而且在EP团队大部分的时间都是FT坐在一起，并不是RD们坐在一起或者配置管理组的人坐在一起。我们一个FT里面，如果是有涉及到推广或者项目管理工作的，就会有项目经理进去，我们刚才说的那些职能，在我们的FT里面都是存在的。

FT的落地，其实它不仅仅是组织架构调整这么简单，它更是工作方式甚至文化的转变，在落地FT的时候，一定要定义清楚，我们每一个角色的职责划分和定位，也要说明清楚，我们FT的生命周期是什么？什么时候该创建一个FT？什么时候一个FT该解散？一个FT内部的工作方式应该是什么？大家的晋升通道又是什么？

如果转型成FT之后，人员的能力要求是不一样的，比如说FTO，它的要求更像一个公司的CEO，它更全面，而不是职能的领导那样的要求，我们就有相应的培训体系。另外，文化，原来是相同职能的人坐在一起，现在变成了不同角色的人坐在一起，我们还要这些人有共同的目标，这种实际上对他们来说是一种文化上的挑战。我们还要有相应的激励措施，这个是在滴滴去落地FT的时候，全盘去考虑的，我们是EP和HR一起合作去推进整个公司的FT的落地。

举个例子，这是我们一个事业部，大概200多人，全部转型成FT的形式，每个FT大概是10个人左右，他们为每个队伍取了一个名字，根据自己的目标取了一个名字，而且大家走到他们的工位上可以看到，他们坐的一两排，每个工位挂了一两个牌子，走过去特别壮观！这就是感觉。其实这个是为了从文化上，让他认识到我的团队已经是另外一种形式了。

三、体验驱动：指标·数据·生态

组织形式，因为时间的关系，我不能讲得更细，我们接下来在这样的组织形式下，怎么去落地数据驱动的管理。

我们先看一下，在体验驱动方向上，我们是怎么做的？

刚才说，最重要的是定指标、比数据和建生态，体验驱动最早解决的问题是什么呢？定什么样的指标，比如说滴滴，我们有一段时间发现，业务线增多之后，体验没有那么好，比如说打不了车，就是最差的体验，那个阶段我们比的是成交率。成交率的指标定好了，最重要的是要有客观数据的支撑，这个地方一定要注意，不能让大家自己去提或者是上报这样的数据，而是就是有一套客观的系统，对所有人都是公平的，而且这个数据是实时可见，我们每个月可以做一次排名，去看谁最好，谁最差。

这有一个小技巧，通常如果只比最好的时候，是不能激发大家的战斗力的，因为第一组总是只有一个，但是我们会对最后一名做一些小小的有意思性的东西。比如说，最后一名给公司的人发水果，这样的一些事情，大家就会涉及到尊严之战了，大家会努力的往前冲。

在这个阶段，我们自建生态是什么呢？体验一定不是一个管理者的事情，它是全公司上下的事情，我们都说腾讯的体验做得好，我们也是希望我们公司的人能像腾讯的人一样，人人都关心体验，人人都成为体验专家。所以我们在这个阶段，调动了全民参与体验，一会儿我会详细讲。

BI数据的完善，因为我刚才说到，我们的数据一定要是客观的。在这个时候一开始的时候就做了所有BI数据的梳理，当时梳理了300多个指标，而且发现我们的业务线，对于某些指标的理解还不一致，有的是错误的，有的还是缺失的。所以在这个阶段梳理那个BI数据特别重要，而且收益也是非常大的。

成交率上来之后，我们就加入了差评率，来源会有非常多种，因为只有这种差评才能看出我们的体验到底差在哪里，我们有工单的、舆情的差评，这个阶段完善的主要是体验闭环。因为刚才说所有人都要参与体验，提了问题谁去解，如果不解，这种体验的热情马上就会没有。后来我们又引入了CPO，客服的投诉率，到今年我们又引入了NPS，大家应该都是知道的，我们现在全球流行的一个衡量用户口碑的衡量方法。在这个阶段，我们完成的生态就是体验工具，因为我们想让大家去实时关心这样的体验，想去实时了解这样的指标，必须有一个东西能随时看到，而不是说到一个月了告诉我哪里做得不好，体验工具的完善是非常重要的。

我们是怎么让所有人都去关注体验，参与体验的？

我们公司有两大项目，一个星火，一个燎原，星星之火可以燎原，星火是对外的一个项目，我们会让对外的人，外面的普通用户经常使用我们的产品，并且给出反馈。燎原就是对内的项目，它有一系列的方法或手段，能让我们所有人都去参与这个体验，在我们公司所有人都必须要经常打车，某一部分人还有打车的要求，要打很多次车，并且要提很多问题，如果没有满足会有什么样的惩罚。而且我们的某些高管是不能自己开车的，有车都不能开，必须所有的出行都是用我们自己的交通工具，用滴滴。

这个效果很好，从一开始有体验问题也没有人报，大家根本不关心体验，就像我这样，我以前打车也发现不了问题，我觉得使用习惯了，怎么都还可以，但是后来有了这样的项目之后，我也有考核指标，我就很专注的找问题，一直到现在，我就发现越来越精益求精，我们能发现很多问题，这就是我们能带来的一些效果。

其实我们做体验闭环，不是说一个指标那么简单，我想说不是说定个指标过完了，而是希望通过这种方式能让体验这件事情变成大家的价值观的一部分，能真正融入到血液里，这才是有效的。而在全民体验中，我们关注的就是一些事业部的解答率，还有应答率，主要目的为了发现产品、流程、策略上的不足。

除了这种让大家都去打车的方式，我们还有客服日，公司所有的高官，所有的PM，所有的新员工都必须要去当一次客服，去接听一下用户的电话。为什么呢？因为公司越来越大了，我们离用户越来越远，听不到用户的声音其实是非常可怕的事情，因为我们在三个月内，开办了31场，55个部门都已经进来了，目标就是我们的问题运营率达到99%，这些都是非常清晰的数据，让所有人知道我们的目标应该是什么。

刚才说所有人都去提问了，而确实现在能看到的，不管是什么角色、什么层级的，我们都是会实时的去反馈问题，我们怎么去把这些问题闭环呢？其实一开始的时候，也没有那么好，很多人觉得我的业务压力那么大，我为什么要做体验的改进？所以我们也是有一些手段的。

首先，我们有体验闭环，建造体验闭环的工具，我们会有专门的下载包的地方，下载完之后有提反馈的地方，我们公司内部看到内测跟外面看到的是不一样的，有一个小笑脸，这个就是我们发现什么样的问题能立马截图，提反馈或者提建议。

这个问题会直接进到G1里面，如果Bug做Bug的流程，可以清晰的看到当前在哪个项目、哪个版本去做改进了。如果是不想进G1，我们也能清晰的看到当前的处理流程，这是第四部分。

这是一个完整的体验闭环，有了体验闭环之后，我们就开始比FT的问题解决率，我们有问题解决率的指标，把所有问题解决率的情况公布出来，别人就会自发的去看，别人做得很好，我做得不好，那么他们就有各种各样的问题闭环手段，有的FT是有半天体验闭环的时间，有的有专职的人，有的又是全同事一起参与，很多种形式。这就是整个过程。

我们这个过程中，真正能起到效果，我们公司想让大家参与体验，我们确实把体验这件事情当成我们自己的一部分，能有这样的效果就很不错。

四、技术领先：指标·数据·生态

在技术领先方面，这套理论是怎么应用的？

公司提技术领先不仅是有多少个优秀的项目能起来或者投资了多少高科技的领域，这些肯定是有的，肯定只是涉及到一部分人而已，一部分优秀的人才，怎么让所有的人感受到公司在重视技术上，一开始也是为了解决一些问题，那时候的问题就是刚才说的，我们的服务还不够稳定，那就去定稳定性的指标，稳定性指标计算很容易。

在这个过程中，我们也要去完善我们的工作，之前围绕基础服务，很多事情做得不够好，就让它一一改进，怎么让大家自驱的把这些东西做起来。技术领先肯定第一个阶段是高可用性，后面还要像高性能、高智能、低成本这些方向去迁移。

我今天会重点讲一下生态的部分，怎么让大家积极的去重视这件事情，定了那个指标之后，一样把所有的都排出来，别人能做到什么样子？我的服务是什么样子的？

一目了然，因为这些数据都是非常客观的，大数据的或者监控的一些数据。大家就开始自发的去做自查，那时候其实在线下，也是分线上、线下，线下从测试、开发，降低上线的故障率，大家在压力测试，代码质量、上线流程、灰度发布也做了很多事情。

线上如何解决快速的发现问题，发现问题如何快速定位，如何快速解决，所以我们的方向在监控到几，降级，故障隔离快速扩容这些方向。后来做了一次调研，看大家都在哪些方向有了一些动作，后来发现在监控报警降级，还有上线流程方面居然是排了TOP3，这说明其实随着滴滴的快速发展，我们一些基础的工作还是在这个过程中逐渐的完善起来的。

刚才说，问题要有问题的闭环，我们的技术改进一样也是要闭环，其实任何一个公司都有一个现象，我说一个很好的技术想法或者很好的改进措施，但是并没有闭环起来，以故障为例，我们对一些关键的指标，像BI的数据，300多个指标，关键指标要可视化，也有比较强的监控和告警。

但是我们在这种快速的定位问题，故障的上报、问题的闭环，上报之后它的改进措施的闭环之前我们是缺失的，我们现在在这个过中逐渐的完善，现在能做到故障有苗头的时候就能提出来，这里有什么样的事情，请大家关注。在很快的时间，只要这个问题解决了都会有一个故障的上报。很亲切的说明这个时间轴是什么样子的，他们的改进措施是什么样子的，并且他们改进措施流转到急转里面，我们会去看他们改进的闭环率。

技术方面我们最想留下的是什么？

一定就是服务平台化，服务平台化并不是一个非常新鲜的概念。在百度三年前提出了服务平台化这个概念，亚马逊和谷歌在这方面已经是领头羊了，做得非常不错。阿里前段时间提出了大中台、小前台，也是服务平台化的概念。因为我们的业务越来越多，但是我们的人力资源、机器资源是有限的，不可能无限的扩充，我们遇到加速创新，加速创新的同时想节省成本，服务的平台化就是一个必经之路，必须要做的。现在我们在做这一阶段的事情，就是把这个可视化和标准化先做起来，因为这个是平台化的基础，标准化的服务，比如说规范的文档、清晰定义的接口，可以监控，有明确SLV，这些其实在很多公司里面，技术服务也是都还是有待提高的地方，我们公司正在推进这样的事情。

另外，除了技术，还希望留下什么？就是人，我们希望有很多优秀的人才能在这个过程中涌现出来，我们每周都有一次案例的分享，技术案例的分享，每个月有一次技术沙龙，我们每个月不是有月会吗？

刚才说了要比数据，所有FT数据的时候还有一个明星分享的环节，让大家识别出哪个做得好，会去把它的优秀经验分享出来。在这个过程中，我们的技术沙龙，第一期做了降级，第二级做了他山之石，公司里面有的人讲，他原来的公司有哪些做得好的，有哪些经验。其实效果挺好的，我们举办了一个多月，就有监控服务、存储服务就已经获得了他们自己的粉丝，一场宣讲完之后，很多人认识到公司原来还有这么好的东西，不会再去重复的开发，这些都是在整个过程中我们去牵引出来的。

回顾一下，为什么说滴滴在数据驱动这块是很有特色的呢？其实最早像数据起动在做项目管理或者做过程改进的人，这种思路应该是一个常见的思路，但是那只是个人的工作方法，而滴滴比较有特色的就是，他公司从上至下的目标分解是用这种方式，这个事实上是很少见的，我们现在公司四大方向，基本上除了团队没有用这种方式，其他三个方向都是要用这种方式去激发大家，调动大家的积极性，这个很有特色。

在滴滴这边，我觉得做得好的主要要素是什么呢？

首先，我们的指标一定是持续迭代的，并且是快速迭代的，不能是一个指标一年，我觉得效果很差，因为只有持续的去变化，它才能让大家认识到，我们其实上一阶段已经做得不错了，下一阶段我们的努力方向应该是什么。

第二个，一定要有客观数据的支撑，不能让大家报数据，所以我们的BI系统，就应该要做到非常的完善。

第三个，我们说建立生态，最重要的是，一定是全民参与、全员参与，这种管理上一定是让目标成为团队的目标，而不是一个人的目标，这个非常重要。

第四个，我们一定要有可落地的东西，到底落地了什么？什么东西有效，这个指标不比了，是不是这些东西还可以继续用下去。

第五个，增加一些趣味性，今天趣味性的东西讲的比较少，一提到趣味性大家都有自己的理解。

怎么叫成功呢？从结果上来说怎么叫成功呢，首先我们之前想达到的目标一定要实现，我们想解决的这种全民体验，大家都关心体验，稳定率更好，这些目标是要实现的。大家的目标是要统一的，通过这种方式让所有人都知道，公司的目标是什么。第二点，一定是影响全民的价值观，让全民参与可能很容易或者定的目标，你给我报就好了，但是你怎么才能让你想要传达给大家的东西，真的是他价值观的一部分，这个很难，这个可能就是背后还有很多要去支撑的东西。第三点，通过一些方法，营造一个大的环境，让所有的人能在这里面受益，如果所有人都能受益了，我觉得它也才能算是一种生态。

五、总结：环境基础·价值观·统一目标

做个总结，这个其实管理方法只是手段，我们主要想说的是，滴滴它这种文化或者价值观，我觉得这种方式不一定适用于所有的公司，像一些成熟的公司，我觉得这种方式就很难，因为那些东西做得非常好了，你要这么一比的话，大家会想方设法的做一些其实并没有那么有价值的东西。在滴滴为什么能做得好呢？

首先由环境基础造成的，滴滴环境是高速发展的创业公司，它实在有太多的事情可以去做，大家都会往前冲，首先我们的空间是很大的，我们先把自己的事情，把我们可以做的事情先做好，这是大的环境基础，我们公司并不是很在乎数据摆出来了，是不是好看。

第二个，价值观，我们公司特别注重价值观的传导，管理层会经常去传递这样的价值观，我觉得在这件事情上能做好的价值观。

首先是绝对信任，不相信别人会造假，因为造假是一个红线。我觉得首先我们是相信大家的。然后，我们要传递主人翁的心态，每个人都是放下小我、成就大我，把自己当做公司的主人。最后，说到做到，我既然承诺了我要在这个方向去努力，你有问题，你可以一开始提，我们当面说，但是没有意义的时候，大家就超强的执行力往前冲，说到做到，这一点滴滴的执行力真的让我叹服。

举个简单的例子，稳定性的指标，一开始其实我是很担心的，因为在还没有开始有这样动作之前，我们有了故障，并不是所有人都会报出来，有了就觉得小故障就不说了，本来很担心，会不会这件事情之后大家更不报故障了，因为你要统计故障率，虽然我们也是有这种系统的，但是有一些可能还真的是由于监控的不完善或者计算不到。但是结果是出乎我意料的，我们上报故障、通知故障这种事情，居然比以前更积极了，你想象不到的积极，一些很小的点，我觉得不需要报的，大家也会提出来，我这里有问题了，正在解决，这种文化很好。

第三个很重要的事情，统一目标，公司不断的开这种月会或者季度会，在管理层这方面统一目标，因为只有讲清楚了我们滴滴现在面临的环境，我们为什么要做这样体验的事情？为什么要做技术领先的事情？传递背景之后，大家理解了，才不会在这种数据方面有什么质疑的地方。

我觉得这些是支撑滴滴按这种方式能做得很好的最大的原因。

Q&A
Q1：能不能具体解释一下成交率的问题？因为一个团队里面有不同的工作角色，方式不一样，怎么统一同一个层次来比较不同角色的指标？

A1：不是比的某一个角色，是比的某一个FT，我们不会比个人，比的都是团队。

Q2：每个团队开发的产品是不一样的，遇到的问题也是不一样的？

A2：对，其实是会有这样的问题，但是我们一开始，我刚才说的成交率，成交率是一开始体验闭环的第一个指标，当时这个指标是因为公司面临的大环境，我们想让更多的人能打到车，因为打不到车是一个最差的体验，而其实我们看到滴滴的产品线，像这种出租车、快车、专车，包括代驾，其实这些产品都是跟成交率挂钩的，当然，肯定有一些FT不是成交率相关的，比如说巴士，巴士考核的不是成交率，肯定考核的落座率。这种小的理解我们会单独的拎出来，有一个例外的点，但大方向是那个成交率。
作者：易芹芹

滴滴工程生产力部门项目经理团队高级经理。负责打造高效的组织形态和项目管理体系，持续提升组织效能。半年内带领团队攻克主App版、战略级项目交付、工具落地、组织Featureteam转型试点等多项难题，带领团队获得2015年优秀团队，并获得公司年度最佳个人。曾任百度资深测试工程师和敏捷教练，具有丰富的组织转型、效能提升和测试经验。