分享一個公司規模近200，研發佔一半的創業公司 Worktile 在研發管理方面的玩法，僅供百人左右研發團隊參考~
什麼是研發團隊，簡單的說，就是由你熟悉的那幫穿格子襯衫程式設計師為核心組成的團隊，就是研發團隊。本來，你以為格子男們是很乖很悶騷的那種，管理和協作起來比銷售和業務簡單很多，而實際情況是，格子男們並不那麼容易管理，面向程式碼世界的複雜度，可能遠比面向財物世界的複雜度還要高。作為致力於團隊協作的公司，我們研究了很多國內和海外牛逼公司的研發模式和研發管理，例如OKr在谷歌、Facebook的應用，Uber的高效會議制度，阿里的績效體系，騰訊的產品流程。除了在自身團隊做了N次不同的試驗和反思，我們也將很多不錯的經驗分享到客戶和使用者，所以本文試圖將Worktile的研發管理全景圖做一個概括性的闡述。要談清楚方法，就先了解清楚問題，研發管理之所以令人頭疼，核心的問題無外乎以下一些方面。
研發管理的典型問題
難以KPI化和考核
任正非有句名言：錢分好了，管理的大部分問題就解決了。我對此深表同意，可問題是，怎麼能分好錢確實非常考驗能力、經驗和智力的。研發之難，恰恰難在無法KPI化工作本身，所有那些試圖KPI化工程師和碼農的做法，最終結果都啼笑皆非、面目可憎、吃力不討好。在我過去經歷，還有客戶實際的研發管理裡，試圖KPI化研發工作一直是不同團隊努力的嘗試，包括和不限於以下方式：
- 解決Bug數
- SLA
- 功能完成度
- 加班，007就比996牛逼，996就比955更值得獎勵
- 營收捆綁
- NPS
這些看起來可以數字化的指標，除了證明研發管理者通過偷懶的方式做績效考核外，可以說毫無價值，也無法給公司和組織帶來正向的激勵。
離程式碼很近，離使用者很遠
另外一個現實且無奈的問題是，工程師和產品經理好像是在象牙塔裡做產品和研發，和使用者往往離得太遠太遠。這種問題帶來的傷害可能遠比其他事情來得更加徹底，但本質上這是研發規則上沒有解決好的問題，導致工程師本身並沒有任何的目標和動力去貼近使用者和客戶場景。
我們常常說要做使用者喜歡的產品，但那些反人類智商的產品，往往是產品經理和工程師合謀的結果。如果說研發管理的目標是提高效能，那麼首先同步研發團隊朝著統一的目標，就是效能管理最重要的第一步。
因此，以什麼樣的制度去驅動研發抬起頭來看客戶場景，是一切研發管理的核心工作之一。
跨部門戰爭頻發
因為低頭幹活，所以往往研發團隊的目標和業務團隊的目標並不是一致的，研發體系和業務體系的跨部門戰爭，簡直罄竹難書：
- 業務認為，怎麼這麼多bug，一個小問題需要花這麼久的時間才能修復
- 而研發認為業務的智商不夠用，這麼好的產品就是無法準確傳達給客戶
- 業務面對客戶點頭哈腰；而研發覺得客戶是業務的客戶，不是研發的客戶
- 業務對需求排期是12345；而研發對需求排期往往是54321
- 業務給客戶承諾就像談戀愛，把星星摘下來也敢接著；
- 研發認為你承諾的，你去寫程式碼實現吧
- 業務認為研發高工資吹著冷氣，自己天天跑在外面曬太陽；研發認為，業務提成那麼高，這產品是我做的，我咋沒提成呢
這種剪不斷、理還亂的關係，是很多公司的普遍現象。因為跨部門的不理解，必然帶來團隊之間的內耗，資訊的折扣和效率低下自然產生。而更重要的影響是跨部門戰爭造成對客戶服務與理解的偏差與推諉，沒有任何公司或者團隊能在一個不流暢的環境下成就對客戶的100%滿意度。
那麼如何解決以上問題呢？
從研發管理全景圖說起
下面的研發全景圖，是我們團隊過去幾年逐步形成的研發管理經驗，其中主要包括以下內容：
- 研發管理的的核心是構建一個開放、自學習、自驅動的組織文化和儀式感，這是打造高效研發團隊最核心的基礎。
- 左邊是工具和方法，主要包括：以OKR驅動的目標管理，基於Scrum的敏捷，和逐步完善的DevOps。
- 右邊是制度和規則，核心包含：研發團隊的績效和考核、跨部門合作、其他儀式感驅動的各種規則，尤其是構建自學習的環境與分享機制。
打造開放與競合的組織架構和文化
一個組織要煥發活力、自驅動、使命必達的信念，開放而透明的文化是績效管理的核武器。總體來說，不管你的方法和制度多麼豐富和完善，無論如何也不可能驅動僵化、死板、沒有活力的團隊產生極其高效的價值。所以，我們在談研發效能的時候，注意力總集中在別人家的團隊是符合管理的，而忽略了團隊啟用的核心首先是塑造超強自由度、透明度和使命感的團隊文化。
從效率這個角度去看，沒有透明度的提效都是打折扣的，在一個組織裡效率低下的首要原因並不是執行力，而是透明度。需要層層審批和報備的組織，設定層層關卡和資訊圍牆的團隊，效率一定是非常低下的，單點的執行力提升並不改變整個團隊的低效基因。
所以，打造開放與競合的組織架構和文化，至關重要。
特種部隊
如何設計研發團隊的組織架構，是個大大的思考題。我們團隊經歷過好幾次不同的組織形態，也經常性的將研發團隊，簡單說，一個研發團隊的角色主要是以下幾類：
- 產品經理
- 設計師
- 服務端工程師
- 前端工程師
- 測試
- 其他
以什麼樣的組織方式調配以上資源，是個非常考驗團隊管理的事情，例如很多公司會將設計團隊作為完全獨立的部門，其他團隊和專案按需調配設計資源，設計團隊就像公司的乙方角色，通過資源調配來匹配執行。而另一種形態則是廣泛存在於Facebook等網際網路公司的方式，設計、產品經理、開發、測試組成短小精悍的特種部隊，在研發團隊中以小組形態組合，就像一個研發業務的介面一樣，有清晰的輸入和清晰的輸出，有清晰的目標和清晰的邊界。顯然，打起仗來，特種部隊方式的小組，從執行到目標都是超級強悍的，也同時能方便研發組織績效考核的落地與激勵。
特種部隊的另一個好處是，每個小組的職能和目標是固定的，在產品研發大架構下執行一個精確的目標和單元。但小組成員可以轉崗或者調配到其他小組，從而避免了研發人員的枯燥和無挑戰的問題。
儀式感
儀式感是團隊管理的調味品，也是必需品，就像你吃飯離不開鹽一樣。研發團隊管理者，例如CTO角色的人，需要有意識的在團隊中設計有價值的儀式感，來增加團隊磨合、默契與調味。好的儀式感，就像宗教儀式一樣，能不斷加強團隊目標的執行、文化的塑造以及階段的激勵。
例如，我們自己團隊就有很大儀式性的東西在執行：
- OKR的階段同步
- 把重大版本釋出變成研發團隊的階段激勵
- 管理層的固定One One訪談
- 研發人員的每月訪談，同步到公司月報
- 花心思的團建
- 每月的產品考核
- 師徒制
- 走出去，參加各種外部的技術大會
- 。。。
還有很多其他的儀式和規則，並且以上幾乎每個規則都值得拿出來說道說道。
使用者體驗委員會
在Worktile團隊，我們建立了組織架構之外的一些虛擬組織，虛擬組織的設計可以很好解決跨部門溝通與資訊同步的問題，以使用者體驗委員會為例，將公司裡研發、設計、產品、銷售、客戶成功的同事組成一個虛擬委員會。委員會主席本質上就是這個組織的祕書，通過定期的會議或者討論，將解決使用者體驗上的問題作為核心目標來解決。委員會的茶話會，每次都能高效推進很多方面的事情：
- 就使用者體驗的重大問題充分討論，產品和研發從不同視角收聽意見，銷售和客戶成功更多代表了來自一線使用者的建議。
- 促進跨部門的彼此理解，很多時候跨部門的戰爭，來自於互相的不理解和看不起。例如，我們在某次茶會中，就一個很久以來的核心需求做了討論，銷售端原本以為是一個簡單的需求，結果討論下來發現，這個簡單需求其實在客戶方也有非常不同的理解，完全推翻了產品已經草創的設計方案。反過來，銷售同事也完全理解了為何產品方案是如此之難的原因。
- 指定行動方案，快速驅動產品研發落實改進方案。使用者體驗委員會不是隻討論，更重要的是驅動行動方案，快速解決使用者關心的體驗問題。
技術委員會
同樣在研發團隊，我們通過技術委員會來實現跨研發團隊的技術溝通、分享和技術選型。技術委員會保證了公司始終以科技驅動商業的基礎不被稀釋，匯聚團隊中技術能力最強的圈子更加自驅動的投入技術貢獻，主要的工作目標包括：
- 公司級的技術方案
- 前沿技術研發小組研發崗的職級評審，技術委員會承擔對技術能力的職級評估
- 驅動公司技術進步和學習，例如組織黑客馬拉松、技術分享、對外技術輸出
- 向市場和銷售輸出技術內容研發下鄉
研發下鄉
就是讓研發走向客戶，貼近客戶需求，瞭解客戶狀況，然後回來完善產品以滿足客戶需求。Worktile本身是企業服務產品，客戶需求在B端是及其複雜而多樣的，憋在辦公室是無法做出好產品的，所以需要從制度上驅動研發、產品和設計走向客戶，而不是待在象牙塔。
研發下鄉給了每個研發人員固定的指標，需要下鄉到客戶現場，所以銷售和客戶成功有了正當的理由要求研發同事完成指標，從另一個方面也加強了研發和業務部門的配合與協作，因為雙方有了共同KPI的時候，大家綁在一起去做好一件事的動力就變得很強。
Polish Week
Polish Week是來自矽谷的流行文化，讓研發團隊在一個緊張迭代之後，有足夠的時間可以休息一下，然後集中火力解決來自客戶的需求或者問題，這種制度設計是非常高效的方法，可以短時間集中兵力解決遺留問題。
技術分享和走出去
5年下來，我們技術團隊每週分享已經正常進行了幾百次，研發團隊中的每個人都或多或少完成過對於所在部門的技術分享。新人來到團隊，可以從過去數百次分享留下來的知識收穫非常多的遺留知識。
（在研發體系共享的技術分享池）
另外一方面，Worktile 的核心客戶本來就是研發團隊和工程師，市場維度需要研發人員能夠不斷共享有價值的技術內容，而技術分享機制恰恰提供了驅動工程師內容創作的土壤。每次內部分享的內容，其實完全可以繼續優化成外部可以傳播的內容，通過市場手段實現二次傳播，同時也能夠將團隊中有活力和分享精神的小夥伴，推到前臺去技術大會或者公司組織的技術分享大會分享。
// 未完待續，接下來會再談談研發中的Scrum和OKr，以及研發績效、工具化等。
本文作者：Worktile CEO anytao
文章來源：Worktile官方部落格
歡迎訪問交流更多關於技術及協作的問題。
文章轉載請註明出處。