• <blockquote id="s4gyg"></blockquote>
  • <blockquote id="s4gyg"><samp id="s4gyg"></samp></blockquote>
    <blockquote id="s4gyg"></blockquote>
  • <blockquote id="s4gyg"></blockquote>

    C114通信網  |  通信人家園

    新聞
    2021/8/12 11:32

    華為時隔5年再次轉發舊文:《華為到該炸掉研發金字塔的時候了》

    C114通信網  顏翊

    C114訊 8月12日消息(顏翊)近日,華為心聲社區時隔5年再次轉發華為創始人兼總裁任正非2016年簽發的郵件《華為到該炸掉研發金字塔的時候了》。該文是一位署名為泥瓦克的華為員工對于軟件研發效率與質量提升的思考。

    該文作者表示,“華為公司在軟件產業的差距還比較大;和中國領先的互聯網產品相比,在易用性、貼近用戶和產品快速迭代等方面也落后不少。我們在軟件研發領域的確存在不少問題,這些問題導致我們的IT軟件產品質量比較低下、開發效率低、產品交付周期漫長,很是讓人痛心。”

    他認為,在組織方面,架構設計SE與開發分離,一些架構師與專家基本不懂開發;開發者多為低級別,比較難有技術積累;多頭管理讓開發人員無所適從;組織復雜,中間層較多導致溝通成本太高。在流程方面,IPD流程不太適合需要快速迭代的軟件;技術任職資格效果不佳,傳幫帶困難。

    任正非為該文加按語稱:在技術工作上的客氣是“毒品”,直面的批評、爭論才是良藥。

    華為常務董事丁耘則表示,“我們在CT領域取得的產品成功不是未來可靠的向導,我們必須要持續進步才能適應時代的客戶需求、才能獲得未來的發展。我們要清晰地認識到,面向ICT融合,在軟件能力、效率和質量方面存在的挑戰,在組織流程、作業環境等多方面存在的或多或少的不適應性和問題。盡管我們在參考業界、反思自己的基礎上,開展了軟件能力建設并取得了部分進展,但要實現我們期望的目標還需要持續做出更大的努力,需要生產力持續的提高,在此過程中我們各級主管和專家在思想意識和行為技能上的轉變是關鍵。期望各級主管和專家閱讀所附文章,不局限于文章中提到的問題建議,深入討論影響軟件研發效率、質量、業務發展的問題,討論中多審視自己、少抱怨別人,天底下容易的是指責別人,難的是改變自己。組織的生命力恰恰在于自我進化能力。我們既需要坐而言,更需要起而行,從自己做起,堅持以客戶為中心,通過點點滴滴、持之以恒的努力,持續有效改進,靜水潛流實現ICT成功的轉型。”

    在該文的跟帖中,眾多華為員工認為,雖然該文發表于5年前,但是回頭看,大部分問題依然存在,有員工評論:“歷史證明單獨的改變某個領域是收效甚微的,需要把KPI、目標統一變革。”

    華為到該炸掉研發金字塔的時候了

    ----關于我司軟件研發效率與質量提升的思考

    作者:泥瓦客

    近年,在從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、整體觀點還是同意的,部分點比如網絡權限、開發流程、工具等現在很多部門已經優化了,跟互聯網公司也差距不大了,不過管理團隊臃腫與問責機制的嚴苛,跨部門溝通成本高,安全紅線與IPD流程的繁瑣確實仍是相對嚴重的問題。不過隨著公司整體對IT化的思考,應該會越來越好,部分部門有可能在2-5年內趕上業界主流互聯網公司的研發效率。

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

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

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

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

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

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

    基因二:組織復雜,各自為政

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    1)管理溝通為王,技術員工就是低級別/低績效員工。一走上管理線還沒做出貢獻就輝煌騰達,又是升級又是加薪,以很多產品線為例,技術員工遲遲停留在14,15級,而一些和領導近,幫著領導完協調溝通開會的就能往上升級。2)形成了一層只懂溝通協調,拉通開會,不懂業務,但會寫匯報材料領獎但又占據高職級的中間層。。。造成大量低效,無用的工作,因為想不清楚要干啥,所以就一拍腦袋安排任務,下面的人把事情做了,才發現方向錯了。3)技術員工無出路,產品線技術儲備上不去,又造成低效。4)領導想不清楚技術能力對部門的價值,因為他自己不懂。5)技術線和管理線一起考核。。讓某些人既做裁判又做運動員。做技術15級就是個坎,和管理員以及溝通協調員一起考核,做技術的就只能背B背C,長此以往,消耗公司的技術儲備。

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

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

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

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

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

    35、看看華為項目中PMO的多寡,就知道 效率高低。項目管理還有個專門的職業通道呢,數數就知道了;ヂ摼W公司哪些什么PMO,QA也是測試人員,和我們的QA也完全不一樣。

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

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

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

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

    給作者點贊
    0 VS 0
    寫得不太好

    版權說明:C114刊載的內容,凡注明來源為“C114通信網”或“C114原創”皆屬C114版權所有,未經允許禁止轉載、摘編,違者必究。對于經過授權可以轉載我方內容的單位,也必須保持轉載文章、圖像、音視頻的完整性,并完整標注作者信息和本站來源。編譯類文章僅出于傳遞更多信息之目的,不代表證實其描述或贊同其觀點;翻譯質量問題請指正。

    熱門文章
      最新視頻
      為您推薦

        C114簡介 | 聯系我們 | 網站地圖 | 手機版

        Copyright©1999-2021 c114 All Rights Reserved | 滬ICP備12002291號

        C114 通信網 版權所有 舉報電話:021-54451141

        曰本AV