数据团队规划布局感悟

作者：祝威廉

前言

记得今年一月份在杭州和W君漫步钱塘江赏霾，畅谈了两个小时，除了聊了研发的两观，全局观和产品观, 也聊了数据部的组织架构。一个良好架构布局确实会让人受益良多。

架构布局

目前我司数据部分成了大体五条线：

• 数据研发团队
  
  
  • 研发/执行
  • 解决方案设计
    
    
• 分析师团队
• 搜索/推荐团队
• 知识库团队（‘人工’智能）
• 平台运维
  
  

数据研发团队

数据研发分成了两个小团队，执行和设计。本来这里应该是把设计叫做算法团队的，但其实叫做算法团队并不太合适。我们把设计定位在能够提供一整套解决方案的那一组人里。

比如来问团队需要一套指数的东西， 设计团队会根据要求，设计建模出一套解决方案，并且先进行Demo验证，这其中可能需要用到很多算法，统计类的知识。交付之后也没啥问题了，就会交给研发进行执行，从而完成工程化。为了方便理解，我们把设计称之为问题建模也是可以的。事实上，我发现效果还是不错的。设计团队正在努力朝深度学习发展，在加强Spark Mllib上的投入同时，也花了更多时间关注TensorFlow平台。

研发执行里面，我们也是有细分，虽然人少，角色会有重叠：

• 分析师辅助
• 工程化团队
• 突击团队
  
  

数据部其实常常面临较多的商务需求，通常我们会让突击团队以最快速度交付第一版，之后再让工程化团队完整的工程化，比如全部转化为我们Spark程序，提供标准的API等，设置定时等等。

突击团队和工程化团队其实还有一个职责，就是团队效率工具的开发。这个基本是以研发负责人为主导，定期根据现状，找到效率瓶颈点，然后抽象出工具，最后排期进行开发。

分析师辅助团队则承担了两个职责，一个是对接纯粹的技术需求。比如ETL之类的。第二个是为分析师做实施执行工作。

虽然研发团队在努力，但是其实不太容易有很明显直观的成果。而且存在感并不强。在解决方案设计团队获得影响力之前，我们还需要一个重要的团队： 分析师团队 去扩大数据部门在公司的影响力。

分析师团队

我经历过两种分析师团队。一种是为研发和公司做support的，一种就是将现在的将分析师打散到各个业务线的方式，团队自身只保留高级分析师做全公司的support。

目前从研发的角度来看，反而是第二种更好。研发工程师和业务线天然有种隔膜，而且很多数据研发并不太喜欢业务。喜欢专研技术，和人打交道并不是他们擅长的，包括和业务团队的工程师打交道。 但是现在有了下放到业务线的分析师后，就变得很便利了。

比如解决方案设计团队了解了需求后，就不用到处去找数据，找人理解数据的含义，他们只要和我们自己的对应的分析师沟通就好，数据分析师直接提取出来数据，解决方案设计团队拿着这些数据就可以建模计算了，部分沟通也可以透过分析师来完成，而且分析师也可以给出较好的反馈，因为他们对业务也是相当了解的，尤其是从数据层面来说。

现在整件事情变得很有趣，以前是分析师依赖于研发，但是现在是研发高度依赖于分析师。基本上我们研发做的大部分事情都离不开分析师。我现在很愁的是，如何给分析师提供更好的support 以作为回馈。

各个业务线的分析师核心是要能够理解业务线里的数据，了解业务规则，问题，结构化业务数据，了解业务痛点，并且能够快速提取出业务/高级分析师/研发想要的数据。高级分析师则会对各个业务进行Review，给出数据方面的建议，为业务Leader提供决策指导。

这里我大致画了个图：

在前公司的时候，因为同事经验都很丰富，大体都5年+，十年的也不乏其人，所以基本没有所谓管理，而在那个阶段，我更关注的也是技术，对管理本身并没有太大兴趣。

来了现在的公司之后，团队的新人比较多，刚工作没多久的同事占的比重也较高，这个时候如果还想要产出，大体就需要一个有效的管理组织方式了，“好整以暇”，如何让 1+1 >>2就变得很重要了。正好老板也比较强调管理，对于中层的培训力度很大，加之自己第一次看譬如《赢》这种管理类的书籍，感触颇多。

对管理的态度

让事物有序的运转，是一定需要施加外力的，否则很容易散乱。就好比房间，我们也是要时刻花费额外的精力保持其舒适。程序也是如此，我们需要不断的重构甚至重写来保证程序的良性运转。所以管理其实是避免不了的。三人成众，如果没有布局组织，众可能就成为 "人人人"，最终是形不成一个字。

管理的目标有四个：

• 确定好使命，远景，价值观，
• 把握好团队方向
• 最大化团队能量
• 保证团队稳定
  
  

确定好价值观，使命

确定好使命，远景，价值观，这是杰克 韦尔奇 提到的。我对“使命，远景，价值观”则有更多一层的理解：它是团队成员发生更替，甚至领导层被更换而依然能够保持团队基因得以传承的重要保证。这里把“使命，远景，价值观” 比作基因，我觉得是恰当的，基因决定了团队的外在和内在表现。这是其一。

其二，“使命，远景，价值观” 是KPI能够发挥积极作用的基本保证，是KPI的润滑剂。我以前对KPI感到很困惑，因为KPI是必要的，但是KPI的副作用也是很显著的，执行KPI后的基本结果是短期效果显著，然而却伤害了长远，并且似乎和员工的情绪也是相抗衡的，更糟糕的是，KPI使得领导和员工变成一种互相博弈而非协同发展的关系。

最终，这个困惑被“使命，远景，价值观”给解除了。有了“使命，远景，价值观” ，我们就知道哪些事情是应该做的，哪些是不应该做的，那么我们知道如果我做了某件事情，虽然提升了KPI，但是违背了我们的“使命，远景，价值观” ，那么我们应该果断放弃。

“使命，远景，价值观” ，就像宪法，对一个团队的基本行为规则起到了一个很好的指导作用。

把握好团队方向

作为团队的负责人，我们努力希望让自己在团队和领导之间左右逢源，当我们不能忘记自己的基本职责： 把握好团队的发展方向。

如果方向错了，大体团队的命运也就终结了。或者无产出，或者产出艰难，或者产出无效，最终逃避不了自己被开掉，或者团队被解散的命运。

最大化团队能量

最大化团队能量，就是让团队有最大的产出，需要做到如下几点：

• 合理的组织结构划分。无论团队多小，一个合理的组织结构划分都是有必要的。好的组织架构是经验与智慧的结晶。你可以类比下系统架构设计。
• 让合适的人做合适的事情。把团队成员合理的划分到你精心设计的组织架构里。一个好的Schema还需要有合适的数据填充。
• 清理掉负值人员。“开除掉不合适的人总是很难的，然而总是的有人做的”。
  
  

保证团队稳定

这个问题我们遇到的非常多。结合现实的经验，我个人认为有：

• 将团队成员的个人目标、兴趣和公司目标尽可能的有机结合。就像拔河一样，要让大家往一处使劲。我们不能“惜才”而让个人目标 、兴趣和公司目标背离。
• 保持团队的一个流动性。额外带来的一个好处是，这样就会保证团队内部的冗余性，不会因为“明星员工”的离职而导致团队出现困难。当然这种流动性是通过管理来完成，而不是因为自身的问题导致人员流动过高，从而降低了团队的能量。
• 招聘不能仅仅考虑应聘者的技能。
• 赏罚要明显。大锅饭无论对于国家和团队，证明都是不利的。
  
  

最后的话

细节多了，就成了一本案例书了。细节太少，就成了哲学书。如果真要让方法有效，还是需要自己的细细的体味和揣摩，尝试。

今天重点讲讲我对感悟（一）中提及的“解决方案设计团队”的看法。其实这个名字是我瞎起的，对应的是大家熟知的“算法团队”或者“机器学习团队”。

关于几个名词的认识

机器学习团队做的事情，我觉得有个简单的规则来判定:

• 普通研发团队觉得实现不了
• 本来是需要人的”认知“和”经验“才能处理的，现在想把人释放出来
  
  

举个例子，付费问答里，我们希望知道用户对回答是否满意，因为显示的反馈如给五星好评似乎没有得到多少用户响应，所以我们只能通过人工的方式去查看，人具有“认知”和“经验”，而且大脑很通用，可以较好的处理这方面的内容。但是也有缺点，就是不够及时并且长远来说成本较高，毕竟要雇佣很多人才能处理那么多问题。

这个情况就符合我上面提及的两点了。首先问答的开发团队也是没有太大的办法的，因为这个需求太“主观“，不太好用代码来实现，除非你给我一些规则。第二个就是，这个确实只能用人来进行判定。人判定其实也是很难的，这个是后话，我们晚点再讨论。

好了，我们说明白了机器学习团队可以解决什么样的问题，那为啥我要取一个新的名字呢，比如叫做“解决方案设计团队”？ 因为我期待的是机器学习团队是任何一件事情的Ower,从需求发现，需求的提出，到demo，到工程化，再到测试，到交互到以后的售后，都有该团队的人来把持。换句话说，就是这个团队需要提供一个端到端的服务，为某个需求提供整套解决方案。所以仅仅会一些算法，是达不到我取的这个title的要求的。

解决方案设计团队 和 其他研发团队的区别

第一个是”交付“上的区别。 对于其他研发团队而言，需求提了之后，完成了就是完成了，没有完成就是没有完成，这个很清楚的。比如你开发了一个留言的功能，有就是有，没有就是没有。而解决方案设计团队则有一个”程度“在里面。比如”交付“了你确实可以用，但是可能只有人脑（我们假设人脑是100%）做出相同事情60%准确率。 而且很多情况下，也仅仅是他们宣称的而已。而且你很难验证是否真的达到了他们宣称的那样。
后续持续的改进，有可能还不如上一个版本，也可能会比上一个版本好很多。

第二个是”合作“方面的区别。 很多团队的基本模式是业务方提需求，自己来实现。”解决方案设计团队“有很多场景也是如此，但是对于”解决方案设计团队“而言，会更多的和分析师团队一起，从数据角度了解很多业务的现状，然后从自己的角度去发现需求，提出需求，然后和业务运营等进行沟通，确定需求的真实性，之后进行设计和Demo,直到最后的工程化和交付。所以更多的是一种“合作”模式，让事情变得更好。这是一起努力，一起担责，一起提升的过程。所以不存在“扯皮”或者“利益之争”。

有个简单的例子，解决方案设计团队通过数据发现大V存在严重的马太效应，这其实是一个标准的流量分配的问题，对于站点而言，利益最大化其实是如何利用你现有的流量让你站点的流量或者成交额或者问题数等最大化，这是一个典型的最优解问题，有点像广告的投放，之后解决方案设计团队可以提出这个问题并且和运营团队沟通，最后提供可能的解决方案。合作的过程中，我一直强调端到端的跟踪，比如解决方案设计团队做的一些有普适性的东西，也必须放到合适的场景下才能有作用，否则你会发现，就是一堆没用的东西。

第三个，”解决方案设计团队“会发生： 一开始认为可以，但是实际观察数据后，甚至到做了demo之后，才能发现这件事我其实是做不了的。 换句话说，就是它可能经常让你失望。

其他的团队大致了解需求后，是基本确定可以做的。但是解决方案设计团队却没办法做到这一点，比如对于情感分析，如果光从问题和回答的文字，很多场景是可以判断出来的。但是某天你发现一个具体的业务场景，这条规则失效了，如果只是通过对话内容，人都很难判断出来，因为这种场景，人并不会表露自己的”情绪“，那么机器其实也没办法判断出来。这种情况可能和具体的业务有关系。

第四个，”解决方案设计团队“ 做需求的过程中，属于厚积薄发，时间周期很长。当然，如果正好合口味，则有可能也是比较快的。

比如一个看似简单的问题，可能一个月，勉强交付了，效果一般般，后面一个月，还是一般般，哦，突然到了第三个月，效果获得明显提升。其实是因为第三个月他们顿悟了么？不是，是因为前两个月的积累产生的效应。和”解决方案设计团队“ 合作，需要放长线，短期你很难充他们身上获取到你满意的东西。“解决方案设计团队”自身也需要有积累的过程，好比一个婴儿，需要不断的学习新东西，长成大人之后才能不断获取做出优秀的成绩。

第五个，”解决方案设计团队“ 因为不局限在哪个业务线，而他又是承担一个找茬并且提供解决方案的团队，他从公司的角度去了解公司的瓶颈在哪，需要解决什么样的问题，所以可以缓解我之前提到的一个问题。参看这篇文章：研发的两观，全局观和产品观。这篇文章一句话就能概括： “局部的最优可能导致全局无法得到最优”。

后话

解决方案设计团队和大数据团队一样，是一个比较昂贵的团队，或者我们说类似于战略规划。或许可以成为公司未来新的驱动引擎，也可能没有产生对公司而言任何有意义的价值。

168大数据经作者授权发布，转载请征得作者和168大数据的同意，一切未经同意的转载均视为侵权。

原文地址：http://www.jianshu.com/p/4668665 ... e&utm_source=qq