前面文章提到过我现在的 manager Michael 是公司的 VP of Data，这让我不仅工作中和各个数据组有更紧密的合作和接触，而且有更多的机会得到一些和数据相关的指导和锻炼。今天就且说说这半年多关于数据的一些新的体会。

 

给我印象最深的，是第一次听他在公司做报告的时候引用的 Peter Drucker 的一句话：“If you can’t measure it, you can’t improve it.” 这句话在后来的工作中多次的被印证，而很多时候，及时有效的一个数据分析，可以帮我们找到正确的方向，做改进最省力的办法，以及时刻帮助我们了解项目或者产品的好坏。

 

先说几个我在管理技术团队的小改进。

 

首先就是对各种 bug、incident或者系统漏洞处理的优先级排序。以前我遇到别人报了一个问题，第一反应就是凭直觉去判断这个问题是因为什么，好不好修，怎么修，以及引发的可能性会不会很大。现在每遇到一个问题，第一件事就是去 “measure it”，这个问题影响到的人可能有多少，给公司带来的损失是多少。每个小时每天新的影响有多大等等。每个 bug report 上都有这样的 SQL query 和数据，然后团队就根据切实的数据去决定哪些问题是急事，哪些可以稍微放一放。这样一来团队始终都可以做到把问题控制在最小，而且对于略推后的问题心里也十分有底会有多大的影响。

 

其次就是通过有效合理的 AB testing，来确保性能改动还是新特性的发布都会带来预期的效果。如果不是，也可以第一时间知道哪里出了问题，就可以及时的改进和调整。关于 AB testing，大家都知道其重要性，不过最近又有了一些新的体会。

 

一是公司内有一个好的 AB testing 系统框架，包括怎么设计和开始一个 AB test，怎么方便的选择哪些 metrics 来监控甚至报警，什么工具可以帮助细拆或者组合不同 tests 之间的影响等等，是一件值得在一开始就做一定的投资把它做好做对的事。设想你能把跑一个 AB testing 的所有准备工作和管理工作的时间从一天降到一个小时甚至更低，对一个大量靠数据驱动的公司来说，可以节省多少时间。更重要的是，AB testing系统把同一时间公司所有的tests一起统筹管理，可以帮助你随时观测其他可能对你所在领域产生的影响，增强大局观和主观能动性。

 

二是不一定要用 AB testing 来做所有的决定，但是使用 AB testing 来测量每个改动对各种 metrics（如收益，客户体验，损失，运营花费等）的全面影响，是非常有用的工具。因为我们的 AB testing 的框架和系统做的很好用，所以我们每个产品改动都会设。一来让我们更加了解每种改动可能带来的预见未预见的影响，二来多一层验证帮助确保代码的质量，有一两次改动是纯粹的 refactor，但是因为有几个非常隐蔽的 bug，结果实验数据和预期不符，顺藤摸瓜，才找到了否则可能很久都不会发现的系统漏洞。

 

最后的结果就是组里不论任何大小决定，都用数据说话，决策过程也变得很透明。不论是季度规划还是每周的项目规划，我们都不断训练每个工程师去学会读数据，定目标，理解数据和内在外在变化的关系。给公司内组外的 update，也是把所有的项目和数据挂钩，这样每个人都很清楚为什么要做什么，以及做的每一件事的影响。

 

这是一些简单的例子，数据在技术团队的应用是渗透到方方面面每个细节中的。不用觉得你不是数据分析师，也不是产品经理，没有必要花太多的时间去想这些。但是其实，一旦你开始花一点精力去了解和掌握数据，你会发现它会帮你对自己的工作有更透彻更全面的认识，也会帮你在综合做事能力上大有助益。

 

那么作为一名工程师，或者技术管理者，如何去利用有限的时间去培养这些思维和能力呢？

 

一是定目标的时候都尽可能量化。不要只是想着要 improve，enable，想想你具体 improve 了多少，enable 了什么。

 

二是动手搭一些简单的 dashboards去追踪你的目标指标。这样你就能随时观测你离你的目标有多少，从趋势上知道你做那些事对你的目标有最大的帮助。

 

三是保持一颗好奇心，看到设定好的数据有任何不是很理所当然的波动或者变化的时候，试着打破沙锅问到底，试试自己能不能去解读这些波动和变化。并且勤于动手去写一些简单的 SQL，知道数据的来龙去脉，知道每个数据的波动，其上游和下游可能受影响的数据还可能有哪些。

 

另外，如果组里有一名数据分析师或者数据科学家，不要觉得只是各做各的事，尝试着更紧密的合作和沟通，学习一些简单的技巧和思路，加上你对系统的实现有很好的了解，等你能够熟练运用一些简单的数据技能的时候，就会发现对彼此的工作都会有很大的帮助。