研發無小事，事事要重視。短期看效益，長期看體系！
做了幾年的產品，剛混熟了產品圈，今年又臨危受命負責整個研發團隊，對過去分散式的研發體系（研發在各事業部）進行整合，研發統一管理。
過去我們一個產品一個產品的突破，逐步形成了多產品線的研發模式，這種模式突出的優點就是敏捷迅速，能結合市場快速的試錯，擁抱變化。但是當業務發展到一定階段，這種太過分散式的管理就會產生一系列的問題，又給發展帶來一定瓶頸。
結合自身團隊，突出的問題表現在：
- 產品分散重疊，產品線之間信息缺乏共享，公共部分產生重複開發；
- 缺少統一技術路線，多語言，多技術體系，不利於深度積累和合作協同；
- 研發人員分散管理，容易產生資源缺乏和浪費，且協同成本巨大。
其實這些問題在一些大的互聯網公司都經歷過，像騰訊、阿里這樣的公司他們經歷的時間也更長，畢竟業務發展太快，來不及調整隻能往前衝。如何打造一個既能解決以上問題，又能依然保持早期的敏捷靈活，這的確是一個難題。這就像春秋戰國一樣，劃分諸侯國容易，但是再把他們合起來那就太難了。
- 難點1：某些業務和產品已經成型，我們知道存在很多重複和浪費，但共享重構是需要付出巨大時間成本和人力成本的，既要修車又不能把車停下來。
- 難點2：每個團隊的技術路線已經成型了，切換的成本是巨大的，但不切換未來的成本會更高，很糾結。
- 難點3：山頭已經形成，打破山頭重新組合，雖然說是不破不立，但必然帶來很多不安定因素。
圖1:IPD研發管理體系
好在IPD（集成產品開發）的研發管理模式，給我提供了一定的理論基礎。經過一個季度的推行，雖然取得一些成果，但依然離我的期望有很遠的距離，過程也比較累。
近幾年很多大公司都在向集成研發，共享研發方向轉型，這是一個趨勢。特別是阿里的中臺戰略就是一個特別典型的案例，通過設立共享事業部整合內部的研發資源，通過中臺架構積累共享的平臺能力，經過幾年的陣痛，阿里的中臺戰略逐漸開始顯露威力。
所以組織架構轉型，著手打造一個優秀的研發體系，從長遠看對業務的發展具有很大的推動作用，否則後面會越來越慢，越來越亂。
我在《互聯網產品運營體系總結之產品設計》一文中曾總結了產品設計的框架模型，順著我做產品的習慣，研發體系可以虛擬成我要做的產品，相對應的我依然提煉了一個框架模型。
圖2：研發體系思維框架
前提：清晰的業務模式
技術是為業務服務的！不管是技術驅動還是市場驅動，首先要清晰的瞭解公司的戰略方向和規劃，清晰的瞭解業務模式，因為不同的業務模式對於研發的要求也不是不同的，世上沒有萬能的理論和方法，只有因地制宜的實踐。
在一次會議上，Boss曾提醒我說，“如果方向不對，管理做的越好可能離目標越遠”，非常有道理，所以研發體系不只是一個技術活，它更是對公司戰略分解的一個重要環節。
圖3：不同業務模式關注點
那我們的業務模式是什麼呢？基於自己的業務模式我們又關注哪些因素呢？
用於舉例說明，我簡單的把業務模式抽象成：軟件外包模式，產品銷售模式，雲服務模式和平臺模式。前兩種偏傳統軟件業務，後兩種偏互聯網業務，它們肯定會存在若干的差異（如上圖表格，僅做示例，不全面）。
當然還有其他關注維度的劃分，比如：從領域上分為行業應用、大數據應用、人工智能、基礎技術服務等等，不論什麼維度或者多維組合，我們要清晰的知道我們在哪！
而且我們也不能僅僅考慮當前的現狀，還要考慮公司的戰略規劃和業務發展的要求，假如現在以做項目為主，但項目意味著源源不斷的需求，這些需求沉澱積累就可能會變成產品，產品反過來又不斷的支撐項目。
軟件產品互聯網化就轉變成雲服務模式，雲服務免費提供，服務開放也說不定變成平臺。研發體系根據業務的變化和發展的不同階段，要在時間和空間維度上建設的更加立體，有效的支撐業務的多樣和多變！過早的投入是浪費金錢，太晚的投入是浪費時機，研發體系的建設也要講究節奏！
發展：高效的產品轉化
定製化的外包項目的毛利率在整個行業基本上不會超過30%，而產品（不管是單體軟件還是平臺上的功能，我們都可以稱之為產品）代表著它具備通用性和普遍性，也就意味著產品具有很強的可複製能力，如何有效的支撐業務換句話講就是看能否高效的進行產品的生產，不斷滿足更多客戶的需求。
現在產品經理的崗位越來越多，也越來越受重視，因為產品經理的職責是設計產品，帶領產品發展，是公司發展的強大支撐。
有的產品經理嗅覺敏銳，發現不為人知的機會，並有效的轉化為產品上的解決方案，我們習慣成為市場型的產品經理，這一類產品經理是可遇不可求的，遇到了就是幸運。其實我們大多數都是從項目中去提煉普遍性的需求，最後轉化為產品。
圖4：需求轉化路徑
項目是需求的來源，它能不斷豐富我們產品能力，前提是我們需要建立一個這樣的體系，培養這樣的意識去積極的挖掘項目中的產品需求。
很多公司的研發團隊分為項目團隊、產品團隊還有比較純粹的技術支撐團隊，所以設計一個合理的協作流程並有效執行，有效的實現需求的轉化，這是研發體系要重點去建設的。（當然需求的轉化也要考慮到我們的業務方向和定位，過度的需求轉化會讓我們戰線拉的太長，導致資源分散。）
動力：優秀的平臺架構
根據圖4的需求轉化模型，產品的豐滿不僅需要項目需求源源不斷的滋養，它也依賴底層平臺的支撐。
不論技術平臺還是產品平臺，平臺的主要作用是：
- 需求的通用性的高度抽象，使其更標準化，便於複用，提升效率；
- 底層架構的設計、技術實現的封裝，實現功能的可擴展性，支持更多場景。
平臺的核心是低耦合，高內聚，一個大點的團隊，可能存在不止一個平臺，比如：互聯網業務和企業應用之間存在著較大的差異，可能構建不同的平臺來支撐不同的業務。比如：我在負責掌上醫訊業務時，它本身是面向C端的互聯網應用，我們構建了代號為camel的平臺用來支撐和該業務相關的產品和項目，在公司內部的其他團隊可能也存在著其他的各種各樣的平臺。
中臺近幾年特別火，阿里的中臺架構開始被眾多公司去學習模仿，但是如果我們不能理解中臺的內涵，我們就會陷入更多的疑惑中，它和平臺有什麼區別？它到底承擔什麼作用？
中臺不是憑空而來，也不是平臺化架構換個名字。中臺化架構是平臺化架構的自然演進。平臺化目標是高內聚、低耦合；職責邊界清晰；易於集成等。那麼中臺化架構進一步可總結為：高內聚、低耦合；數據完整性原則；業務可運營原則。
簡單的說，平臺關注的更多是技術屬性架構設計，所以平臺的功能設計我們一般講究業務無關性的設計原則，而中臺在平臺的基礎上更關注的是業務屬性的架構設計，它把業務的最佳實踐進行更標準化、更具有擴展能力的設計。
所以中臺不是多個平臺的集合，否則中臺就毫無意義，而是它應該具備以下幾個特點：
- 公共業務組件的抽象設計，業務功能上實現更好的複用，減少重複建設，提高效率，降低成本；
- 過去叫集成平臺，現在叫共享中臺，一種是被動的事後工作，一種是主動的事前規劃，都是為打破孤島而生；
- 因為是主動共享，中臺一個很大的作用就是它能快速孵化新產品，加快創新業務的發展進程，我認為這才是中臺架構最有價值的地方。
圖5：醫療服務中臺架構
並不是所有的企業都適合做中臺，像圖3提到的那四種業務模式，前兩種有平臺就足夠了，後兩種就比較適合去構建中臺，特別是平臺化、生態化的企業。為了更直觀的展現中臺的架構。
我簡單設計了一個醫療服務行業的中臺架構（藍色部分為中颱部分），圖好畫，事難做。如果阿里的中臺沒有成為集團戰略強力的自上而下推動，也很難成功。因為中颱架構首先要調整組織架構以適應新的業務架構，而且過程中充滿了各種矛盾，沒有組織的強力推動，中臺是很難成功的。但中臺一旦成功，這就是產品研發最強有力的動力，為業務提供源源不斷的能量。
基礎：規範的研發管理
遠大的理想不可缺少，但基礎的能力更需要關注，否則就是好高騖遠，偉大願景則如空中樓閣，沒有根基！所有的管理都是管人、管事、管物、研發管理也是如此。研發管理更偏重工程管理，研發過程就像構建一座城市，更加系統化，更加立體化。
圖6：研發管理的範圍
相對於其他的管理側重管人不同，它首先更關注對物的管理。首先物作為工具意味著成本，分散式的研發團隊很容易犯的錯誤就是對技術棧的管理。就像我們團隊，存在三種主流服務端語言，現在要搞研發協同，資源根據項目情況進行調配平衡，技術體系都不一樣，我想幫你但我不會你的技術，我這裡閒的蛋疼也只能看著你忙的焦頭爛額。
像我們這樣規模的團隊，人力一直都不夠用，如果技術路線不控制，意味著研發成本根本沒法控制，協同性太差也就意味著存在更多的浪費，效率是低下的。所以第一步就是要根據多數人使用的技術確定統一的技術路線，其他技術的團隊和人員要逐步開始向這個技術路線來靠攏，大力推行微服務架構，支持異構系統之間的集成共享。
同時建立新技術的引進制度，我們鼓勵創新，但一旦引入生產環境，我們需要進行技術評審，因為每引進一項新技術也就意味著為團隊增加一項成本，我們必須評估它帶來的價值。
其次，有些物是我們過程的成果，比如代碼，文檔，方案，這是我們的寶貴資產，過去它分散在各處，既不安全，而且不能形成知識，這就非常的可惜，所以這些都是我們做研發管理最基礎的事情，沒有這些基礎，團隊就無從建設，事情就混亂不堪。
協同是我們提倡的，但是它是一種精神，一種態度，我們不能過度的依賴它。我們所依賴的是大家的職責是清晰的，因為屁股決定腦袋！過去我們完全產品線的團隊劃分，考核的指標是產品的指標，現在我們需要共享研發。
誰去做共享的這部分？大家都在做廣度，誰又該去做深度？
完全依靠協同是不行的，必須職責清晰。研發體系是立體結構，是T字型結構，如圖4和圖5所示，我們既要兼顧事業（如產品線）的維度，又要形成前臺-中臺-後臺的分層梯隊，按照不同的能力進行組織的調整。所以大部分的改革首先要伴隨著人員的調整，因為屁股決定腦袋，屁股不動思想就不會動！
前幾天在《領導力培訓》上老師講的，管理只要搞定了人，也就沒有難辦的事。
我很認同，畢竟事在人為嘛！對事情的管理最基本的建立基本的做事流程，建立各種評審機制，這些相對都不難，難的是在沒有形成研發文化或者low一點說是研發習慣之前，執行必須靠盯。我們做cmmi，做項目管理培訓那些理論不知道學了多少遍，但回頭想想，那些規範、流程基本都躺在文檔庫裡睡大覺了。
因地制宜，找到適合自己團隊的方法，哪怕是很簡單，關鍵是貴在堅持，在實踐中不斷的完善它，直至形成習慣和文化。
囉嗦了這麼多，其實很多思路也沒有表達出來，也有很多東西沒有想清楚，研發體系的建設是一個長期的工程，並非一日之功，我們只要保持足夠的重視，不斷的實踐，就一定能做好。
有人說研發部門是成本中心，其實我更願意稱它為效率中心、創新中心，因為它不僅僅是服務業務，更多時候是助力業務發展，是企業發展的核心動力。
故研發無小事，事事要重視。短期看效益，長期看體系！
附研發體系腦圖供交流討論：
圖7：研發體系建設思路腦圖
#專欄作家#
菜根亂譚，微信公眾號：CGLT_TAN，人人都是產品經理專欄作家。經歷程序員、技術負責人、產品經理等多種崗位，現在負責百洋智能科技的研發管理。關注醫療，早教領域，擅長技術應用型產品的設計和運營。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
