20年研發管理經驗談（六）

本文繼 20年研發管理經驗談（五）

如何進行產品研發業務外包？

　　進行產品研發業務外包的方式沒有絕對的標準。行業分析師指出,理解其中的差別一般與一家公司管理層的成熟度有關,而不是與公司自己規模或者存在的歷史有關。最佳的方式是把產品線和研發分紅兩類：一類是構成該公司將來競爭力的核心要素,另外一類是非核心要素,把非核心的部分外包。

　　許多狀況下,OEM公司傾向於將本身無力承擔的工做外包出去,即便是系統中的關鍵部分。「許多廠商將軟件開發外包給印度和其它地方的軟件設計商,這並非由於它們不是核心業務,而是由於這些廠商不具有這樣的開發能力和團隊。」市場諮詢公司Pittiglio Rabin Todd & McGrath(PRTM)歐洲創新業務主管David Percival表示,「沒有足夠的人手致使了許多公司將軟件開發這種核心的研發業務外包。」

　　比較適宜的作法應是充分利用本身的內部資源來定義和制訂產品規格,監督第三方合做夥伴開發,而後在內部進行測試和驗證。Percival認爲,這可能要求OEM廠商的開發隊伍從新進行技能訓練。

　　另外一個廠商常常犯的錯誤是將一些比較先進的開發工做外包。由於他們老產品的技術檔案太糟糕和複雜,只有他們本身內部開發人員才能維護這些文檔。「結果致使公司寶貴的研發資源和團隊被禁錮起來,公司依賴外部夥伴來開發新的和使人激動的產品,而這些產品正是其競爭力的來源。」Percival說。

　　比較適宜的作法是多花點時間進行正確地設計、調試和對當前設計創建文檔,而後再外包,將內部資源集中用於新產品的研發上。Percival強調說：「在你將產品中獨特元素外包的同時,你將利潤也外包出去了,最後剩下的只有一個空殼。」

 

產品開發流程的七要素

　　引言：PACE在產品開發過程當中的應用和擴展是一種實實在在的挑戰，而那些成功運用PACE方法論和工具的企業也必將從這種挑戰中獲得顯著的回報。

　　產品開發流程能夠分爲七個相關要素，每個要素都有其常見的不足之處。PACE提供了各類方法、技巧和手段，以克服每個要素的不足之處。下文對這七個相關要素做了介紹，對一些常見的不足之處進行了總結，並針對每個要素簡單介紹了PACE的解決辦法。　　

　　在之後的章節裏，將進一步詳述PACE的每個要素。

決策

　　全部的公司都有一個新產品決策流程，儘管他們有可能並無認識到這是一個有明肯定義的流程。在決策流程薄弱的公司，因優柔寡斷形成的延誤很廣泛。例如，若是某個實際流程是順序性的，要求許多經理一一確認某產品設計概念的優劣，那麼，起動就會延誤。咱們看到，許多良機的錯失只是由於產品先驅們不知道如何運用這種不正規的決策流程。

　　咱們曾經幫助過的一家電腦公司有一個效率低下的決策流程，能夠說它是咱們所見過的許多流程當中的典型。在這家公司裏，項目評審已淪爲一系列面向不一樣聽衆的冗長的彙報。參加的人不少，提出的問題也不少，但這些彙報會並非決策會議。評審並無在開發流程的適當時機進行以促使決策，合適的信息也沒有提供出來以推進決策。高層管理人員迴避了評審，而且沒有其餘機制來推進適時決策。

　　然而，並不是全部明肯定義的決策流程都是有效的。有些流程要麼設計得很糟糕，要麼實施不當。在這些狀況下，一個正正規規的流程實際上對產品開發構成了管理障礙。花費大量時間，卻收效甚微，這樣的決策流程早已不能推動產品開發。

　　在產品開發評審中，咱們發現因決策流程不當會引起下列問題：

·因爲高層管理人員不知道應該由誰來做出決策，或者須要什麼樣的一致意見，因此他無心識的延遲決策或修訂決策。
·信息不夠充分或細節不清楚致使決策質量低劣。
·沒有及時解答疑問。
·未定義決策控制點，以致在適當的重要階段又出現了評審工做。
·須要投入的資源過多，以致沒法定期完成任何事情。
·受權審批和設定優先順序的人沒有明確批准給予產品開發項目的撥付資金。
·決策太遲——常常是在產品已經設計出來以後。
·沒有用週期指導來證明項目進度。
·高層領導沒有做出戰略決策，卻由開發人員在無奈中做出這種決策。

　　在PACE流程中，新產品決策是經過階段評審流程進行的，這種階段評審須要在開發流程中具體定義的點上做出決策。一個產品開發項目必須在預約時間內達到明肯定義的目標，才能獲准進入下一階段。

　　產品審批委員會（Product Approval Committee, PAC）是指在一個部門或一個公司內負責主要新產品決策的高層領導小組。PAC有權在開發週期內的具體決策點經過給新產品撥付資金或修改新產品的途徑來批准或拒絕新產品。PAC負責經過產品開發活動實施公司的戰略，所以，他們具備資源分配權，以推動新產品的開發。

　　PAC通常經過階段評審流程來做出決策和進行資源分配。沒有這樣一個流程，高層領導就難以有效地引導新產品的開發。然而，只有一個評審流程（或相似的一個流程，如把關流程或階段開發流程）是不夠的。定義不清、實施不當或與開發流程中的其餘必要要素不協調，均可能使評審流程效率低下。

　　階段評審流程在產品開發中還扮演着另外一個重要角色。經過它，PAC能夠直接明瞭地受權項目小組分階段地開發產品。項目小組爲產品制定詳細的建議，提交產品開發計劃，並申請下一階段所需的資源。若是PAC批准工做小組的各項建議，它會賦予項目小組以權力、責任以及實施小組計劃的下一階段所須要的資源。

項目小組構成

　　在評審中咱們發現，儘管大多數公司有正規的項目小組，但多數並不成功。總的來講，因爲這些項目小組的構成、角色和責任沒有明確的定義，結果使溝通、協調和決策效率低下、紛繁混亂。

　　有這麼一家很典型的公司，不可勝數的經理們只在他們有空的時候或是有什麼特別緣由使會議變得最優先的時候，他們才參加產品開發小組的會議。因爲這種方法產生的效果差，因此公司曾嘗試用不一樣的方法來改變這種情況。他們創建了專門的項目管理www.hi-blue.com部門，負責監督進度和任務的提交，以明確由誰去作什麼以及事情作了沒有。後來，每一個部門都給每個主要項目指定了本身部門的項目經理。但這些方法效果並不理想，只是增長了毫無價值的勞動，而這種勞動已經太多了。

　　許多公司創建了項目小組的組織形式，但大多數效果不佳。針對這些不成功的案例，咱們發現如下典型緣由：

·若是項目小組和職能部門的責權不明確，將形成困惑。
·項目小組沒有獲得明確受權去實現目標，於是效率低下；在某些狀況下，他們只被賦予了責任，卻沒有相應的權力和資源。
·缺少並行工程，一些職能和技能沒法和諧地融入到項目小組中去。
·項目領導工做效率低，這源於幾個因素：項目領導人沒有經驗；對項目領導人角色不明確；培訓不足；項目領導人更換頻繁；或者項目小組的組織有缺陷。
·項目小組缺少項目實施所需的人手和技能，於是沒法實現目標；各類資源在項目小組間調來調去，缺少明確的決定。
·因爲沒有明肯定義項目小組和職能部門之間的協做方法，二者之間便有衝突和困擾。
·小組成員任務分配形成的困擾使整個小組效率低下：好比說，小組成員把本身看做職能部門的評估者或記錄者，而非真正地幫助進行實時決策。

　　項目小組構成是產品開發流程的一個關鍵要素。一個高效的項目小組能極大地增進溝通、協做和決策。在評審初期，咱們就發現許多廣爲接受的項目小組模式效率低下，而低下的緣由與上文所述頗爲類似。咱們開發了一個新的模式。這個模式既能發揮項目小組這種組織形式的最佳方面，又能克服上述缺陷。咱們把它稱之爲項目小組構成中的核心小組模式（Core Team Approach）。

　　核心小組是有權開發特定產品的一個小型跨部門項目小組。一個典型的核心小組有5—8名成員，有權力也有責任管理全部與開發該特定產品相關的任務。這些特定任務分配到核心小組的每一個成員身上，每一個成員都利用相應資源完成這些任務。小組成員們爲指定給他們的工做肯定方向，與職能部門打交道，並做爲核心小組的一員參與集體決策。PAC則在開發工做的每一階段經過階段評審流程賦予核心小組責任和權力。每一個核心小組都有一個指導和引導小組工做的領導人。該小組在執行每一開發階段時遵照與PAC簽訂的有關重大項目目標以及可變更的範圍的「合同」。

開發活動的結構

　　開發活動是開發新產品的實質性工做。在PACE中，結構化的開發流程明確了應作什麼開發工做、相應的前後次序、其間的關聯性以及用於開發項目的標準術語。在評審流程中，咱們發現，開發活動的結構中每每存在三類廣泛的缺陷：(1)沒有任何明確的產品開發結構的公司；(2)有具體流程手冊但並沒獲得遵循的公司；(3)有結構化的流程但並不能改進或加快開發進度的公司。

　　對第一種狀況來講，公司必須在產品開發流程中不斷地「從新發明車輪」，即從新定義產品開發流程。每個項目小組都定義其要遵循的流程，結果，每一個項目小組即便在執行相同的或類似的任務時，開發流程也迥然不一樣。這種模式延長了開發週期，且整個公司的項目小組都易犯一樣的錯誤。

　　對第二種狀況來講，流程被文檔化了，可是並無獲得執行。典型的狀況是，某個職員在程序手冊裏定義開發流程，而後把手冊散發出去，天真地期待每一個人都會遵照它，結果固然是他們並不遵照。多數狀況下，他們不遵照反而好一點。項目小組又各自將本身的那一套流程搬了出來。

　　對第三種狀況來講，開發流程已獲得明確和遵照，惋惜這個流程天生就效率低下。使人吃驚的是，許多公司在規範流程時，只是簡單地將他們現有的作法寫成文件，哪怕這個流程效率低下，其結果天然是把問題制度化了。

　　在評審開發流程時，咱們發現廣泛存在下列缺陷：

·無章可循的開發活動致使產品不斷更新。
·因爲對必須完成什麼樣的開發活動及什麼時候完成有誤解，於是形成項目計劃不周及準備不足。
·缺少通用術語以及由此引發的理解問題，致使開發工做不理想。
·產品開發定義過於詳細，尤爲是缺少結構化的定義，使得開發效率不高。
·每一步都須要多個簽字蓋章的官僚流程延緩了開發工做。
·缺少並行工程，由於它沒有被設計到結構化開發流程裏。
·缺少開發活動的週期時間指導，致使項目進度不許確。
·因爲沒有將責任落實下來，致使未能不斷地改進產品開發流程。

　　在PACE方法中，核心小組用結構化開發流程開發產品，這將確保一致性，並避免小組創立各自的流程。基於一個通用的結構化流程，就可使用通用的週期時間指南併爲持續改進打下基礎。

　　按照PACE的方法，一個結構化開發流程包括幾個等級。在階段評審流程所提供的框架中，通常有15—20個主要步驟來定義一個公司的產品開發流程；每一步又分紅10—30項任務，規定每個步驟如何在公司裏得以實施。這些任務又爲每個步驟定義出標準週期時間，所以能夠根據這些基本步驟編制進度表、預估資源需求、制定計劃及進行管理。

　　每一項任務還可進一步細分紅各類各樣的開發活動。根據任務的性質，每一步驟的開發活動數量從幾個到30或40個不等。總的來講，各步驟與任務永遠適用於各類項目，而開發活動則因項目不一樣而不一樣。