DevOps|研發效能團隊組織架構和能力建設

laofo(公眾號scmroad)發表於2023-09-25

研發效能團隊相對於各個公司主營業務規模來說並不是很大,但是在經歷的幾家公司裡主要是有兩種組織架構,職能獨立型組織架構和業務閉環型組織架構。本文主要講解這兩種組織架構的特點、優劣、劣勢。

業務閉環組織架構

DevOps|研發效能團隊組織架構和能力建設

這裡引入了一個概念-特性團隊,以及特性團隊的負責人(FTO),更多的內容在我之前的文章《研發效能組織能力建設之特性團隊FeatureTeam(上)》有過介紹,這裡只把一些關鍵點列出來。特性團隊是一個長期穩定、跨職能跨元件、持續端到端交付使用者價值的團隊。特性團隊就是一個業務閉環的組織架構。圖中的負責具體業務的運維人員、QA、設計師甚至都可以閉環到業務中去,這樣整體效率會更高。

業務閉環組織架構特點

  • 最大化響應速度
  • 最大限度減少外部、內部依賴
  • 最大限度降低溝通成本
  • 最大限度降低決策成本
  • 責、權、利對等

 

業務閉環組織架構好處

  • 交付快,單位產出多
  • 小步快跑,唯快不破,精英小團隊
  • 團隊內可以做到端到端交付,極少等待時間,交付速度快
    • 一手的資訊來源,從頭跟到尾的負責制模式
  • 減少團隊之間依賴,計劃更容易、更有保障
    • 如果團隊間有依賴,那肯定是弱依賴,如果是非常強的依賴,團隊內部要麼有人主動出來承擔這部分工作,要麼閉環到團隊內部。
  • 團隊內部快速溝通、交流、決策,快速響應使用者的訴求
    • 大家都圍繞著幾個桌子坐,每日例會,平時有問題快速溝通。
  • 以業務為中心、以使用者為中心驅動團隊運轉
    • 閉環團隊的工作人少活多,強調自我驅動、主動承擔。
  • 責、權、利對等,成員責任心、自驅力高
    • 大家每天坐在一起工作,每天做什麼,做得怎麼樣,團隊貢獻度,每個人心裡都有一杆秤

 

業務閉環組織架構劣勢

 

  • 團隊整體壓力大
  • 對業務閉環組織的負責人(FTO)要求高,定方向、搭班子、帶團隊的綜合能力都要很出色。FTO不但要強於業務,還要在多項職能上都要有很好的判斷,尤其是帶領產品、研發、QA、運維、設計師、運營等多種背景的小夥伴上。雖然很多決定是FTO和團隊溝通後作出的,但是我們依然認為FTO是所有問題的第一責任人,團隊內部所有問題,業務問題等都要FTO擔責,FTO壓力比職能型管理者大很多。千金易得,一將難求
  • 對成員要求高,不斷學習、自我驅動、主動承擔。每日例會,每個人都做了哪些事情質量如何,團隊內部每個人心知肚明,大家都知道。任務催的緊,工作壓力很大,「葛優躺」「摸魚族」難生存,未必所有人都能適應
  • 長期高強度的端到端使用者價值的交付,團隊注意力全部集中在事上,工作壓力大、對團隊內部成員的關懷度低
  • 長時間工作在一個業務領域,部分隊員可能會對做的事情失去興趣,公司、部門需要有便利的內部活水、轉崗制度和機制。很多公司在這一點做得不好,我覺得要放開這方面的限制。
  • 各個業務閉環團隊都會針對自己的團隊、自己的業務非常實際地做出決定,在技術棧選擇、規範性遵從上一般不是很注重,需要技術委員會、專家團隊橫向引導

 

業務閉環組織架構的一個很重要的點在於找到一個懂業務的 FTO來負責整個業務。

 

職能獨立型組織架構

DevOps|研發效能團隊組織架構和能力建設

職能獨立型組織架構特點

  • 每個人都根據專業線,按照職能向上彙報,決策集中在最高領導
  • 當需要做專案時,從產品、技術,運維、QA等團隊中抽調人員組成專案團隊。
  • 一線的專案人員需要按照職能線向上彙報,也需要橫向做專案上的溝通,有更多的溝通、協調工作。
  • 對一線的專案人員要求高。不但要處理好專案上的事情,還需要處理好職能線的事情。
  • 雖然某些公司號稱context not control,但是實際一線的專案人員在某些方面還是無法作出決策的,要不斷的向上反饋,有時要上升到整個組織/團隊的高層,同時也需要不斷的橫向溝通
  • 為了推動專案順利開展,因為涉及眾多角色,需要更多工作流程、平臺的支援,以便減少在模糊地帶、中間地帶的溝通、等待、決策成本。
  • 專案規模大、共享資源多
  • 比較適合成熟的業務,或者團隊比較大的公司

 

職能獨立組織架構優勢

  • 專家領導專家。你的彙報線都是相關職能的專家。上級對下級有絕對的專業判斷。很少會出現外行領導內行。
  • 同一職能團隊內部可以相互交流、相互支援
  • 因為決策團隊中包含了各個職能的相關人員,集體決策。集體決策在大團隊大組織裡永遠是最不壞的選擇,但未必是最優選擇。
  • 面向規則辦事,一切走流程

職能獨立組織架構劣勢

  • 決策鏈路長、決策過程慢,決策時間長
    • 職能線之間達成一致後,再橫向溝通,橫向都滿意後專案才能向下推進。如果有不同意見,那麼只能職能線溝通->橫向溝通再來一遍。
    • 職能線內部也要同時承擔多個橫向專案,優先順序重要度出現變化時,其他職能團隊也需要變化,但未必能及時反應。
  • 責、權、利不對等。「摘桃子」「背黑鍋」常發生。
    • 職能線內部被「摘桃子」「背黑鍋」時常發生。不同職能線基於臉面都是有桃子一起吃,更多的是「被甩鍋」。
  • 各個職能部門的利益與橫向團隊的利益、客戶的需求未必一致,缺少使用者利益的代言人
    • 誰代表使用者誰有決定權。職能獨立型的組織之間,各個職能是互相配合的關係,誰都可以說代表使用者可是誰又無法完全代表。
  • 分割的各個職能部門之間的溝通交流協作耗時、耗力、費心
  • 按照流程做事,集體決策,各個職能部門集體對最終業務成果負責,常常導致無人對業務結果負責
    • 誰都在做事,也都很辛苦,可是最後結果不好,能怪誰?產研運各個職能向上最近交叉點的那個人麼?
    • 更多的對流程、對支撐平臺的反饋、抱怨。但是平臺無法解決解決不了人心。

 

本文總結

本文主要對比了職能獨立型組織架構和業務閉環型兩種組織架構的特點、優勢、劣勢。通常來說對於小組織、小業務、業務目標相對明確採用業務閉環型組織更好。

 

 


閱讀我的更多文章

研發效能組織能力建設之特性團隊FeatureTeam(上)
高效能敏捷交付團隊反思:特性團隊(FeatureTeam)+Scrum
網際網路公司研發效能/工程效率團隊建設和規劃
找到能做好研發效能的人
中小網際網路公司研發效能團隊規模、職能劃分和優劣勢分析

 

 

相關文章