豆瓣的研发管理

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

嘉宾简介

段念，现任豆瓣网工程副总裁。80 年代开始接触编程（BASIC），在个人兴趣的支持下进入软件行业，先后在华为、新太科技等企业任职，后加入 Google 中国。在软件开发、测试、软件团队管理等多个领域都有所涉及，近期关注的重点是团队建设，工程师文化推进。对于能够提升团队生产率和个人技能的方法感兴趣。

概况

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

1. 最终的评价标准取决于对产品线的贡献
2. 以正确的方式做事
3. 要有技术目标

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

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

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

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

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

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

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

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

规则如何制定

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

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

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

1. 愿景。就是“什么该做什么不该做”。比如往页面上放广告，这事儿该不该做，大家会有自己的看法。
2. 价值观。就是“应该怎样做事”，在愿景之下，通过规则和约束体现出来。我觉得价值观不是贴在墙上的东西——越是贴在墙上反复念叨的，一般都是越没有的东西。
3. 规则与约束。这是在行为层面。规则是一个很容易被复制的东西，比如开发流程，你看到大家都用 pull request 提交，你也很容易跟着这样做。在这个过程中，价值观得到了强化。

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

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

最早豆瓣只有 20 多个人的时候，当时还没有分产品线，所有的任务都在一个池子里，公开列在 Trac 上，大家选择感兴趣的自己去做。当然，那时候也有一些约束，例如一个惯例是“自己维护自己的代码”。09 年以后为了解决工程师的归属感，以及保持小团队快速响应，改成了产品线的方式。在产品线方式下，工程师的工作范围相对固定，而不像以前那样走一个公共的池子。

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

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

激励机制

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

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

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

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

不过，我认为绩效评估并不是考评最重要的部分。考评最重要的部分应该是目标设定与定期检查，这里面内容就多了，比如如何授权、如何进行目标选择等等。管理者管理的对象不是人，而是系统：对于团队这一个系统，你如何让团队认可大的目标和约束，如何让团队有能力形成自己的规则，让这些规则与目标调和，这是团队管理者应该关注的事情。对于人的管理，管理者最多只应该做到激励机制这个层面，再往下给人分配事情就不合适了。团队自己只要有了目标，就会自发的往前走，你不需要去关注团队具体是怎么去做的。

现在市面上很多管理学的理论，都有各自强调的点，比如 KPI 或者奖金，其实你会发现很多理论之间是冲突的，因为他们没有把公司整体纳入考量，而是只看到某一个层面，一个部分，就着这一个部分衍生出一套管理理论，看起来很有道理，但真要实践起来，其中不少都仅仅是”看上去很美“而已。

最后推荐两本书：一本是我刚才提到的《管理 3.0》，里面提供了很好的框架和管理者需要考量的维度。虽然这本书的作者为了贴合“复杂理论下的管理”这个“颠覆性”的主题，在提到不少经典管理理论中也存在的概念时，故意用一些不同的名字或是描述方式——从这一点上说作者有点“故弄玄虚”，但书仍然是好书。《管理 3.0》提到的复杂性理论的知识可以从梅拉妮的《复杂》一书中找到，《复杂》这本书介绍了很多复杂领域的基本理论，比如细胞自动机、蚁群、混沌理论、非图灵机、生物信息工程等，对理解复杂系统有很大帮助。当然，要对复杂理论有更多了解的话，侯世达的书是不能错过的。

采访人简介

庄表伟，目前在华为 2012 实验室的研发能力中心工作。也是 80 年代中期就开始接触计算机和编程，一直对软件开发、技术社区、开源软件等抱有浓厚的兴趣。近期关注的重点是：如何将开源社区的经验，应用于企业内部实践。

感谢杨赛对本文的审校。另，段念是 2014 年 QCon 北京团队文化专题的出品人，有兴趣跟他沟通的同学可以留意大会相关信息。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。