內部人建議華為炸掉研發金字塔，然後任正非給全公司發了封郵件

鈦媒體注：近日，華為內部署名“泥瓦客”的一名海龜程式設計師，從組織、流程、環境、工具四個方面痛斥在華為做研發的不易，並將這些問題形成了一篇文章釋出在一本內部刊物上，然後這篇名為《華為該炸掉研發金字塔的時候了》的文章，又被轉發到華為員工官方社群“心聲社群”，激起了一場轟轟烈烈的內部討論，更驚動了華為創始人& CEO 任正非。任正非看完所有人的討論後，簽發了一封總裁辦郵件，把文章和大家的討論貼出來，告知全司，此舉動背後的心思不得不說耐人尋味。

任正非簽發郵件的按 1 寫到：在技術工作的客氣是毒品，直面的批評、爭論才是良藥。鈦媒體編輯把這篇作者原文和上述任正非郵件的核心內容整理了出來，倒是一份很好的關於“研發”與技術管理的研究材料，也能更深層次幫助理解華為變大之後的內部問題。考慮到微信篇幅，鈦媒體對相關素材在不影響意思的前提下，有所刪減，本週週末深閱讀，重磅推薦：

華為到該炸掉研發金字塔的時候了——關於我司軟體研發效率和質量提升的思考

近年，在從 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 作為學習和資源分享不可分割的一部分。

一石激起千層浪，上述文章，直接引起了大量華為內部爭論，摘錄如下：

很多研發的同學都抱怨過，聰明的人都去做管理了。根源還是研發團隊的作戰方式。一個專案需要那麼多人，必然需要有管理，就有所謂的管理者，管的人越多，管理者做技術的時間越少。要轉變開發的模式，班長的戰爭。如果都是一個個的小團隊，就不需要那麼多的所謂的技術管理者了。

這些問題其實5，6 年前我們內部早已經發現，如今從一個外界來的專家身上也提出了。因為以前我們的人員、組織快速膨脹，其中最難的問題：骨幹員工都提拔去當官、當專家、專家不碰程式碼的情況確實存在。隨著這兩年我們的人員、組織逐漸穩定、任職上的牽引，讓骨幹員工深耕一線開發崗位，核心骨幹負責架構程式碼、核心模組程式碼、產品的設計正在成為現實，只要堅持下去，研發扁平化組織我們也會實現。

這是由華為公司兩大基因決定的！

基因一: 基於不信任的管理

假定了一個團隊或者一個員工個體，沒有辦法自動地按要求完成任務，一定要有外力的干預和指導，才能保證航行在正確的軌道上。不信任的假定，造成了領導很焦慮，員工被干擾。

基因二：組織複雜，各自為政

華為缺少扁平化管理，層級多，通道多。這樣複雜的組織機構，造成了資訊溝通對齊非常困難，每個組織機構又有自己的考評，都要考慮自己的團隊建設和發展，價值呈現。人都有趨利的本性，必然會希望更多堅持對自己發展和價值有利的，而放棄那種不太出彩又要大體力投入的。

其實話說回來，說難聽點，這叫多頭管理多通道管理，說好聽一點，這不就是管理上的民主嗎？這兩個基因，在華為這種大公司，不太可能改變掉，區域性試點是有可能的，比如搞搞精英團隊，或者在某些專案上試點扁平化，都是有可能的，至於全面改變，不現實。而且真的改成那個樣子，還指不定出什麼更大簍子。

在公司做研發 8 年多了，以前也心態穩定，相信板凳要坐十年冷，以學徒的態度和品質去面對自己承擔的工作任務，對業務轉換和工作安排基本上沒有抱怨和懷疑。可是這兩三年來，我越來越不自信了。看見版本經理滿口髒話地安排工作的時候，我在想研發人員的地位和自尊哪裡去了?研發汪的待遇就是這樣嗎?如果一個研發人員連尊嚴和榮譽感都不能感知的話，那點鈔票能代表一切嗎?能夠做出代表著工匠精神的產品嗎?

之前我覺得公司是硬體+技術型公司的代表，是挺立於新世紀技術浪潮的旗艦，但現在我覺得公司和這個目標漸行漸遠。

寫的很真實到位，尤其是 LM/PL 不編碼、SE 不會編碼等現象還是比較普遍的。組織分散、會議多、協調多也是頑疾。這兩年研發顯率提升在工程、方法上進步較多。在怎麼讓編碼人員能夠長期在編碼崗位上發展，是要好好研究解決。

導致研發質量不高的原因還有一條：過量的外包開發人員，通常是一個 PL 帶著 100 人的團隊，95 個都是外包的。完成任務和用心做事兒的差別還是很大的，PL 也根本管不過來，程式碼質量自然不高。

技術專家在華為非常沒地位，績效/股票/分紅/任職等方面都什麼話語權，一直幹技術會非常擔心失業，因為很多領導認為，一個技術老專家乾的活，找個新手讓技術老專家帶一段時間就可以代替老專家了，技術老專家成本高，常常會成為降成本很不錯的選擇，華為這種氛圍，真是讓想專心搞技術的兄弟心寒。

說一個幾天前來我司某基地出差來的見聞：鄰桌某 PL 在和別人 espace 語音，話間大意：我們組那個A童鞋，能力可以說是最強的，但他有個很嚴重的問題，他不會展示自己，他做的很多高質量的工作，但是無法很好的向領導展示。所以他的這個上半年績效不能給太高。。。坐在旁邊“無意”聽到談話的我一臉懵逼，內心一緊，又是個悲催的汪啊。

我就沒搞明白，華為對自己的定位到底是軟體公司還是硬體公司？向網際網路看齊，你客戶跟網際網路的是一樣的？你的客戶能讓你低成本試錯嗎，你的客戶可以讓你遠端推送補丁嗎，你的客戶允許你的產品產品閃退嗎？現實是，一個 bug，華為的晶片得重新流片；一個 bug，華為的基站得退服，客戶得跟政府解釋；網際網路追求快，華為追求穩。

作為一個以產品/專案交付為主的公司，解決方案架構師的作用是什麼？主要是通過架構保持整個組織對於解決方案認知的一致，這是為什麼很多架構師/SE 花大量時間在架構圖/PPT 上的原因，這也是保證整個組織、很多專案不亂的一個很重要的因素(我沒有說唯一因素，沒有否定 coder 的作用，顯然再好的架構也需要 coder 去實現），這跟做產品運營的網際網路公司，就一個版本持續不斷優化，業務上線速度優先是不一樣的，比如：大家都知道淘寶的架構從一開始 2000 美金買的簡單購物網站到現在的超大規模網站，10 年之間架構推倒重來了 5 次，包括其中請 sun 的 Java 專家重寫了一遍系統，這在華為是不可想象的，在華為首先要講清楚 WHY，工程商人，投入產出先講清楚，至少要保障邏輯上成功，這就是為什麼投入大量人力在前端，也是 IPD 的重要作用之一。

我認為還沒有挖到根上，很深的一個根因，那就是 PBC 牽引太強，績效結果應用太強，績效結果簡直決定員工的一切回報！！現在 PBC 牽引太強了，如果能力強的員工不去搞與程式碼無關的事情，就會沒有很好的績效。為啥？因為現在的績效管理是“人與 PBC 比”、“人與人比”。。。PBC 是死的，一般員工都會看好，但人是活的，你要超過別人，你必須搞點其他與程式碼無關的事情，結果一搞就搞多了。研發普遍有一種認識，搞定周邊部門遠比搞定程式碼要難度大。久而久之，寫程式碼的績效就差了，誰還願意寫。

我司產品對需求管理較弱，都是市場人員說了算，再加上各種原因導致軟體產品本身就缺少架構和設計，為了交差就用最簡單粗暴的疊加方法，什麼設計啊，架構啊先放一邊，搞上去再說。幾年下來，幾波人輪流修改，程式碼變得龐大和冗餘，很多產品都是越到後期越爛。

公司很多的軟體專案給專案組留的時間非常短，經常是 3 到 6 個月就要出產品。從另一個方面講，就是前瞻性不夠。產品不需要的時候根本就不佈局。等產品要的時候，跟本不給時間做探索。這樣做出來的產品質量可想而知。過去成功的產品，基本上都是提前佈局（悄悄的佈局），等產品要的時候基本路都走通了。這個時候說三到六個月就可以從容應對了。海思現在的做法也是一個技術樣片加一個產品樣片，中間相差半年到一年，這就非常合理。好的軟體架構是需要時間去探索和磨合，不是一上來就百分之百能做好做對。而且將來還需要不斷的重構。Google 的主力產品每一年到一年半就要做一次大的重構。如果不重構，工程師自己都覺得他維護的產品會落後。

問題的根源在於我們越來越厚重的管理，現在的管理要求越來越多，管理手段越來越繁瑣，績效評價、薪資調整、獎金評定、配股、任職資格、人崗匹配、團隊穩定、離職跳池等，是必須有一個強有力的管理者進行團隊管理，從 PL 開始，要想管理好團隊，必須拋棄技術走向管理，導致無精力專注技術。

原文出自 「心聲社群 」作者：泥瓦客