編者按：
最近看到一篇文章，發文時間其實是4年前，是華為內部員工闡述了當時華為研發組織、流程等存在的問題。當時此文引起了任正非、丁耘（華為常務董事、運營商BG總裁）的重視，他們也對此作出了回應。
當時，任正非，特地以此簽發郵件：在技術工作的客氣是毒品，直面的批評、爭論才是良藥。
4年后的今天如何呢？讓我們先來看看原文作者泥瓦客發現了華為研發存在哪些問題。
華為到該炸掉研發金字塔的時候了——關于我司軟件研發效率和質量提升的思考
近年，在從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作為學習和資源分享不可分割的一部分。
一石激起千層浪。上述文章，直接引起了大量華為內部爭論，摘錄如下：
1.很多研發的同學都抱怨過，聰明的人都去做管理了。根源還是研發團隊的作戰方式。一個項目需要那么多人，必然需要有管理，就有所謂的管理者，管的人越多，管理者做技術的時間越少。要轉變開發的模式，班長的戰爭。如果都是一個個的小團隊，就不需要那么多的所謂的技術管理者了。
2.這些問題其實5，6年前我們內部早已經發現，如今從一個外界來的專家身上也提出了。因為以前我們的人員、組織快速膨脹，其中最難的問題：骨干員工都提拔去當官、當專家、專家不碰代碼的情況確實存在。隨著這兩年我們的人員、組織逐漸穩定、任職上的牽引，讓骨干員工深耕一線開發崗位，核心骨干負責架構代碼、核心模塊代碼、產品的設計正在成為現實，只要堅持下去，研發扁平化組織我們也會實現。
這是由華為公司兩大基因決定的！
基因一: 基于不信任的管理
假定了一個團隊或者一個員工個體，沒有辦法自動地按要求完成任務，一定要有外力的干預和指導，才能保證航行在正確的軌道上。不信任的假定，造成了領導很焦慮，員工被干擾。
基因二：組織復雜，各自為政
華為缺少扁平化管理，層級多，通道多。這樣復雜的組織機構，造成了信息溝通對齊非常困難，每個組織機構又有自己的考評，都要考慮自己的團隊建設和發展，價值呈現。人都有趨利的本性，必然會希望更多堅持對自己發展和價值有利的，而放棄那種不太出彩又要大體力投入的。
其實話說回來，說難聽點，這叫多頭管理多通道管理，說好聽一點，這不就是管理上的民主嗎？這兩個基因，在華為這種大公司，不太可能改變掉，局部試點是有可能的，比如搞搞精英團隊，或者在某些項目上試點扁平化，都是有可能的，至于全面改變，不現實。而且真的改成那個樣子，還指不定出什么更大簍子。
3.在公司做研發8年多了,以前也心態穩定,相信板凳要坐十年冷,以學徒的態度和品質去面對自己承擔的工作任務,對業務轉換和工作安排基本上沒有抱怨和懷疑。可是這兩三年來,我越來越不自信了。看見版本經理滿口臟話地安排工作的時候,我在想研發人員的地位和自尊哪里去了?研發汪的待遇就是這樣嗎?如果一個研發人員連尊嚴和榮譽感都不能感知的話,那點鈔票能代表一切嗎?能夠做出代表著工匠精神的產品嗎?
4.之前我覺得公司是硬件+技術型公司的代表，是挺立于新世紀技術浪潮的旗艦，但現在我覺得公司和這個目標漸行漸遠。
5.寫的很真實到位，尤其是LM/PL不編碼、SE不會編碼等現象還是比較普遍的。組織分散、會議多、協調多也是頑疾。這兩年研發顯率提升在工程、方法上進步較多。在怎么讓編碼人員能夠長期在編碼崗位上發展，是要好好研究解決。
6.導致研發質量不高的原因還有一條：過量的外包開發人員，通常是一個PL帶著100人的團隊，95個都是外包的。完成任務和用心做事兒的差別還是很大的，PL也根本管不過來，代碼質量自然不高。
7.技術專家在華為非常沒地位，績效/股票/分紅/任職等方面都什么話語權，一直干技術會非常擔心失業，因為很多領導認為，一個技術老專家干的活，找個新手讓技術老專家帶一段時間就可以代替老專家了，技術老專家成本高，常常會成為降成本很不錯的選擇，華為這種氛圍，真是讓想專心搞技術的兄弟心寒。
8.說一個幾天前來我司某基地出差來的見聞：鄰桌某產品經理在和項目管理人員espace語音，話間大意：我們組那個A童鞋，能力可以說是最強的，但他有個很嚴重的問題，他不會展示自己，他做的很多高質量的工作，但是無法很好的向領導展示。所以他的這個上半年績效不能給太高。。。坐在旁邊“無意”聽到談話的我一臉懵逼，內心一緊，又是個悲催的汪啊。
9.我就沒搞明白，華為對自己的定位到底是軟件公司還是硬件公司？向互聯網看齊，你客戶跟互聯網的是一樣的？你的客戶能讓你低成本試錯嗎，你的客戶可以讓你遠程推送補丁嗎，你的客戶允許你的產品產品閃退嗎？現實是，一個bug，華為的芯片得重新流片；一個bug，華為的基站得退服，客戶得跟政府解釋；互聯網追求快，華為追求穩。
10.作為一個以產品/項目交付為主的公司，解決方案架構師的作用是什么？主要是通過架構保持整個組織對于解決方案認知的一致，這是為什么很多架構師/SE花大量時間在架構圖/PPT上的原因，這也是保證整個組織、很多項目不亂的一個很重要的因素(我沒有說唯一因素，沒有否定coder的作用，顯然再好的架構也需要coder去實現），這跟做產品運營的互聯網公司，就一個版本持續不斷優化，業務上線速度優先是不一樣的，比如：大家都知道淘寶的架構從一開始2000美金買的簡單購物網站到現在的超大規模網站，10年之間架構推倒重來了5次，包括其中請sun的Java專家重寫了一遍系統，這在華為是不可想象的，在華為首先要講清楚WHY，工程商人，投入產出先講清楚，至少要保障邏輯上成功，這就是為什么投入大量人力在前端，也是IPD的重要作用之一。
今天，我們請到方老師——華為公司原無線產品線創始團隊成員、能源產品線IPMT核心成員（首席技術官）、華為公司管理藍血十杰獲獎者——對此也發表了一些自己的看法：
作者提的這些問題，有對IPD理解偏差的因素，IPD是一個研發投資管理框架，他談的內容是IPD流程框架下的軟件開發流程的弊端。不過，指出的問題和給出的建議確實很到位。
因為客戶需求的不確定，以及競爭的愈加激烈，產品交付周期越來越短，軟件開發模式確實需要從傳統的瀑布模型轉型為敏捷迭代模型。敏捷迭代不僅有利于快速交付，也使質量盡快穩定。
第二個是研發組織陣型，組織結構一定要匹配業務架構，組織運作一定要順應業務特征。敏捷開發后，最佳做法是大平臺下的精兵團隊。如果還是采用傳統的多層級結構，在開發效率、響應速度上就會落后于時代。
就是說，研發管理不能僵化，拿過去的成功應對新的局面；不能照搬，而要分析自身面臨的環境和態勢。要與時俱進，一切以是否有利于研發質量、成本和效率為準繩。
而如今，已經4年過去了，華為是一個學習型組織，從來沒有停止變革、優化的步伐，不斷在學習業界最佳實踐。
目前在云業務、消費者業務軟件領域，已經廣泛導入了敏捷開發、全功能團隊，其開發效率、質量和交付周期已經跟上了業界領先水平。
在ICT領域，因為嵌入式軟件的獨特性，會有所不同，從2018年開始投入20億美元，全面深化軟件工程，對存量軟件和增量軟件進行安全固化和質量升級，確保ICT軟件質量支撐網絡設備的安全性、健壯性。
【相關課程】
您的位置：
