今天的主題是關于團隊組織方式的。

    后數字化時代，傳統企業數字化部門早已經不止是最開始打江山的5、6個人的小團隊。

    團隊里的角色會更多樣化：產品經理、業務分析師、測試工程師、數據工程師、前端開發、后端開發、運維人員、線上運營推廣這些都是常見的角色。對于質量要求較高的團隊，甚至測試工程師就會有幾十個，還會分為技術測試和功能測試不同角色，如果規模更大，還會有專職的架構師團隊，PMO團隊，如果還有敏捷角色的話，還有敏捷教練，DevOps等角色，另外，可能需要再加上管理崗和協調崗……

    此外還有公司內部，因地制宜定義出來的崗位title。

    這么多的崗位和角色該怎么管理呢？如何更高效地組織呢？這是每個數字化部門領導都在思考的問題。

    有的崗位人數眾多，管理工作繁重；

    有的崗位人數少，但需求又不穩定，不一定夠飽和；

    有的崗位需要對接非常多的其他部門，信息非常集中，嚴重依賴一兩個人成天“救火”；

    有的崗位交給了外包團隊，有的崗位還是內部、外部和來自不同公司的外包團隊混合編制。

   這些都是組織結構上經常遇到的問題。

    我們的第一反應是按崗位職能劃分，建立職能部門，因為傳統企業一直就是這么做的。

    于是就有了第一批基層領導。

    馬上，我們會發現這些需要緊密協作的職能部門之間，扯皮打架、甩鍋不斷。

    于是我們再建立起第二批中層領導，來管理這些基層領導。

    隨著業務或者組織越來越復雜，我們發現依然很吃力的時候，我們再添加一層管理層，來管理這些管理層。

    ……

    管理金字塔越搭越高，管理層離一線工作越來越遠，管理成本占研發成本的比重越來越高，組織越來越重，直到一天我們決定推倒一切重組，但是換個方式搭金字塔是不是就沒問題呢？

    有沒有其他可以嘗試的選項呢？

    老規矩，討論解決方案之前。我們可以先聊一下，傳統企業數字化部門的組織結構，都有哪些特點。

特點1 地盤不明確。

    在傳統企業里，其他各部門已經成功運轉了好久，每個部門都有自己穩定的“地盤”，制造，銷售、市場、財務、法務、人事等等。一個企業運行了這么久，這些部門已經有了相對明確的邊界、分工，在企業中肯定有自己明確的價值，否則早就不會存在了。

    而數字化部門像一個班級里的新生，最好是與其他人合作，也就是我們常說的內部賦能。

    但是，是數字化產品為傳統產品賦能，還是傳統業務為數字化產品賦能呢？坦率來講，不同人心中肯定會有不同的答案。

    緊接著，問題來了，臨界在業務領域和數字化領域之間的灰色地帶，屬于誰的地盤或者責任呢？

    這些新的領域，數字化與傳統業務結合形成的新業務，根據項目而異，根據團隊而異，根據各領導的性格而異。

    不同部門各自的職責邊界，絕對不是一兩句話就能劃分得清楚的。即使分清楚了，也只能是暫時的，尤其在大企業中，更難做到一刀切。

特點2， 很容易變得臃腫。

    一個專業軟件公司，開發一套軟件，給成千上萬、甚至數千萬上億的用戶提供服務，是一個非常復雜的過程，需要非常嚴謹的工作流程，涉及到許多方面的專業知識。不是簡單的做一個頁面，做幾個按鈕，幾個表單那么簡單。

    要考慮的內容太多啦，產品是不是偽需求？界面交互是否人性化？系統架構是否合理，是不是小小的改動，就牽一發動全身？業務數據是否有歸口統一治理？是不是經常數據顯示不正確，各種數據對不上？有沒有敏感數據泄露？說是測試了，是不是上線一堆bug？產品性能如何，是不是按一個按鈕等好久，幾個人用就很慢？系統是不是不知道為啥就崩了？最后產品上線了，有沒有人用？產品到底是給人添麻煩了，還是帶來便利了？

    這么多問題想想都頭大。這都是專業活，需要專業軟件角色的專業技能。

    在傳統行業的數字化團隊里，不會因為主營業務不是軟件產品就降低要求，相反，要求會更高。當傳統企業的數字化部門不得不支持一大堆老舊系統平臺互相關聯，一大堆新老數據，互相依賴又互相矛盾的時候。數字化團隊的產品和組織常常會比一個正常的軟件公司更臃腫，更復雜，需要考慮的因素，牽扯到的內部客戶和外部客戶只會更多。

    為了應對復雜的業務背景，怎么辦？加人唄！一個不小心，組織就會變得很臃腫龐大。不加人也可以，十口鍋，八個鍋蓋，哪里需要哪里蓋。這種情況下，團隊覆蓋的業務又臃腫了，好像方方面面都涉及。

    最后，這么多人，這么多業務，誰在干什么都很難說得清楚，職責邊界更難界定了。

特點3， 變數大，不穩定

    首先是業務內容的變數就會很大，之前幾期也說了，數字化部門想做什么往往并不由自己全權決定。公司層面的戰略，客戶的需要，政策的引導，以及公司經濟財務狀況都直接影響數字化部門的業務活動，在這些事情都考慮完了之后，還會考慮數字化部門自己內部想做的創新嘗試，可能成功也可能失敗。所有這些因素都是不定性的，數字化部門只能接受這一點。

    其次，項目周期自身也會帶來變化，一個軟件項目，最開始可能只是幾個人去驗證方向，建設期需要大量投入人力，產品成功上線，進入維護期，又不需要那么多人了。而且經常需求要的很急，終止的也很快。項目或者產品的正常生命周期就是這樣，那么這些人從哪里來，到哪里去呢？

    人員的變動也是常態，一方面是離職，以我的觀察，傳統企業數字化團隊的離職率一般是高于穩定的產品開發團隊的。另一方面，數字化團隊的成員常常會被當成“資源”，資源是隨著需求走的，“我是一塊磚，哪里需要哪里搬。” 很難做到讓小伙伴們專注在一個項目或產品上，甚至短期專注都很難做到。

    不同事項之間優先級和緊迫性會不停的變化，管理層會承擔很大的壓力，只能協調這些“資源”，在不同的事項上來回切換。

    “一會做一下這個項目，一會做一下那個產品，感覺自己是個打雜的?！边@句話我聽過無數次了。

    無論是人員在項目之間來回切換還是人員離職，組織的穩定性肯定是會低的，帶來一系列壞處不用我多說。

    上面說了傳統行業數字化部門的組織結構的三個特點，

    1.地盤不明確

    2.很容易變得臃腫

    3.變數很大，不穩定

    按老規矩，肯定還有其他的特點，今天只列出來三個。

    這些特點與其他部門會有很大反差，以銷售或者商務部門為例，不可能今天讓這個銷售跟這個客戶，明天讓他對接那個客戶，大家都知道蜻蜓點水出不了業績。產品或者市場需要做的邊界也很清晰，相對來說都會比較專注。

    所以數字化部門必須琢磨出自己的一套管理體系和組織方法，并不能照搬其他部門的方式，其中職能部門的建立，就是一個例子。

    明確一下，我們說的職能部門，指的是：測試部門，開發部門，設計部門，等等各種根據崗位角色劃分的部門。

    合理的職能部門需要有明確的職責邊界，負責的工作與資源能夠合理匹配，人員和業務相對穩定、專注。

總之一句話，“打雜”從來不能是一個職能部門的主營業務。

    當這個職能部門招聘的JD，也就是崗位說明，很難用幾句話說清楚，或者JD和具體工作內容大相徑庭的時候，就應該知道職能部門已經不好用了。

推薦實踐：

    如果不專注和不穩定已經成為困擾團隊的一個重要因素的話，有幾個可以嘗試的實踐：

1. 圍繞業務建立全功能小隊，提升專注度。

圍繞不同業務領域建立多個小而輕的全功能團隊，盡可能讓每個團隊在一段時間內專注于一個業務領域。

專注的時間越長，業務領域越純粹，越可以增加團隊的專注度，更關注產品，關注業務，這個條件下，團隊把上下游分工理順，積累業務知識，提升產品質量，都會是很有利的。

1. 建立“救火小隊”，限制突發需求和雜事的影響范圍。

在實踐中，難免會有一些突發的雜事、必須要應付的，優先級又高的短期項目，尤其是一兩個星期或者幾天內就要滿足的需求。像這種突發性強的雜事，難啃的骨頭，可以統一歸口到一個特定的小組里面來。把不穩定性和突發事情限制在這個“救火小組”里，而不去攪亂整個組織。

得讓大家知道，這個小組為了大家的專注，而犧牲了自己的穩定。同時這個救火小組里的成員，需要他們的性格匹配這個崗位，喜歡接受挑戰，希望嘗試不同的內容，最后公司內部升遷或者加薪要注重考慮這些救火小組里的消防員們，也應當重點關注他們的情緒。

如果實在沒有合適的人選組成這個小組，那么就采取不同小組輪值當“救火小組”的方式，起碼讓大家有一個心理預期，在這段時間內，我們會去處理一些雜事，其他的事情我們會放一放，突發的要求會很正常，但是下個時間段，我們會回歸到專注上來。

同樣是做事，建立心理預期之后，大家的心態會好很多。

1. 建立社群

想必大家也想到了，圍繞著不同的業務線建立全功能團隊也會有一些問題。比方說，重復造輪子的問題，業務孤島的問題等等……

這些可以通過社群的方式來優化或者解決，我們將來在另外一期專門來聊一聊社群的好處和玩法，有些時候能夠代替職能部門起到很好的收效。

    總而言之，數字化部門的組織架構有自己的獨特性，并不能照搬其他部門的管理方式。

    并且，數字化部門的組織架構是一門綜合學科，并不是某個敏捷實踐或者采用一個JIRA工具就萬事大吉，需要一系列的實踐和組織方式來不斷優化。

    從根本上來說，組織架構的根本出發點，是應該去創造足夠的條件，讓團隊能夠自己去解決他們所面對的問題。

    除了人力資源，預算這些剛性的需求之外，更多的專注，更多的穩定性，應該是組織上能夠給到團隊最大的幫助了。

    今天聊了數字化部門里面的組織結構，并不是推銷什么萬能解藥，而是思考，組織如何能夠更好幫助到團隊。

    還有什么是組織應該給到團隊的幫助呢？歡迎大家留言討論。