編者按：《管理優(yōu)化》報7月15日第504期，署名“泥瓦客”的一篇文章《關于我司軟件研發(fā)效率與質(zhì)量提升的思考》在華為人中引起強烈反響,，文章從四個方面痛陳研發(fā)的問題,，同時文章被網(wǎng)友轉(zhuǎn)發(fā)到心聲社區(qū)引起更激烈的討論。8月15日,，任總簽發(fā)布總裁辦電子郵件,，將泥瓦客的原文及網(wǎng)友爭鋒相對的評論帖在心聲社區(qū)上。

以下為電子郵件原文：

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

筆者以前曾在美國硅谷工作,，和世界上最頂尖的軟件工程師和計算機領域的牛人一起共事過,，也先后帶領過不同的團隊交付了一些業(yè)界領先的企業(yè)級軟件產(chǎn)品。幾年前進入華為,，和幾個做企業(yè)業(yè)務的產(chǎn)品線有些合作,，在此過程中感到華為公司在軟件產(chǎn)業(yè)的差距還比較大；和中國領先的互聯(lián)網(wǎng)產(chǎn)品相比,，在易用性,、貼近用戶和產(chǎn)品快速迭代等方面也落后不少。我們在軟件研發(fā)領域的確存在不少問題,，這些問題導致我們的IT軟件產(chǎn)品質(zhì)量比較低下,、開發(fā)效率低、產(chǎn)品交付周期漫長,，很是讓人痛心,。

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

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

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

2、開發(fā)者多為低級別,，比較難有技術積累

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

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

3、多頭管理

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

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

4,、溝通成本高

由于組織復雜,，中間層較多，各種各樣的任務從上面下來,，落實的方法就是各種各樣的會議,，所以現(xiàn)在很多研發(fā)員工的不少時間都被各種各樣的規(guī)劃、研討,、問題回溯,、客戶支持等會議占用。員工笑稱：白天是用來開會的,，晚上加班才有時間編程序,。針對于不同的組織和項目，能盡快找出相應的溝通節(jié)點并能有效地減少這些溝通節(jié)點,，是一個項目和部門領導需要經(jīng)常思考的問題,。

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

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

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

安全紅線的目的是防止產(chǎn)品出現(xiàn)安全漏洞，初衷是好的,，但執(zhí)行起來相對比較僵化,，效率也低。試想一個互聯(lián)網(wǎng)產(chǎn)品為了過安全紅線一個版本等一兩個月,，根本無法生存,。

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

1、沒有時間抬頭看路

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

互聯(lián)網(wǎng)時代,，MOOC提供了大量實時、實用,、先進的網(wǎng)上課程（包括免費的和收費的）,，如Coursera、Udemy,、Pluralsight,、Stanford Online、edX,、YouTube相應的Channel等,，想要學的課程幾乎什么都有。

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

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

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

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

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

1、研發(fā)辦公環(huán)境

在硅谷先進的軟件公司里，MacBook Pro/Air是標準配置,，方便攜帶，隨時隨地編程。很多軟件及移動開發(fā)調(diào)試都在家里,、公司、食堂隨時可以進行，包括編程、編譯、Review和提交,；數(shù)據(jù)庫,、各種Library,、工具和Docker等都可以在本地的OSX/Linux環(huán)境下運行。需要的話,，也隨時可以跟公司內(nèi)部服務器通過命令行互聯(lián)，進行文件、代碼的傳輸和測試,。

筆者在硅谷工作時認識一個美國小伙子,，他基本都是深夜在家里寫代碼,，白天幾乎看不到人,，但效率和質(zhì)量都很高。而我們的大部分研發(fā)人員,，都被局限在公司內(nèi)部擁擠嘈雜的敏捷島，用著桌面云進行著低效開發(fā)。

2,、代碼庫管理,、Review,、Checkin和Bug Tracking工具

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

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

3,、知識資源的獲取

由于公司內(nèi)網(wǎng)Proxy權限問題和受限于大家英語水平的原因,，大部分員工還是習慣于使用百度進行程序、庫,、方法和問題的搜索,。但由于共享性差，同時技術水平與美國相差比較大,，所有能在百度上找到的好的資源非常有限,，質(zhì)量也較差。美國軟件開發(fā)人員已經(jīng)把諸如StackOverflow,、GitHub和Google作為學習和資源分享不可分割的一部分,。

1、整體觀點還是同意的,，部分點比如網(wǎng)絡權限,、開發(fā)流程、工具等現(xiàn)在很多部門已經(jīng)優(yōu)化了,，跟互聯(lián)網(wǎng)公司也差距不大了,，不過管理團隊臃腫與問責機制的嚴苛，跨部門溝通成本高,，安全紅線與IPD流程的繁瑣確實仍是相對嚴重的問題,。不過隨著公司整體對IT化的思考，應該會越來越好,，部分部門有可能在2-5年內(nèi)趕上業(yè)界主流互聯(lián)網(wǎng)公司的研發(fā)效率,。

2、很多研發(fā)的同學都抱怨過,，聰明的人都去做管理了,。根源還是研發(fā)團隊的作戰(zhàn)方式,。一個項目需要那么多人，必然需要有管理,，就有所謂的管理者,，管的人越多，管理者做技術的時間越少,。要轉(zhuǎn)變開發(fā)的模式,，班長的戰(zhàn)爭,。如果都是一個個的小團隊，就不需要那么多的所謂的技術管理者了,。

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

4,、總體陳述較客觀,。不過華為畢竟是硬件公司,，任總說改進也最好是小步前進。企業(yè)網(wǎng)項目將是后起之秀，現(xiàn)在比消費者項目稍微落后點，請你海歸回來也是想獲得些新的理念獲得改進提高，但炸掉研發(fā)金字塔有些過火,。

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

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

假定了一個團隊或者一個員工個體，沒有辦法自動地按要求完成任務,，一定要有外力的干預和指導,，才能保證航行在正確的軌道上。不信任的假定,，造成了領導很焦慮,，員工被干擾。領導焦慮哪一步?jīng)]看住就要出問題,，所以比如各種對齊,，各種進展報告，各種回溯會,。然后制定各種管控流程（包括IPD）,，設定各種管控角色，這些東西都需要員工參與,，員工就寫膠片開會,，為各種流程上繳交付件，向各種管控角色匯報,。話分兩頭講,，這一點也不能說是領導完全不對，他其實觸動了華為的另一個“傳統(tǒng)”（這段可能有些人不愛聽）,。我們設想一下,，文中提到的那個白天不出現(xiàn)，晚上寫代碼的哥們,，怎么保證他是按需求和設計在編碼的呢,？怎么審計？怎么考核,？怎么跟蹤,？其實答案很簡單，那個哥們必定是個極客,，而極客是免運維的,。而我司的研發(fā)定位，絕大部分基本就是程序員而已,，這能不管理嗎,？這就像手動擋和自動擋,，既然選擇了開手動，那為了適應不同速度的換擋干預就是必不可少的,，否則起步后永遠掛1擋就是快不了?，F(xiàn)狀嘛，我司是需要大量手動擋的開發(fā)人員,，只要按部就班做好自己的事情就行,，這是批量化標準化作業(yè)的要求。極客嘛,，當然也是需要的,，但很少，這些人單獨管理就行,。我覺得公司推了這么多年的所謂敏捷開發(fā)流程,，其實也是要建立在精英團隊基礎上，幾個人簡單思想一碰撞,，各自都能清楚的理解和心中有數(shù),，就能按時完成任務對接起來，這是很高技巧的,，也不是2,3年能掌握的，如果一個團隊大部分員工剛寫了2年代碼,，工作還需要別人指導,，早上像模像樣的開個早會，會上各種問題從9點開到11點,，這不叫早會,，這叫罰站。這也不叫敏捷,，這叫保姆式開發(fā),。

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

華為缺少扁平化管理,，層級多,，通道多。這樣復雜的組織機構,，造成了信息溝通對齊非常困難,，每個組織機構又有自己的考評，都要考慮自己的團隊建設和發(fā)展,，價值呈現(xiàn),。人都有趨利的本性，必然會希望更多堅持對自己發(fā)展和價值有利的,，而放棄那種不太出彩又要大體力投入的,。但活在那里,，總要有人干，很多事情都不是一兩個leader能確定的,，小leader也不能什么事都升級給大leader,，顯得自己無能。于是就討論劃域定界再討論爭議升級開會對齊拉通再討論裁決拍板……甚至于,，這種決策過程花費的人力和時間甚至超過真正做事情本身,。這還是組織自上而下沒太大分歧的情況。如果趕上不同通道的組織之間分歧很大,，那決策和研討時間又要再翻幾倍了,。我甚至見過有領導感嘆自己指揮不動下面的人的情況，并不是因為指揮不動,，而是多個通道的要求不同,，下面不確定要怎么動。其實話說回來,，說難聽點,，這叫多頭管理多通道管理，說好聽一點,，這不就是管理上的民主嗎,？因為民主，所以才爭吵啊,，所以才決策慢啊,，要是一個老專家或者老領導一發(fā)話，大家都照辦,，那是效率高,，是不是又要有人抱怨專政了？

這兩個基因,，在華為這種大公司,，不太可能改變掉，局部試點是有可能的,，比如搞搞精英團隊,，或者在某些項目上試點扁平化，都是有可能的,，至于全面改變,，不現(xiàn)實。而且真的改成那個樣子,，還指不定出什么更大簍子,。

6、首先肯定要直面批評。但是：1）不能用純軟件互聯(lián)網(wǎng)公司的開發(fā)模式來套用一個有深厚硬件開發(fā)任務的公司,。美國的洛克希德馬丁公司也不會純粹這樣玩,；2）不能用一個小作坊模式的開發(fā)團隊來要求8萬人研發(fā)的大公司，高通也不會容忍你半夜在家寫代碼白天不來,； 3）美國公司的問題也挺多,，容易讓擅長拍馬屁的印度人上位，長久下來誰優(yōu)誰劣不好說,。有病治病沒病辭退,。

7、問題是存在的,，不過沒有那么嚴重,，世上沒有理想的環(huán)境，各家都有各家的問題,。說Java過時這種無謂的語言之爭的說法格局就太小了,。我在華為PaaS部,，開發(fā)用Go,、Python,、Java各種語言，代碼review是Gerrit,，公司還經(jīng)常會請Go,、Scala的作者在公司做培訓，全公司可以接入?yún)⒓?。華為很大,，沒有完美的環(huán)境，心態(tài)很重要,。

8、在公司做研發(fā)8年多了,以前也心態(tài)穩(wěn)定,相信板凳要坐十年冷,以學徒的態(tài)度和品質(zhì)去面對自己承擔的工作任務,對業(yè)務轉(zhuǎn)換和工作安排基本上沒有抱怨和懷疑.可是這兩三年來,我越來越不自信了,發(fā)現(xiàn)工作總是那樣撲天蓋地,一波又一波,自己花了很多時間和心血保障了版本特性以及歷史版本的驗證,這在別人看來已經(jīng)是理所應當,本該如此了.PL和LM們急切地需要看到亮點,看到能包裝成高大上的東西.看見版本經(jīng)理滿口臟話地安排工作的時候,我在想研發(fā)人員的地位和自尊哪里去了?研發(fā)汪的待遇就是這樣嗎?如果一個研發(fā)人員連尊嚴和榮譽感都不能感知的話,那點鈔票能代表一切嗎?能夠做出代表著工匠精神的產(chǎn)品嗎?

9,、之前我覺得公司是硬件+技術型公司的代表,是挺立于新世紀技術浪潮的旗艦,但現(xiàn)在我覺得公司和這個目標漸行漸遠,。

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

11,、雖然知道是好文,，然而也知道并無卵用，公司現(xiàn)階段,，不管哪個層級的管理都不會重視這個問題,，有的都是各種浮躁的發(fā)文研討運動和各種浮于表面的質(zhì)量檢查。最無語的是發(fā)起和評價的人都是不懂具體技術細節(jié)的人,。其實我說的是QA...

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

13、技術專家在華為非常沒地位,，績效/股票/分紅/任職等方面都什么話語權,，一直干技術會非常擔心失業(yè)，因為很多領導認為,，一個技術老專家干的活,，找個新手讓技術老專家?guī)б欢螘r間就可以代替老專家了，技術老專家成本高,，常常會成為降成本很不錯的選擇,，華為這種氛圍，真是讓想專心搞技術的兄弟心寒,。

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

15、一個小小PL,，平時既要聽資源領導,，也要聽業(yè)務領導的，兩個老大的意見經(jīng)常還不一致,，一言不合就吵起來,，做下屬的都要累死了，實在左右為難啊,。為什么在一個PDU內(nèi)部還要搞矩陣管理呢,，實在降低效率增加扯皮，是為了安排人員崗位嗎,。

16,、關于先進研發(fā)工具、平臺甚至開發(fā)語言,，確實作為研發(fā)作戰(zhàn)武器是至關重要的,，目前公司研發(fā)能力中心、各產(chǎn)品線在開源應用和向外界學習的過程中,，都在引入試點,，希望擴大規(guī)模，公司是倡導的,。我們基層干活的也需要多看看外界軟件,、硬件設計、開發(fā)上的一些新工具,、新平臺,、新方法，測試,，使用,。

17、我就沒搞明白,，華為對自己的定位到底是軟件公司還是硬件公司,？向互聯(lián)網(wǎng)看齊，你客戶跟互聯(lián)網(wǎng)的是一樣的,？你的客戶能讓你低成本試錯嗎，你的客戶可以讓你遠程推送補丁嗎,，你的客戶允許你的產(chǎn)品產(chǎn)品閃退嗎,？現(xiàn)實是，一個bug,，華為的芯片得重新流片,；一個bug,，華為的基站得退服，客戶得跟政府解釋,；互聯(lián)網(wǎng)追求快,，華為追求穩(wěn)。

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

19,、這篇文章和其后的討論，讓我聯(lián)想到一本書《失去的制造業(yè)  日本制造業(yè)的敗北》,，其中分析日立,、NEC和三菱干不過三星的原因，和當前的市場狀態(tài)蠻像的,。

日本人在DRAM產(chǎn)品上80年代到90年代取得了巨大的成功,，占據(jù)了核心供應商位置，市場占比達到80%,。但在市場需求來源從高可靠性的大型機轉(zhuǎn)向低成本的PC過程中,，因為執(zhí)著于高可靠性的制程、工藝,、一致性,、良品率等指標,，長期按三星的兩倍甚至更高的運作成本在銷售DRAM，盈利微薄,，最終完全退出了DRAM市場,。ICT領域的商業(yè)價值在向軟件、生態(tài)系統(tǒng)或者平臺型的提供者轉(zhuǎn)移過程中,，如果我們也始終執(zhí)著于過去在通訊領域,，為高可靠性產(chǎn)品開發(fā)而建立的組織、文化,、流程,，那在新的商業(yè)地圖上，我們的版圖終究會縮減下來,。

20,、點點滴滴都說到我的心坎上了。但是,，怎么改,？華為文化，乃至中國文化,，一放就亂,，一管就死。創(chuàng)造性的研發(fā)工作當作低級簡單老動來管理,，必然抹殺創(chuàng)造性,。好在勤能補拙，以華為企業(yè)文化“累死自己,、逼死友商,、成就客戶”，還是一步一步地走向成功,。

21,、領導以為給個人就能編碼，不知道編碼才是所有事情的核心,，所以各個產(chǎn)品不停的重復犯錯,，所以公司各級每年都要開狗屁沒有用的質(zhì)量大會

22、我司很多軟件的idea,，不是來自懂業(yè)務懂技術的大牛,，而是來自領導拍腦袋；然后領導忙別的去了,，具體落地業(yè)務需求有MO和SE完成,。如果MO和SE就可以領導重大軟件的開發(fā)，那么多公司還招聘CTO干啥,？

23,、對于研發(fā)工程師的定位在西方公司和中國公司之間確實有著巨大差異，本人曾經(jīng)工作的美國企業(yè)和歐洲企業(yè),，美國工程師和歐洲工程師50多歲還在寫代碼,，做測試的比比皆是，并且都在項目,、組織中享有重要地位,；相比較之下，國內(nèi)連40多歲的程序員都很鮮見,。

24,、深有同感，但是樓主離開硅谷,，是意味著其他公司比華為更亂嗎,？

25、首先“標題”取“硅谷海歸..”有什么意義,？有崇拜的因素,？結果還引起一片附和?？擅魈煲痪渲鞴苜潛P的話就讓你感激涕零,，換了想法。談什么思想,？不過是小心思罷了,。這里面有好多人回復時自以為是，但都是拿自己的工作當成全部,，進而去低估別人的工作,，不是想著通力合作而只想著斗爭。請問：別人有沒有對你的工作指手劃腳,？只不過是一個最初級的實用主義者的牢騷之主,，談什么格調(diào)。各級主管信心爆棚,，很難聽取意見

26,、我認為還沒有挖到根上，很深的一個根因,，那就是PBC牽引太強,，績效結果應用太強，績效結果簡直決定員工的一切回報??！現(xiàn)在PBC牽引太強了，如果能力強的員工不去搞與代碼無關的事情,，就會沒有很好的績效,。為啥,？因為現(xiàn)在的績效管理是“人與PBC比”、“人與人比”,。,。。PBC是死的,，一般員工都會看好,，但人是活的，你要超過別人,，你必須搞點其他與代碼無關的事情,，結果一搞就搞多了。研發(fā)普遍有一種認識,，搞定周邊部門遠比搞定代碼要難度大,。久而久之，寫代碼的績效就差了,，誰還愿意寫,。因此，要從根本上解決軟件開發(fā)的問題,，必須要解決利益分配在執(zhí)行層面的問題,，也就是績效管理問題，寫代碼的取消相對考評,、采用絕對考評?。?！減少考評結果的應用,，比如只關系晉升，不關系獎金??！所謂流程的問題，根本就是表面現(xiàn)象,，雖然也需要解決,，但這種解決，我認為只是持續(xù)演進和適配的問題?。,。?/span>

27,、深有體會,，不過華為有自我進化的能力，當它發(fā)現(xiàn)和認識到問題的時候，就會進化,。華為的進化就像中國的改革開放,，不斷的試探發(fā)展。

28,、任何一個企業(yè)都存在自身的問題,，每一個企業(yè)都有他獨特的文化，華為能發(fā)展到今天說明目前的方式是適應華為的,，你真正從華為工作過10年以后你再出來看看，外面的大部分企業(yè)都和華為有很大的差距,。炸掉研發(fā)金字塔后又如何重建呢,？

29、在工程師文化這一塊,，我們確實做得很不夠,，如果純技術員工都覺得很痛苦，沒出路,，長久肯定會導致人才流失,，優(yōu)秀的人才吸引不來，自己的好員工都想逃離,。但我覺得這個是整體導向的問題,，而不光是HR思路問題，比如任職資格,，本身在HR政策上就是為了牽引員工技術提升的,，只是在執(zhí)行上，被論資排輩和“管理者優(yōu)先”的思想給害了,，關鍵還是文章里說的,，我們從上到下沒有給予頂尖程序員的成長空間和足夠的牽引，希望能引起公司的重視,。

30,、現(xiàn)在的HR建設思路估計會在N年后帶來危機。,。,。希望我說的是錯的

1）管理溝通為王，技術員工就是低級別/低績效員工,。一走上管理線還沒做出貢獻就輝煌騰達,，又是升級又是加薪，以很多產(chǎn)品線為例,，技術員工遲遲停留在14,，15級，而一些和領導近，幫著領導完協(xié)調(diào)溝通開會的就能往上升級,。

2）形成了一層只懂溝通協(xié)調(diào),，拉通開會，不懂業(yè)務,，但會寫匯報材料領獎但又占據(jù)高職級的中間層,。。,。造成大量低效,，無用的工作，因為想不清楚要干啥,，所以就一拍腦袋安排任務,，下面的人把事情做了，才發(fā)現(xiàn)方向錯了,。

3）技術員工無出路,，產(chǎn)品線技術儲備上不去，又造成低效,。

4）領導想不清楚技術能力對部門的價值,，因為他自己不懂。

5）技術線和管理線一起考核,。,。讓某些人既做裁判又做運動員。做技術15級就是個坎,，和管理員以及溝通協(xié)調(diào)員一起考核,，做技術的就只能背B背C，長此以往,，消耗公司的技術儲備,。

31、組織的這部分描述,，很認同,。架構、專家等好像是為了樹品牌,，直接作戰(zhàn)基層人員那種扎根持久奮戰(zhàn)的環(huán)境不好,，矩陣式管理和溝通繁瑣等。另外,，不僅僅是研發(fā),，公司現(xiàn)在幾大流程為主支撐，流程中每個環(huán)節(jié)角色相對獨立,，但又相互關聯(lián),，于是又設置了很多KCP

31、我司產(chǎn)品對需求管理較弱，都是市場人員說了算,，再加上各種原因?qū)е萝浖a(chǎn)品本身就缺少架構和設計,，為了交差就用最簡單粗暴的疊加方法，什么設計啊,，架構啊先放一邊,，搞上去再說。幾年下來,，幾波人輪流修改,，代碼變得龐大和冗余，很多產(chǎn)品都是越到后期越爛,。

32,、工業(yè)時代的管理思維和模式如IPD，在當下的數(shù)字時代肯定問題百出,，不僅是研發(fā)，市場,、運營也都處在類似的矛盾和沖突中,，我司在追求成為社會各行各業(yè)數(shù)字化轉(zhuǎn)型的使能者，但反觀自身的管理運作確仍深陷工業(yè)化思維無法自拔,，有時真覺得挺崩潰,。

33、電信級的安全,、穩(wěn)定要求與消費級的快速迭代和快速適應調(diào)整天然就存在矛盾,，如果用電信的思維去管理必然導致以上問題，但我們的基因就是電信級的嚴謹,；要想在消費領域有效突破唯有破釜沉舟大膽啟用外部新人,，同時挑選一些內(nèi)部仍有變革思想和欲望的員工組建新團隊，以新帶舊實現(xiàn)轉(zhuǎn)型,；突破既有的電信級研發(fā)管理框架啟用新流程,，人與流程適配才能有所作為！

34,、軟件開發(fā)模式不是一種就可以包打天下,，因此還需要針對不同的軟件開發(fā)進行適當?shù)亩ㄖ苹驼{(diào)整，包括組織,、流程,、環(huán)境和工具：如文中所提的互聯(lián)網(wǎng)應用軟件，其體量,、周期短,，因此勢必要調(diào)整為快速迭代的敏捷開發(fā)模式。如果是開發(fā)體量大、周期長的通信底層軟件,，可以應用稍厚重的軟件開發(fā)流程,。還有一個觀點不太認同，“IPD流程不太適合需要快速迭代的軟件”,，這里不應該是IPD流程,，而是在IPD流程體系下的軟件開發(fā)模型，對軟件開發(fā)怎么走起到?jīng)Q定性的還是下面的軟件開發(fā)流程（CMM or 敏捷等子流程）,。事實上IPD流程框架只解決如何將產(chǎn)品開發(fā)作為投資來管理,。

35、看看華為項目中PMO的多寡,，就知道 效率高低,。項目管理還有個專門的職業(yè)通道呢，數(shù)數(shù)就知道了,?；ヂ?lián)網(wǎng)公司哪些什么PMO，QA也是測試人員,，和我們的QA也完全不一樣,。

36、公司很多的軟件項目給項目組留的時間非常短,，經(jīng)常是3到6個月就要出產(chǎn)品,。從另一個方面講，就是前瞻性不夠,。產(chǎn)品不需要的時候根本就不布局,。等產(chǎn)品要的時候，跟本不給時間做探索,。這樣做出來的產(chǎn)品質(zhì)量可想而知,。過去成功的產(chǎn)品，基本上都是提前布局（悄悄的布局）,，等產(chǎn)品要的時候基本路都走通了,。這個時候說三到六個月就可以從容應對了。海思現(xiàn)在的做法也是一個技術樣片加一個產(chǎn)品樣片,，中間相差半年到一年,，這就非常合理。好的軟件架構是需要時間去探索和磨合,，不是一上來就百分之百能做好做對,。而且將來還需要不斷的重構。Google的主力產(chǎn)品每一年到一年半就要做一次大的重構,。如果不重構,，工程師自己都覺得他維護的產(chǎn)品會落后,。當然我司的產(chǎn)品也在做持續(xù)改進，但意思好像不完全一樣,。我們更多的關心的是競爭力,，人家關心的是架構可持續(xù)發(fā)展。

37,、程序猿,、攻城獅文化的建設首先需要在晉升通道要暢通，讓更多的人留在專業(yè)崗位上,，才能真正的出現(xiàn)沉淀,、傳承和創(chuàng)新。如果每個人都想著往管理崗走,，意味著一圈又一圈的輪回,，競爭力就更無從談起。

38,、樓主用硅谷的互聯(lián)網(wǎng)軟件開發(fā)模式,，跟華為的ICT行業(yè)嵌入式軟件開發(fā)模式來比較，是不是有些南轅北轍了呢,？互聯(lián)網(wǎng)軟件是全球集中控制（如Google）,，系統(tǒng)發(fā)現(xiàn)bug后，能夠在線低成本實時更新版本,，你甚至都沒有感覺，人家就悄悄的整完了,，因此敢玩敏捷試錯,，可以每周甚至每天更新版本。由此也就產(chǎn)生了與之對應的新的開發(fā)模式,。CT嵌入式軟件,，發(fā)布之后是隨硬件發(fā)貨遍布到全球各地，發(fā)現(xiàn)bug就要到現(xiàn)場批量召回/替換/整改,，你得跟客戶道N次謙,，做好N個應急切換方案，才敢去干,，成本非常高昂,。我司主力產(chǎn)品每年都是上百萬級別的，“敏捷試錯”一下試試,，每個錯的代價最低都是千萬美刀起步吧,？你敢玩兒嗎？你的客戶讓你這么玩嗎,？ IPD流程根本就不是為了敏捷試錯,，而是為了高可靠性而打造的,。拿互聯(lián)網(wǎng)的開發(fā)模式跟嵌入式ICT軟件的IPD開發(fā)模式，來比較,，有些牛頭 VS 馬嘴了吧,？當然，改善下程序猿們的工作環(huán)境,，工作氛圍,，讓大家身心健康的工作，我還是舉雙手支持的,，但一上來就要比照互聯(lián)網(wǎng)軟件的開發(fā)模式來整組織,、動流程，咱是不是先悠著點兒呢,？

39,、問題的根源在于我們越來越厚重的管理，現(xiàn)在的管理要求越來越多,，管理手段越來越繁瑣,，績效評價、薪資調(diào)整,、獎金評定,、配股、任職資格,、人崗匹配,、團隊穩(wěn)定、離職跳池等,，是必須有一個強有力的管理者進行團隊管理,，從PL開始，要想管理好團隊,，必須拋棄技術走向管理,，導致無精力專注技術。管理是需要灰度的,，但是我們現(xiàn)在的管理（特別是績效,、薪資、獎金,、配股,、任職、人崗等）,，更多的是對復雜多變規(guī)則的理解和執(zhí)行,，導致管理成本進一步上升。

為你講述華為人的新鮮事兒