網際網路公司研發效能團隊為啥必須獨立?何時獨立?

2022-06-10 12:05:51

 

上期發表了一篇文章「 中小網際網路公司研發效能團隊規模、職能劃分和優劣勢分析」, 左一小夥伴就提出來一個問題,研發效能團隊必須獨立麼?這個問題很好,終於從給 svn 打 tag 這類技術問題開始轉到團隊建設和組織架構問題了。

其實這個問題可以類比一下:

  • RD 團隊必須獨立麼?

  • 產品團隊必須獨立麼?

  • QA 團隊必須獨立麼?

  • 運維團隊必須獨立麼?

  • 設計師團隊必須獨立麼?

這樣就容易得到答案了。按照職能來劃分,越早獨立會越好,1 人也可以是個獨立團隊,直接彙報高階別領導,獨立開展業務;按照人數來思考就是 1-4 個人的時候不是必須成為一個獨立的團隊,合作、共建、兼職、虛擬團隊也許是個不錯的選擇,但是當團隊大了後(4 人或者 4 人以上)成為一個獨立的團隊就會勢在必行。具體什麼時候獨立,幾個人獨立,這個和公司定位、已有組織架構、領導認知都有很大關係。

 

「DevOps 研發效能群」:

左一的問題:為啥研發效能團隊必須獨立?

清川:不獨立咋體現價值

韓老師:大小總要有個團隊嗎?不能兼職是不是?虛擬也是個團隊

研發效能團隊必須獨立麼?不是必須,有的團隊都沒有專職的研發效能工程師,都是其他人員兼職在做,談不上獨立。

有專職的研發效能工程師就必須獨立麼?也不是必須。較少的研發效能工程師無法覆蓋所有的工作職責,更容易孤立,無法提供有效支援。

場景設定:效能團隊 1~4 人

講問題要有背景和場景,唐洪山唐老闆指出了這一點,我覺得很好。比如在這篇文章中我們有這樣的場景限制

  • 產研人員小於 200 人

  • 效能團隊 1~4 人

我們假設就是 100 人的產研團隊,分成兩個大部門,2 個研發效能支援人員,每人支援一個。其實在這種情況下,2 個人去支援 50 個人還是挺吃力的。這個時候部分職能由其它相應的人員承擔才能維護整個研發體系正常運轉,比如

  • 每個研發效能小夥伴支援一個業務團隊,分別隸屬於自己的業務團隊

  • PMO 同學監管 Jira 的使用培訓和許可權分配

  • 運維小夥伴兼職部分研發效能系統維護工作,背 SLA 指標,同時負責資料備份

從上面可以看到,實際上我們雖然只有兩個專職的小夥伴,但是通過兼職、共建的合作方式,我們已經是一個四人的虛擬小團隊了。區別就在於專職的研發小夥伴支援實際業務,其它共建的任務由其它 PMO、運維甚至 QA 兼職完成。團隊小其實對於個人成長有個很大的問題,不容易找到特別資深的人,招到了如果公司發展得慢也不容易留下;招資歷比較淺的,又不利於成長,也待不久。

舉個例子:

我們部門自打有設計師的時候就是獨立的團隊,直接彙報給大老闆。同時負責部門內的所有產品,最大程度保證所有產品 UI 都在比較高的水平。設計資源最大化利用對於公司也是合理的。

當產研團隊成長到 4 個部門,200 人的時候,研發效能的小夥伴也增加到 4 位專職人員。這個時候工作內容和權責就需要梳理下

  • 4 個業務部門,每個業務部門 50 人。每個業務部門都是需要 1 個研發效能的小夥伴支援的「業務支援工作」

  • 4 個業務部門需要支撐的工作量不同,APP 端和伺服器端兩個部門支援工作量巨大,2 個創新部門相對少。「支援工作量差異較大」

  • 公司開始注重規範流程建設,需要統一 4 個業務部門的流程「橫向拉通工作」

  • 因為已經有 4 位專職小夥伴,PMO、運維和 QA 的小夥伴期望研發效能團隊承擔更多的工作「基礎設施」

  • 4 位專職的小夥伴資歷、能力差異較大。一個剛畢業的小夥伴,一個資深的;一個指令碼小子,一個社交達人

 

團隊組織架構方案

這個時候我們面臨的選擇有兩個。

方案一、保持虛擬團隊

第一個方案是依然保持之前的虛擬團隊,每個專職小夥伴負責對應的業務團隊支援工作,共建的部分依然由其它團隊支撐。存在的問題是:

1)剛畢業的小夥伴態度好但無法獨立支撐一個業務線,需要有人帶

2)資深員工支撐目前業務線綽綽有餘,感到沒有新鮮感,想主動承擔更多職能向上發展

3)指令碼小子做一些指令碼沒問題但是溝通能力不強

4)社交達人流程梳理、改進、實施這方面給力,指令碼能力不行系統管理經驗欠缺

 

方案二、獨立團隊

第二個選擇,相關職能合併到一個研發效能團隊。資深員工做團隊 Lead,帶領其他小夥伴一起完成工作。具體做法如下

1)滿足了資深員工對管理的訴求,積極性立刻打滿

2)校招生得到資深員工的指導,承擔更多業務支撐工作,個人成長迅速

3)指令碼小子承擔小部分支撐工作,同時把大部分精力放到系統穩定,平臺建設上

4)社交達人負責整體橫向工作,流程改進優化進展神速,工作得到公司領導好評

 

帶來的變化 1)資深員工需要培養、提高管理職能 2)每個人各自承擔部分業務支撐工作互為備份, 同時也各自承擔公共職能。

 

對比結論

通過上面兩個方案的對比,人數少的時候直接進入團隊,業務閉環,有利於開展業務,更接地氣;人數多的時候組成團隊更具有韌性,既滿足了業務對於研發效能團隊的訴求,同時也有利於研發效能團隊的穩定,可以人盡其才針對每個人不同的經驗和能力分配不同的工作,也滿足了員工各自的訴求。

 

按照職能來劃分,越早獨立會越好,1 人也可以是個獨立團隊,直接彙報高階別領導,獨立開展業務;

 

按照人數來思考,1-4 個人的時候不是必須成為一個獨立的團隊,合作、共建、兼職、虛擬團隊也可以,但是當團隊大了後(4 人或者 4 人以上)成為一個獨立的團隊就會勢在必行。

 

具體什麼時候獨立,幾個人獨立,這個和公司定位、已有組織架構、領導認知都有很大關係。

 

參考資料:

 

研發效能團隊規模、職能劃分和優劣勢分析概述

 

中小網際網路公司研發效能團隊規模、職能劃分和優劣勢分析

 

一二三線網際網路公司劃分標準和榜單