研發管理

出自 MBA智库百科(https://wiki.mbalib.com/)

該條目對應的頁面分類是研發管理。

研發管理(Research and Development Management，簡稱R&D Management)

　　研發管理就是在研發體繫結構設計的基礎之上，藉助信息平臺對研發進行的團隊建設、流程設計、績效管理、風險管理、成本管理、項目管理和知識管理等活動。

　　研發管理首先要確定研發體繫結構，然後按照體繫結構組建高水平研發團隊，設計合理高效的研發流程，藉助合適的研發信息平臺支持研發團隊高效工作，用績效管理調動研發團隊的積極性，用風險管理控制研發風險，用成本管理使研發在成本預算範圍內完成研發工作，用項目管理確保研發項目的順利進行，而知識管理讓研發團隊的智慧聯網和知識沉澱。

　　研發體系設計

　　在具體的研發模式上，通常有以下三種，通常有以下三種：

　　研發團隊建設

　　研發是一項創造型的工作，卓有成效的研發需要優秀的研發團隊來完成，可以說"有什麼樣的研發團隊就有什麼樣的研發成果"。卓越的研發團隊由以下三個因素決定：團隊中的個人、團隊機制和團隊文化

　　研發流程設計

　　研發優勢的唯一可持續源泉是卓越的研發管理流程。以某項卓越設計、天賜良機、對手的某個失策或某一次幸運為基礎的優勢是不可能長久的。而優越的研發流程則始終能夠發現最佳的機遇，推出有競爭力的產品和服務，並以最快的速度把這些研發成果投入市場。

　　研發流程改進也是個持續的過程，需要不斷的持續改進研發流程。研發流程管控保證研發流程設計與改進的持續性、規範化、程式化。

　　研發成本管理

　　隨著微利時代的來臨，企業要從各個方面節約成本，包括研發成本也要控制。研發成本控制並非指壓縮研發規模或者減少研發投資，而是指減少研發中不必要的開 支，用較少的投入獲取較大的研發成果。研發成本管理要和研發成果收益結合起來。產品在其生命周期的不同階段，所能獲取的利益不同，研發要在產品的不同生命 周期有不同的投入，比如在新產品開發的時候研發投入較大，但是研發收益幾乎沒有，一旦新產品開發出來，收到市場的歡迎，則要加大研發投入，改進產品性能。 到產品的成熟期，市場競爭激烈，產品改進研發投入要收縮，直至完全取消。

　　研發項目管理

　　研發屬於動態作業，整個流程可能橫跨所有部門，故研發是以項目為導向的，研發管理中項目管理不可或缺。

　　研發績效管理

　　研發管理的績效管理能夠有效的激勵研發團隊積極工作，促成研發成果。研發管理的績效評價指標有如下幾個方面：研發項目的難度、研發效率和研發質量。研發績效管理應該考慮企業的整體戰略，應用平衡記分卡等工具制定研發績效評估系統。

　　研發風險管理

　　研發人員可能被競爭對手挖角，對外泄密或者惡意破壞。研發信息風險指研發信息可能被研發人員泄密或者破壞，也可能因為遭受災難、意外事件或者別人的攻擊導 致風險。研發成果風險指研發出來的產品或者服務可能是過時的或者是不受歡迎的，或者研發的投入太大引至企業經營風險，或者研發的投入大於研發產生的效益。 研發風險管理則是以風險為主要的控制目標，制定一系列規章制度有效將風險降低到可接受水準以下，否則就必須增加控制措施。

　　研發管理至少應具備以下三種條件：

　　1、 製造一個鼓勵創新、適合研發的環境，必須採取彈性而目標化的管理，不以死板的制度限制員工的創意，必須要求實質的成果。

　　2、 將行銷的觀念融入研發中：為使有限的資源發揮最大的效益，研發部門亦須有"行銷感"，最好是讓行銷人員參與研發的過程，如此產品才具有市場價值。

　　3、 研發策略的訂定與掌握：有了策略方針，才能對手中所掌握的有限資源善加規劃、運用，以求在最短的時間內，達到最高效益。

　　研發管理與技術創新的關係

　　在技術創新過程中必須理清技術創新與科研管理的關係。

　　第一，技術創新必須建立在企業現有的現實基礎上。由於當前世界的技術進步是建立在不斷創新的基礎上，對於任何一種新產品來講都具有許多技術創新點。如何確定新產品的技術創新定位是與企業的現實基礎直接相關的，也是該新產品研製成功的關鍵。

　　第二，科研管理必須嚴格控制技術創新帶來的隨意性和不可預見性。由於技 術創新的含義就是在產品研製過程中引入了企業不熟悉或者未掌握的新技術，如何預期新技術帶來的效應，嚴格控制研製過程各個技術狀態，把技術創新納入到規範 化的科研管理流程中去是新產品研製成功的必要保證。

　　第三，技術創新必須建立在規範化科研管理的基礎上。由於技術創新需求在產品的生命周期內不斷變化和增 加，在科研過程中必須鎖定技術創新的變化，使整個研製過程技術狀態控制在系統預期設計的狀態控制流程中去。

　　研發管理與技術創新考慮的基本要素：

　　a.技術創新主要考慮的幾個主要方面： 市場需求、技術儲備、人力資源、資金需求、設備狀態、研製周期；

　　b. 技術創新狀態在系統需求設計時確定；

　　c. 在項目研製過程中要嚴格控制技術創新, 所有的後續設計與研製必須控制在系統設計的控制流程內；

　　d. 新的技術創新一般按階段在系統升級產品中或新立項產品中統一解決；

　　e. 確因十分必要, 新的技術創新首先在系統設計師會議上研究, 確定該項目當前研製的技術狀態, 確定的各狀態回溯節點, 修改系統需求設計, 形成新的項目的所有的研發控制文件,以及新的響應文檔。

　　研發管理和麵向市場的關係

　　在技術創新過程中必須理清面向市場與規範管理的關係。

　　第一，要面向市場，市場需求是企業新產品的主要來源；

　　第二，在新產品開發前要確定當前市場的需求, 並預測一定量的市場需求的超前發展的餘量。

　　第三，在新產品開發過程中, 應凍結市場需求的變化, 所有的開發與研製過程都必須嚴格控制在系統規範管理的控制流程中。

　　第四，市場新的需求一般在系統升級產品或新立項的產品中考慮。

　　研發管理與面向市場考慮的基本要素：

　　a.市場需求是研發項目的主要來源；

　　b.在系統需求設計時要確定當前市場的需求, 並預測一定量的市場需求的超前發展的餘量；

　　c.在系統需求完成後, 凍結市場需求, 所有的後續設計與研製都必須嚴格控制在系統設計的控制流程中；

　　d.市場新的需求一般在系統升級產品或新立項的產品中考慮。

　　系統最優和局部最優的關係

　　在系統設計時, 綜合分析和考慮市場需求、技術儲備、資金狀態、設備狀態、以及研製周期等重要因素，儘可能在當前情況下進行系統綜合考慮，儘可能做到系統最優設計。

　　在系統設計時,一般不考慮局部最優。主要原因如下：

　　a.在系統設計階段, 無法詳細考慮局部的實現；

　　b.一旦系統設計完成, 所有的局部實現必須嚴格在系統設計的控制下, 遵循系統規範和約束條件實現局部設計；

　　c.在系統設計時, 一般都考慮了系統餘量, 所以局部最優對整體系統性能影響不大；

　　d.追求局部最優很容易帶來系統失控和一些副作用, 將影響系統最佳的實現。

　　（1） 相信原則

• 相信規範；
• 相信工具；
• 相信經驗；
• 相信上層。

　　（2）不相信原則

• 對自己完成任務的正確性和完整性不相信；
• 對下層完成任務的正確性和完整性不相信；
• 對已驗證過的任務進行綜合的正確性和完整性不相信；
• 對已驗證過綜合的系統適應性正確性和完整性不相信。

　　縱橫分工原則

　　（1）橫向分工

• 按專業分工劃分。如：通信、軟體、硬體、結構、電源等。

　　（2）縱向分工

• 按層次劃分。
• 系統設計、開發與調試，生產加工、測試與驗證

　　信息文檔化原則

• 信息規範化；
• 流程階段化；
• 傳遞文檔化；
• 文檔模板化。

　　需求分析過程

　　需求分析過程是在新產品研發啟動之前，對新產品研發過程將要涉及到的各種要素進行系統化、定量化的分析，使之後繼的研發過程都在預先研發要素設計的控制流程中。在需求分析過程主要進行以下要素分析：

• 市場需求可行性分析；
• 關鍵技術需求分析；
• 開發環境需求分析；
• 開發成本需求分析；
• 人力資源需求分析；
• 研發進度估算與分析。

　　設計過程是在項目啟動的條件下，根據需求分析的要素定義，旨在建立一套規範的研發設計流程，明確專業技術分工，確定設計考慮的範圍和要素，消除研髮狀態混淆不清、研發問題隱藏和向後傳遞等問題。在設計過程主要進行以下過程設計：

• 系統設計規範；
• 系統需求設計；
• 硬體設計需求；
• 軟體設計需求；
• 系統可靠性設計；
• 硬體測試性要求；
• 軟體測試性要求；
• 硬體系統邏輯頂層設計；
• 軟體頂層設計（概要設計）；
• 硬體邏輯詳細設計；
• 軟體詳細設計與編碼；
• 硬體測試環境設計；
• 軟體測試平臺設計。

　　模擬驗證過程設在設計過程完成的基礎上，為了充分保證設計的正確性，提高設計質量，消除後續工程實施的不確定性，並驗證工程餘量的要求，必須對新產品的關 鍵技術進行模擬驗證，以確保新產品的關鍵技術的工程可行性。在有條件的情況下，要對設計實現的硬體電路進行模擬驗證，以保證產品基礎運行平臺（硬體系統） 的穩定型；還要對軟體設計和軟硬體綜合進行模擬驗證，以保證軟體實現的正確性和軟硬綜合的融合性。

　　由於IT產品設計中蘊藏了大量的設計者對產品功能要求的理解和處理思想，而這些理解與實現有緊緊地依靠設計者個人的知識背景、專業領域和個人能力等方面的限制，因此必然在產品功能的設計實現中，存在大量的錯誤和不完善的地方。

　　另外，在設計中還採用了大量的設計工具， 設計者面對的不是產品，而是面對的由一組工具組成的設計平臺，設計者根據工具的功能，發出相應的命令，由工具完成 命令的實現。由於工具實現過程是工具的設計者依據通用情況考慮的，對產品設計者來說是一個"黑箱" 操作過程，因此必然存在工具設計者的思想與產品設計者 思想和理解存在著差異，特別是對產品的一些不太重要的性質或要素尤為突出。這就是IT行業中經常談到的工具的副作用。

　　因此，建立產品的開發環境是IT產品研發重要的組成部分。

　　對於IT產品的研發來說，測試環境具有十分特殊的地位。從發達國家IT產業的研發來看，產品測試的費用和測試周期占產品研發費用和周期的40%左右，並保持上升的趨勢。由此可見，測試環境對IT產品的研發來講，具有十分重要的意義。

　　為什麼測試環境具有如此重要的地位？其主要因素是由IT產品自身的特征所決定的。由於IT產品的功能設計是一種事前決策規則設計，決策人的能力和知識背 景、環境要素的變化狀態都將影響決策的質量。那麼在環境要素動態組合變化的基礎上，如何確認決策的正確性，特別是非正常環境變化的基礎上，如何確認決策的 安全性，是一項難度很大的任務。這種確認的技術難度在通常狀態下要比決策本身難度大得多。這就是測試環境具有重要地位，也是IT產品與傳統產差異的主要特 徵之一。

　　產品的構型是產品研發成功的保證。

　　新產品研發過程構型定義是站在工程的角度上，對新產品研製過程里程碑的定義。

　　關鍵技術構型

　　根據"需求分析"定義的關鍵技術，在企業技術儲備的基礎上，定義該新產品採用的關鍵技術的構型狀態，驗證其關鍵技術的可行性，確定產品的新技術的含量和定位，為後繼的構型消除新技術帶來的不確定性。

　　原理樣機構型

　　根據關鍵技術構型確定的新技術的定位，根據其它成熟技術的配套，定義新產品原理樣機的構型狀態，驗證產品所有功能、新技術與成熟技術融合的可行性，併在滿 足系統功能的前提下，對軟硬體的邏輯進行適應性修正，確定新產品軟硬體功能實現的正確性，為後繼的構型奠定軟硬體功能的基礎。

　　工程樣機構型

　　根據原理樣機構型軟硬體的功能，根據工程環境的要求（如：重量、功耗、尺寸、散熱、電磁兼容性等），以及和其它設備的鉸鏈關係，定義新產品工程樣機的構型 狀態，完善原理樣機構型在應用工程環境中要素要求，驗證新產品在應用的（或模擬的）工程環境中的性能指標和實現功能的正確性，為最終形成產品的應用狀態- 生產樣機的構型奠定工程化的基礎。

　　生產樣機構型

　　根據工程樣機構型驗證的結果，定義新產品 生產樣機的構型狀態，提交給用應用試驗環境驗證。從用戶使用的角度出發，通過大量的、不同用戶的應用試驗實例，驗證新產品所有功能實現的效果和正確性，並 根據其結果形成最終使用結果意見，提交給研發部門。研發部門根據產品的當前狀態，根據企業或行業的生產能力，生成生產流程和相應的生產工藝文件，並確定測 試與檢驗標準，為產品的生產奠定基礎。

　　（1）設計驗證環境：系統功能模擬、 硬體設計操作（時序）模擬、軟體功能模擬；

　　（2）開發驗證環境：硬體測試、軟體測試、軟硬體綜合測試；

　　（3）系統驗證環境：與各種環境、各種型號、各種廠家的產品綜合試驗環境；

　　（4） 例行試驗環境：溫度、振動、場強、電磁干擾試驗等。

　　研發管理方法，通俗地講就是：告訴人們在什麼時候做什麼事情，而且學會把事情做好。衡量研發管理優劣的三個關鍵指標是：質量、時間和成本。人們總是希望做 得好（即質量高）、做得快（即時間少）而且少化錢（即成本低）。如果出現三者難以同時兼得的情況，那麼決策者一定要搞清楚質量、時間、成本之間的複雜關 系，判斷孰重孰輕，給出優化和折中的措施。

　　1 "雙崗制"

　　"雙崗制"是我國許多科研企業針對人員流動造成知識產權流失提出的一種解決方法。所謂"雙崗制"是在研發過程的重要位置上設立兩個崗，完成同樣的工作，互為備份。"雙崗制"帶來的主要問題是：

　　第一，由於重要的崗位用兩套人馬使用兩套設備完成同樣的工作，造成人力資源和設備資源浪費；

　　第二，如果兩套人馬完成的結果不一致，造成確認成本的增加；

　　第三，由於研發過程有許多環節，如開發過程：設計、模擬、調試、測試；研製階段：原理件、工程件、工藝件、試驗件、試用初件等，如果兩套人馬生成的兩套版本都要通過驗證過程的所有環節，將大大的增加研製成本、研製周期和造成資源的浪費。

　　由於在每個"雙崗制"研製成本和研製周期幾乎翻一番，這樣，如果在該產品研製過程中有多個"雙崗制"位置，整個研製成本和研製周期將會形成爆炸性組合增加。

　　2 "重要的部分由多個人分解承擔"

　　"重要的部分由多個人分解承擔"，這是我國許多科研企業針對人員流動造成知識產權流失提出的另一種解決方法。所謂"重要的部分由多個人分解承擔" 是研發過程中將重要的部分和環節進行任務分解，由多個人共同承擔和協作完成。"重要的部分由多個人分解承?quot;帶來的主要問題是：

　　第一，如果將重要的部分和環節進行任務分解，將增加系統內部通信開銷和協作成本；

　　第二，如果採用重要的工作由重要的人承擔的原則，如果重要的人員不再承擔其它重要的工作，將造成人力資源的浪費；如果重要的人員還承擔其它 重要的工作，如果一旦人員流動，將會造成多個重要任務的知識產權流失，涉及和影響的面會更大；

　　第三，由於研發過程環節很多，重要任務的分解和多個人員的參與將會大大增加研發成本和研製周期。

　　3 "記者式"的研發方法

　　接受主題: 根據上級領導的要求立項和接受項目

　　採訪素材: 自行搜尋和定義市場需求

　　自行歸納: 自行歸納核定系統功能需求

　　自由發揮: 獨立自由完成功能的實現

　　自己定稿: 自行定義測試和驗收的標準

　　"記者式"研發管理方法主要問題是：第一，以個人為主體，從接收任務（接受主題）、搜集需求（採訪素材）、定義功能（自行歸納）、獨立研究（自由 發揮）、自行測試（自己定稿）到任務交付，整個研發過程都由個人控制完成，從而受到了個人認知能力的限制。特別在當今知識經濟社會中，知識爆炸、專業分工 與綜合技術是知識經濟的主要特征，因此，個人認知能力遠遠不能滿足社會的需求；

　　第二，由於個人專業分工的限制，"記者式"研發管理方法往往只突出了個人的專業領域的應用，而忽視了其它專業領域的有效介入；例如：硬體工程師只突出了硬體設計的有效性，忽視了系統設計、模擬分析、軟體設計、硬體測試、軟體測試、系統綜合等專業應用發揮；

　　第三，自行定義測試和驗收標準屬於自己立法，自己執法，與研發產品質量控制和最終確認的基本原則相違背。

　　第四，"記者式"研發管理方法將導致知識產權落入個人控制之中。

　　4 "逐級下達式"研發管理方法

　　主題選擇決策： 上級領導

　　系統功能確定： 由承擔任務書個人的能力和理解力確定

　　研製狀態控制： 項目組各自為政

　　結果測試確認： 自定義測試與驗收標準

　　"逐級下達式"研發管理方法主要問題是

　　第一，以責任傳遞為研發控制流程的主線，以任務書為研發任務完成的目標，忽略了研發過程和研製狀態節點的控制與檢驗；

　　第二，責任書和任務書難以全面反映市場需求和產品功能定義，把市場需求和產品功能定義交給任務組來完成，從而受到任務組認知能力的限制，難以體現多專業系統綜合和企業整體水平的有效發揮，造成產品研製目標與市場需求脫鉤；

　　第三，各任務組以任務書為研發任務完成目標，以責任書為交付狀態，各自為政，造成各任務組之間技術協調和系統綜合難度增大，難以有效實現系統總體目標；

　　第四，各任務組根據責任書和任務書自行定義自己承擔任務的測試和驗收標準，從而不僅造成了自己立法，自己執法狀態，違背了研發產品質量控制和最終 確認的基本原則，而且由於各任務組承擔任務的角度和認知能力的不同，各自定義的測試和驗收標準難以統一合併形成系統統一的測試和驗收標準。

　　5 "小爐匠式"研發方法

　　自我中心：以自我為中心，不願易與別人合作

　　自我封閉：以自身技術能力為項目全技術狀態

　　自我開發：自我封閉開發，不願意讓別人瞭解和提建議

　　"小爐匠式"研發管理方法主要問題是：

　　第一，容易產生以個人為中心，個人的認知能力決定了項目的技術狀態；

　　第二，自我封閉開發，不願意採用自己認知能力之外的成熟技術和新技術，一切從底層開始，低水平重覆；

　　第三，缺乏規範設計，增大了產品技術實現的模糊性，難以實現產品的維護和升級；

　　第四，知識產權掌握在個人手中，容易造成知識產權流失。

　　PACE法

　　早在1986年，美國PRTM公司創作了PACE（Product And Cycle-time Excellence，產品及周期優化法）方法論。 PACE關註的要素有：正確決策、項目小組構成、開發活動的結構、開發工具與技術、產品戰略、技術管理、資源管理。PACE算得上是產品生命周期管理領域 的方法論鼻祖。PACE誕生之後，很多企業和學術機構不斷地提出了適合於本行業的研發管理方法論，

　　ISO9000族質量體系

　　國際標準化組織（ISO）為了滿足國際經濟交往中質量保證活動的需要，在總結各國質量保證制度經驗的基礎上，經過近十年的工作，於1987年發佈了 ISO 9000質量管理和質量保證標準系列。1994年進行了第一次修訂，形成了ISO 9000族標準。2000年再進行了重大修訂，發佈了 ISO 9000新標準（2000版）。

　　CMM/CMMI

　　1986年11月，美國聯邦政府委托卡內基梅隆大學（Carnegie-Mellon）軟體工程研究所（SEI）開發一套用於評估軟體承包商能力的方法。 SEI於1987年9月發佈了一套軟體過程成熟度框架和一套成熟度問卷。1991年，SEI將軟體過程成熟度框架發展成為軟體能力成熟度模型 （Capacity Maturity Model，CMM），誕生了CMM 1.0。

　　PMBOK

　　項目管理知識體系是項目管理專業領域知識的總稱，它是20世紀80年代由美國項目管理協會（PMI）總結了項目管理實踐中成熟的理論、方法、工具和技術所提出的。PMBOK還在不斷更新和完善當中，目前最新版是PMBOK2012。

　　PMBOK定義了為44個基本的項目管理過程，從過程輸入、輸出以及採用的工具和技術的角度給出了項目管理過程的詳細描述。這44個項目管理過程基本覆蓋了項目管理實踐中的基本管理過程，但是，這些項目管理過程必須和產品實現過程結合起來，才能完成整個項目活動。

　　敏捷開發

　　RUP