百人研發團隊的難題：研發管理、績效考覈、組織文化和OKR

分享一個公司規模近200，研發佔一半的創業公司 Worktile 在研發團隊管理方面的玩法，僅供百人左右研發團隊參考~

什麼是研發團隊？簡單的說，你熟悉的那幫穿格子襯衫，以程序員爲核心組成的團隊，就是研發團隊。

原本，你覺得格子男們是很乖很悶騷的那種，管理和協做起來比銷售和業務簡單不少，而實際狀況是，格子男們並不那麼容易管理，面向代碼世界的複雜度，可能遠比面向財物世界的複雜度還要高。

做爲致力於團隊協做的公司，咱們研究了不少國內和海外牛逼公司的研發模式和研發管理，例如OKR在谷歌、Facebook的應用，Uber的高效會議制度，阿里的績效體系，騰訊的產品流程。除了在自身團隊作了N次不一樣的試驗和反思，咱們也想將不少不錯的經驗分享給用戶。要談清楚方法，就先了解清楚問題，研發管理之因此使人頭疼，核心的問題無外乎如下一些方面。

研發管理的典型問題

 

 

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的基本知識，推薦去Worktile 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則以敏捷的週期和原則執行。

大方向由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在試圖努力的方向，也是咱們本身獻給本身工程師們的禮物。

歡迎你貢獻大家團隊的經驗，私信我，或者留言，我們看看還有什麼更好的辦法，解放天下程序員。

  

本文做者：Worktile CEO anytao

文章來源：Worktile官方博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。