規模化研發組織的模式創新

　　對于國內眾多提供電信、電力、金融等行業IT解決方案的組織來說，在業務發展規模化后，組織整體的發展就會出現許多問題，其中重要的問題之一就是內部的組織模式如何創新，因為這是運營效率改善的體現。
　　
　　組織規模化后易出現的問題
　　
　　第一，原有市場及客戶服務與新業務、新產品的持續研發投入之間的矛盾與平衡。國內提供行業解決方案的組織，在規模化之后，很多會面臨這種局面：不僅要同時服務多個客戶，因不斷增加的客戶需求和服務要求而疲于投入，而且要研發面向新市場的新產品或目前產品的升級，往往顧此失彼。
　　第二，以研發流程為中心構建的組織結構，不能適應規模化后的競爭和服務要求。當前的各行業事業部制的研發組織結構，大都為項目矩陣型、離岸交付的模式，一般都是按照軟件開發流程設置設計部門、開發部門、實施部門。其中，設計部門要負責新系統、新項目軟件需求及設計，也要負責原有核心業務系統需求變更、衍生項目的系統設計；開發部門負責新項目、新產品的軟件開發，以及老項目服務i實施部門作為交付及管理主體，負責協調設計部門、開發部門完成軟件交付。這種組織模式存在如下弊端：
　　●快速反應效率低。設計部門、開發部門、實施部門因為按照流程進行分工，在需求變更及服務方面，快速反應效率不高，一項工作可能跨多個部門溝通才能得出結論。
　　●無法保障新項目、新產品投入。一般大型產品周期都很長，原有產品在進入服務階段后，不斷有衍生項目、需求變更、客戶要求等，設計部門無法集中資源和精力對新項目、新產品投入，而恰恰新產品在業務和技術方面的風險是最高的。
　　●組織效率低下。設計部門、開發部門雖然都參與了新產品、新項目的定制，但只是參與其中一個環節，沒有對最終交付結果負責，交付時主要依靠前端實施隊伍溝通協調，導致協作效率、交付質量降低。
　　●員工梯隊建設和發展受到影響。如，做軟件定制開發的員工不一定安心做好服務；做新產品開發的員工因為原項目客戶不斷增加的需求和服務，而無法集中精力到新產品上。
　　
　　
　　
　　那么，如何根據產品演化周期、項目類型來進行部門的劃分，使得各部門不僅僅是一個環節，而是都面向結果的呢?所以，組織模式創新的目標要以技術為中心向以客戶為中心的組織模式轉變，并且要遵循如下原則：一是要把組織的核心資源用在找目標和將目標轉化成結果上，才能提高一線以及后方的組織效率；二是要在前線打破組織壁壘，構建全能型的面向客戶的線隊伍；三是如何讓前線的炮聲有效地傳導到后方，讓后方能高效支持一線。
　　
　　組織模式的漸進型演進
　　
　　組織模式漸進型演進，即根據各產品周期和項目所處階段，將設計責任是歸屬到設計部門還是開發部門進行規劃(如圖1)。
　　1.新產品或子產品的研發由設計部負責
　　產品演化周期可分為：產品定義、產品R＆D(研究與開發)、產品試點、產品推廣(定制)、產品服務、下一代產品開發。對于新產品實例化(產品試點)完成之前，設計應該歸口到設計部門總負責：對于超出原有產品范圍，衍生出的豐富內涵或外延的子產品也應歸口到設計部門。同時，在這個階段，開發部門要在設計部門主導下參與產品設計，為將來項目交接做好充分準備。
　　2.產品后期的設計責任交接到開發部
　　當一個新產品或者他的子產品完成了實例化(典型項目上線應用)，后續就是產品的推廣階段，該階段是根據同質客戶的要求進行定制開發，這時就可以將設計責任從設計部交接到開發部門，實現設計開發一體化。對于一些重大項目，可以延后到進入產品維護階段時，再進行交接。
　　表1是產品設計及開發的組織規劃，大致說明了一個重大產品從R＆D到完成項目實例化，衍生出子產品、衍生出子項目過程中，設計與開發工作的歸屬關系。
　　3.漸進型演進的優點
　　●精力更專注。設計部門可以根據公司業務發展需要，集中精力投入到新產品或新項目的設計研發中，不會因為對老產品或老項目的服務而牽扯過多精力。
　　●責任認定簡單。對于老產品變更及小衍生項目設計、開發統一歸口到開發部門，由其負責項目實施，使保障溝通協作及責任認定更簡單有效。
　　●規劃便于掌控。設計和開發兩個部門都可以較好掌控未來產品的發展及交接節奏，包括對人員的規劃和提前準備等。
　　4.漸進型演進的缺點
5d1714a22ba3410d2e75322f5c4adec4192a1c27aa124ec9854bbe514121fd95　　因為設計部門對老產品、老項目的業務變更跟蹤較少，當規劃原有產品的下一代產品時，可能脫節。另外對于一些重大項目方案，需要設計部門介入，但其可能對于細節流程、數據流程缺乏了解。
　　對此缺點，可以采取如下解決辦法：一是設計部門可派駐初級設計師到開發部門擔當設計或開發崗位，保障對核心產品變化的跟進；二是設計部門要對開發部門的需求規格變化、業務流變化、數據流變化進行審查，并作為產品的重要資產進行管理。
　　
　　組織模式的徹底型變革
　　
　　組織模式徹底型變革運作，即不按照開發流程、而是按照項目類型劃分部門，并且建立產品開發部，同時將定制開發部門與實施部門整合為一個部門，一口對外提供客戶定制服務(如圖2)。
　　1.變革后組織的特點
　　產品開發部全流程負責新產品、大項目的設計、開發。在交付階段，以新產品開發部為核心，實施部門配合進行交付。因為新項目新產品試點階段，最大的風險是新業務、新系統、新技術能否成功。另外，在人員安排上，新產品開發部要擔當試點項目的重要崗位，例如項目軟件經理由新產品開發部該產品開發負責人擔當。
　　實施部門與定制開發部門整合，一口對外提供項目交付和客戶服務，同時定制開發部門也可以由完全離岸開發模式，根據客戶發展要求，演進為離岸、在岸互補的分布式開發模式，對應產品開發，與漸進型演進方案相同，在產品形成項目并完成試點或推廣后，由產品開發部移交給定制開發部門負責定制后續的設計、開發和服務。
　　2.變革后組織模式優勢
　　●考核得以落地。產品開發部門主要考核新產品最終市場表現、客戶滿意度。定制開發部，主要考量通過服務帶來衍生項目和運維服務。從分工和組織上，解決了后方對一線服務不到位的問題。
　　●關注項目結果。產品開發部門與定制開發部都會負責項目，而且是全流程的負責，只是關注不同的項目。這樣避免組織以分工為目標，而不是以結果為目標，各組織將都有明確的以客戶滿意度為結果、以業績為結果的目標，只是所負責的產品階段不同，項目類型不同。
　　●防止部門間扯皮。軟件生產的管理流程、質量流程、質量要求，不是跨多個子部門，而更多是在一個子部門內流轉。
　　●避免與客戶脫離。定制開發部門與實施部門合并為一口對外提供服務，避免出現原有離岸開發隊伍慢慢脫離客戶的情況。同時實施部門與定制開發部門可以大大增加人員復用，而且實施部門直接指揮定制開發部門提高了人員利用率。
　　●人員管理動態化。可以根據行業的發展要求，動態調整負責產品和維護開發人員的比例。
　　3.實施的前提
　　通常來說，只有當業務發展到一定階段，組織規模化后才會遇到類似問題，而在業務開展初期，不用構建如此復雜的組織模式。在具體實施組織模式變革前，首先應獲得關鍵領導的支持，其次要贏得部門經理的認同，最后有專門的組織對各部門責任履行情況進行評估，保障組織運轉的有效性。各行業在進行方案選擇時，可以根據各自研發組織模式的特點、組織改變所帶來的影響進行方案選擇，并靈活運用。
　　對于各行業在規模化后所面臨的在經營、成本、質量等各方面復雜的、疊加的因素考驗下，我們必須學會從表面問題入手，深入挖掘分析深層次矛盾，抓住主要矛盾；同時借鑒各行業優秀公司在組織創新方面的經驗，從實踐中完善軟件生產及交付管理的主線，把握好方向，謀定而后動，從實踐中來，到實踐中