本文基于莊表偉跟豆瓣工程副總裁段念的一次溝通整理而成，雙方主要探討了如何給團隊設(shè)置規(guī)則、如何傳輸價值觀、如何恰到好處的設(shè)置激勵策略、如何考核工程師等話題。

嘉賓簡介

段念，現(xiàn)任豆瓣網(wǎng)工程副總裁。80年代開始接觸編程（BASIC），在個人興趣的支持下進入軟件行業(yè)，先后在華為、新太科技等企業(yè)任職，后加入Google中國。在軟件開發(fā)、測試、軟件團隊管理等多個領(lǐng)域都有所涉及，近期關(guān)注的重點是團隊建設(shè)，工程師文化推進。對于能夠提升團隊生產(chǎn)率和個人技能的方法感興趣。

概況

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

1. 最終的評價標準取決于對產(chǎn)品線的貢獻
2. 以正確的方式做事
3. 要有技術(shù)目標

第一點也可以說是績效認可原則，也就是什么樣的績效能夠被認可。1000行代碼不是績效，帶來了什么才是績效?；蛘呷绻銢]有對業(yè)務(wù)直接貢獻，但提高了生產(chǎn)力，這個也算。

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

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

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

比如，所有的代碼都可以被review，這是一個總體的規(guī)則。這條規(guī)則需要工具的支持，這也是我們開發(fā)CODE的初衷。我們的代碼review是一個相對自治的過程，不是從上到下，也不能算是從下到上?；旧希總€團隊內(nèi)部會形成一兩個有代碼潔癖的人，他們就成了發(fā)現(xiàn)低質(zhì)量代碼的人這樣一個角色。

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

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

總體而言，約束是不變的，規(guī)則是可以調(diào)整的。

規(guī)則如何制定

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

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

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

1. 愿景。就是“什么該做什么不該做”。比如往頁面上放廣告，這事兒該不該做，大家會有自己的看法。
2. 價值觀。就是“應(yīng)該怎樣做事”，在愿景之下，通過規(guī)則和約束體現(xiàn)出來。我覺得價值觀不是貼在墻上的東西——越是貼在墻上反復(fù)念叨的，一般都是越?jīng)]有的東西。
3. 規(guī)則與約束。這是在行為層面。規(guī)則是一個很容易被復(fù)制的東西，比如開發(fā)流程，你看到大家都用pull request提交，你也很容易跟著這樣做。在這個過程中，價值觀得到了強化。

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

如何激勵跨團隊協(xié)作與分享

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

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

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

激勵機制

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

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

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

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

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

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

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

采訪人簡介

莊表偉，目前在華為2012實驗室的研發(fā)能力中心工作。也是80年代中期就開始接觸計算機和編程，一直對軟件開發(fā)、技術(shù)社區(qū)、開源軟件等抱有濃厚的興趣。近期關(guān)注的重點是：如何將開源社區(qū)的經(jīng)驗，應(yīng)用于企業(yè)內(nèi)部實踐。