<mark id="oztn4"></mark>
0
| 本文作者： 代潤澤 | 2021-10-15 15:04 |
導語：華為軍團的靈魂三問：Google為何反對“大軍團”模式、華為能否學成Google“小軍團”戰術、軍團如何實現三權分立？
作者 | 代潤澤
編輯 | 馬曉寧 王亞峰
華為再度創建了四大“軍團”。
何為軍團？簡單來講就是華為把企業BG、運營商BG、云BU等核心部門的將才，整合在一個個以細分場景（如海關、公路、能源、光伏）為單位的獨立部門中，為客戶提供一套更全面的解決方案。
好比讓專職料理鮑魚、海參、魚翅、魚唇等食材的幾位廚師，聯手為顧客提供一道每類食材味道都無可挑剔的佛跳墻。
而軍團設立的因，則是數字化沖擊傳統產業的果。
當前的傳統政企機構，急需提升硬件、軟件、高速網絡等IT基礎設施的性能，而過往華為每個BG單兵作戰，只能解決客戶的某一類訴求，無法同時實現對客戶“云-管-端”的一體化改造。
這過程中，各BG/BU也試圖為客戶提供更多服務，因此踏進其他BG/BU的領地，越界、內斗、搶客戶事件頻頻發生，資源和資金重復投入，技術和產品重復建設，組織問題頻出、內耗嚴重。
尤其是在外患的大背景下，讓各BG的產品和服務能力融合，以場景為單元，快速生長，集中輸出，迫在眉睫。
這也是任正非親自制定并督導軍團的重要原因。
與此同時，為了讓軍團擁有較大的獨立權，任正非賦予了華為軍團與運營商BG、企業BG、消費者BG等同的部門地位，同屬于集團一級部門。
但軍團模式的推進，會產生兩大組織問題：
其一，大軍團模式，雖然有望讓華為更快破局，但從長期來講，該模式會帶來軍團獨大后“失控”的后果。
其二，具體項目的研發，任正非學習借鑒了Google“小軍團”模式，讓算法研究員打頭陣深入到項目中去。
而現實是，當前的華為并不具備Google小軍團作戰的工程人才儲備，能否把該模式進行本地化改良，過程中仍存在著不少坑。
關于大軍團和小軍團組織模式的利弊，接下來我們一一講述。
任正非曾在接受采訪時強調：“軍團”就是把基礎研究的科學家、技術專家、產品專家、工程專家、銷售專家、交付與服務專家全都匯聚在一個部門，縮短產品進步的周期。
而與之相反的組織設計，便是研究、工程、產品、銷售、交付各自成獨立部門，每項業務的推進都需要不斷進行跨部門來協作。
這種組織設計結構在大公司中十分常見，我們在此稱之為“反軍團模式”，或是功能型組織結構。每個部門承擔各自的功能。
歷史上頗為知名的案例是發明了Java的SUN公司，在鼎盛時期從“反軍團模式”，轉型為“軍團模式”，最終以失敗告終。
Google前CEO施密特曾在《重新定義公司》中寫道，早期他在SUN公司擔任CEO時，SUN公司隨著業務越來越復雜，公司決定重組，分設多個業務單元，新設的單元稱之為“行星”，與華為的“軍團”相似。
每個“行星”獨立運作，人員配置五臟俱全，自負盈虧，SUN公司的員工經常會用“自掃門前雪”來形容每個單元各自為政的情況，甚至認為集團的戰略、文化、價值觀，與他們無關。
最終，SUN的行星結組織構，對企業的生產力造成了重創。究其原因，這種制度使得各單元的領導者，不再潛心研發那些能為企業真正贏利的高質量產品，而是一心盤算著如何提高營收。
而施密特在擔任Google CEO后，受佩奇和布林等人的影響，谷歌堅持按職能劃分部門，將企業分為工程、產品、財務以及銷售等部門，每個部門直接向CEO匯報。
施密特為代表的Google管理層一致認為，以業務或產品線為基礎的組織結構，會造成“各成一家”的局勢，從而對人員和信息的自由流動形成扼制。
每個部門自負盈虧、自主獨立的措施，看似有利于加強業績，卻會使各業務部門的領導者把自己部門的盈虧置于企業整體利益之上，從而對部門的發展方向造成誤導。
軍團模式的好處，初期階段，像任正非所說的，能夠快速成長，運轉更加靈活。
弊端在中后期也顯而易見，如施密特所言，自成一派，軍團利益高于集團利益，讓集團失去向心力和控制力。
那么施密特提倡的“反軍團模式”，就是正確的嗎？并不見得。
一直以來，反軍團模式，都被大公司認為是效率的最大攔路虎。
華為在過去的幾十年間，飽受反軍團模式之苦：業務部門和IT部門一旦獨立運營，效率大幅折損。
過往的華為，IT部門和業務部門如孤島般彼此隔離，而作為支持單位，IT部會同時服務成百上千個業務單元。
華為CIO陶景文曾談道，常見的業務部門和技術部門協同過程，是業務部門先提出需求，然后與IT部門開會，梳理清楚需求后，IT部門對需求進行規劃排期，開發完畢再交給運維人員做好保障。
“這種方式很像是擊鼓傳花，看上去每個人分工明確，流程順暢，但實際上，只要經歷過的人都知道，這種方式是有問題的。”
第一個問題就是慢，需求從提出到實現，周期很長，使得時間和人力成本雙雙變高。
“最讓抓狂的是，這種方式會讓原本簡單的事情處理起來非常難。各個業務部門都會向技術提各種需求，技術到底把資源分配給誰？各個業務領域都去跟技術團隊溝通，做調整，可能開完五個會之后，原本優先級最高的那個需求就變成最不緊急的需求了?！?/p>
在《鳳凰項目：一個IT運維的傳奇故事》一書中提到，在IT和業務協作過程中，會出現部門不配合、“各掃門前雪”的現象。
換句話說，拋開技術層面，從“人”的角度來看，各部門間如何做到真正的信任？
該書表示，信任包含了業務部門和IT部門之間，IT部門內部如開發、測試、運維、安全等之間，甚至是IT部門與IT外包之間……
吃了多年的IT與業務協同之苦后，2010年之后，華為開始采用項目型組織。
業務人員和IT人員組成一個項目組，去解決特定的問題，解決完后，項目組解散。
但這又引發出新問題：能力無法固化下來，容易流失。臨時組織只對項目目標負責，不對長期結果負責。致使項目組織，無法把做項目得來的數字化賦能經驗，沉淀成公司的能力。
因為慢、貴、難，以及能力流失等問題，華為開始考慮優化組織，最終確定了“業務IT一體化”的組織模式。
在華為看來，這是當前數字化轉型過程中最好的一種組織方式。
華為認為，技術必須懂業務規則才能施工，業務必須和技術的流程相配合。只有指導員和官兵們在一起，最新的思想、前線的戰況，才能互相同步，把支部建在連隊上。
再次回看任正非這句話，會發現業務IT一體化，本質上是軍團的底層組織保障：“華為的軍團就是把基礎研究的科學家、技術專家、產品專家、工程專家、銷售專家、交付與服務專家全都匯聚在一個部門，縮短產品進步的周期，把業務實行顆?；??！?/p>
技術根據業務的需求生長，IT技術能力也能成為企業核心能力要素，能更好地支持企業數字化轉型。
業內人士曾向雷鋒網表示，華為的IT技術能力是自上而下的，也就是領導層本身就是帶著數字化意識、能力管理公司，然而這樣的能力并不是所有的企業都具備的。
華為的五大軍團，就是在這一背景下誕生的，它們的歷史使命是進一步把行業做深做透。
但問題來了，無論是軍團模式，還是反軍團模式，都存在著顯而易見的利弊。
那么未來該如何進一步優化組織結構，才能讓軍團在變大變強后，仍舊在集團的控制范圍內，并且把集團的利益，放在第一位。
軍團的反失控，本質上是對軍團權力進行拆分，多方互相制衡，防患于未然。
尤其需要將軍團、人事部、核心技術部，進行三權分立：授予人事部更高的話語權、把基礎技術產品掌握在集團手中。
我們知道，腦力勞動密集型企業的人事部，往往形同虛設，如互聯網公司當中人事部門，并沒有過高的話語權，對企業和業務的經營，起到重要影響作用。
而Google在權力分配上，則賦予人事部非常大的權力。
Google前高管告訴雷鋒網，當項目結束，或者產品已奠定行業地位進入“守城階段”后，作為資源池的人事部，有權力直接將部分人力抽回，投入到創新業務當中，不讓員工待在自己的舒適區，同時阻礙這些部門占山為王，形成挑戰集團的派系勢力。
而多數企業的人事部并沒有如此之大的話語權，因此人員的調離和權力的稀釋，往往需要公司董事長親自出面調整，而當問題大到需要董事長協調時，意味著組織痼疾已堆積嚴重，調整阻礙重重，覆水難收。
鮑爾默時期的微軟，就是典型代表。
20世紀的微軟仰仗著強大的產品、銷售和法律能力，讓Windows和Office兩大產品線在市場上一度沒有對手。在微軟內部，這兩大山頭也越來越大，團隊人數和資金投入猛增，但不見任何重大創新，還處處打壓其他部門，不思進取，讓微軟集體錯過了移動時代。
直至納德拉上任后，微軟才正式刷新，成為云與AI時代的引領者。
用納德拉的著作《刷新》中的一句話來說：每一個人、每一個組織乃至每一個社會，在到達某一個點時，都應點擊刷新——重新注入活力、重新激發生命力、重新組織并重新思考自己存在的意義。
而Google正是賦予了人事部“刷新者”的角色。
人事權力分立外，還需對基礎技術部進行分立，把核心技術和底層技術產品控制在集團手中。
早些年，騰訊前CTO張志東與部門技術線、業務線高管，在某項基礎技術的組織劃分上，產生了分歧。
前者認為該基礎技術和技術團隊，應該由技術部統一管理，給各個業務線做支撐。而后者則認為，該技術團隊應該打散，融入至各業務線當中，與華為的“業務IT一體化邏輯”及出發點相似。
兩種模式如我們文章前半部分所說，各有利弊。
但多數企業為了更加敏捷，在發展最迅猛的階段，選擇了后者，這也是為何當今絕大多數科技巨頭不需要CTO的主要原因。（關于大公司不需要CTO這一話題，雷鋒網將在近期發布深度解析文章）
多年后的今天，CTO張志東雖已離開騰訊，但它的技術組織理念，其實仍有所延續：騰訊是中國互聯網公司當中，唯一有著接近萬人規模的獨立技術事業群（TEG），從某種程度上講，承載著“分權”的使命。
當今的騰訊，一部分技術人員融入至其他事業群、而一部分則歸屬于TEG，從事基礎技術支撐的研發，把整個公司的核心研發和技術產品掌握在手中。
推動獨立的技術部門，掌控業務線的核心技術命脈，對其形成一定的權力制約，或是一種變向卡脖子。
無論是人事分權，還是基礎技術分權，其都是組織戰略層面的設計，但執行過程困難重重，如同煉獄。
商業世界永遠沒有長期正確的戰略，但有當下正確的戰術。
而華為戰術的主角，則是“小軍團”。
2019年，任正非在講話中談道：向Google軍團學習，編制不大，但戰斗力極強，撲上去，殺出一條血路。
“我們算法團隊要直接殺入到項目中去，一線既有算法又有數據，就容易突破。你們組織優秀的博士形成一個Google式軍團，撲上去，就可能把口子撕開。抽象的平臺一定要有實踐東西檢驗，多幾個具體化的平臺，綜合起來才會有抽象平臺。別關在深宮大院里面，到戰場上去，立功去，說不定你就從少尉升少將了。希望你們的Google式軍團能率先殺出一條血路來，成功了我會來看你們?！?/p>
分析華為學習Google小軍團戰術的利弊之前，我們先來看看Google小軍團的真正主軸心：工程師。
這里的工程師是指狹義上的工程開發人員，而非廣義上的工程+研究人員。
《紐約時報》曾寫道，在2004年，有3萬多員工的微軟的創新，居然比不過不到2000人的Google?！都~約時報》認為差距在于，微軟的開發模式沒有Google的效率高。
當時的微軟，有700多名做算法的研究員，且都是博士，但是他們的研究的和工程開發存在嚴重脫節，研究的部分技術，并沒有應用價值，工程也無法實現。
而Google則是研究和工程開發不分家，Google沒有嚴格意義上的研究部門，所有開發人員遇到實際問題需要研究時，因為沒有可以指望的研究部門做后盾，只能自己動手。Google雖然有一個很小的研究部門，但是所有的研究員都在第一線做開發。
這種工程文化，無疑受到兩位創始人和Jeff Dean的技術理念影響。
這要求Google每個工程師不僅要會寫程序，還會做研究。
這么高的人才要求，唯一的解決辦法是盡可能地招動手能力強的博士。因此，Google也就成了全球單位辦公面積博士最集中的地方。
此外，Google也傾向招募有著工科博士背景的產品經理，進一步降低工程團隊和產品團隊之間的溝通成本。
但需要注意的是，Google的小軍團發起點是工程師，而從任正非的發言中可以分析出，華為“小軍團”的發起點是算法博士（即研究員），華為讓算法研究員們打頭陣，深入到項目當中。
華為的小軍團：研究→工程→產品/項目
Google的小軍團：研究←工程→產品/項目
Google式“小軍團”運轉，需要滿足三個基本條件：共識、共同話語體系、無背景（學歷）歧視。而研究員歧視工程師和產品經理，工程師歧視產品經理，在國內已是常態。
反觀華為，任正非的小軍團組織設計邏輯是，直接讓研究團隊殺入到項目當中，但中間還隔著一道工程的鴻溝。
由于工程和研究培養體系在時間上整體晚于歐美，國內的絕大多數研究員，并不具備出色的工程開發和代碼水平，他們深入到項目的前提，是先同工程團隊協作，隨之雙方再與產品/項目團隊協作。兩層協作關系的推進，無疑讓這種“小軍團”協作和信息流通效率，大打折扣。
而Google以工程作為軸心，上碰研究，下碰產品，軍團的協作效率以及跨部門溝通成本，可降到最低。
微軟式的研究與工程獨立分拆模式，也被國內的BAT以及頭部AI公司商湯、曠視等企業沿用，究其根本，畢竟能做研究的工程人才可遇不可求。
而這類人才一旦稀缺， 小軍團模式的推進，也相應會受到限制，因此華為要成功將Google小軍團模式成熟應用，仍需不斷地進行本地化探索，適配自身特性。
當然，Google式的、以工程師為軸心的小軍團，更多可在技術門檻頗高的項目中扮演重要作用。
而在做部分技術門檻較低的數字化賦能時，是否擁有杰出的工程人才，其實并不重要，重點在于交付和服務質量。
于是在交付和服務上，華為采用了“鐵三角”和“鐵四角”的小軍團作戰方法。
華為內部人士告訴雷鋒網，鐵三角和鐵四角，這種如同特種部隊的模式，能讓單兵能力非常強，目前在華為企業BG表現得非常突出。
鐵三角，即一個項目，三人服務：客戶經理、產品經理、交付經理；
鐵四角，即一個項目，四人服務：渠道經理、客戶經理、產品經理、交付經理。
鐵三角和鐵四角“小軍團”模式對企業來說，在多種組合的配合下，根據不同項目情況安排合適的人手，這樣的方式更靈活，每個人都可以調動起來完成任務，因此在做大項目攻堅戰的時候，甚至輪值CEO都可以來支持。
可以預見，這種小軍團的作戰模式，會在華為的煤炭等五大軍團中頻繁出現。
當下的華為，在多種核心業務受挫的情況下，進入了“刷新”期。
而大、小軍團的組織作戰方式，正在成為自我刷新的重要形態。
歷史上的任何一場組織革新，都是一場持久戰，如任正非所言，在管理和流程上要堅決反對盲目創新，要在原有的基礎上不斷改良和優化。我們要持續百年地不斷改良，不要隨意地改革，改來改去的。只有歷經數年充分認證，才能進行必要的革命。
雷鋒網雷鋒網
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
