豆瓣研发管理的三板斧：规则、考核和激励

本篇文章3123字，读完约8分钟

编者按:基于豆瓣的研发管理哲学，本文主要讨论了如何为团队设定规则，如何传递价值观，如何正确设定激励策略，以及如何评估工程师。作者当年的段念原文来自微信公众账号聊天架构(身份证号:archtime)，36kr授权转载。

豆瓣的研发管理理念是基于一系列的约束和规则，其中约束是根本，规则是基于约束而制定的。我们有三个基本限制:

最终的评估标准取决于对产品线的贡献

以正确的方式做事

必须有技术目标

第一点也可以说是绩效认可的原则，即什么样的绩效可以被认可。1000行代码不是性能，而是什么是性能。或者，如果你没有直接为你的企业做贡献，但是你提高了你的生产力，这很重要。

第二点是不要接受低质量的代码。优秀的工程师天生就有品味。

第三点也可以说是我们要求成员追求代码。如果我们雇佣一个人，如果他只把工作当成一项任务，对提高自己的技能缺乏热情，那么即使他擅长，我们也会拒绝。这些人可能只关注绩效，而不是如何更聪明、更高效地做事。

基于这三个约束，我们制定了一些规则，这将导致其他规则，每个团队也将产生自己的规则。

例如，所有代码都可以审查，这是一个一般规则。这个规则需要工具的支持，这是开发代码的初衷。我们的代码审查是一个相对独立的过程，既不是从上到下，也不是从下到上。基本上，每个团队中会形成一两个代码整洁的人，他们将成为发现低质量代码的人。

在代码评审形成了代码平台之后，其他规则也随之产生，如在合并代码之前执行ci、创建分支、提交代码等。当然，这也需要工具的支持。代码作为一个平台，可以很好地适应这些实现规则。

在每个团队中，比如项目经理和工程师，他们可以有不同的规则。一些团队已经建立了20%的时间不进行功能开发的规则，并特别使用这20%的时间来进行产生长期价值的开发，例如弥补技术债务。有些团队每次都通过协商来分配无形的工作量。所有这些都来自团队的技术追求。

一般来说，约束是不可改变的，规则是可以调整的。

如何制定规则

管理3.0说一个好的经理绝不是游戏规则的制定者。我们倾向于让团队成员以民主的方式形成他们自己的团队规则，所以我尽量不去干涉。当然，在团队开发的早期阶段，你也可以尝试为它设置一些规则，但是你会发现这些规则很快就会被团队内部产生的新规则所取代。

作为管理者，我们不能不设计游戏这样的规则，但这是不可能的，我们不应该这样做。我们应该强调约束，定义规则的边界，确保规则和约束之间没有冲突。

有些公司更注重员工的一致性，尤其是意识形态的一致性和统一的价值观，我不同意。我认为统一我们的思想是没有意义的。所谓的共识大致有三个层次:

愿景。意思是“做什么和不做什么”。例如，如果你在页面上放广告，你会有自己的观点。

价值观。是“如何做事”，在愿景下，通过规则和约束来体现。我不认为价值观是贴在墙上的东西——它们贴在墙上的次数越多，重复的次数就越少。

规则和约束。这是在行为层面。规则是容易复制的东西，比如开发过程。当你看到每个人都提交了一个拉请求，你可以很容易地遵循它。在这个过程中，价值观得到了加强。

就我而言，我更喜欢每个人在行为上保持一致，而不是在思想上追求一致。制定规则的过程应该是民主的。这个过程需要冲突、碰撞和妥协——因为每个人的想法都不一致；规则一旦确立，每个人都会遵守。

如何鼓励跨团队协作和共享

当豆瓣最早只有20多人的时候，那时没有子产品线，所有的任务都在一个池中，并在trac上公开上市，所以每个人都选择自己做。当然，当时有一些限制，例如，约定是“维护您自己的代码”。2009年后，为了解决工程师的归属感和保持小团队快速反应，产品线发生了变化。在产品线模式下，工程师的工作范围是相对固定的，而不是像以前那样走在一个普通的水池里。

这样，工程师之间的横向联系被削弱了，好的经验、系统和原则不能在产品线之间共享；与此同时，工程师们自己被限制在一条生产线上，这将是很长一段时间的无聊。

所以去年，我们投入了大量精力来促进跨团队协作。起初，这种做法是建立一个公共游泳池，让个人有更多的机会展示自己的成就，但效果并不特别好。现在我们关注的是绩效规则，这样跨团队的贡献就可以被豆瓣绩效系统所认可。虽然不能说它比去年的尝试更好，但它比去年的尝试更合适。

激励机制

我们对激励机制的使用非常谨慎。一方面，你应该表明你已经看到并关心员工所做的贡献；另一方面，你应该避免事情因为过度的动机而恶化，并把自发的行为转变成为动机而做的事情。

去年，我们的一名员工自发地清理了数据库中无用的数据，并花费了大量的空闲时间，这大大提高了数据库的访问速度。那么，他应该得到奖金吗？显然，这是一个值得鼓励的宝贵贡献，但立即现金奖励不是最好的方式。因为这种直接的现金奖励很可能导致事情的动机发生变化。还有分享。我们也考虑过让分享成为一个积分系统，但是我们非常担心这是否会把一个内部驱动的东西变成一个外部驱动的东西——你不分享而没有积分奖励吗？此外，如果你设置点，一些任务有更多的点，一些任务有更少的点，这将导致“选择工作”的问题。

如何平衡这件事的动机？我认为奖金和工资应该跟随着绩效考核，而不是为某个特定的事件支付奖金——这一方面会导致自发行为的恶化，另一方面也很容易不公平。对于员工自发做的好事，应该立即给予奖励，但他们不一定需要钱。代码的徽章系统是一个很好的即时激励机制——徽章意味着我已经看到了他的努力，它也可以展示给别人，可以很好的传播而不会对内部驱动力造成不良干扰。

评估系统主要解决如何评估工程师的问题。基本上没有具体的量化指标，主要基于两个基本点:一是与技术负责人面对面评估每个工程师。另一个是开放的，即所有工程师的评价基础都是开放的。我们每六个月做一次评估，每次三天，五六个技术负责人一起讨论，甚至pk，各种原因都一一通过。现在我需要参与所有的评估。整个开发团队有130多人。我基本上需要每个人都去做。今后，我希望评估过程能够转变为一个委员会。

然而，我不认为绩效评估是评估中最重要的部分。评价最重要的部分应该是目标设定和定期检查，它有许多内容，如如何授权和如何选择目标。管理者管理的对象不是人，而是系统:对于团队系统来说，如何使团队认识到大的目标和约束，如何使团队有能力形成自己的规则，并使这些规则与目标相协调，这是团队管理者应该注意的。对于人的管理来说，管理者最多只能达到激励机制的水平，然后把事情分配给人是不合适的。只要团队有自己的目标，它就会自发地前进，你不需要注意团队实际上是如何做到的。

市场上的许多管理理论现在都有自己的重点，比如kpi或奖金。事实上，你会发现许多理论都有冲突，因为它们没有把整个公司考虑在内，而是只看某个层次和某个部分。这一部分衍生出一套管理理论，看起来很合理，但如果你真的想把它付诸实践，很多理论都只是“看起来很美”。

最后，我推荐两本书:一本是管理3.0，它提供了一个好的框架和管理者需要考虑的维度。尽管这本书的作者为了配合“复杂理论下的管理”这一颠覆性主题，在提到许多经典管理理论中也存在的概念时，故意使用了一些不同的名称或描述——从这一点来看，作者有点“故弄玄虚”，但这本书仍然是一本好书。管理3.0中提到的复杂性理论知识可以在梅勒妮的《复杂性》一书中找到，该书介绍了复杂领域中的许多基本理论，如细胞自动机、蚁群、混沌理论、非图灵机、生物信息学工程等。，这对理解复杂系统非常有帮助。当然，如果你想了解更多复杂的理论，你不能错过侯世达的书。

这篇文章由读者提交，并不代表36英寸的立场。如有转载，请注明出处

“读完这篇文章还不够吗？如果你也开始创业，希望你的项目被报道，请点击这里告诉我们！”