任正非5年後重新強調:華為到了炸研發金字塔的時候

任正非5年後重新強調:華為到了炸研發金字塔的時候

任正非

日前,華為心聲社群時隔5年再次轉發華為創始人兼總裁任正非2016年簽發的郵件《華為到該炸掉研發金字塔的時候了》。

一名華為研發員工在這篇文章中表示,華為在軟體研發領域存在不少問題,這些問題導致華為的IT軟體產品質量比較低下、開發效率低、產品交付週期漫長,讓人痛心。

該文章的再次簽發,是基於近期華為剛公佈的經營業績。

今年上半年,華為實現銷售收入3204億元人民幣,淨利潤率為9。8%;

但消費者業務受到外部影響,收入為1357億元,同比降幅達46.95%。

今年以來,華為的手機出貨量更是顯著下滑。一季度,華為手機出貨量跌出全球排名前五名。據市場研究機構Omdia7月底釋出的報告顯示,目前,華為出貨仍在持續下滑。

今年第二季度,華為出貨980萬部,同比下降了74.6%,環比下降了33.3%。

從市場格局來看,儘管華為依舊以2450萬部位列第六,但今年上半年,華為已經因為外部原因與同期相比下降了三分之二,目前全球前五分別是三星、小米、蘋果、OPPO、vivo,華為七年來首次跌破前五名。

這也意味著,過去,以硬體收入為主的華為,不得不增加軟體方面的投入,擴大軟體服務業務,從而降低對晶片的依賴。

而5年來,華為從前面臨的軟體研發問題,至今未能得到解決。當此之時,重提炸掉軟體研發金字塔,恰逢其時。

研發問題:多頭管理、晉升困難、研發環節脫離

這篇題為《華為到該炸掉研發金字塔的時候了》的作者,網名“泥瓦客”,曾在美國矽谷工作,與世界頂級軟體工程師共事,也帶領團隊交付了許多企業級軟體產品。2016年之前的幾年,泥瓦客進入華為,後來於2016年寫下此文,並獲得了任正非認可,分享給了全體員工。

泥瓦客談到,

在華為做了幾年的企業服務後,他感受到華為公司在軟體產業方面,與世界領先水平差異較大;與中國領先的網際網路產品相比,也存在易用性、貼近使用者和產品快速迭代方面的差距。華為在軟體研發領域存在的問題,導致了IT軟體產品質量比較低下、開發效率低、產品交付週期漫長。

在組織架構方面,泥瓦客認為,華為主要存在的問題在以下三方面:

1、架構設計SE與開發分離:一些架構師與專家基本不懂開發,造成了設計與開發環節之間的脫節,而在矽谷公司,好的架構設計師一般隨時能上手程式設計,且程式設計能力很強。

2、開發者多為低級別,比較難有技術積累:一般基層程式設計師在工作幾年後,都會升值、加薪,成為管理者,一直做開發就會在金字塔的底層;但在矽谷,收入較高、說話有分量的是各層級中的技術佼佼者,因此技術人員不容易流失。

3、多頭管理、溝通成本高:不同的經理在產品開發過程中有不同的想法和意見,可能出現多頭指揮,讓開發人員無所適從,溝通的成本也大。這種複雜的結構會對IT軟體開發帶來很大制約。

作者還表示,開發員工長期在上述流程、組織問題和客戶支援的壓力下加班加點,幾乎沒有時間“抬頭看路”。技術任職上升通道不佳,論資排輩現象嚴重,需要完善獎勵機制。

任正非迴應:直面批評、爭論才是良藥

對於泥瓦客的觀察和建議,任正非迴應稱:“在技術工作的客氣是毒品,直面的批評、爭論才是良藥。”

任正非5年後重新強調:華為到了炸研發金字塔的時候

總裁辦電郵

丁耘也在編者按中提到,華為要清晰地認識到,面向ICT融合時在軟體能力、效率和質量方面存在的挑戰,在組織流程、作業環境等多方面存在的或多或少不適應性和問題。儘管華為在參考業界、反思自己的基礎上,開展了軟體能力建設並取得了部分進展,但要實現期望的目標還需要持續做出更大的努力。

針對該文,員工也發表了一些各自的觀點。

有員工表示,整體觀點還是同意的,部分點比如網路許可權、開發流程、工具等現在很多部門已經優化了,跟網際網路公司也差距不大了,不過隨著公司整體對IT化的思考,應該會越來越好,部分部門有可能在2-5年內趕上業界主流網際網路公司的研發效率。

也有華為員工表示,研發團隊可以考慮採用兩套流程,偏硬的使用IPD,按傳統的重組織架構保收入,純軟的偏網際網路化的用敏捷的團隊管理,避免一刀切。

還有的員工提到,要轉變開發模式,就要改變作戰模式,把大規模的專案模式改成一個個小團隊作戰,就不再需要如此多的技術管理者了,也就是扁平化管理。

華為未來重點:鴻蒙系統和車聯網

華為此時再次轉發5年前的文章,顯然是要強調其從硬體為主的公司,想要轉變為更加重視軟體研發的企業。

4月中旬,華為輪值董事長徐直軍在2021年華為分析師大會上表示,華為面向未來的關鍵戰略舉措之一是最佳化產業組合,增強產業韌性,包括三項具體措施:

一是強化軟體;二是開創和加大對於先進工藝依賴性相對較低的產業的投資;三是持續加大智慧汽車部件產業的投資,尤其是自動駕駛軟體。

分析人士普遍認為,定位為IoT作業系統的鴻蒙,將成為支撐消費者業務的重要動力。

從2019年正式釋出HarmonyOS至今,華為在兩年時間裡加快推進HarmonyOS落地。

截至2021年6月,已經有300+應用和服務、1000+硬體、50萬+開發者共同參與到鴻蒙生態建設當中。

華為的鴻蒙作業系統,不僅可以解決手機作業系統問題,還是華為消費者業務“全場景智慧生活戰略”的核心抓手,也可能是國產作業系統彎道超車海外傳統廠商的機會。

此外,在車聯網方面,據瞭解,華為與車企的合作方式主要有3種:定位為智慧化零部件供應商,直接向車企提供智慧汽車軟硬體智慧化產品;定位為車企平臺化產品及服務提供商,向車企提供多款智慧汽車軟硬體產品組合;定位為智慧汽車全棧式解決方案提供商,向車企提供華為Inside。

目前,華為已推出30餘款智慧汽車軟硬體產品,覆蓋鐳射雷達、車載晶片、鴻蒙OS車機系統、自動駕駛軟體等。在中信證券看來,華為賦能的相關車企,在中國市場有望拿到20%至30%市場份額。

華為多年來一直堅持對研發領域的投入,過去3年,華為把每年近15%的收入投入到研發領域。今年,還會繼續加大研發投入。

(鈦媒體APP編輯陶淘綜合自每日經濟新聞、北京晚報、中國經濟週刊)

以下為內部信全文:

總 裁 辦 電 子 郵 件

電郵其他【2016】071號 簽發人:任正非

轉發《華為到該炸掉研發金字塔的時候了》及評論

按1:在技術工作的客氣是毒品,直面的批評、爭論才是良藥。

丁耘按2:我們在CT領域取得的產品成功不是未來可靠的嚮導,我們必須要持續進步才能適應時代的客戶需求、才能獲得未來的發展。我們要清晰地認識到,面向ICT融合,在軟體能力、效率和質量方面存在的挑戰,在組織流程、作業環境等多方面存在的或多或少的不適應性和問題。儘管我們在參考業界、反思自己的基礎上,開展了軟體能力建設並取得了部分進展,但要實現我們期望的目標還需要持續做出更大的努力,需要生產力持續的提高,在此過程中我們各級主管和專家在思想意識和行為技能上的轉變是關鍵。期望各級主管和專家閱讀所附文章,不侷限於文章中提到的問題建議,深入討論影響軟體研發效率、質量、業務發展的問題,討論中多審視自己、少抱怨別人,天底下容易的是指責別人,難的是改變自己。組織的生命力恰恰在於自我進化能力。我們既需要坐而言,更需要起而行,從自己做起,堅持以客戶為中心,透過點點滴滴、持之以恆的努力,持續有效改進,靜水潛流實現ICT成功的轉型。

華為到該炸掉研發金字塔的時候了

——關於我司軟體研發效率與質量提升的思考

作者:泥瓦客

近年,在從CT到ICT的轉型的過程中,華為公司的研發如何能解放和發展生產力,大幅提升研發效率,是我們未來能否立足於強者之林的一個關鍵。

筆者以前曾在美國矽谷工作,和世界上最頂尖的軟體工程師和計算機領域的牛人一起共事過,也先後帶領過不同的團隊交付了一些業界領先的企業級軟體產品。幾年前進入華為,和幾個做企業業務的產品線有些合作,在此過程中感到華為公司在軟體產業的差距還比較大;和中國領先的網際網路產品相比,在易用性、貼近使用者和產品快速迭代等方面也落後不少。我們在軟體研發領域的確存在不少問題,這些問題導致我們的IT軟體產品質量比較低下、開發效率低、產品交付週期漫長,很是讓人痛心。

因此筆者寫下了這篇文章,希望能拋磚引玉,供大家思考。

一、組織

1、架構設計SE與開發分離,一些架構師與專家基本不懂開發

一般各個產品線都會設有架構設計部,主要成員也會以各個層次的SE為主。這些SE也都曾是程式設計師,但通常因為長期脫離開發部門,主要精力都放在會議、膠片和文件的編寫上,以致程式設計的能力基本丟失,新技術學習的機會也有限。例如一個移動開發的SE,自己對怎麼在Android、iOS上進行開發一點兒都不清楚。在這樣的基礎上,做好真正的架構簡直是空談。在矽谷成功的公司裡,好的架構設計師一般是融入在產品團隊中的,隨時都能上手程式設計,而且程式設計能力非常強。

2、開發者多為低級別,比較難有技術積累

一般基層程式設計師在工作幾年後,有能力的都被提升到PL、PM、SE等職位,員工也都想著被提拔,漸漸成為管理者。大家覺得,光做開發沒有職業前途,永遠都是在金字塔的底層。而在矽谷的公司,說話比較有分量、收入相對較高的有很多是在各層級中的技術佼佼者,他們備受尊重,幹得也開心,不少人根本不願意轉做管理者。

程式設計其實是一門藝術,熱愛和用心是非常重要的,也相應的容易出成績。這就是為什麼在計算機領域,如果做到頂尖程式設計師,一個人頂一百個很正常。如果程式設計師覺得沒有前途,不思進取,而資質較好的很快又被提拔為管理者,那我們的軟體開發將很難有技術和人才的積累。

3、多頭管理

我司負責產品開發的部門有PDT、PDU等,相應的擁有PDT經理、PDU經理、架設部經理和SE、Project Manager、PO經理、RDPDT經理、Line Manager、Project Leader等多個角色。這種組織結構清晰地定義了每個Leader的角色,確保一個大的產品開發週期和質量有保證,同時保證開發的人力得到最合理的應用。

但它帶來的問題也顯而易見,就是各個角色在產品開發過程中有不同的想法和意見,可能出現多頭指揮,讓開發人員無所適從,溝通的成本也非常大。同時,這種複雜的管理結構對需要快速迭代的IT軟體開發也會帶來很大制約。大家看看微信的起家史,應該能感覺到,對於一些相對獨立的、需要快速迭代的IT軟體產品,往往在一個比較強的(產品)經理帶領下的一個扁平化的團隊效率會高很多。

4、溝通成本高

由於組織複雜,中間層較多,各種各樣的任務從上面下來,落實的方法就是各種各樣的會議,所以現在很多研發員工的不少時間都被各種各樣的規劃、研討、問題回溯、客戶支援等會議佔用。員工笑稱:白天是用來開會的,晚上加班才有時間程式設計序。針對於不同的組織和專案,能儘快找出相應的溝通節點並能有效地減少這些溝通節點,是一個專案和部門領導需要經常思考的問題。

二、流程

1、IPD流程不太適合需要快速迭代的軟體

公司引入的IPD產品開發交付流程給公司帶來了巨大的收益。但時代在發展,技術在演進,IPD流程更適合偏硬體的產品開發,為了保障產品質量,開發交付的週期較為漫長。從基層員工的角度,IPD流程節點的很多環節,如為完成CLINT減少Warning的數字、DTS值減少等僵化的指標,實際上反而可能會加大產品的風險,降低產品質量。

2、安全紅線耗費資源巨大

安全紅線的目的是防止產品出現安全漏洞,初衷是好的,但執行起來相對比較僵化,效率也低。試想一個網際網路產品為了過安全紅線一個版本等一兩個月,根本無法生存。

建議參照一些先進公司的方法,把安全意識教育和SDLC(安全開發生命週期)融入到員工日常開發習慣中,在開發的同時進行測試和督促整改,對於一些紅線達標比較好的部門,可以適當放鬆以加快交付,檢查出問題,相應的問責機制要嚴格。把安全意識充分融入到開發者的血液中,讓安全紅線檢查“形同虛設”。

三、環境

1、沒有時間抬頭看路

開發員工長期在上述流程、組織問題和客戶支援的壓力下加班加點,幾乎沒有時間“抬頭看路”,只會用一些比較老舊的技術,也不太會站在巨人的肩膀上前進,走了不少彎路,消耗了更多的資源。

網際網路時代,MOOC提供了大量實時、實用、先進的網上課程(包括免費的和收費的),如Coursera、Udemy、Pluralsight、Stanford Online、edX、YouTube相應的Channel等,想要學的課程幾乎什麼都有。

現在的計算機技術日新月異,新的思想、方法、工具等層出不窮,例如Java語言是2000年左右在企業軟體領域崛起的,幾乎成為很多平臺、服務端軟體的必選,但隨著大規模分散式架構、雲計算的興起,它的短板,如記憶體管理/GC不可控性、多執行緒或是非同步對IO的控制效率,過度依賴較為過載的OOP等問題,如果使用不當很容易造成災難性問題。Google內部漸漸把它們有些後臺軟體都遷移到了他們自己發明的更為先進的Go語言環境下。Dropbox更是兩年前開始使用了比Go還先進的Rust語言,無縫遷移了90%以上的雲端儲存平臺。試問,我司有幾個人用過甚至是聽說過這些語言?我們的研發員工如果不去不斷地提升,怎麼可能趕上時代的步伐?怎麼能開發出質量好的產品?

2、技術任職資格效果不佳,傳幫帶困難

理論上,技術任職資格是用來給搞技術的人提供晉升通道的。但實際應用上,雖然有破格提拔機制,總體上還是按資排輩,評委也大多是由有較高級別技術任職資格,但對現在技術並不太瞭解的管理者擔當。

同時,任職從申請、技能鑑定考試到做答辯膠片、答辯,消耗了員工不少時間和精力。矽谷的公司一般在這方面比較靈活,技術通道由360 Review和與其工作密切相關的主管直接評價、申請和授予,有些員工在28-33歲左右已經有了非常高的技術職級和地位。

因為技術晉升通道不順暢,能力較強的員工漸漸離開了開發崗位,較多時間沉浸在文件、膠片和會議中,新來的年輕員工過幾年又在走同一個迴圈。是否可以徹底打通技術升值通道,鼓勵有能力的人帶新人,同時完善獎勵機制,在及時激勵和長期激勵上下功夫,讓研發人員看到技術發展空間,樂於編碼,留住人才。

四、工具

1、研發辦公環境

在矽谷先進的軟體公司裡,MacBook Pro/Air是標準配置,方便攜帶,隨時隨地程式設計。很多軟體及移動開發除錯都在家裡、公司、食堂隨時可以進行,包括程式設計、編譯、Review和提交;資料庫、各種Library、工具和Docker等都可以在本地的OSX/Linux環境下執行。需要的話,也隨時可以跟公司內部伺服器透過命令列互聯,進行檔案、程式碼的傳輸和測試。

筆者在矽谷工作時認識一個美國小夥子,他基本都是深夜在家裡寫程式碼,白天幾乎看不到人,但效率和質量都很高。而我們的大部分研發人員,都被侷限在公司內部擁擠嘈雜的敏捷島,用著桌面雲進行著低效開發。

2、程式碼庫管理、Review、Checkin和Bug Tracking工具

基於Web/Git的Review和Checkin的相應工具差距非常大。透過源程式的Review審批和Checkin的機制,可以很快傳遞能力和互相學習,提升程式碼質量。同時,在任何一個時間點,任何一個高階工程師或是領導都可以透過這些工具來了解員工真正在程式碼上的貢獻和價值,審查進度和版本分支,進度和質量也好把握。以筆者的經驗,這是最好的傳遞技能的工具之一,往往有一個能人,很快就能把一批年輕人的能力帶起來。

我司一般用的是內部開發的DTS bug tracking的工具,比較死板,總體和上述提到的最新的Git源程式管理工具、Review工具、自動化和Nightly Build、敏捷管理工具無法無縫地連線在一起。

3、知識資源的獲取

由於公司內網Proxy許可權問題和受限於大家英語水平的原因,大部分員工還是習慣於使用百度進行程式、庫、方法和問題的搜尋。但由於共享性差,同時技術水平與美國相差比較大,所有能在百度上找到的好的資源非常有限,質量也較差。美國軟體開發人員已經把諸如StackOverflow、GitHub和Google作為學習和資源分享不可分割的一部分。

頂部