伯特人力資本管理專家人力資本管理軟件-HCM
網站導航

首頁 > 資訊分享 > 讀書筆記 > 精選書籍《智慧研發管理》

精選書籍《智慧研發管理》

來源:伯特管理咨詢公司    發布時間:2020-03-24    瀏覽次數:
作者:謝寧


伯特咨詢為您呈現經典管理書籍的內容摘要,幫助高管們隨時隨地——拿出5分鐘,讀完這本書。




微信圖片_20190917143719.png




- 關鍵詞1:質量保證、技術評審-

技術評審是在研發過程中由技術專家對研發人員交付的工作產品從技術角度進行評審。技術評審是以發現工作產品的缺陷為目的,幫助糾正缺陷,避免把缺陷帶入到下個階段。針對一些技術風險,要幫助研發團隊進行分析以及決策是否可以帶著風險進入下個階段或者如何跟蹤防范風險的發生。另外,許多企業只有生產產品的測試工作,沒有研發過程測試,如單元測試、集成測試等。某公司的產品質量控制手段從質量度量與測評、引導和培訓、質量審計、問題溝通協調及上升以及問題分析及回溯五大方面展開。


將質量控制目標分解到各個階段,以便于分階段進行質量控制活動。



- 關鍵詞2:產品可維護性、客戶導向 -

華為工程師早期在“技術文化”引導下開發的產品在市場上遭到了大量的問題和挫折,同時因為可維護性差導致技術服務難度加大,供應鏈庫存積壓嚴重。最明顯的是研發工程師喜歡采用新工藝、新技術(或受到供應商推薦影響)導致量產不良率非常高,BOM(Bill Of Material的縮寫,指物料清單)數量在同類公司中最多,部件零件數量最多,更改通知單“滿天飛”,這樣狀況導致內部管理成本急劇膨大,因為這些產品過度地強調了“創新”。華為為了解決這個問題,在內部搞了一個“反幼稚病”活動,把從運營商退回來的設備單板和為運營商進行維護的往返機票,“獎”給了研發人員。后來,在針對市場、研發等新員工入職引導培訓中,增加一項“巡查供應鏈物流‘三品’庫房積壓物品”。這些宣傳、培訓等種種措施都是為了將“以客戶需求為導向”、“創新更強調對成熟技術的繼承”、“下一個工序就是客戶”等理念灌輸到研發工程師腦海里面。



- 關鍵詞3:系統工程師的職能、專業煙囪-

在很多企業中,由于開發技能和知識的不同,人員按照專業技能需求被分到不同的職業序列中,這往往容易造成每個專業領域的人員站在各自的立場上考慮事情,只關注于本領域效果的最優化,而非整體的、系統上的最優化。久而久之,便形成了專業領域的“煙囪”(或叫做專業技術上的“官僚主義”),縱向溝通不強,橫向整合不夠,一旦出現問題后,互相推諉,導致質量惡性循環下去。設計工程師與系統工程師在思路上的差異。設計工程師從專家的角度看問題,從內部看系統:只關心那些會影響其個人的設計任務的系統其它部分;但不一定關心設計工作如何影響其它人的工作。系統工程師具有系統觀,從外部看系統:關注系統所有部分,這些部分會影響系統總體設計/性能/成本/進度。系統工程是對將需求轉換為一個具體的技術工作的管理,需要對以下各項進行綜合考慮,以滿足成本、技術性能及計劃目標:系統性能參數、滿足需求的、最優的系統配置、技術活動的計劃和控制、各個專業領域的集成等。系統工程師要倡導系統的整體性。復雜系統的成功設計需要在設計概念的選擇、各個相互關聯的功能間的優先級及子系統間的接口定義進行大量的折中性考慮。每位技術專家或子系統設計者必須在其負責的范圍內盡力減少這些折中性因素的影響。 然而,系統工程師必須根據其對系統總體性能、設計風險、成本、進度等的影響而對這些問題進行審視,系統工程師是系統和項目的整體性的倡導者。



- 關鍵詞4:研發人才培養的策略、戰略分解、業務能力建設、標桿管理-

“上接戰略、中接標桿和下接業務”的人才培養機制從總體來說,“上接戰略、中接標桿和下接業務”的人才培養機制需要從戰略分解、業務能力建設和參考標桿企業做法三個方面來搭建整體的框架。

企業戰略是人才培養規劃和各項工作開展的總綱領和源頭。反過來說,人才培養說到底是為了支撐并服務于戰略目標的實現,必須圍繞著核心戰略目標進行設計。原則上,是從戰略和項目規劃分解下來對各類別、各層級的人才需求以及人才現狀對比來形成所需解決的人才缺口(結構化缺口),具體從戰略項目數量與級別、戰略要求的關鍵領域突破、關鍵能力建設等逐步分解到對人才結構化需求缺口(這點可以和任職資格等級對應起來)。

標桿企業的標桿做法是企業進行人才培養的一面重要鏡子。針對現有業務模式和標桿企業模式的差距,可以進一步將這種差距映射到平臺或能力的要求中。例如,需求管理與規劃能力、系統設計能力、DFX能力,進而提出對流程、業務建設能力更高的要求和對員工更高級別的能力要求,從而清晰化“下接業務”的人員培養需求。



- 關鍵詞5:知識管理、流程管理-

知識管理、流程管理是“基于任職資格的人才培養機制”的支撐基礎。知識管理、流程管理在一般中小企業的困境是太隨意、個體化以及膚淺化,無法形成可以集成的爆破力;流程管理改善未聚焦于“問題引入活動”的控制和對關鍵業務能力提升的幫助上;知識管理、流程管理在案例、檢查清單、規范的“三位一體”架構中未形成生動、形象、有趣的知識數據庫,難以吸引也難以激發員工的學習興趣。其實,企業在發展過程中摸索出來的成功經驗或失敗教訓是一筆寶貴的財富,因此需要對這些經驗或教訓進行系統化的總結。模板化是企業將良好經驗成功復制的有效手段,是知識管理和流程管理的基本手段,通過模板化,可以避免大部分工作重新開始探索,提高工作效率和效果。另外,知識管理、流程管理對人才尤其是高級別人才的要求需要進一步落實到任職資格標準的建設中。



- 關鍵詞6:并行開發模式、異步開發模式、技術與產品開發分離-

并行開發模式,是通過跨部門團隊的方式,整個團隊一起策劃如何開發和交付有利可圖的產品及其它關鍵的商業問題,以達成公司的商業目標。另外研發以外的功能部門代表能在產品需求和方案階段就能將可服務性、可制造性、可測試性等需求和相關配套方案加入到產品的早期設計中。


通過向并行開發模式轉變,解決了很多串行開發的弊端,大大降低了返工,縮短了產品的開發周期,同時也大大地提升了產品的交付質量。隨著技術開發和管理能力的提升,產品平臺和組件逐漸成為減少產品開發總體工作量、提升產品多樣化與系列化戰略的有力武器。通過對產品平臺或共用模塊的開發和管理實現跨產品的技術封裝和共享,為企業進一步縮短產品的上市周期提供了很好的基礎,這就是異步開發模式。異步開發模式的重中之重是技術和產品開發相分離,識別產品開發所基于的平臺和能夠共享的基礎模塊來達成提高技術共享,用來支持各業務分層的產品和技術進行統一協調的規劃和獨立開發。


- 關鍵詞7:產品平臺-

一個產品平臺是關于產品規劃及其戰略決策而制定的一個概念。它是整個系列產品所采用的共同要素,特別是基本的決定性技術(核心技術)的集合。——《PACE》中關于產品平臺的定義


產品平臺是戰略性的、對產品起到核心作用的共同要素的集合。產品平臺和產品的開發息息相關。從平臺化角度出發,任何獨立的產品開發只是產品平臺或公司產品線的一個分支,是實現公司開發戰略的一個要素。而產品平臺的作用與影響是根本性的,同時由于產品平臺的開發周期較長且需要很好的前瞻性,通常通過技術開發與產品開發相分離的方式,搭建貨架化的技術體系(如分為技術、部件、模塊、子系統、系統和平臺等)。


因此,企業想要成功,必須要有效地掌握產品平臺和各產品方案之間關系處理的多項目管理技能。技術和產品開發相分離,確保產品在業務分層中考慮到各層次技術、平臺、產品和解決方案等規劃,這種考慮需要通過自身的業務模型來驅動,根據技術創新的速度和及時向市場交付具有競爭力的產品的要求來加以均衡。在每個合適的業務層次上進行“恰當”的整合,如外購、合作開發或自主開發。


- 關鍵詞8:異步開發模式的方法、產品平臺類型-

采取異步開發模式,在進入一個新的產品領域之前,就根據關鍵的市場需求和技術架構選擇和規劃產品平臺,先進行產品平臺或平臺產品的開發,然后在平臺的基礎上規劃產品線和開發具體的產品。進行技術預研和平臺規劃需要較長的時間和大量投入,過程中會探索不同的技術和平臺,并進行選擇。


原則上,應該只選其中一種產品平臺和相應的技術。根據細分市場柵格(細分市場柵格是一個矩陣,橫軸代表企業產品針對的主要細分市場;縱軸表示企業面向的市場中不同層次的價格和性能,以“低成本、中間范圍和高成本”表示),可以將產品平臺分成四類:特定利基產品平臺、橫向產品平臺、縱向產品平臺和橋頭堡產品平臺。



- 關鍵詞9:產品平臺類型-

特定利基產品平臺:每種產品開發群體和制造廠完全致力于一個非常特定的利基。雖然這種模式有其優勢,但成本也非常高。研發可以很容易復制,一個團隊的發現對于其他團隊來說仍然保持未知。


橫向產品平臺:優勢是公司在一系列相關的客戶群體引入多股新產品,而不必為每種客戶群體單獨投資。研發的主要利益是,新產品可以更快開發。


縱向產品平臺:一個原來在高端細分市場的企業將平臺往下延伸至更低水平的價格/績效;另一種通過增加更有力的技術或新的模塊,滿足了更高水平市場的需求,從而從低端產品平臺升級至更高的價格/績效水平。


橋頭堡產品平臺:這是一種低成本但有效的平臺,工程師提高平臺的績效,增加用來吸引其他細分市場的特征。對初始平臺進行擴展,使之吸引不同的細分市場,提供細分市場內部高端客戶所需的功能



- 關鍵詞10:研發任職資格體系構建-

從總體來說,“上接戰略、中接標桿和下接業務”的人才培養機制需要從戰略分解、業務能力建設和參考標桿企業做法三個方面來搭建整體的框架。原則上,是從戰略和項目規劃分解下來對各類別、各層級的人才需求以及人才現狀對比來形成所需解決的人才缺口(結構化缺口),具體從戰略項目數量與級別、戰略要求的關鍵領域突破、關鍵能力建設等逐步分解到對人才結構化需求缺口(這點可以和任職資格等級對應起來)。標桿企業的標桿做法是企業進行人才培養的一面重要鏡子。針對現有業務模式和標桿企業模式的差距,可以進一步將這種差距映射到平臺或能力的要求中。例如,需求管理與規劃能力、系統設計能力、DFX能力,進而提出對流程、業務建設能力更高的要求和對員工更高級別的能力要求,從而清晰化“下接業務”的人員培養需求。知識管理、流程管理是“基于任職資格的人才培養機制”的支撐基礎。知識管理、流程管理在一般中小企業的困境是太隨意、個體化以及膚淺化,無法形成可以集成的爆破力;流程管理改善未聚焦于“問題引入活動”的控制和對關鍵業務能力提升的幫助上;知識管理、流程管理在案例、檢查清單、規范的“三位一體”架構中未形成生動、形象、有趣的知識數據庫,難以吸引也難以激發員工的學習興趣。其實,企業在發展過程中摸出來的成功經驗或失敗教訓是一筆寶貴的財富,因此需要對這些經驗或教訓進行系統化的總結。模板化是企業將良好經驗成功復制的有效手段,是知識管理和流程管理的基本手段,通過模板化,可以避免大部分工作重新開始探索,提高工作效率和效果。另外,知識管理、流程管理對人才尤其是高級別人才的要求需要進一步落實到任職資格標準的建設中。

a1.png



- 關鍵詞11:研發團隊管理模式 -

一般而言,項目團隊結構從職能結構發展到“輕度矩陣”,再到“重度矩陣”團隊結構,甚至到完全獨立運作的團隊結構。

1、職能結構的特點:· 職能部門經理處理本部門的所有決策· 當項目或組織變得很大或需要廣泛的跨部門運作時,難以協調

2、“輕度矩陣”的特點:· 項目經理是協調人· 項目組成員是職能部門的聯絡員(沒有權力)· 職能部門經理仍然做出本部門的關鍵決策· 當規模和復雜度增大時,這種結構也難以支持

3、“重度矩陣”的特點:· 項目經理在不同功能中發揮直接的、綜合性的影響· 組員完全代表相應的職能部門· 項目經理和成員有項目權力和責任· 職能部門經理關注于建立優秀的部門,而不是日常的決策· 是復雜項目和組織的最好的組織結構。

現在我們要用虛擬的團隊來開發、生產產品和提供服務,以虛擬團隊來應對挑戰已經成為現實的革命。事實上,“隨需而變”整合資源能力正在成為企業的支柱,盡管這個能力是全新的,也有可能是短暫的,但企業想要在知識經濟時代的社會網絡中構筑自己的生態環境,就必須擁有它。不管知識來自何方,團隊來自何處,必須快速加以整合、融合,以應對市場瞬息萬變的需求。團隊圍繞著客戶需求運轉,知識圍繞著客戶需求才能產生價值。矩陣式管理模式在尋找有效項目管理答案的路上,確實起到了很大的啟示作用,不過,在企業實際運作中的結果卻很糟糕,項目經理被授予的權利名不符實,反而容易陷入到無休止的跨領域的糾紛之中,在較為強勢的功能部門經理的相互推諉下,項目經理往往“孤掌難鳴”。這里有企業本身功能領域建設滯后的原因,也涉及到了對項目經理的定位、項目經理和功能部門經理相互關系等因素。以市場為導向、以項目為導向,就要給予項目經理足夠的權利和要求,從企業運作規則上明確功能領域對項目運作、項目經理的支撐要求。例如,某企業對項目經理就賦予了足夠的授權——在對項目成員的績效管理中,項目經理有“一票否決”的權利,從而保證“重度矩陣”團隊運作模式的成功建立。

a1.png




- 關鍵詞12:研發目標的平衡 -

如何在需求、質量和進度以及成本之間達到一個合理的均衡?在達到控制研發產出變異的過程中,有哪些措施可以協助我們在諸多約束條件下取得一個“最優解”?不同的企業采取的方法不同:有的傾向于要求員工加班加點來保證完成,但這畢竟不是長久之計,員工成就感低,容易疲勞,離職率高;有的喜歡砍掉一部分需求或降低質量,匆忙上市,但這如果把握不當的話,會造成客戶不滿和在維保階段的成本劇增;有的傾向于放松過程控制,托付給“高手”,但問題是高手是“稀缺資源”,“不能以一己之力承擔重托”……如果從項目管理的角度出發,通過分析企業可以采取不同的措施和手段對項目整體產生影響.

我們發現,流程裁減、砍掉部分需求、降低質量要求、增加人手、加班等手段要么對質量、成本,要么對時間產生一定的不良影響,而對技術評審和共用模塊重用卻不會產生不良影響。從整體上看,技術評審和共用模塊重用從項目質量、成本和時間都可以生產良性的正作用。

a1.png



- 關鍵詞13:研發標準化 -

標準化的形態主要有三種:設計標準化、過程標準化和工程方法標準化。下面簡單介紹它們的相關定義:  標準化的三種形態· 

設計標準化:主要指使用面廣、通用性強、作用時間較長、與產品的特性關系較小,并且已被公司廣泛接受的技術,它往往是公司產品平臺、模塊化的重要組成部分。

· 過程標準化是指相互關聯的工作形成一定的管理框架結構,并要有一定的組織原則來支持,對于每項工作都應清清楚楚地明確規定,與產品開發有關的人應該清楚工作內容、工作方法以及輸出內容,同時能夠配套度量指標以進一步衡量和優化過程。

· 工程方法標準化可以提高專業設計人員的生產力和高效工作,它是技術團隊、工程團隊的技能與能力的標準化,是設計手段、工程優化的工具。每種工程方法,如果能夠加以適當運用,將對產品開發過程起到很大的改進作用。



- 關鍵詞14:檢查清單 -

檢查清單是設計標準化的一種非常重要的途徑。對檢查清單不斷優化,是不斷固化經驗教訓、避免同樣錯誤的過程。在產品開發過程中,往往出現一種場景:在某產品某事故總結會議上,有人指出“之前好像在另一個產品中也發生過這樣的問題”。交了學費,而沒有學到東西,這是多么令人遺憾。如果不能形成檢查清單就不能夠進行設計標準化,同時,公司對經驗的學習也是零散的、艱難的、迷失的。檢查清單的使用是通過嵌入相關流程的方式來實現的。在需求階段,市場工程師、系統組和設計工程師等通力合作,對需求的各個方面,以需求檢查簡單為指導,直到得出明確的、達成共識的需求。在設計階段,隨著設計從總體、模塊到詳細設計的展開,都有各自配套的檢查清單。在驗證、試制階段,檢查清單用來把握前段環節輸入的準確性、驗證和試制輸出的有效性。



- 關鍵詞15:研發流程結構化 -

流程結構化可以達到共用流程共享和業務增值的效果。結構化流程能夠讓團隊和角色了解自身在什么時候應該做什么活動,并且也清楚彼此的需求以及何時需要對方的投入,釋放了員工的創造力。同時,結構化可以凸顯更有價值的活動,團隊成員尤其是高級人員應該重點聚焦、投入更多的時間在此類活動中。在企業管理層面,可以將員工的能力和流程活動類別對應起來(一般而言,高級人員從事創造性大、難度大和風險高的活動,而基層員工執行相對簡單的基礎活動),這樣更容易達到“讓合適的人做合適的事情”的目標。結構化開發流程自上而下總共有4個層次:階段、步驟、任務和活動。一般有3~6個階段,每個階段里有多個步驟,每個步驟里有多重任務,每個任務里又有多重活動。結構化的最高層次是階段。階段的終點是開發過程的里程碑,在某些階段的關鍵節點上,需要對是否進入下一環節做出決策。每個階段都由一些具體的步驟組成。在結構化開發中,步驟是最重要的。步驟為開發活動計劃的制訂和監控提供基礎。大部分公司的開發過程中有15~20個步驟。雖然某些項目或許不包括所有步驟,但是步驟一直應用于所有項目。例如,軟件開發步驟雖然在所有項目中是一樣的,但是,沒有軟件開發部分的項目就會省去這個步驟。步驟由多個任務組成。一般來說,每個步驟有12~35個任務。一般說來,如果沒有非常合理的理由要做出改變,任務在各種項目中是一致的。人們用任務來計算標準周期時間及定義要做的工作。完成任務是負責具體步驟的核心小組成員的職責。任務又可分成一定數量的活動。每項任務的活動數額從幾個到上百個不等。它們是每個項目小組成員每天都在做的事情。與任務不同,活動常常因項目的不同而有所變化,因為各個項目的實際工作劃分可能是不同的。這4個層次綜合起來形成了一個決策、項目進度制訂、資源規劃、過程衡量以及持續改進的基礎。






相關書籍:

《用戶力:需求驅動的產品、運營與商業模式》——互聯網的特性與價值、產品決策、需求驅動

《企業再造:企業革命的宣言書》——管理職業化、復原流程、歸納法思維

《麥肯錫意識》——產品可執行性、歸納推理、關系網絡


+86 (021) 6660 0069
總部:上海市普陀區安遠路518號寶華城市晶典大廈4樓
舊版入口

版權所有?伯特管理咨詢公司   滬ICP備12025008號  滬公網安備 31010702001269號

微信

頂部
首頁
關于我們
公司簡介
專業積累
企業愿景
客戶名錄
友情鏈接
管理咨詢服務
人力資源戰略
定崗定編定薪
績效激勵體系
員工能力開發
人力資本管理
組織效能診斷
選拔招聘服務
人力資本軟件
資訊分享
原創文章
讀書筆記
人力資本數字新聞
加入我們
加入我們
職業發展
員工留言
誠邀合作伙伴
在線留言
聯系我們
黑龙江十一选五电子版