任正非

日前，華為心聲社區時隔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軟件開發帶來很大制約。

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

任正非回應：直面批評、爭論才是良藥

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

總裁辦電郵

丁耘也在編者按中提到，華為要清晰地認識到，面向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作為學習和資源分享不可分割的一部分。

更多精彩內容，關注鈦媒體微信號（ID：taimeiti），或者下載鈦媒體App