微信号:infoqchina

介绍:有内容的技术社区媒体

豆瓣的研发管理

2014-03-27 18:37 段念

本文基于庄表伟跟豆瓣工程副总裁段念的一次沟通整理而成,双方主要探讨了如何给团队设置规则、如何传输价值观、如何恰到好处的设置激励策略、如何考核工程师等话题。


概况


豆瓣的研发管理理念建立在一系列约束与规则之上,其中约束是根本,规则基于约束去制定。我们的基本约束有三条:

  1. 最终的评价标准取决于对产品线的贡献

  2. 以正确的方式做事

  3. 要有技术目标


第一点也可以说是绩效认可原则,也就是什么样的绩效能够被认可。1000行代码不是绩效,带来了什么才是绩效。或者如果你没有对业务直接贡献,但提高了生产力,这个也算。


第二点主要是不接受低质量的代码。品味是好的工程师天然就有的。


第三点也可以说是我们要求成员有对代码的追求。如果我们招聘一个人,他如果只是把工作当成一项任务,对提升自己的技术这件事本身缺乏热情,那么哪怕他技术再好,我们也会拒绝。这样的人可能会仅仅关注绩效,而不关注如何更聪明、更有效率的做事。


基于此三点约束,我们制定了一些规则,这些规则又会衍生出其他规则,同时各个团队自己内部也会产生自己的规则。


比如,所有的代码都可以被review,这是一个总体的规则。这条规则需要工具的支持,这也是我们开发CODE的初衷。我们的代码review是一个相对自治的过程,不是从上到下,也不能算是从下到上。基本上,每个团队内部会形成一两个有代码洁癖的人,他们就成了发现低质量代码的人这样一个角色。


代码review在形成CODE这个平台之后,又衍生出了其他的规则,比如在merge代码前执行CI,还有创建分支的规则,提交代码的规则等等。当然,这也需要工具的支持。CODE作为平台,可以很好地容纳这些实现规则。


各个团队内部,如PM与工程师如何做分工,他们可以有各自不同的规则。有些团队则建立了20%的时间不做功能开发的规则,专门用这20%的时间做产生长期价值的开发,比如补技术债。有些团队则采取每次协商的方式来分配不可见的工作量。这些都来源于团队的技术追求。


总体而言,约束是不变的,规则是可以调整的。


规则如何制定


《管理3.0》这本书里说:好的管理者绝不是游戏规则制定者。我们倾向于让团队成员自己以民主的方式形成自己团队的规则,我尽量不插手。当然,在团队发展早期,你也可以尝试为它设置一些规则,但你会发现这些规则很快就会被团队内部产生的新规则所替代。


作为管理者,我们会忍不住像游戏一样去设计规则,但这是不可能的,我们也不应该这样做。我们应该去强调约束,定义规则的边界,确保规则跟约束没有冲突。


有些公司比较看重员工的一致性,尤其是思想上的一致性,统一的价值观,这点我是不认可的。我觉得统一思想这件事毫无意义。所谓共识,大致有三个层次:


  1. 愿景。就是“什么该做什么不该做”。比如往页面上放广告,这事儿该不该做,大家会有自己的看法。

  2. 价值观。就是“应该怎样做事”,在愿景之下,通过规则和约束体现出来。我觉得价值观不是贴在墙上的东西——越是贴在墙上反复念叨的,一般都是越没有的东西。

  3. 规则与约束。这是在行为层面。规则是一个很容易被复制的东西,比如开发流程,你看到大家都用pull request提交,你也很容易跟着这样做。在这个过程中,价值观得到了强化。

对于我来说,我更愿意大家在行为上一致,而不去追求思想上的一致。规则创建的过程应该是民主的,这个过程需要有冲突,有碰撞,有妥协——因为大家的思想并不一致;而规则一旦建立,则人人遵守规则。


如何激励跨团队协作与分享


最早豆瓣只有50多个工程师的时候,当时还没有分产品线,所有的任务都在一个池子里,公开列在一个黑板上,大家感兴趣的自己去做。后来慢慢地形成了一些重点产品线,这些产品线需要更专注的投入——换句话说,需要在工程师的时间投入和质量上有所约束,因此就形成了各个产品组,而不能像以前那样走一个公共的池子。


这样一来就弱化了工程师之间的横向联系,好的经验、体系、原则无法跨产品线共享;同时,工程师自己也被限制在了一个产品线之内,时间长了会觉得没意思。


所以在去年,我们用很大精力去推动跨团队的协作。一开始的做法是建立公共池,给个人成果更多展示的机会,但是没有特别好的效果。现在我们把注意力放在绩效规则上,让跨团队的贡献能够被豆瓣绩效体系识别,虽然也不能说就好了很多,但相比去年的尝试更加适合一些。


激励机制


我们对激励机制的使用非常谨慎。一方面你要表示自己看到了员工做的贡献、在意他的贡献,另一方面你又要避免激励过度而导致事情变质,把自发的行为变成了为激励去做一件事情。


去年,我们有个员工自发地清理了数据库中的无用数据,投入了很多业余时间,让数据库访问速度大大提升。那么,该不该给他发奖金?显然,这是一个很有价值的,应该鼓励的贡献,但立即的现金奖励并非是最好的方式。因为这种直接的现金奖励很可能会导致事情的动机发生变化。还有分享也是,我们也考虑过把分享做成一个积分体系,但我们非常在意这样会不会把一个内部驱动的事情变质成了外部驱动——难道没有积分奖励大家就不分享了吗?而且你设置了积分,有的任务积分多,有的任务积分少,又会导致“挑活儿”的问题。


激励这件事情要如何做的平衡?我觉得奖金、工资最好跟着绩效考核走,而不能针对具体某个事件来发奖金——会导致自发行为变质是一方面,另一方面也很容易不公平。对于员工自发做的好事,即时激励是应该的,但未必要用金钱。CODE的徽章系统就是一个不错的即时激励机制——徽章代表我看到了他的努力,同时也可以展示给别人看,可以有很好的传播,又不会对内部驱动力造成不良干扰。


评估制度主要解决如何评价工程师的问题。我们基本上没有设置特别具体的量化指标,主要是两个基本点:一个是面对面,跟tech lead面对面评估每一个工程师。另一个是公开,就是所有工程师的评估依据都是公开的。我们每半年做一次评估,每次3天时间,5、6个tech lead,大家一起讨论,甚至PK,各种理由一条一条的过。现在所有的评估我自己都需要参与,整个开发团队现在130多人,我基本上需要每个人都过,今后长期发展,我希望评估的流程能转变成委员会的形式。


之后段念还介绍了他对绩效评估的态度。更多精彩内容,请点击阅读原文。


***********************************

本文来自InfoQ微信公众账号:infoqchina

1、回复“今日新闻”,查看今天更新的新闻;

2、回复“今日英文”,查看今天英文站的更新;

3、回复“文章 +关键词”,搜索关键词相关内容;

4、回复“QCon”,了解QCon大会相关信息;

5、回复“活动”,了解最近InfoQ组织的线下沙龙;

6、回复“架构师”,获取《架构师》下载地址;

7、回复“投稿”,了解投稿和加入编辑团队的流程。

***********************************

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 给女朋友的 iOS 开发 7 AutoLayout 入门产品经理如何分析设计一个产品 Linux命名空间入门(一) UTS命名空间 React系列之(二)-React组件的生命周期 街访:美女眼中的IT程序员?(尺度有点大)