編者按：本文基于豆瓣的研發管理理念，主要探討了如何給團隊設置規則、如何傳輸價值觀、如何恰到好處的設置激勵策略、如何考核工程師等話題。本文作者 那年的段念，原文來自微信公眾號 聊聊架構(ID：archtime)，36kr 經授權轉載。

　　豆瓣的研發管理理念建立在一系列約束與規則之上，其中約束是根本，規則基于約束去制定。我們的基本約束有三條：

　　最終的評價標準取決于對產品線的貢獻

　　以正確的方式做事

　　要有技術目標

　　第一點也可以說是績效認可原則，也就是什么樣的績效能夠被認可。1000 行代碼不是績效，帶來了什么才是績效。或者如果你沒有對業務直接貢獻，但提高了生產力，這個也算。

　　第二點主要是不接受低質量的代碼。品味是好的工程師天然就有的。

　　第三點也可以說是我們要求成員有對代碼的追求。如果我們招聘一個人，他如果只是把工作當成一項任務，對提升自己的技術這件事本身缺乏熱情，那么哪怕他技術再好，我們也會拒絕。這樣的人可能會僅僅關注績效，而不關注如何更聰明、更有效率的做事。

　　基于此三點約束，我們制定了一些規則，這些規則又會衍生出其他規則，同時各個團隊自己內部也會產生自己的規則。

　　比如，所有的代碼都可以被 review，這是一個總體的規則。這條規則需要工具的支持，這也是我們開發 CODE 的初衷。我們的代碼 review 是一個相對自治的過程，不是從上到下，也不能算是從下到上。基本上，每個團隊內部會形成一兩個有代碼潔癖的人，他們就成了發現低質量代碼的人這樣一個角色。

　　代碼 review 在形成 CODE 這個平臺之后，又衍生出了其他的規則，比如在 merge 代碼前執行 CI，還有創建分支的規則，提交代碼的規則等等。當然，這也需要工具的支持。CODE 作為平臺，可以很好地容納這些實現規則。

　　各個團隊內部，如 PM 與工程師如何做分工，他們可以有各自不同的規則。有些團隊則建立了 20%的時間不做功能開發的規則，專門用這 20%的時間做產生長期價值的開發，比如補技術債。有些團隊則采取每次協商的方式來分配不可見的工作量。這些都來源于團隊的技術追求。

　　總體而言，約束是不變的，規則是可以調整的。

　　規則如何制定

　　《管理 3.0》這本書里說：好的管理者絕不是游戲規則制定者。我們傾向于讓團隊成員自己以民主的方式形成自己團隊的規則，我盡量不插手。當然，在團隊發展早期，你也可以嘗試為它設置一些規則，但你會發現這些規則很快就會被團隊內部產生的新規則所替代。

　　作為管理者，我們會忍不住像游戲一樣去設計規則，但這是不可能的，我們也不應該這樣做。我們應該去強調約束，定義規則的邊界，確保規則跟約束沒有沖突。

　　有些公司比較看重員工的一致性，尤其是思想上的一致性，統一的價值觀，這點我是不認可的。我覺得統一思想這件事毫無意義。所謂共識，大致有三個層次：

　　愿景。就是 “什么該做什么不該做”。比如往頁面上放廣告，這事兒該不該做，大家會有自己的看法。

　　價值觀。就是 “應該怎樣做事”，在愿景之下，通過規則和約束體現出來。我覺得價值觀不是貼在墻上的東西越是貼在墻上反復念叨的，一般都是越沒有的東西。

　　規則與約束。這是在行為層面。規則是一個很容易被復制的東西，比如開發流程，你看到大家都用 pull request 提交，你也很容易跟著這樣做。在這個過程中，價值觀得到了強化。

　　對于我來說，我更愿意大家在行為上一致，而不去追求思想上的一致。規則創建的過程應該是民主的，這個過程需要有沖突，有碰撞，有妥協因為大家的思想并不一致；而規則一旦建立，則人人遵守規則。

　　如何激勵跨團隊協作與分享

　　最早豆瓣只有 20 多個人的時候，當時還沒有分產品線，所有的任務都在一個池子里，公開列在 Trac 上，大家選擇感興趣的自己去做。當然，那時候也有一些約束，例如一個慣例是 “自己維護自己的代碼”。09年 以后為了解決工程師的歸屬感，以及保持小團隊快速響應，改成了產品線的方式。在產品線方式下，工程師的工作范圍相對固定，而不像以前那樣走一個公共的池子。

　　這樣一來就弱化了工程師之間的橫向聯系，好的經驗、體系、原則無法跨產品線共享；同時，工程師自己也被限制在了一個產品線之內，時間長了會覺得沒意思。

　　所以在去年，我們用很大精力去推動跨團隊的協作。一開始的做法是建立公共池，給個人成果更多展示的機會，但是沒有特別好的效果。現在我們把注意力放在績效規則上，讓跨團隊的貢獻能夠被豆瓣績效體系識別，雖然也不能說就好了很多，但相比去年的嘗試更加適合一些。

　　激勵機制

　　我們對激勵機制的使用非常謹慎。一方面你要表示自己看到了員工做的貢獻、在意他的貢獻，另一方面你又要避免激勵過度而導致事情變質，把自發的行為變成了為激勵去做一件事情。

　　去年，我們有個員工自發地清理了數據庫中的無用數據，投入了很多業余時間，讓數據庫訪問速度大大提升。那么，該不該給他發獎金？顯然，這是一個很有價值的，應該鼓勵的貢獻，但立即的現金獎勵并非是最好的方式。因為這種直接的現金獎勵很可能會導致事情的動機發生變化。還有分享也是，我們也考慮過把分享做成一個積分體系，但我們非常在意這樣會不會把一個內部驅動的事情變質成了外部驅動難道沒有積分獎勵大家就不分享了嗎？而且你設置了積分，有的任務積分多，有的任務積分少，又會導致 “挑活兒” 的問題。

　　激勵這件事情要如何做的平衡？我覺得獎金、工資最好跟著績效考核走，而不能針對具體某個事件來發獎金會導致自發行為變質是一方面，另一方面也很容易不公平。對于員工自發做的好事，即時激勵是應該的，但未必要用金錢。CODE 的徽章系統就是一個不錯的即時激勵機制徽章代表我看到了他的努力，同時也可以展示給別人看，可以有很好的傳播，又不會對內部驅動力造成不良干擾。

　　評估制度主要解決如何評價工程師的問題。我們基本上沒有設置特別具體的量化指標，主要是兩個基本點：一個是面對面，跟 tech lead 面對面評估每一個工程師。另一個是公開，就是所有工程師的評估依據都是公開的。我們每半年做一次評估，每次 3 天時間，5、6 個 tech lead，大家一起討論，甚至 PK，各種理由一條一條的過。現在所有的評估我自己都需要參與，整個開發團隊現在 130 多人，我基本上需要每個人都過，今后長期發展，我希望評估的流程能轉變成委員會的形式。

　　不過，我認為績效評估并不是考評最重要的部分。考評最重要的部分應該是目標設定與定期檢查，這里面內容就多了，比如如何授權、如何進行目標選擇等等。管理者管理的對象不是人，而是系統：對于團隊這一個系統，你如何讓團隊認可大的目標和約束，如何讓團隊有能力形成自己的規則，讓這些規則與目標調和，這是團隊管理者應該關注的事情。對于人的管理，管理者最多只應該做到激勵機制這個層面，再往下給人分配事情就不合適了。團隊自己只要有了目標，就會自發的往前走，你不需要去關注團隊具體是怎么去做的。

　　現在市面上很多管理學的理論，都有各自強調的點，比如 KPI 或者獎金，其實你會發現很多理論之間是沖突的，因為他們沒有把公司整體納入考量，而是只看到某一個層面，一個部分，就著這一個部分衍生出一套管理理論，看起來很有道理，但真要實踐起來，其中不少都僅僅是” 看上去很美 “而已。

　　最后推薦兩本書：一本是我剛才提到的《管理 3.0》，里面提供了很好的框架和管理者需要考量的維度。雖然這本書的作者為了貼合 “復雜理論下的管理” 這個 “顛覆性” 的主題，在提到不少經典管理理論中也存在的概念時，故意用一些不同的名字或是描述方式從這一點上說作者有點 “故弄玄虛”，但書仍然是好書。《管理 3.0》提到的復雜性理論的知識可以從梅拉妮的《復雜》一書中找到，《復雜》這本書介紹了很多復雜領域的基本理論，比如細胞自動機、蟻群、混沌理論、非圖靈機、生物信息工程等，對理解復雜系統有很大幫助。當然，要對復雜理論有更多了解的話，侯世達的書是不能錯過的。