最近一段時間，我一直在反復思考一個問題：我們的軟件研發管理體系應該是怎樣的？在不斷思考的過程中，逐步有一些粗淺的認識，在此將這些認識記錄成文字，并期待能夠與更多的伙伴碰撞，進一步完善這種認識，并逐步上升到理論高度，從而有利于指導具體實踐。

1. 對軟件研發管理體系的一些概念認知
1.1. 研發管理是什么
關于研發管理，百度百科中這樣定義：研發管理就是在研發體系結構設計和各種管理理論基礎之上，借助信息平臺對研發過程中進行的團隊建設、流程設計、績效管理、風險管理、成本管理、項目管理和知識管理等的一系列協調活動。

也就是說，研發管理首要一點就是要根據公司業務的發展確定相應的研發體系結構，之后按照這種研發體系結構組件一支高水平的研發團隊，設計高效合理的研發流程，借助合適的研發信息平臺支持研發團隊高效工作，以績效管理調動研發團隊的積極性，以風險管理控制研發風險，以成本管理使研發在成本預算范圍內完成研發工作，以項目管理確保研發項目的順利進行，而知識管理使得研發團隊的智慧聯網和知識沉淀。

縱觀各類軟件企業，由于自身所處環境不同，因此其軟件研發管理模式也不盡相同，這其中有基于CMMI能力成熟度模型指導下構建的研發管理體系，也有基于IPD集成產品研發框架指導下構建的研發管理體系，當然也有一些目前不少小企業、互聯網企業推崇的敏捷研發管理體系。不同的研發管理體系其實都會有相應的交叉部分，最終追求的目標都是能否適合企業的發展，給企業帶來市場和財務上的成功。

1.2. 基于CMMI的研發管理
CMMI能力成熟度模型相信大家都不陌生，從一級到五級，覆蓋了22個過程域，一般能達到CMMI3級別的基本上可以理解為各類流程、過程規則等已經達到一個較好的水平。當然，這里主要是指企業能夠確實按照CMMI模型去實踐，這種實踐其實更適合于以瀑布式開發為主導的項目開發及產品研發模式。然則，實際上，大部分企業尤其是國內企業并不會嚴格按照這個模型去做，因為如果每一個過程域都不打折扣地執行地話，需要非常標準化的流程和強大的資源支撐，在這個講究快速響應變化的時代其實是很難做到的，通常這個時候都會進行相應的裁剪，甚至會結合敏捷迭代等方面的模式，從而逐步形成自己公司的研發管理體系。

1.3. 基于敏捷模式的研發管理
在這個快魚吃慢魚的互聯網時代，對用戶和環境越來越要求要快速響應。敏捷研發是當前不少互聯網企業、中小企業推行的研發管理體系，主要理念就是敏捷迭代、小步快跑，快速改進、擁抱變化，用戶參與等等。目前這方面也有不少公司除了有相應的敏捷研發體系之外，還有相應的成熟工具做支撐。例如，騰訊的TAPD敏捷研發平臺就是其中的代表。通過對用戶故事的層級拆分，實現對需求的有效管控和分解，從而確保持續迭代上線。

敏捷研發管理在當前我們以業務為導向、項目為主的情況下，要全面實施尚有較大困難，當然并非是完全不能做，主要是當前所處的環境、所面向的業務、項目開發模式、人員結構等可能較難滿足敏捷模式推行的需要。

1.4. 基于IPD的研發管理
之前有簡單了解過IPD產品研發管理體系，我認為其中的核心就是“四四四”模型，四四四代表了四大團隊、四個流程、四個支撐體系。

四大團隊建設包括建立集成產品管理團隊（IPMT）、建立產品市場團隊（PMT）、建立產品開發團隊（PDT）、建立技術開發團隊（TDT）。

四大流程建設包括建立產品戰略流程、建立需求管理流程、建立產品開發流程、建立技術開發及平臺開發流程。

四個支撐體系建設包括建立項目管理體系、建立質量管理體系、建立績效管理體系、建立成本管理體系。

個人感覺，基于IPD的產品研發管理從整體上來看是一個相對重量級的體系，要落地執行往往需要從整個公司層面去整體考慮和推動。

IPD的理念和敏捷開發理念在本質上是基本一致的，比如以市場需求（用戶價值）為核心，將產品開發看成一項投資（商業價值），通過CBB—公共基礎模塊和跨部門的團隊準確、快速、低成本、高質量地推出產品（各評審點的多團隊參與和決策、通過各種技術改進提升產品開發效率和降低浪費、持續交付）。

從理論上來講，IPD研發管理體系是一個較全面的體系，在當前我們的現狀下也可能容易出現水土不服的情形，當然其中有一些好的做法是值得借鑒的。

2. 什么樣的軟件研發管理體系適合我們的發展
從項目及產品的研發角度來看，發展到一定階段的傳統IT企業在研發管理上多數都是基于瀑布型的傳統研發模式，由于項目的特點及人員的組織結構等因素，項目開發及產品研發的周期往往較長，較難適應市場快速變化的需要，也較難做到對客戶的需求進行快速響應。而大部分的互聯網公司及一些大廠，推行了敏捷研發模式，或者是在標準化項目管理和敏捷迭代兩者融合上進行了相應的實踐。

那么，針對當前我們所面臨的一系列問題，究竟什么樣的軟件研發管理體系在未來一定時期內適合我們的發展？我們需要重構我們的軟件研發管理體系嗎？我們有必要重構我們的軟件研發管理體系嗎？帶著這些問題，我想主要思考幾個方面的問題。

2.1. 能否快速適應未來業務的發展變化
技術是為業務發展而服務的，因此在考慮軟件研發管理體系構建時，第一個要考慮的問題就是我們的軟件研發管理體系能否快速適應公司未來業務的發展變化。特別是在傳統IT業務與互聯網新興業務加速融合的大環境下，信息化能力是越來越多客戶的第一選擇，因此在業務的快速發展方面需要更加強有力的技術支撐，而這個支撐的背后就是需要我們能夠有一套能夠快速響應變化、敏捷高效的研發體系，特別是能夠有一定的前瞻性并支撐到老業務的快速轉型和新業務的拓展。

2.2. 在業務出現較大波動時能否彈性伸縮
另外一個問題就是，業務在發展過程中，受大環境等諸多因素的影響，定然很難一直都是呈現直線上升的發展趨勢，這當中必然會有波峰波谷，只不過這個波峰波谷是大是小的問題。而我們面臨的問題則是，當出現較大的波峰波谷的時候，我們的研發管理體系應該如何適應？特別是在軟件業務處于相對低谷時，既能夠繼續保持對技術研發的持續投入，又能夠在應用開發等方面有一定的可伸縮性，從而正確地處理好軟件生產效益問題。這里面可能會涉及到中高層次軟件人才的相對穩定和低層次軟件人才的靈活流動等問題。特別是在我們業務多樣化的背景下，不同業務單元的發展會有不同的發展路徑，對軟件研發能力的訴求也有所不同，那么這里面首先涉及到的一點就是如何有效平衡基礎研發能力和行業研發能力。

對于基礎研發能力，個人認為應該是一個軟件公司最內在的核心技術能力，往往很多時候基礎研發工作很難像做行業應用開發那樣立竿見影，但這項工作干得不好往往又容易成為行業研發能力的掣肘，這也是我們當前在人工智能、區塊鏈等新技術潮流背景下總感覺難以發力的原因之一。

對于行業研發能力，個人認為應該要從兩個方面去考慮，一個是產品化的能力，其二才是應用開發能力。應用開發能力很好理解，就是目前我們這么多年以來一直在做的各種類型的項目開發，而這里面大部分的項目開發其實都是偏應用層面的開發。而產品化的能力則是最近一兩年以來我們重新關注的一個內容，不過這條路上我們尚開始起步，還有很長的路要走，也還有不少坑要踩。個人認為，產品化的能力能否真正發展起來，其中很重要的一點就是要考慮如何與基礎研發能力做充分融合。產品化不等同于應用開發，應用開發更多是定制化的開發，是客戶導向的軟件開發，通常面向的是一個或少數幾個的客戶；而產品化則是要綜合行業、市場、客戶群體、新技術等多方面因素的研發，是市場導向的軟件開發，面向的是一個或多個的客戶群體，甚至面向的是一個市場或跨界市場。

2.3. 新技術研發及成果轉化能否跟上業務變化
最近幾年，新技術層出不窮，在軟件架構的發展方面也非常迅猛，歷經了單體架構、垂直架構、SOA架構、微服務架構的演化。從我們公司目前的技術研發實際來看，我們有少量的項目/系統采用了SOA架構，然則大部分的項目/系統仍然采用的是單體架構和垂直架構。單從這一點來看，我們在技術領域的持續跟進及成果轉化方面已然有落后趨勢，這方面需要我們奮起直追才行。當然，出現如今這種局面固然由眾多因素催生而成。比如，已有開發框架前端兼容性的問題最近一兩年以來常常被詬病，誠然有它內在的好處，然則最近一兩年以來，用戶對系統的用戶體驗要求更高了，不再是單純地滿足于功能實現層面，而是開始追求良好的人機交互和界面展現。因此，這方面勢必對新技術的要求更加迫切。最近幾年，當不少團隊都在往前后端分離走的時候，我們至今的絕大部分軟件項目開發仍然停留在前后端分離之前，對不少用戶界面展現要求高的軟件項目而言，難以快速有效響應變化，同時對一些相對比較成熟的軟件產品而言也難以做到接口自動化。

因此，能否在新技術的研發上抓住正確的方向并加快研發成果轉化，為業務的快速變化提供強有力的技術支撐，是一個擺在我們面前急需解決的課題。從當今新技術的發展趨勢來看，研發架構方面，我們雖說不能完全拋棄傳統的單體/垂直架構，但我們必須要往微服務架構方向邁進，除了與最新技術接軌之外，更重要的是如何進行業務解耦，沉淀行業積累，并反向推動人員組織層次的變革，提升軟件生產效率，提高軟件質量。

除此之外，對于人工智能、區塊鏈等新領域，也是需要綜合業務應用場景打造適合我們自身發展的技術+業務融合之路。

2.4. 在標準化和敏捷迭代之間如何平衡
標準化的軟件研發道路固然有不少好處，有嚴謹的流程、規范的體系、固定的套路，當然更多的則是瀑布開發模式，雖然最近幾年也陸續有迭代開發的模式，但更多的是被動式響應，而且這種迭代開發模式基本上是大階段的劃分，在每一個大階段里面依舊是一個典型的瀑布開發模式，即歷經需求分析、交互原型設計、UI設計、Web前端開發、程序開發、系統測試、部署實施等步驟，橫跨周期往往較長，一旦發生需求變更，變動的代價過高。

敏捷開發強調以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。

那么，問題來了，既然標準化項目管理模式下存在太多流水線作業及效率低下等問題，那么我們能夠直接轉向敏捷迭代模式呢？世界上萬事萬物都是對立統一的，個人認為不論是標準化項目管理模式還是敏捷迭代項目管理模式都有其擅長的一面。一方面，在現有的以項目為主導的軟件開發體系中，標準化模式是我們一直以來的主要做法，也積累了不少經驗做法；另一方面，采用敏捷迭代模式對于產品復雜不斷有新需求加入等場景是比較適合的。所以這里面更多的是考慮如何更好地平衡標準化項目管理和敏捷迭代兩者之間的關系。基本的思路就是結合標準化項目管理和敏捷迭代的優缺點進行適度裁剪，既能提高軟件質量和軟件開發效率，也能夠保留一定的規范性和軟件過程文檔。例如，針對項目管理，通常是五個過程組：啟動、規劃、執行、監控、收尾，那么我們其實可以結合實際將規劃提前，將監控貫穿于執行過程，這樣就勢必要求在啟動時也要做好項目計劃相關工作，在執行過程中抓住關注點并定期監控其執行情況，在收尾階段做好項目回顧總結。

不論采用何種模式，我們的根本目標就是達到更低的成本實現更快速、更可靠的交付。近年來比較火熱的是DevOps。DevOps（Development和Operations的組合詞）是一組過程、方法與系統的統稱，用于促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。它是一種重視“軟件開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發布軟件能夠更加地快捷、頻繁和可靠。

因此，我們的軟件研發管理體系中是否應該引入DevOps，進而改善公司組織文化、提高員工的參與感、提高交付效率，我想這也是需要重點關注和考慮的。

2.5. 組織過程資產能否持續積累并盤活
組織過程資產指一個學習型組織在項目操作過程中所積累的無形資產。組織過程資產的累積程度是衡量一個項目組織管理體系成熟度的重要指標，項目組織在實踐中形成自己獨特的過程資產，構成組織的核心競爭力。

組織過程資產主要包括但不限于以下內容：項目組織在項目管理過程中指定的各種規章制度、指導方針、規范標準、操作程序、工作流程、行為準則和工具方法等。項目組織在項目操作過程中所獲得的經驗和教訓，其中既包括已經形成文字的檔案，也包括留在團隊成員腦子中沒有形成文字的思想。項目組織在項目管理過程中形成的所有文檔，包括知識資料庫、文檔模板、標準化的表格、風險清單等。 項目組織在以往的項目操作過程中留下的歷史信息。

經過多年的軟件開發，我們做了大大小小形形色色的軟件項目和產品，也逐漸積累了一些行業化的軟件項目，但總的來看，能夠形成規模化效應的軟件產品尚較為匱乏，更多的是以定制化開發為主的軟件系統，當然也積累了不少項目經驗。在這過程中，也積累了不少標準、規范、流程、模板等各類軟件過程資源。然而，從目前掌握的情況來看，這些資源是分散的，不夠體系化的，還談不上真正意義上的資產，至少在價值的發揮上還不充分。況且，軟件行業這幾年的人才流動率明顯加快，人員更替的速度以及未能體系化的過程資產積累，加劇了組織過程資產的盤活難度。

那么，構建一個相對健全的、動態的、能夠適應未來業務發展的組織過程資產庫就顯得尤為重要。這既是軟件研發管理體系的一個重要組成部分，也是公司層面應該給予充分重視的。在組織過程資產庫構建的過程中，其中很重要的一點就是如何讓研發知識與經驗成為公司的寶貴財產，這里就要充分考慮研發知識管理。知識管理把“隱形知識顯性化”，是一項涉及知識庫、過程資產、環境和交流等元素的整合過程，所管理的知識將作為一個團組織中過程資產的重要組成部分。對于軟件研發而言，我們需要考慮怎么把業務人員和技術人員腦中的藍圖轉化為顯性知識。

3. 構建我們的軟件研發管理體系應包含哪些內容
軟件研發管理體系的建設離不開幾個關鍵要素：人員、技術、過程、資源，并在此基礎上配以相應的管理手段。進一步來看，要構建適合我們自身發展的軟件研發管理體系，需要著重考慮幾個能力體系的建設，即：人員組織能力、技術研發能力、過程管理能力和資源建設能力。

前面也有針對“什么樣的軟件研發管理體系適合我們的發展”進行了一些相對粗淺的探討，那么在考慮如何構建適合我們發展的軟件研發管理體系之前，我想這里首先要明確一下我們期待構建的軟件研發管理體系。我們公司的業務涉及眾多行業客戶，一直以來主要以定制化項目開發為主，同時也涉及運維服務，而在產品研發等方面則處于起步階段，且在一段時期內項目、產品、服務將會長期并存，因此，個人認為適合我們的軟件研發管理體系應該至少經歷三個階段，包括初期的標準化軟件研發管理體系、中期的標準化與敏捷相結合的軟件研發管理體系和后期的敏捷化軟件研發管理體系。

基于上述這樣的考慮，正常來講我們當前應該在標準化的軟件研發管理體系中要做進一步強化，而考慮到市場的快速變化、技術的日益進步，個人認為我們當前就需要開始考慮標準化的與敏捷相結合的軟件研發管理體系。為什么還需要考慮標準化的軟件研發管理體系呢？主要是傳統的定制化的軟件項目開發依舊占據主體，且目前在這方面仍然有非常大的改進提升空間，然而標準化的模式常常是過于強調標準、規范、流程，開發模式過于線性化，因此需要引入敏捷開發模式。所以，我們又需要考慮敏捷的軟件研發管理體系，這主要是為了更好地適應市場變化、更快速地響應客戶需求，更好地提升軟件開發生產效率。

3.1. 人員組織能力
關于人員組織能力，個人認為有兩個關注點：一是團隊的發展，二是個體的發展。這兩者是相輔相成、互相融合促進的。綜合來看，人員組織能力的建設主要包括設立與公司戰略、業務、技術發展相適應的組織架構，并配以構建相對完整可行的崗位體系和對應的人員考核體系，同時在團隊建設等方面持續改進與提升。

關于組織架構，當前的組織架構雖然解決了一些曾經的主要矛盾，但依然存在不少問題，突出的一點就是核心薄弱，即核心技術能力不強，仍舊需要投入大量的人力到各行業的應用開發中，當然這與我們一直以來承接定制化的軟件項目開發不無關系。這是當前乃至未來一定時期需要解決的。

同時，最近幾年來的組織架構主要是以職能型組織架構為主，產品線為主導的研發模式尚不成熟，針對項目及產品的團隊構建主要是以項目經理來驅動，在項目團隊的組成方面固然與互聯網的項目團隊截然不同。在團隊建設方面，需要進一步打通團隊之間的壁壘，強化團隊的整體協同作戰能力。

在崗位體系方面，特別是對人員的績效評價方面，需要在已有的崗位體系基礎上進一步考慮如何更好地執行落地，確保個人績效目標與團隊績效目標的一致性和順利達成。

3.2. 技術研發能力
結合我們的實際，我認為在技術研發能力方面要考慮四個方面：一是技術預研，二是技術開發，三是產品開發，四是定制開發。

關于技術預研，通俗來講就是：預研=預先+研究。這種預先研究通常來源于幾個方面，例如來自外部競爭對手的迫使、來自客戶或市場的需求、來自公司高層的決策等。為什么要做技術預研呢？這是掃清前行障礙的過程，這為后續展開總體設計、詳細設計指明了方向，也是持續積累公司技術能力、保持與新技術同步而不至于脫離軌道的方式之一。

關于技術開發，其實這里主要指與基礎平臺、公共組件、關鍵技術等方面的技術研發。另外一個方面來理解，技術開發是技術預研的延續，是在技術預研成果經論證的基礎上開展的一系列能促進公司發展、業務發展、技術發展而開展的技術研發工作。

軟件產品是指向用戶提供的計算機軟件、信息系統、套裝軟件或在提供計算機信息系統集成、應用服務等技術服務時提供的軟件，是通用的產品應用于某一行業領域而不是像軟件項目一樣為某一需求或者單位定制開發。

軟件項目主要為特定企業開發或者部署實施一套專用的系統，在進入項目開發之前需要與用戶進行具體的交流和討論，了解用戶心中對于軟件預期的樣子，后經過招投標，簽訂合同，實施交付。

關于產品開發，這方面我們尚處于起步階段，尚缺乏一套完整可行的產品研發流程及最佳實踐，需要摸著石頭過河，也需要長期堅持不懈地努力。

關于定制開發，當前主要是基于客戶需求的軟件項目定制開發，后續還會包括基于產品衍生出來的定制化開發。前面的這種方式是我們當前最熟悉的模式，主要面臨的困境是兩個：一是如何實現快速交付，二是如何實現成本可控，從而提升軟件項目的利潤。

做項目側重于在最短的時間內，按照客戶的需求開發出操作敏捷，用戶體驗良好的軟件。而做產品則側重于市場驅動，時間相對充足，但要開發出有競爭力，有自身特色，且受客戶歡迎的產品，要求功能響應速度快，操作簡單，界面美觀。

技術預研+技術開發是強化內核的內在需要，定制開發是現階段的生存根本，產品開發則是為未來發展鋪路。

3.3. 過程管理能力
過程管理能力主要包括項目管理、開發管理、質量管理和配置管理等幾個方面，需要一套完整合理的流程貫穿整個過程。

在項目管理方面，我們需要梳理當前項目管理體系的標準、規范、流程及相關實踐，建立以過程為核心、以度量為基礎、以人為本的可裁剪、受認可、能執行的信息集成項目管理體系，進一步規范公司的項目管理，提升項目群管理能力。結合項目管理的五大過程組（啟動、計劃、執行、監控、收尾），并結合敏捷迭代的思想，形成標準化項目管理與敏捷迭代相結合的具有實際指導意義的方法體系，同時將這套方法體系以指南性文件、規范性文件等形式傳導到相關人員，確保可落地執行。此外，為加強過程管控、資源共享、工作協同，組建PMO團隊，實現對項目群及重大項目的統一管控與決策支持。

在開發管理方面，一是要落實統一的軟件開發規范，包括架構規范、設計規范、UI規范、編碼規范、測試規范等。強化設計及開發關鍵環節的評審，包括對需求、概要設計、詳細設計、UI設計等的設計方面的評審，對測試用例等方面的評審，對代碼的評審檢查（例如利用SonarQube進行代碼的自動檢查等）及發布評審等。同時通過試點+逐步鋪開的方式著力推進CI/CD的落地。

在質量管理方面，進一步強化項目質量審計，逐步改進軟件過程生產效能。而在配置方面，則加強對配置項的識別、配置空間的管理、變更控制等，規范軟件開發過程，確保構建正確的系統。正確應用軟件配置管理是開發高質量軟件所不可缺少的。軟件配置管理的過程是軟件開發過程中質量管理的精髓。

綜合來講，在過程管理方面就是要形成一套適用的軟件研發管理流程，并配以相應的節點管控，讓不同開發角色之間即各司其職又相互融合促進，從而促進軟件開發自組織能力的逐步提升，充分調動軟件開發人員的主動性和積極性。

3.4. 資源建設能力
簡單來講，資源建設是軟件研發管理體系中的支撐體系。資源建設主要包括了一系列的制度規范、工具、模板、過程資料及交付物（例如項目文檔、源代碼等），以及相應的經驗、知識沉淀等。一是要適時梳理相應的制度、規程、標準、規范、文檔模板等，形成標準化資源庫；二是要對不同行業歷年來的項目資料及源代碼分門別類做好規劃和歸檔管理，形成靜態庫（歸檔庫）和活躍庫，同時做好數據安全管理；三是要對軟件研發人員及工作中的一些隱性知識轉化為顯性知識，并逐步構建軟件研發的知識圖譜，促進知識經驗的持續積累與轉化，并通過鏈條式、網狀式等方式實現知識分享與傳播，形成經驗知識庫。