-------------
reprint http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650993132&idx=1&sn=8c5c8f51805907dfec9dd937bec7a4e8&scene=23&srcid=0705LnR7hYJqe09NnEg1CaNn#rd
-------------
Well said, looks very attentive
“ How to set rules for teams? How to transmit values? How to set incentive strategy just right? How to evaluate engineers?
Introduction of the old driver
Duan Nian ,the current Vice President of Huaxia Xincai and CEO of Internet Finance Brand, former CTO of Yirendai, Vice President of Engineering of Douban.com, EGO member. In the 1980s, he began to contact programming (BASIC) and entered the software industry with the support of his personal interests. He worked in Huawei, Xintai Technology and other companies successively, and then joined Google China. It is involved in many fields such as software development, testing, software team management, etc. The recent focus is on team building and the promotion of engineer culture. Interested in ways to improve team productivity and individual skills.
Overview
Douban's R&D management concept is based on a series of constraints and rules, of which constraints are fundamental, and rules are formulated based on constraints. Our basic constraints are three:
The final evaluation criteria depend on the contribution to the product line
do things the right way
have technical goals
The first point can also be said to be the principle of performance recognition , that is, what kind of performance can be recognized. 1000 lines of code is not performance, what it brings is performance. Or if you don't contribute directly to the business, but increase productivity, that counts.
The second point is mainly about not accepting low quality code . Taste is a natural part of a good engineer.
The third point can also be said that we require members to have the pursuit of code . If we recruit a person, if he only regards work as a task and lacks enthusiasm for improving his own technology, then no matter how good his skills are, we will refuse. Such people may focus solely on performance and not on how to do things smarter and more efficiently.
Based on these three constraints, we have formulated some rules, and these rules will derive other rules, and each team will also generate its own rules within itself.
For example, all code can be reviewed, this is a general rule . This rule requires the support of tools, which is the original intention of our development of CODE. Our code review is a relatively autonomous process, not top-to-bottom, nor bottom-to-top. Basically, one or two people with code cleanliness will form within each team, and they will become the person who finds low-quality code.
After the code review forms the CODE platform, other rules are derived, such as executing CI before merge code, as well as rules for creating branches, rules for submitting code, and so on. Of course, this also requires the support of tools. CODE as a platform can accommodate these implementation rules very well.
Within each team, such as how PMs and engineers do division of labor, they can have their own different rules . Some teams have established a rule of not doing functional development for 20% of their time, and dedicated this 20% of their time to development that generates long-term value, such as making up technical debt. Some teams take a negotiation-by-negotiation approach to distribute unseen workloads. These all come from the technical pursuit of the team.
In general, constraints are immutable and rules can be adjusted.
How the rules are made
The book "Management 3.0" says: A good manager is never a rule maker. We tend to let the team members themselves democratically form the rules of their own team, and I try not to get involved. Of course, you can try to set some rules for it early in the development of the team, but you will find that these rules are quickly replaced by new rules generated within the team.
作为管理者，我们会忍不住像游戏一样去设计规则，但这是不可能的，我们也不应该这样做。我们应该去强调约束，定义规则的边界，确保规则跟约束没有冲突。
有些公司比较看重员工的一致性，尤其是思想上的一致性，统一的价值观，这点我是不认可的。我觉得统一思想这件事毫无意义。所谓共识，大致有三个层次：
愿景。就是“什么该做什么不该做”。比如往页面上放广告，这事儿该不该做，大家会有自己的看法。
价值观。就是“应该怎样做事”，在愿景之下，通过规则和约束体现出来。我觉得价值观不是贴在墙上的东西——越是贴在墙上反复念叨的，一般都是越没有的东西。
规则与约束。这是在行为层面。规则是一个很容易被复制的东西，比如开发流程，你看到大家都用pull request提交，你也很容易跟着这样做。在这个过程中，价值观得到了强化。
对于我来说，我更愿意大家在行为上一致，而不去追求思想上的一致。规则创建的过程应该是民主的，这个过程需要有冲突，有碰撞，有妥协——因为大家的思想并不一致；而规则一旦建立，则人人遵守规则。
如何激励跨团队协作与分享
最早豆瓣只有20多个人的时候，当时还没有分产品线，所有的任务都在一个池子里，公开列在Trac上，大家选择感兴趣的自己去做。当然，那时候也有一些约束，例如一个惯例是“自己维护自己的代码”。09年以后为了解决工程师的归属感，以及保持小团队快速响应，改成了产品线的方式。在产品线方式下，工程师的工作范围相对固定，而不像以前那样走一个公共的池子。
这样一来就弱化了工程师之间的横向联系，好的经验、体系、原则无法跨产品线共享；同时，工程师自己也被限制在了一个产品线之内，时间长了会觉得没意思。
所以在去年，我们用很大精力去推动跨团队的协作。一开始的做法是建立公共池，给个人成果更多展示的机会，但是没有特别好的效果。现在我们把注意力放在绩效规则上，让跨团队的贡献能够被豆瓣绩效体系识别，虽然也不能说就好了很多，但相比去年的尝试更加适合一些。
激励机制
我们对激励机制的使用非常谨慎。一方面你要表示自己看到了员工做的贡献、在意他的贡献，另一方面你又要避免激励过度而导致事情变质，把自发的行为变成了为激励去做一件事情。
去年，我们有个员工自发地清理了数据库中的无用数据，投入了很多业余时间，让数据库访问速度大大提升。那么，该不该给他发奖金？显然，这是一个很有价值的，应该鼓励的贡献，但立即的现金奖励并非是最好的方式。因为这种直接的现金奖励很可能会导致事情的动机发生变化。
还有分享也是，我们也考虑过把分享做成一个积分体系，但我们非常在意这样会不会把一个内部驱动的事情变质成了外部驱动——难道没有积分奖励大家就不分享了吗？而且你设置了积分，有的任务积分多，有的任务积分少，又会导致“挑活儿”的问题。
激励这件事情要如何做的平衡？我觉得奖金、工资最好跟着绩效考核走，而不能针对具体某个事件来发奖金——会导致自发行为变质是一方面，另一方面也很容易不公平。对于员工自发做的好事，即时激励是应该的，但未必要用金钱。CODE的徽章系统就是一个不错的即时激励机制——徽章代表我看到了他的努力，同时也可以展示给别人看，可以有很好的传播，又不会对内部驱动力造成不良干扰。
评估制度主要解决如何评价工程师的问题。我们基本上没有设置特别具体的量化指标，主要是两个基本点：一个是面对面，跟tech lead面对面评估每一个工程师。另一个是公开，就是所有工程师的评估依据都是公开的。
我们每半年做一次评估，每次3天时间，5、6个tech lead，大家一起讨论，甚至PK，各种理由一条一条的过。现在所有的评估我自己都需要参与，整个开发团队现在130多人，我基本上需要每个人都过，今后长期发展，我希望评估的流程能转变成委员会的形式。
不过，我认为绩效评估并不是考评最重要的部分。考评最重要的部分应该是目标设定与定期检查，这里面内容就多了，比如如何授权、如何进行目标选择等等。管理者管理的对象不是人，而是系统：对于团队这一个系统，你如何让团队认可大的目标和约束，如何让团队有能力形成自己的规则，让这些规则与目标调和，这是团队管理者应该关注的事情。
对于人的管理，管理者最多只应该做到激励机制这个层面，再往下给人分配事情就不合适了。团队自己只要有了目标，就会自发的往前走，你不需要去关注团队具体是怎么去做的。
现在市面上很多管理学的理论，都有各自强调的点，比如KPI或者奖金，其实你会发现很多理论之间是冲突的，因为他们没有把公司整体纳入考量，而是只看到某一个层面，一个部分，就着这一个部分衍生出一套管理理论，看起来很有道理，但真要实践起来，其中不少都仅仅是”看上去很美“而已。
最后推荐两本书：一本是我刚才提到的《管理3.0》，里面提供了很好的框架和管理者需要考量的维度。虽然这本书的作者为了贴合“复杂理论下的管理”这个“颠覆性”的主题，在提到不少经典管理理论中也存在的概念时，故意用一些不同的名字或是描述方式——从这一点上说作者有点“故弄玄虚”，但书仍然是好书。
《管理3.0》提到的复杂性理论的知识可以从梅拉妮的《复杂》一书中找到，《复杂》这本书介绍了很多复杂领域的基本理论，比如细胞自动机、蚁群、混沌理论、非图灵机、生物信息工程等，对理解复杂系统有很大帮助。当然，要对复杂理论有更多了解的话，侯世达的书是不能错过的。