“日前，一位華為內(nèi)部署名“泥瓦匠”的海歸程序員，寫下了這篇《華為到該炸掉研發(fā)金字塔的時候了》，從組織、流程、環(huán)境、工具等四方面怒斥在華為做研發(fā)之不易。此文被轉(zhuǎn)發(fā)到華為心聲社區(qū)后引起激烈討論，更驚動了任正非本人。

任正非按：在技術(shù)工作的客氣是毒品，直面的批評、爭論才是良藥。

丁耘按：我們在CT領(lǐng)域取得的產(chǎn)品成功不是未來可靠的向?qū)?，我們必須要持續(xù)進(jìn)步才能適應(yīng)時代的客戶需求、才能獲得未來的發(fā)展。我們要清晰地認(rèn)識到，面向ICT融合，在軟件能力、效率和質(zhì)量方面存在的挑戰(zhàn)，在組織流程、作業(yè)環(huán)境等多方面存在的或多或少的不適應(yīng)性和問題。

盡管我們在參考業(yè)界、反思自己的基礎(chǔ)上，開展了軟件能力建設(shè)并取得了部分進(jìn)展，但要實(shí)現(xiàn)我們期望的目標(biāo)還需要持續(xù)做出更大的努力，需要生產(chǎn)力持續(xù)的提高，在此過程中我們各級主管和專家在思想意識和行為技能上的轉(zhuǎn)變是關(guān)鍵。

期望各級主管和專家閱讀所附文章，不局限于文章中提到的問題建議，深入討論影響軟件研發(fā)效率、質(zhì)量、業(yè)務(wù)發(fā)展的問題，討論中多審視自己、少抱怨別人，天底下容易的是指責(zé)別人，難的是改變自己。組織的生命力恰恰在于自我進(jìn)化能力。我們既需要坐而言，更需要起而行，從自己做起，堅持以客戶為中心，通過點(diǎn)點(diǎn)滴滴、持之以恒的努力，持續(xù)有效改進(jìn)，靜水潛流實(shí)現(xiàn)ICT成功的轉(zhuǎn)型。

華為到該炸掉研發(fā)金字塔的時候了關(guān)于我司軟件研發(fā)效率與質(zhì)量提升的思考

作者：泥瓦客

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

筆者以前曾在美國硅谷工作，和世界上最頂尖的軟件工程師和計算機(jī)領(lǐng)域的牛人一起共事過，也先后帶領(lǐng)過不同的團(tuán)隊交付了一些業(yè)界領(lǐng)先的企業(yè)級軟件產(chǎn)品。

幾年前進(jìn)入華為，和幾個做企業(yè)業(yè)務(wù)的產(chǎn)品線有些合作，在此過程中感到華為公司在軟件產(chǎn)業(yè)的差距還比較大;和中國領(lǐng)先的互聯(lián)網(wǎng)產(chǎn)品相比，在易用性、貼近用戶和產(chǎn)品快速迭代等方面也落后不少。我們在軟件研發(fā)領(lǐng)域的確存在不少問題，這些問題導(dǎo)致我們的IT軟件產(chǎn)品質(zhì)量比較低下、開發(fā)效率低、產(chǎn)品交付周期漫長，很是讓人痛心。

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

1組織

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

一般各個產(chǎn)品線都會設(shè)有架構(gòu)設(shè)計部，主要成員也會以各個層次的SE為主。這些SE也都曾是程序員，但通常因?yàn)殚L期脫離開發(fā)部門，主要精力都放在會議、膠片和文檔的編寫上，以致編程的能力基本丟失，新技術(shù)學(xué)習(xí)的機(jī)會也有限。

例如一個移動開發(fā)的SE，自己對怎么在Android、iOS上進(jìn)行開發(fā)一點(diǎn)兒都不清楚。在這樣的基礎(chǔ)上，做好真正的架構(gòu)簡直是空談。在硅谷成功的公司里，好的架構(gòu)設(shè)計師一般是融入在產(chǎn)品團(tuán)隊中的，隨時都能上手編程，而且編程能力非常強(qiáng)。

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

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

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

3、多頭管理

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

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

4、溝通成本高

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

2流程

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

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

2、安全紅線耗費(fèi)資源巨大

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

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

3環(huán)境

1、沒有時間抬頭看路

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

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

現(xiàn)在的計算機(jī)技術(shù)日新月異，新的思想、方法、工具等層出不窮，例如Java語言是2000年左右在企業(yè)軟件領(lǐng)域崛起的，幾乎成為很多平臺、服務(wù)端軟件的必選，但隨著大規(guī)模分布式架構(gòu)、云計算的興起，它的短板，如內(nèi)存管理/GC不可控性、多線程或是異步對IO的控制效率，過度依賴較為重載的OOP等問題，如果使用不當(dāng)很容易造成災(zāi)難性問題。

Google內(nèi)部漸漸把它們有些后臺軟件都遷移到了他們自己發(fā)明的更為先進(jìn)的Go語言環(huán)境下。Dropbox更是兩年前開始使用了比Go還先進(jìn)的Rust語言，無縫遷移了90%以上的云存儲平臺。試問，我司有幾個人用過甚至是聽說過這些語言?我們的研發(fā)員工如果不去不斷地提升，怎么可能趕上時代的步伐?怎么能開發(fā)出質(zhì)量好的產(chǎn)品?

2、技術(shù)任職資格效果不佳，傳幫帶困難

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

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

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

4工具

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

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

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

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

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

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

3、知識資源的獲取

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

5管報、微信、心聲社區(qū)評論摘錄

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

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

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

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

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

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

假定了一個團(tuán)隊或者一個員工個體，沒有辦法自動地按要求完成任務(wù)，一定要有外力的干預(yù)和指導(dǎo)，才能保證航行在正確的軌道上。不信任的假定，造成了領(lǐng)導(dǎo)很焦慮，員工被干擾。領(lǐng)導(dǎo)焦慮哪一步?jīng)]看住就要出問題，所以比如各種對齊，各種進(jìn)展報告，各種回溯會。

然后制定各種管控流程(包括IPD)，設(shè)定各種管控角色，這些東西都需要員工參與，員工就寫膠片開會，為各種流程上繳交付件，向各種管控角色匯報。話分兩頭講，這一點(diǎn)也不能說是領(lǐng)導(dǎo)完全不對，他其實(shí)觸動了華為的另一個“傳統(tǒng)”(這段可能有些人不愛聽)。

我們設(shè)想一下，文中提到的那個白天不出現(xiàn)，晚上寫代碼的哥們，怎么保證他是按需求和設(shè)計在編碼的呢?怎么審計?怎么考核?怎么跟蹤?其實(shí)答案很簡單，那個哥們必定是個極客，而極客是免運(yùn)維的。而我司的研發(fā)定位，絕大部分基本就是程序員而已，這能不管理嗎?這就像手動擋和自動擋，既然選擇了開手動，那為了適應(yīng)不同速度的換擋干預(yù)就是必不可少的，否則起步后永遠(yuǎn)掛1擋就是快不了。

現(xiàn)狀嘛，我司是需要大量手動擋的開發(fā)人員，只要按部就班做好自己的事情就行，這是批量化標(biāo)準(zhǔn)化作業(yè)的要求。極客嘛，當(dāng)然也是需要的，但很少，這些人單獨(dú)管理就行。

我覺得公司推了這么多年的所謂敏捷開發(fā)流程，其實(shí)也是要建立在精英團(tuán)隊基礎(chǔ)上，幾個人簡單思想一碰撞，各自都能清楚的理解和心中有數(shù)，就能按時完成任務(wù)對接起來，這是很高技巧的，也不是2,3年能掌握的，如果一個團(tuán)隊大部分員工剛寫了2年代碼，工作還需要別人指導(dǎo)，早上像模像樣的開個早會，會上各種問題從9點(diǎn)開到11點(diǎn)，這不叫早會，這叫罰站。這也不叫敏捷，這叫保姆式開發(fā)。

基因二：組織復(fù)雜，各自為政

華為缺少扁平化管理，層級多，通道多。這樣復(fù)雜的組織機(jī)構(gòu)，造成了信息溝通對齊非常困難，每個組織機(jī)構(gòu)又有自己的考評，都要考慮自己的團(tuán)隊建設(shè)和發(fā)展，價值呈現(xiàn)。

人都有趨利的本性，必然會希望更多堅持對自己發(fā)展和價值有利的，而放棄那種不太出彩又要大體力投入的。但活在那里，總要有人干，很多事情都不是一兩個leader能確定的，小leader也不能什么事都升級給大leader，顯得自己無能。于是就討論劃域定界再討論爭議升級開會對齊拉通再討論裁決拍板……甚至于，這種決策過程花費(fèi)的人力和時間甚至超過真正做事情本身。這還是組織自上而下沒太大分歧的情況。

如果趕上不同通道的組織之間分歧很大，那決策和研討時間又要再翻幾倍了。我甚至見過有領(lǐng)導(dǎo)感嘆自己指揮不動下面的人的情況，并不是因?yàn)橹笓]不動，而是多個通道的要求不同，下面不確定要怎么動。

其實(shí)話說回來，說難聽點(diǎn)，這叫多頭管理多通道管理，說好聽一點(diǎn)，這不就是管理上的民主嗎?因?yàn)槊裰?，所以才爭吵啊，所以才決策慢啊，要是一個老專家或者老領(lǐng)導(dǎo)一發(fā)話，大家都照辦，那是效率高，是不是又要有人抱怨專政了?

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

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

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

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

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

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

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

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

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

日本人在DRAM產(chǎn)品上80年代到90年代取得了巨大的成功，占據(jù)了核心供應(yīng)商位置，市場占比達(dá)到80%。但在市場需求來源從高可靠性的大型機(jī)轉(zhuǎn)向低成本的PC過程中，因?yàn)閳?zhí)著于高可靠性的制程、工藝、一致性、良品率等指標(biāo)，長期按三星的兩倍甚至更高的運(yùn)作成本在銷售DRAM，盈利微薄，最終完全退出了DRAM市場。

ICT領(lǐng)域的商業(yè)價值在向軟件、生態(tài)系統(tǒng)或者平臺型的提供者轉(zhuǎn)移過程中，如果我們也始終執(zhí)著于過去在通訊領(lǐng)域，為高可靠性產(chǎn)品開發(fā)而建立的組織、文化、流程，那在新的商業(yè)地圖上，我們的版圖終究會縮減下來。

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

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

16、我認(rèn)為還沒有挖到根上，很深的一個根因，那就是PBC牽引太強(qiáng)，績效結(jié)果應(yīng)用太強(qiáng)，績效結(jié)果簡直決定員工的一切回報!!現(xiàn)在PBC牽引太強(qiáng)了，如果能力強(qiáng)的員工不去搞與代碼無關(guān)的事情，就會沒有很好的績效。為啥?因?yàn)楝F(xiàn)在的績效管理是“人與PBC比”、“人與人比”。。。

PBC是死的，一般員工都會看好，但人是活的，你要超過別人，你必須搞點(diǎn)其他與代碼無關(guān)的事情，結(jié)果一搞就搞多了。研發(fā)普遍有一種認(rèn)識，搞定周邊部門遠(yuǎn)比搞定代碼要難度大。久而久之，寫代碼的績效就差了，誰還愿意寫。

因此，要從根本上解決軟件開發(fā)的問題，必須要解決利益分配在執(zhí)行層面的問題，也就是績效管理問題，寫代碼的取消相對考評、采用絕對考評!!!減少考評結(jié)果的應(yīng)用，比如只關(guān)系晉升，不關(guān)系獎金!!所謂流程的問題，根本就是表面現(xiàn)象，雖然也需要解決，但這種解決，我認(rèn)為只是持續(xù)演進(jìn)和適配的問題!!!

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

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

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

20、軟件開發(fā)模式不是一種就可以包打天下，因此還需要針對不同的軟件開發(fā)進(jìn)行適當(dāng)?shù)亩ㄖ苹驼{(diào)整，包括組織、流程、環(huán)境和工具：如文中所提的互聯(lián)網(wǎng)應(yīng)用軟件，其體量、周期短，因此勢必要調(diào)整為快速迭代的敏捷開發(fā)模式。如果是開發(fā)體量大、周期長的通信底層軟件，可以應(yīng)用稍厚重的軟件開發(fā)流程。

還有一個觀點(diǎn)不太認(rèn)同，“IPD流程不太適合需要快速迭代的軟件”，這里不應(yīng)該是IPD流程，而是在IPD流程體系下的軟件開發(fā)模型，對軟件開發(fā)怎么走起到?jīng)Q定性的還是下面的軟件開發(fā)流程(CMM or 敏捷等子流程)。事實(shí)上IPD流程框架只解決如何將產(chǎn)品開發(fā)作為投資來管理。

21、公司很多的軟件項(xiàng)目給項(xiàng)目組留的時間非常短，經(jīng)常是3到6個月就要出產(chǎn)品。從另一個方面講，就是前瞻性不夠。產(chǎn)品不需要的時候根本就不布局。等產(chǎn)品要的時候，跟本不給時間做探索。這樣做出來的產(chǎn)品質(zhì)量可想而知。過去成功的產(chǎn)品，基本上都是提前布局(悄悄的布局)，等產(chǎn)品要的時候基本路都走通了。這個時候說三到六個月就可以從容應(yīng)對了。

海思現(xiàn)在的做法也是一個技術(shù)樣片加一個產(chǎn)品樣片，中間相差半年到一年，這就非常合理。好的軟件架構(gòu)是需要時間去探索和磨合，不是一上來就百分之百能做好做對。而且將來還需要不斷的重構(gòu)。Google的主力產(chǎn)品每一年到一年半就要做一次大的重構(gòu)。如果不重構(gòu)，工程師自己都覺得他維護(hù)的產(chǎn)品會落后。當(dāng)然我司的產(chǎn)品也在做持續(xù)改進(jìn)，但意思好像不完全一樣。我們更多的關(guān)心的是競爭力，人家關(guān)心的是架構(gòu)可持續(xù)發(fā)展。

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

23、樓主用硅谷的互聯(lián)網(wǎng)軟件開發(fā)模式，跟華為的ICT行業(yè)嵌入式軟件開發(fā)模式來比較，是不是有些南轅北轍了呢?互聯(lián)網(wǎng)軟件是全球集中控制(如Google)，系統(tǒng)發(fā)現(xiàn)bug后，能夠在線低成本實(shí)時更新版本，你甚至都沒有感覺，人家就悄悄的整完了，因此敢玩敏捷試錯，可以每周甚至每天更新版本。由此也就產(chǎn)生了與之對應(yīng)的新的開發(fā)模式。

CT嵌入式軟件，發(fā)布之后是隨硬件發(fā)貨遍布到全球各地，發(fā)現(xiàn)bug就要到現(xiàn)場批量召回/替換/整改，你得跟客戶道N次謙，做好N個應(yīng)急切換方案，才敢去干，成本非常高昂。我司主力產(chǎn)品每年都是上百萬級別的，“敏捷試錯”一下試試，每個錯的代價最低都是千萬美刀起步吧?你敢玩兒嗎?你的客戶讓你這么玩嗎?IPD流程根本就不是為了敏捷試錯，而是為了高可靠性而打造的。