什么是研發團隊？簡單的說，你熟悉的那幫穿格子襯衫，以程序員為核心組成的團隊，就是研發團隊。
本來，你以為格子男們是很乖很悶騷的那種，管理和協作起來比銷售和業務簡單很多，而實際情況是.......格子男們并不那么容易管理，面向代碼世界的復雜度，可能遠比面向財物世界的復雜度還要高。
作為致力于團隊協作的公司，我們研究了很多國內和海外牛逼公司的研發模式和研發管理，例如OKR在谷歌、Facebook的應用，Uber的高效會議制度，阿里的績效體系，騰訊的產品流程。
除了在自身團隊做了N次不同的試驗和反思，我們也想將很多不錯的經驗分享給用戶。而要談清楚方法，就先了解清楚問題，研發管理之所以令人頭疼，核心的問題無外乎以下一些方面。
研發管理的典型問題
任正非有句名言：錢分好了，管理的大部分問題就解決了。我對此深表同意，可問題是，怎么能分好錢確實非常考驗能力、經驗和智力的。研發之難，恰恰難在工作本身無法KPI化，所有那些試圖KPI化工程師和碼農的做法，最終結果都啼笑皆非、面目可憎、吃力不討好。
在我過去經歷，還有客戶實際的研發管理里，試圖KPI化研發工作一直是不同團隊努力的方向，包括但不限于以下方式：
解決Bug數
SLA
功能完成度
營收捆綁
NPS
加班，007就比996牛逼，996就比955更值得獎勵
這些看起來可以數字化的指標，除了證明研發管理者通過偷懶的方式做績效考核外，可以說毫無價值，也無法給公司和組織帶來正向的激勵。
另外一個現實且無奈的問題是：工程師和產品經理好像是在象牙塔里做產品和研發，和用戶往往離得太遠太遠。這種問題帶來的傷害遠比其他事情來得更加徹底，但本質上這是研發規則上沒有解決好的問題，導致工程師本身并沒有任何的目標和動力去貼近用戶和客戶場景。
我們常常說要做用戶喜歡的產品，但那些反人類智商的產品，往往是產品經理和工程師合謀的結果。如果說研發管理的目標是提高效能，那么首先同步研發團隊朝著統一的目標，就是效能管理最重要的第一步。
因此，以什么樣的制度去驅動研發抬起頭來看客戶場景，是一切研發管理的核心工作之一。
因為低頭干活，所以往往研發團隊的目標和業務團隊的目標并不是一致的，研發體系和業務體系的跨部門戰爭，簡直罄竹難書：
業務認為：怎么這么多bug，一個小問題需要花這么久的時間才能修復
研發認為：業務的智商不夠用，這么好的產品就是無法準確傳達給客戶
業務面對客戶點頭哈腰；而研發覺得客戶是業務的客戶，不是研發的客戶
業務對需求排期是12345；而研發對需求排期往往是54321
業務給客戶承諾就像談戀愛，把星星摘下來也敢接著；研發認為你承諾的，你去寫代碼實現吧
業務認為研發高工資吹著冷氣，自己天天跑在外面曬太陽；研發認為，業務提成那么高，這產品是我做的，我咋沒提成呢
這種剪不斷、理還亂的關系，是很多公司的普遍現象。因為跨部門的不理解，必然帶來團隊之間的內耗，信息的折扣和效率低下自然產生。
更重要的影響是跨部門戰爭造成對客戶服務與理解的偏差與推諉，沒有任何公司或者團隊能在一個不流暢的環境下成就對客戶的100%滿意度。
從研發管理全景圖說起
上圖是研發管理全景圖，是我們團隊過去幾年逐步形成的研發管理經驗，其中主要包括以下內容：
研發管理的的核心是構建一個開放、自學習、自驅動的組織文化和儀式感，這是打造高效研發團隊最內核的基礎。
左邊是工具和方法，主要包括：以OKR驅動的目標管理，基于Scrum的敏捷，和逐步完善的DevOps。
右邊是制度和規則，核心包含：研發團隊的績效和考核、跨部門合作、其他儀式感驅動的各種規則，尤其是構建自學習的環境與分享機制。
打造開放和競合的組織架構和文化
一個組織要煥發活力、自驅動、使命必達的信念，開放而透明的文化是績效管理的核武器。總體來說，不管你的方法和制度多么豐富和完善，無論如何也不可能驅動僵化、死板、沒有活力的團隊產生極其高效的價值。
所以，我們在談研發效能的時候，注意力總集中在別人家的團隊是符合管理的，而忽略了團隊激活的核心首先是塑造超強自由度、透明度和使命感的團隊文化。
從效率這個角度去看，沒有透明度的提效都是打折扣的，在一個組織里效率低下的首要原因并不是執行力，而是透明度。需要層層審批和報備的組織，設定層層關卡和信息圍墻的團隊，效率一定是非常低下的，單點的執行力提升并不改變整個團隊的低效基因。
我們熟悉的Facebook從誕生到現在就是不斷在驅動【黑客文化】，核心共識是：馬上上手、快速搞定和持續迭代，這個Hack Culture從底層文化上驅動了Facebook歷經10年，從小團隊到超級大公司可以保持不斷進取的能力；
亞馬遜的文化被定義為始終Day1，始終回到創業的第一天；
至于我們自己的文化就是簡單而認真，在團隊里不斷實現盡可能簡單的協作和決策規則，打破層級觀念，快速響應和試錯，足夠開放、足夠容錯、足夠快。
所以，打造開放與競合的組織架構和文化，至關重要。
如何設計研發團隊的組織架構，是個大大的思考題。我們團隊經歷過好幾次不同的組織形態，也經常性的將研發團隊進行組織調整，簡單說，一個研發團隊的角色主要是以下幾類：
產品經理
設計師
服務工程師端
前端工程師
測試
其他
以什么樣的組織方式調配以上資源，是個非常考驗團隊管理的事情，例如很多公司會將設計團隊作為完全獨立的部門，其他團隊和項目按需調配設計資源，設計團隊就像公司的乙方角色，通過資源調配來匹配執行。
而另一種形態則是廣泛存在于Facebook等互聯網公司的方式，設計、產品經理、開發、測試組成短小精悍的特種部隊，在研發團隊中以小組形態組合，就像一個研發業務的接口一樣，有清晰的輸入和清晰的輸出，有清晰的目標和清晰的邊界。
顯然，打起仗來，特種部隊方式的小組，從執行到目標都是超級強悍的，也同時能方便研發組織績效考核的落地與激勵。
特種部隊的另一個好處是：每個小組的職能和目標是固定的，在產品研發大架構下執行一個精確的目標和單元。但小組成員可以轉崗或者調配到其他小組，從而避免了研發人員的枯燥和無挑戰的問題。
儀式感是團隊管理的調味品，也是必需品，就像你吃飯離不開鹽一樣。研發團隊管理者，例如CTO角色的人，需要有意識的在團隊中設計有價值的儀式感，來增加團隊磨合、默契與調味。
好的儀式感，就像宗教儀式一樣，能不斷加強團隊目標的執行、文化的塑造以及階段的激勵。
例如，我們自己團隊就有很大儀式性的東西在執行：
OKR階段同步
把重大版本發布變成研發團隊的階段激勵
管理層的固定one one訪談
研發人員的每月訪談，同步到公司月報
花心思的團建
每月的產品考核
師徒制
走出去，參加各種外部的技術大會
......
還有很多其他的儀式和規則，并且以上每個規則都值得拿出來說道說道。
在Worktile團隊，我們建立了組織架構之外的一些虛擬組織，虛擬組織的設計可以很好解決跨部門溝通與信息同步的問題，以用戶體驗委員會為例，將公司里研發、設計、產品、銷售、客戶成功的同事組成一個虛擬委員會。
委員會主席本質上就是這個組織的秘書，通過定期的會議或者討論，將解決用戶體驗上的問題作為核心目標來解決。委員會的茶話會，每次都能高效推進很多方面的事情：
就用戶體驗的重大問題充分討論，產品和研發從不同視角收聽意見，銷售和客戶成功更多代表了來自一線用戶的建議。
促進跨部門的彼此理解，很多時候跨部門的戰爭，來自于互相的不理解和看不起。例如，我們在某次茶會中，就一個很久以來的核心需求做了討論，銷售端原本以為是一個簡單的需求，結果討論下來發現，這個簡單需求其實在客戶方也有非常不同的理解，完全推翻了產品已經草創的設計方案。反過來，銷售同事也完全理解了為何產品方案是如此之難的原因。
指定行動方案，快速驅動產品研發落實改進方案。用戶體驗委員會不是只討論，更重要的是驅動行動方案，快速解決用戶關心的體驗問題。
（每次用戶體驗交流都熱火朝天）
同樣，在研發團隊，我們通過技術委員會來實現跨研發團隊的技術溝通、分享和技術選型。
技術委員會保證了公司始終以科技驅動商業的基礎不被稀釋，匯聚團隊中技術能力最強的圈子更加自驅動的投入技術貢獻，主要的工作目標包括：
公司級的技術方案
前沿技術研發小組
研發崗的職級評審，技術委員會承擔對技術能力的職級評估
向市場和銷售輸出技術內容
驅動公司技術進步和學習，例如組織黑客馬拉松、技術分享、對外技術輸出
研發下鄉就是讓研發走向客戶，貼近客戶需求，了解客戶狀況，然后回來完善產品以滿足客戶需求。
Worktile本身是企業服務產品，客戶需求在B端是及其復雜而多樣的，憋在辦公室是無法做出好產品的，所以需要從制度上驅動研發、產品和設計走向客戶，而不是待在象牙塔。
研發下鄉給了每個研發人員固定的指標，需要下鄉到客戶現場，所以銷售和客戶成功有了正當的理由要求研發同事完成指標，從另一個方面也加強了研發和業務部門的配合與協作，因為雙方有了共同KPI的時候，大家綁在一起去做好一件事的動力就變得很強。
Polish Week是來自硅谷的流行文化，讓研發團隊在一個緊張迭代之后，不再計劃大的功能和需求安排，而是有足夠的時間可以【停一下】，然后集中火力解決來自客戶的細節需求或者小問題，這種制度設計是非常高效的方法，可以短時間集中兵力解決遺留問題。
5年下來，我們技術團隊每周分享已經正常進行了幾百次，研發團隊中的每個人都或多或少完成過對于所在部門的技術分享。新人來到團隊，可以從過去數百次分享留下來的知識收獲非常多的遺留知識。
（在研發體系共享的技術分享池）
另外一方面，Worktile的核心客戶本來就是研發團隊和工程師，市場維度需要研發人員能夠不斷共享有價值的技術內容，而技術分享機制恰恰提供了驅動工程師內容創作的土壤。
每次內部分享的內容，其實完全可以繼續優化成外部可以傳播的內容，通過市場手段實現二次傳播，同時也能夠將團隊中有活力和分享精神的小伙伴，推到前臺去技術大會或者公司組織的技術分享大會分享。
基于OKR和Scrum的研發管理
源于業務關系，我們在N個不同的客戶場景做過測試，就是把團隊老大的目標在公司群里做個調研，比較打臉的現實是，99%的情況下老大想的目標和執行層理解的目標不是一回事，而且大部分時候差別都非常大。因此，回到在研發團隊或者公司層執行OKR，本質上要解決的核心問題是：上下同欲。
俗話說，上下同欲者勝。如果目標這件事都沒法達成一致，那么一切效能和效率的優化都是無稽之談。因為你效率越高，但方向不對，可能偏離方向跑的更遠，這不是很尷尬的事情么？
因此，我們可以通過了解OKR來在團隊形成一個基本的能力，這就是戰略同步和戰略溝通，從而實現目標統一這件事。
（OKR的基本知識，推薦去Worktile OKR專題頁了解：https://help.worktile.com/okr/）
（OKR是戰略同步和戰略溝通工具，服務于團隊的使命和愿景）
在研發團隊落地OKR，本身并不是一件特別容易的事情，Worktile 團隊經歷了將近3年的反復嘗試才逐漸找到OKR執行的感覺，而所有難點中，開始階段是：如何寫好你的O（目標）和KR（關鍵結果）。
（一個典型的研發O和KR定義）
所以，開始階段需要不斷在形式上保證OKR的執行，這個是非常必要且需要堅持的事情，然后不斷打磨每個周期里的O和KR的定義。下面是一些OKR模板大全，看看優秀團隊OKR是如何定義的：
產品經理的OKR模板大全：https://worktile.com/blog/okr/okr-template-01-product-and-design
技術和研發的OKR模板大全：https://worktile.com/blog/okr/okr-template-02-dev
本文并不能將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保證，并且影響優先級，小迭代和任務計劃，基于敏捷的原則執行，簡直是完美配搭。
我們推薦以Sprint Meeting和OKR Review Meeting為核心的復盤和計劃會議。
Worktile研發團隊，通常會定期在每周五的上午有一個非常長的同步會議，核心內容是基于Scrum的一個Sprint迭代來復盤進度和異議解決，產品和研發在一起高效溝通當前版本的進度和問題，并快速協商解決方案，指定執行人。
而另一方面，我們會在例會中共同復盤和更新研發團隊的目標樹，投影將打出兩個頁面，一個是迭代的故事板，一個是OKR的目標樹。
對研發團隊而言，通過OKR例會和Scrum例會，很好的規范了每次會議的核心內容，效率自然非同反響。
（例行的Scrum會議，同時復盤迭代的進度和OKR目標達成）
4. 每日站立
每日15分鐘的站立會議，是敏捷型研發團隊的必修課。快速交流昨日進展和問題，快速商議解決，然后快速計劃今天的工作安排，每天花很小的時間復盤，這才是小步迭代。
當然，如果對著Worktile的迭代故事板去討論，就免去了在墻上貼一大堆的標簽，感覺很爽很到位。
（每天發生的短小精悍的站立會議）
執行OKR，一些坑是初次體驗的團隊常常犯的問題，總結下來主要是以下方面：
和績效考核掛鉤
一上來就全員執行
變成目標分解工具
HR負責，而不是團隊老大
OKR不是靈丹妙藥，更像一個二把刀大夫，你信就能行，你不信就不行。OKR提供了基本的方法論、儀式、流程和規則，能夠為團隊構建基本的目標同步框架，實際落地需要公司決策層有堅持走下去的決心，嘗試一次不行，要再調整然后接著來。我們自己團隊從開始接觸到今天，OKR的嘗試上已經是第三次才逐漸找到感覺。
談談研發績效
縱橫江湖這么多年，知名的外企，頭部的公司，小而美的海外企業，特別官僚的國內公司，包括我們一起共建和共創的客戶，我經歷和了解的公司至少上百家以上。
但是講真，在研發績效管理上做的好的，鳳毛麟角。本身而言，研發的績效、目標、管理和獎懲，從來都是一件難的事情，不要試圖以過于簡單的方案來解決。
我曾見識過一家500人研發團隊的公司，為了指標化研發的KPI，將研發工作細分成幾千個指標，然后通過幾千個指標的動態結果來指導績效和方向。這種嘗試骨骼清奇，但我從過往經驗里表達了深深的懷疑。我們所認識的那些牛逼閃閃的公司，沒有一家是這樣做的，更多的方式還是停留在人類智力可以理解和共識的方式上：
360度
職級
Peer Review
項目制獎懲
分級考核
下面，將我們自己在運行的績效和獎懲方法，做一些淺嘗輒止的分享。
我們在研發績效制度上，主要實行360考核，每半年一個周期，年中考核占30%的權重，年底考核占70%權重。包括了自評、同事、直屬上級、HR和老板，考核的核心是以個人對公司影響力作為最重要的標準。
因此考核前的述職過程對每個人至關重要，因為你需要說清楚我在這個周期里，做了哪些有價值的事情，帶來了哪些有意義的結果，存在哪些問題，以后如何避免和解決。
我們的部門考核，直接由部門總監的360度結果來代替，所以這意味著部門總監的個人考核結果，就是部門整體的結果，會影響部門整體的系數。
有考核就有獎懲。360考核是決定一個個體和團隊一年的獎勵或者懲罰，做得好的和做的不好，都由這個結果來評定。
獎金由結果決定，我們通常會定義公司、部門和個人三級系數，不同的系數代表了不同的含義，然后加權出來的結果代表了你能拿到多少獎勵：
公司系數：基本由公司的總體營收和整體目標達成情況有關，決定了公司總獎金池和調薪池的多少。
部門系數：也就是部門總監的個人系數，決定了部門在公司多個部門的排序，以及該部門總的獎勵系數。
個人系數：就是個人的考核結果，決定了個人在所在部門的排序，以及個人總的獎勵系數。
這三個因素加權到一起，基本就為每個人和每個部門定義了一年的收成。
360度或許不是最佳的績效方案，但這是當下普遍執行的規則里最有效的辦法和方式。當然，執行360度考核有很多執行的細節，這些是施行過程中很重要的平衡，每個考核結束都要復盤做哪些調整。
總體而言，獎勵和懲罰也沒有永遠的絕對公平，只有相對的。但是在規則定義上，如何實現按照影響力評價，就能最大程度的保證能者多勞這一基本常識。
職級體系是研發型團隊最有價值的工具，職級體系是一個職業序列，可以方便的定義一個人對公司影響力的評級和序列，而不是職位序列。所以，對于資深的工程師或者架構師來說，他的職級可以比自己的部門領導高，但職位可以略低。
職級體系同時定義了薪資范圍和期權范圍，從而讓職級成為一個程序員向上通道的必經之路，原因是職級可能定義他在公司維度下薪資的上限，必須職級提升才能突破某個薪資瓶頸。
職級的價值在于：它是清晰定義的透明規則，包括薪資范圍、期權、附加福利、評級標準。這樣的透明標準能夠最大程度上調動每個人向上成長的積極性。例如，職級對應的附加福利中，我們會包括你每年可以參加外部培訓的額度，這對學習型工程師都是非常好的小福利。
（職級體系）
職級體系不是一個簡單的工具，需要考慮很多細節和適配不同公司的規則，例如如何評級職級，技術委員會對研發崗位每個人的技術能力定義，職級評價的周期，每個職級的要求。
總體而言，職級是個有效工具，能夠好的驅動那些有向上野心的團隊成員，以最透明和公平的方式在向上的通道前進。
多說一句，我們在研發團隊是以OKR+ 360度 + 職級體系來建立相對完善的管理體系，而在業務團隊，包括銷售、客戶成功、市場團隊，則更加突出KPI的導向性，所以KPI也不是毒藥，KPI要善用到合適的地方，以及以合適的方式。
分級考核是我們在逐步嘗試的方案，還沒有完全落地，只是一個探討階段的東西。實行分級考核的原因是，任何組織和團隊，都常識性的遵循2-7-1原則，一定有20%的牛人來長遠的帶來公司前進，也大概率上有70%的執行層需要靠規則和優秀的角色來影響前進。
所以考核的方式上不能實行統一的規則，否則要么對牛人定了太低的標準，要么對一般能力的人定了太高的標準。
另一方面，分級考核也能夠從規則上驅動70%的小伙伴，有努力向20%提高的動力和標準。當然，我們還在考察和嘗試，這里僅僅拋磚引玉。
這一條本來是一個常識性的結論，只是這個時代太多融資了的公司并沒有很好的理解獎勵的本質，很多時候拿融資的錢獎勵，是不道德的。所以，讓總營收和總獎勵掛鉤，是最合理，也最理直氣壯的方式。
這一條在我們的邏輯里，就是由總營收來影響績效考核的公司級系數，這個系數由核心管理層來定義即可。
工具化
工欲善其事必先利其器，這是真理。工具的核心價值，不是僅僅通過工具提高效率，更重要的是，利用工具能夠為團隊修好水渠。
研發團隊本身的管理、績效、工作流程有很多可以水渠化的事情，所以用一個好的工具能夠最有效的幫助研發團隊修好水渠，然后達成團隊的目標。
當然，主要推薦的是我們自己在用，并且很有效的自家工具：Worktile。核心原因是對研發團隊而言，Worktile能夠幫助解決的主要是以下兩個方面：
基于敏捷的全流程項目管理
基于OKR的目標工具
目前已經有幾十萬團隊通過Worktile協同工作，其中研發團隊占比是最高的，源于我們提供了對敏捷全流程的完整工具鏈支持，以及更好的產品體驗：
支持Scrum和Kanban兩種敏捷實踐方式
基于敏捷方法論的完整迭代、故事板、需求、任務和缺陷管理
豐富的報表和數據統計，對研發決策管理一目了然
打通研發和業務，更好的跨部門協作支持
落地敏捷，需要能夠支撐全流程的簡單工具，Worktile為你提供了所需的一切。
Worktile是國內首家將OKR落地到工具化的產品，為團隊執行OKR提供了更好，更方便，更數據化的支持，主要包括：
OKR的執行全流程管理，從啟動、周期、打分和評審
基于公司、部門和個人分級的O和KR管理
一個基于目標體系的目標樹
基于目標執行的自動化運營分析，同統計報表告知團隊OKR執行和更新的情況
自動目標更新提醒
（在Worktile以更有效的方式定義OKR）
OKR是個簡單的方法論，工具本身并不復雜，但自動化方式顯然好過Excel共享方式帶給團隊的價值。這些都是Worktile已經修好的水渠，你只需將水引入即可。
總結
好了，這是一篇匯聚研發團隊，從管人到管事的一些點滴經驗，背后投射的是一個百人規模研發團隊在過去成長之路上不斷迭代的經驗和方法。
每個團隊都是獨特和與眾不同的，所以經驗和方法也不一定適合所有，只是希望一些可能的思路，能帶給你的團隊一些轉折和啟發。
程序員群體，也是獨特而與眾不同的一群可愛的家伙，他們有自命不凡的習慣，也有改天換地的雄心，他們不會循規蹈矩，更不會一直被996束縛手腳，驅動這群難搞的人不是一件容易的事，需要站在開發者的視角去理解他們的工作和樂趣，然后共創出能夠執行、能夠激勵、能夠數字化的方案，這是我們Worktile在試圖努力的方向，也是我們自己獻給自己工程師們的禮物。
歡迎你貢獻你們團隊的經驗，私信我，或者留言，咱們看看還有什么更好的辦法，解放天下程序員。
//anytao
//2019-7-12
