如何管理好研發團隊？

先介紹一下我們公司，我司是一個公司規模近200，研發佔一半的創業公司 Worktile。

我們的團隊一起開始也只有不到10個人，基本都是研發出身。對於研發管理這塊，多年來我們也總結了一些經驗，在這裡和大家分享一下：

什麼是研發團隊？簡單的說，就是由你熟悉的那幫穿格子襯衫程式設計師為核心組成的團隊，就是研發團隊。

本來，你以為格子男們是很乖很悶騷的那種，管理和協作起來比銷售和業務簡單很多，而實際情況是，格子男們並不那麼容易管理，面向程式碼世界的複雜度，可能遠比面向財物世界的複雜度還要高。

作為致力於團隊協作的公司，我們研究了很多國內和海外牛逼公司的研發模式和研發管理，

例如OKR在谷歌、Facebook的應用，Uber的高效會議制度，阿里的績效體系，騰訊的產品流程。

除了在自身團隊做了N次不同的試驗和反思，我們也將很多不錯的經驗分享到客戶和使用者，所以本文試圖將Worktile的研發管理全景圖做一個概括性的闡述。

要談清楚方法，就先了解清楚問題，研發管理之所以令人頭疼，核心的問題無外乎以下一些方面。

研發管理的典型問題

1. 難以KPI化和考核

任正非有句名言：錢分好了，管理的大部分問題就解決了。我對此深表同意，可問題是，怎麼能分好錢確實非常考驗能力、經驗和智力的。研發之難，恰恰難在無法KPI化工作本身，所有那些試圖KPI化工程師和碼農的做法，最終結果都啼笑皆非、面目可憎、吃力不討好。在我過去經歷，還有客戶實際的研發管理裡，試圖KPI化研發工作一直是不同團隊努力的嘗試，包括和不限於以下方式：

解決Bug數

SLA

功能完成度

加班，007就比996牛逼，996就比955更值得獎勵

營收捆綁

NPS

這些看起來可以數字化的指標，除了證明研發管理者透過偷懶的方式做績效考核外，可以說毫無價值，也無法給公司和組織帶來正向的激勵。

2. 離程式碼很近，離使用者很遠

另外一個現實且無奈的問題是，工程師和產品經理好像是在象牙塔裡做產品和研發，和使用者往往離得太遠太遠。這種問題帶來的傷害可能遠比其他事情來得更加徹底，但本質上這是研發規則上沒有解決好的問題，導致工程師本身並沒有任何的目標和動力去貼近使用者和客戶場景。

我們常常說要做使用者喜歡的產品，但那些反人類智商的產品，往往是產品經理和工程師合謀的結果。如果說研發管理的目標是提高效能，那麼首先同步研發團隊朝著統一的目標，就是效能管理最重要的第一步。

因此，以什麼樣的制度去驅動研發抬起頭來看客戶場景，是一切研發管理的核心工作之一。

3 .跨部門戰爭頻發

因為低頭幹活，所以往往研發團隊的目標和業務團隊的目標並不是一致的，研發體系和業務體系的跨部門戰爭，簡直罄竹難書：

業務認為，怎麼這麼多bug，一個小問題需要花這麼久的時間才能修復

而研發認為業務的智商不夠用，這麼好的產品就是無法準確傳達給客戶

業務面對客戶點頭哈腰；而研發覺得客戶是業務的客戶，不是研發的客戶

業務對需求排期是12345；而研發對需求排期往往是54321

業務給客戶承諾就像談戀愛，把星星摘下來也敢接著；研發認為你承諾的，你去寫程式碼實現吧

業務認為研發高工資吹著冷氣，自己天天跑在外面曬太陽；研發認為，業務提成那麼高，這產品是我做的，我咋沒提成呢

這種剪不斷、理還亂的關係，是很多公司的普遍現象。因為跨部門的不理解，必然帶來團隊之間的內耗，資訊的折扣和效率低下自然產生。而更重要的影響是跨部門戰爭造成對客戶服務與理解的偏差與推諉，沒有任何公司或者團隊能在一個不流暢的環境下成就對客戶的100%滿意度。

從研發管理全景圖說起

下面的研發全景圖，是我們團隊過去幾年逐步形成的研發管理經驗，其中主要包括以下內容：

研發管理的的核心是構建一個開放、自學習、自驅動的組織文化和儀式感，這是打造高效研發團隊最核心的基礎。

左邊是工具和方法，主要包括：以OKR驅動的目標管理，基於Scrum的敏捷，和逐步完善的DevOps。

右邊是制度和規則，核心包含：研發團隊的績效和考核、跨部門合作、其他儀式感驅動的各種規則，尤其是構建自學習的環境與分享機制。

打造開放與競合的組織架構和文化

一個組織要煥發活力、自驅動、使命必達的信念，開放而透明的文化是績效管理的核武器。總體來說，不管你的方法和制度多麼豐富和完善，無論如何也不可能驅動僵化、死板、沒有活力的團隊產生極其高效的價值。所以，我們在談研發效能的時候，注意力總集中在別人家的團隊是符合管理的，而忽略了團隊啟用的核心首先是塑造超強自由度、透明度和使命感的團隊文化。

從效率這個角度去看，沒有透明度的提效都是打折扣的，在一個組織裡效率低下的首要原因並不是執行力，而是透明度。需要層層審批和報備的組織，設定層層關卡和資訊圍牆的團隊，效率一定是非常低下的，單點的執行力提升並不改變整個團隊的低效基因。

所以，打造開放與競合的組織架構和文化，至關重要。

1. 特種部隊

如何設計研發團隊的組織架構，是個大大的思考題。我們團隊經歷過好幾次不同的組織形態，也經常性的將研發團隊，簡單說，一個研發團隊的角色主要是以下幾類：

產品經理

設計師

服務工程師端

前端工程師

測試

其他

以什麼樣的組織方式調配以上資源，是個非常考驗團隊管理的事情，例如很多公司會將設計團隊作為完全獨立的部門，其他團隊和專案按需調配設計資源，設計團隊就像公司的乙方角色，透過資源調配來匹配執行。而另一種形態則是廣泛存在於Facebook等網際網路公司的方式，設計、產品經理、開發、測試組成短小精悍的特種部隊，在研發團隊中以小組形態組合，就像一個研發業務的介面一樣，有清晰的輸入和清晰的輸出，有清晰的目標和清晰的邊界。顯然，打起仗來，特種部隊方式的小組，從執行到目標都是超級強悍的，也同時能方便研發組織績效考核的落地與激勵。

特種部隊的另一個好處是，每個小組的職能和目標是固定的，在產品研發大架構下執行一個精確的目標和單元。但小組成員可以轉崗或者調配到其他小組，從而避免了研發人員的枯燥和無挑戰的問題。

2。 儀式感

儀式感是團隊管理的調味品，也是必需品，就像你吃飯離不開鹽一樣。研發團隊管理者，例如CTO角色的人，需要有意識的在團隊中設計有價值的儀式感，來增加團隊磨合、默契與調味。好的儀式感，就像宗教儀式一樣，能不斷加強團隊目標的執行、文化的塑造以及階段的激勵。

例如，我們自己團隊就有很大儀式性的東西在執行：

OKR的階段同步

把重大版本釋出變成研發團隊的階段激勵

管理層的固定One One訪談

研發人員的每月訪談，同步到公司月報

花心思的團建

每月的產品考核

師徒制

走出去，參加各種外部的技術大會

。。。

還有很多其他的儀式和規則，並且以上幾乎每個規則都值得拿出來說道說道。

3。 使用者體驗委員會

在Worktile團隊，我們建立了組織架構之外的一些虛擬組織，虛擬組織的設計可以很好解決跨部門溝通與資訊同步的問題，以使用者體驗委員會為例，將公司裡研發、設計、產品、銷售、客戶成功的同事組成一個虛擬委員會。委員會主席本質上就是這個組織的秘書，透過定期的會議或者討論，將解決使用者體驗上的問題作為核心目標來解決。委員會的茶話會，每次都能高效推進很多方面的事情：

就使用者體驗的重大問題充分討論，產品和研發從不同視角收聽意見，銷售和客戶成功更多代表了來自一線使用者的建議。

促進跨部門的彼此理解，很多時候跨部門的戰爭，來自於互相的不理解和看不起。例如，我們在某次茶會中，就一個很久以來的核心需求做了討論，銷售端原本以為是一個簡單的需求，結果討論下來發現，這個簡單需求其實在客戶方也有非常不同的理解，完全推翻了產品已經草創的設計方案。反過來，銷售同事也完全理解了為何產品方案是如此之難的原因。

指定行動方案，快速驅動產品研發落實改進方案。使用者體驗委員會不是隻討論，更重要的是驅動行動方案，快速解決使用者關心的體驗問題。

4。 技術委員會

同樣在研發團隊，我們透過技術委員會來實現跨研發團隊的技術溝通、分享和技術選型。技術委員會保證了公司始終以科技驅動商業的基礎不被稀釋，匯聚團隊中技術能力最強的圈子更加自驅動的投入技術貢獻，主要的工作目標包括：

公司級的技術方案

前沿技術研發小組

研發崗的職級評審，技術委員會承擔對技術能力的職級評估

驅動公司技術進步和學習，例如組織駭客馬拉松、技術分享、對外技術輸出

向市場和銷售輸出技術內容

5。 研發下鄉

研發下鄉就是讓研發走向客戶，貼近客戶需求，瞭解客戶狀況，然後回來完善產品以滿足客戶需求。Worktile本身是企業服務產品，客戶需求在B端是及其複雜而多樣的，憋在辦公室是無法做出好產品的，所以需要從制度上驅動研發、產品和設計走向客戶，而不是待在象牙塔。

研發下鄉給了每個研發人員固定的指標，需要下鄉到客戶現場，所以銷售和客戶成功有了正當的理由要求研發同事完成指標，從另一個方面也加強了研發和業務部門的配合與協作，因為雙方有了共同KPI的時候，大家綁在一起去做好一件事的動力就變得很強。

6。 Polish Week

Polish Week是來自矽谷的流行文化，讓研發團隊在一個緊張迭代之後，有足夠的時間可以休息一下，然後集中火力解決來自客戶的需求或者問題，這種制度設計是非常高效的方法，可以短時間集中兵力解決遺留問題。

7。 技術分享和走出去

5年下來，我們技術團隊每週分享已經正常進行了幾百次，研發團隊中的每個人都或多或少完成過對於所在部門的技術分享。新人來到團隊，可以從過去數百次分享留下來的知識收穫非常多的遺留知識。

（在研發體系共享的技術分享池）

另外一方面，Worktile 的核心客戶本來就是研發團隊和工程師，市場維度需要研發人員能夠不斷共享有價值的技術內容，而技術分享機制恰恰提供了驅動工程師內容創作的土壤。每次內部分享的內容，其實完全可以繼續最佳化成外部可以傳播的內容，透過市場手段實現二次傳播，同時也能夠將團隊中有活力和分享精神的小夥伴，推到前臺去技術大會或者公司組織的技術分享大會分享。

基於OKR和Scrum的研發管理

源於業務關係，我們在N個不同的客戶場景做過測試，就是把團隊老大的目標在公司群裡做個調研，比較打臉的現實是，99%的情況下老大想的目標和執行層理解的目標不是一回事，而且大部分時候差別都非常大。因此，回到在研發團隊或者公司層執行OKR，本質上要解決的核心問題是：

上下同欲

俗話說，上下同欲者勝。

如果目標這件事都沒法達成一致，那麼一切效能和效率的最佳化都是無稽之談。因為你效率越高，但方向不對，可能偏離方向跑的更遠，這不是很尷尬的事情麼？

因此，我們可以通過了解OKR來在團隊形成一個基本的能力，這就是戰略同步和戰略溝通，從而實現目標統一這件事。

（想了解OKR的同學可以看看這個知識庫：OKR從認知到落地）

（OKR是戰略同步和戰略溝通工具，服務於團隊的使命和願景）

1. 寫好O和KR是執行OKR最難的第一步

在研發團隊落地OKR，本身並不是一件特別容易的事情，Worktile 團隊經歷了將近3年的反覆嘗試才逐漸找到OKR執行的感覺，而所有難點中，在開始階段是如何寫好你的O（目標）和KR（關鍵結果）。

（一個典型的研發O和KR定義）

所以，開始階段需要不斷在形式上保證OKR的執行，這個是非常必要且需要堅持的事情，然後不斷打磨每個週期裡的O和KR的定義。下面是一些OKR模板大全，看看優秀團隊OKR是如何定義的：

產品經理的OKR模板大全

技術和研發的OKR模板大全

2. OKR + Scrum的方法論

本文並不能將Scrum展開來討論，因為這實在是一個大大大的話題，在我們團隊實施Scrum有個大圖景，其中包括了：敏捷開發、程式碼託管、持續整合、持續部署和持續釋出。

下面這張圖是以最基礎的敏捷開發為例，從如何開會、如何定義團隊規模、如何角色劃分、如何迭代、如何測試，有非常專業且詳細的管理細節。

不過，回到落地Scrum，同時又關注OKR的研發團隊來說，Scrum + OKR是一個及其有價值的組合工具，我們自己的經驗是以以下方式結合的：

部門級OKR驅動 + 部門內敏捷驅動，OKR不到個人層級，但團隊中的牛人可以OKR驅動

迭代與OKR週期匹配，Sprint Meeting和OKR Review Meeting結合

OKR輔助最佳化產品Backlog的優先順序

Scrum Master 參與 OKR Master 目標修正

我們總體在公司層將OKR執行的單元控制在部門層級，並沒有強制個人制定個人的O和KR，所以回到研發團隊管理上，部門的大方向和大目標靠OKR保證。而部門內的迭代，Product Backlog和Sprint Backlog則以敏捷的週期和原則執行。

PS：落地OKR和落地敏捷都離不開好的工具，這裡自薦一下：

大方向由OKR保證，並且影響優先順序，小迭代和任務計劃，基於敏捷的原則執行，簡直是完美配搭。

3. 會議制度

我們推薦

以Sprint Meeting和OKR Review Meeting為核心的覆盤和計劃會議。

Worktile研發團隊，通常會定期在每週五的上午有一個非常長的同步會議，核心內容是基於Scrum的一個Sprint迭代來複盤進度和異議解決，產品和研發在一起高效溝通當前版本的進度和問題，並快速協商解決方案，指定執行人。

而另一方面，我們會在例會中共同覆盤和更新研發團隊的目標樹，投影將打出兩個頁面，一個是迭代的故事板，一個是OKR的目標樹。

對研發團隊而言，透過OKR例會和Scrum例會，很好的規範了每次會議的核心內容，效率自然非同反響。

（例行的Scrum會議，同時覆盤迭代的進度和OKR目標達成）

4. 每日站立

每日15分鐘的站立會議，是敏捷型研發團隊的必修課。快速交流昨日進展和問題，快速商議解決，然後快速計劃今天的工作安排，每天花很小的時間覆盤，這才是小步迭代。

當然，如果對著Worktile的迭代故事板去討論，就免去了在牆上貼一大堆的標籤，感覺很爽很到位。

（每天發生的短小精悍的站立會議）

5. 落地OKR的各種坑

執行OKR，一些坑是初次體驗的團隊常常犯的問題，總結下來主要是以下方面：

和績效考核掛鉤

一上來就全員執行

變成目標分解工具

HR負責，而不是團隊老大

OKR不是靈丹妙藥，更像一個二把刀大夫，你信就能行，你不信就不行。

OKR提供了基本的方法論、儀式、流程和規則，能夠為團隊構建基本的目標同步框架，實際落地需要公司決策層有堅持走下去的決心，嘗試一次不行，要再調整然後接著來。我們自己團隊從開始接觸到今天，OKR的嘗試上已經是第三次才逐漸找到感覺。

談談研發績效

縱橫江湖這麼多年，知名的外企，頭部的公司，小而美的海外企業，特別官僚的國內公司，包括我們一起共建和共創的客戶，我經歷和了解的公司至少上百家以上。

但是講真，在研發績效管理上做的好的，鳳毛麟角。本身而言，研發的績效、目標、管理和獎懲，從來都是一件難的事情，不要試圖以過於簡單的方案來解決。

我曾見識過一家500人研發團隊的公司，為了指標化研發的KPI，將研發工作細分成幾千個指標，然後通過幾千個指標的動態結果來指導績效和方向。這種嘗試骨骼清奇，但我從過往經驗裡表達了深深的懷疑。我們所認識的那些牛逼閃閃的公司，沒有一家是這樣做的，更多的方式還是停留在人類智力可以理解和共識的方式上：

360度

職級

Peer Review

專案制獎懲

分級考核

下面，將我們自己在執行的績效和獎懲方法，做一些淺嘗輒止的分享。

1. 360度

我們在研發績效制度上，主要實行360考核，每半年一個週期，年中考核佔30%的權重，年底考核佔70%權重。包括了自評、同事、直屬上級、HR和老闆，考核的核心是以個人對公司影響力作為最重要的標準。

因此考核前的述職過程對每個人至關重要，因為你需要說清楚我在這個週期裡，做了哪些有價值的事情，帶來了哪些有意義的結果，存在哪些問題，以後如何避免和解決。

我們的部門考核，直接由部門總監的360度結果來代替，所以這意味著部門總監的個人考核結果，就是部門整體的結果，會影響部門整體的係數。

有考核就有獎懲。

360考核是決定一個個體和團隊一年的獎勵或者懲罰，做得好的和做的不好，都由這個結果來評定。

獎金由結果決定，我們通常會定義公司、部門和個人三級係數，不同的係數代表了不同的含義，然後加權出來的結果代表了你能拿到多少獎勵：

公司係數：

基本由公司的總體營收和整體目標達成情況有關，決定了公司總獎金池和調薪池的多少。

部門係數：

也就是部門總監的個人係數，決定了部門在公司多個部門的排序，以及該部門總的獎勵係數。

個人係數：

就是個人的考核結果，決定了個人在所在部門的排序，以及個人總的獎勵係數。

這三個因素加權到一起，基本就為每個人和每個部門定義了一年的收成。

360度或許不是最佳的績效方案，但這是當下普遍執行的規則裡最有效的辦法和方式。

當然，執行360度考核有很多執行的細節，這些是施行過程中很重要的平衡，每個考核結束都要覆盤做哪些調整。

總體而言，

獎勵和懲罰也沒有永遠的絕對公平，只有相對的。

但是在規則定義上，如何實現按照影響力評價，就能最大程度的保證能者多勞這一基本常識。

2. 職級驅動

職級體系是研發型團隊最有價值的工具，職級體系是一個職業序列，可以方便的定義一個人對公司影響力的評級和序列，而不是職位序列。所以，對於資深的工程師或者架構師來說，他的職級可以比自己的部門領導高，但職位可以略低。

職級體系同時定義了薪資範圍和期權範圍，從而讓職級成為一個程式設計師向上通道的必經之路，原因是職級可能定義他在公司維度下薪資的上限，必須職級提升才能突破某個薪資瓶頸。

職級的價值在於：它是清晰定義的透明規則，包括薪資範圍、期權、附件福利、評級標準。

這樣的透明標準能夠最大程度上調動每個人向上成長的積極性。例如，職級對應的附加福利中，我們會包括你每年可以參加外部培訓的額度，這對學習型工程師都是非常好的小福利。

（職級體系）

職級體系不是一個簡單的工具，需要考慮很多細節和適配不同公司的規則，例如如何評級職級，技術委員會對研發崗位每個人的技術能力定義，職級評價的週期，每個職級的要求。

總體而言，

職級是個有效工具，能夠好的驅動那些有向上野心的團隊成員，以最透明和公平的方式在向上的通道前進。

多說一句，我們在研發團隊是以OKR+ 360度 + 職級體系來建立相對完善的管理體系，而在業務團隊，包括銷售、客戶成功、市場團隊，則更加突出KPI的導向性，所以

KPI也不是毒藥，KPI要善用到合適的地方，以及以合適的方式。

3. 分級考核

分級考核是我們在逐步嘗試的方案，還沒有完全落地，只是一個探討階段的東西。實行分級考核的原因是，任何組織和團隊，都常識性的遵循2-7-1原則，一定有20%的牛人來長遠的帶來公司前進，也大機率上有70%的執行層需要靠規則和優秀的角色來影響前進。

所以考核的方式上不能實行統一的規則，否則要麼對牛人定了太低的標準，要麼對一般能力的人定了太高的標準。

另一方面，分級考核也能夠從規則上驅動70%的小夥伴，有努力向20%提高的動力和標準。當然，我們還在考察和嘗試，這裡僅僅拋磚引玉。

4. 總獎勵和總營收掛鉤

這一條本來是一個常識性的結論，只是這個時代太多融資了的公司並沒有很好的理解獎勵的本質，很多時候拿融資的錢獎勵，是不道德的。所以，讓總營收和總獎勵掛鉤，是最合理，也最理直氣壯的方式。

這一條在我們的邏輯裡，就是由總營收來影響績效考核的公司級係數，這個係數由核心管理層來定義即可。

工具化

工欲善其事必先利其器，這是真理。

工具的核心價值，不是僅僅透過工具提高效率，更重要的是，利用工具能夠為團隊修好水渠

。

研發團隊本身的管理、績效、工作流程有很多可以水渠化的事情，所以用一個好的工具能夠最有效的幫助研發團隊修好水渠，然後達成團隊的目標。

當然，主要推薦的是我們自己在用，並且很有效的自家工具：Worktile。核心原因是對研發團隊而言，Worktile能夠幫助解決的主要是以下兩個方面：

基於敏捷的全流程專案管理

基於OKR的目標工具

1. 透過Worktile專案管理（Scrum和Kanban）驅動敏捷研發全流程

目前已經有幾十萬團隊透過Worktile協同工作，其中研發團隊佔比是最高的，源於我們提供了對敏捷全流程的完整工具鏈支援，以及更好的產品體驗：

支援Scrum和Kanban兩種敏捷實踐方式

基於敏捷方法論的完整迭代、故事板、需求、任務和缺陷管理

豐富的報表和資料統計，對研發決策管理一目瞭然

打通研發和業務，更好的跨部門協作支援

落地敏捷，需要能夠支撐全流程的簡單工具，Worktile為你提供了所需的一切。

2. 透過Worktile OKR工具落地OKR的執行

Worktile是國內首家將OKR落地到工具化的產品，為團隊執行OKR提供了更好，更方便，更資料化的支援，主要包括：

OKR的執行全流程管理，從啟動、週期、打分和評審

基於公司、部門和個人分級的O和KR管理

一個基於目標體系的目標樹

基於目標執行的自動化運營分析，同統計報表告知團隊OKR執行和更新的情況

自動目標更新提醒

（在Worktile以更有效的方式定義OKR）

OKR是個簡單的方法論，工具本身並不複雜，但自動化方式顯然好過Excel共享方式帶給團隊的價值。這些都是Worktile已經修好的水渠，你只需將水引入即可。

總結

好了，這是一篇匯聚研發團隊，從管人到管事的一些點滴經驗，背後投射的是一個百人規模研發團隊在過去成長之路上不斷迭代的經驗和方法。

每個團隊都是獨特而與眾不同的，

所以經驗和方法也不一定適合所有，只是希望一些可能的思路，能帶給你的團隊一些轉折和啟發。

程式設計師群體，也是獨特而與眾不同的一群可愛的傢伙，他們有自命不凡的習慣，也有改天換地的雄心，他們不會循規蹈矩，更不會一直被996束縛手腳，驅動這群難搞的人不是一件容易的事，需要站在開發者的視角去理解他們的工作和樂趣，然後共創出能夠執行、能夠激勵、能夠數字的方案，這是我們Worktile在檢視努力的方向，也是我們自己獻給自己工程師們的禮物。

歡迎你貢獻你們團隊的經驗，私信我，或者留言，咱們看看還有什麼更好的辦法，解放天下程式設計師。

圖中截圖皆是來源於以下工具：

專案協作與目標管理工具：

研發全流程管理工具：