如何快速響應市場的變化，如何推出更有競爭力的產品，如何在競爭中脫穎而出，是國內研發企業普遍面臨的核心問題，爲了解決這些問題，越來越多的企業開始重視創新與研發管理，加強研發過程的規範化，集成產品開發（IPD）、集成能力成熟度模型（CMMI）、敏捷開發（Scrum）是當前企業產品研發管理的最熱門的3個體系，但是很多朋友並不真正瞭解這3套管理體系的適用範圍和內涵，本文描述了它們之間的區別以及如何在企業研發管理過程中合理加以應用才能達到最優化的結果，使企業在市場競爭中保持不敗之地並能脫穎而出。
上篇請參考：如何理解IPD+CMMI+Scrum一體化研發管理解決方案之IPD篇
http://blog.sina.com.cn/s/blog_81427a800102wqm5.html
中篇請參考：如何理解IPD+CMMI+Scrum一體化研發管理解決方案之CMMI篇
http://blog.sina.com.cn/s/blog_81427a800102wqm6.html
下篇請參考：如何理解IPD+CMMI+Scrum一體化研發管理解決方案之Scrum篇
http://blog.sina.com.cn/s/blog_81427a800102wqk7.html
CMMI的歷史、核心內容、實施難點和侷限性、實施建議
CMM/CMMI的歷史
信息時代，軟件質量的重要性越來越爲人們所認識。軟件管理工程引起廣泛注意源於20世紀70年代中期。當時美國國防部立題專門研究軟件項目做不好的原因，發現70%的項目是因爲管理不善而引起，而並不是因爲技術實力不夠，進而得出一個結論：管理是影響軟件研發項目全局的因素。1987年，美國卡內基.梅隆大學軟件研究所（SEI）受美國國防部的委託，率先在軟件行業提出了軟件過程成熟度模型（CMM），隨後在全世界推廣實施，用於評價軟件承包能力並幫助其改善軟件質量的方法。
CMM發佈後，不但在單純軟件行業得到很好的實踐，同時在系統工程領域、硬件領域、集成產品開發領域也有很大的借鑑價值，當年華爲印度所推行CMM後，將軟件CMM的方法嫁接到硬件項目開發管理中，形成了HW-CMM就是一個很好的例證。爲此SEI推出CMM的升級版本CMMI，從而支撐更多領域的開發管理規範化。
CMMI的核心思想
CMMI，全稱爲“過程能力成熟度模型集成”，核心目的是用於衡量和改善組織過程能力的，雖然強調“人+技術+流程”三個方面共同決定開發項目的成敗，而實際CMMI實施更多還是關注流程，強調過程規範性，最終達到保證開發交付質量的目的，CMMI的核心思想爲如下2個方面：
1、過程質量決定交付質量。CMMI將開發活動劃分爲22個過程域（PA），每一個過程域是關注研發項目中某個方面（PA），並且在CMMI標準中也定義和相應的工具方法，例如需求跟蹤矩陣（RTM），強調組織只要嚴格按照規範化的過程去開發，開發最終交付的質量應該是可以保證的。
2、組織能力需要持續改進。CMMI將組織的研發能力劃分爲5個等級，每個等級有詳細的標準，建議組織根據自身能力、實際商業需要、組織資源多少靈活決定組織優化改進的目標。這一點本人深有感受，完全沒有必要看別人已經過CMMI L5了，自己就着急，也要搞什麼4級、5級，作爲系統產品（涵蓋軟件、硬件、結構）的產品化公司，達到CMMI L3就完全夠用了。如果招標書中嚴格要求承包商必須要達到什麼CMMI的4級、5級水平，純屬誤人子弟。
CMMI的4類管理領域
CMMI將開發活動劃分爲22個過程域（PA），同時這22個PA分別隸屬4大管理領域，分別爲：項目管理、流程管理、工程管理、支撐管理，而與產品開發組密切相關的主要是項目管理、工程管理、支撐管理三個領域：
項目管理：本質沒有脫離PMI標準的項目管理體系，例如項目策劃、項目跟蹤與控制、風險管理、供應協議管理這些內容在PMBOOK中都有詳細的定義，所以可以理解爲CMMI的項目管理是MiniPM，更加開發化的PM。
流程管理：流程管理描述的也是非常通用化的流程優化與改進的方法，識別組織流程改進點，然後召集團隊進行未來業務流程設計，全面推行前先試點，試點後修正，確保沒有大的風險後，再全面推行，所以CMMI的流程管理沒有脫離業界流程改進、流程優化的範疇，說實話沒有什麼神祕的，這些方法早在上個世紀80年代，在製造行業都已經普及了。
工程管理：不同行業的工程技術方法存在比較大差異，雖然都叫軟件編程，C語言與Java就有很大的差別，都叫可靠性設計，汽車行業與手機行業的差異也是顯而易見的，所以CMMI針對工程管理只是定義最通用的方法，例如需求收集的方法就給推薦了一堆，什麼訪談法、頭腦風暴法、市場調研法、原型測試法、業務分析、Usecase法、逆向工程法、客戶滿意度調查法等，基本涵蓋了人類可以想到的所有方法，而每種方法該如何做呢？哪個方法適合呢？CMMI沒有告訴你，自己去修煉吧！所以針對工程管理，本人感覺CMMI定義的比較粗淺，只告訴做什麼，但怎麼做，幾乎沒有說明。
支撐管理：個人認爲支撐管理領域是CMMI 4個領域中定義最具有可操作性、最完備的部分，由此可以推測，估計當時CMMI定義小組，大部分成員是質量管理人員，尤其配置管理、度量和分析、質量保證定義的非常不錯，能給實施CMMI的公司以非常具體的指導。
CMMI的侷限性
從CMM/CMMI的出生就決定了CMMI作爲研發管理體系的侷限性，美國國防部爲確保外部開發機構交付產品的質量，而資助SEI形成CMMI開發管理體系，所以CMMI的核心侷限有2點：
1）本身不談如何賺錢的問題。作爲美國國防部的外包方往往有充足的人員、資金、時間來從事產品研發；同時只要確保質量、按時交付，至於交付後產品怎麼賣、怎麼盈利不用關心，所以CMMI通篇規範幾乎沒有涉及競爭分析、財務分析、市場分析、上市推廣；同時對產品的量產交付能力、量產採購供應風險也基本沒有考慮，如果是產品化公司，單純靠CMMI就很難確保市場成功，往往會進入爲了流程而流程、爲了量化而量化、爲了質量而質量，這樣的境地是非常危險的。
2） 更多關注的是開發活動，沒有將產品開發上升爲涉及多個業務領域的系統工程。作爲一個成功的產品往往涉及策劃、實現、運營；及時在實現階段也需要涉及市場調研、競爭分析、可製造性、可服務性、製造策略定義、服務策略定義，同時研發時，要充分考慮批量交付的可行性；CMMI針對研發項目團隊的定義也更多侷限在技術層次，如何讓市場部門、採購部門、製造部門等相關領域的人員有效參與到產品開發並承擔責任，CMMI沒有明確的解決辦法，沒有設計一個貫穿整個產品生命週期的團隊和角色存在，也沒有橫向交叉管理機構，而整個產品開發被分成一節一節的“封閉車廂”，這樣往往導致局部最優，整體不優的結果。
CMMI的實施難點
首先：CMMI對象是一幫喜歡個性化，不願被約束的人；CMMI主要是開發管理，同時需要開發人員配合收集提交相應的信息；開發人員普遍存在獨立、內向、不善溝通、個人意識強，同時開發工作又難以量化等問題，CMMI實施往往被技術人員所抵制，很多公司最終就變成爲應付交差，爲了認證，造假一套資料，拿到證書後，原來怎麼幹，還繼續怎麼幹，CMMI變成形式。
其次，CMMI體系本身很散，需要豐富工程管理經驗團隊才能更好地把握實施內容。CMMI本身爲了結構化，將研發相關活動劃分爲22個過程域，這樣做的好處是便於專項學習，針對性改進。本人接觸過國內一些企業CMMI實施的內容，就是按照CMMI的22個過程域分別對應定義22個管理規定，這是一幫絕對傻顧問、傻團隊的自作聰明的作法，這樣做認證評估很簡單，一個對一個即可，但直接結果是項目管理團隊不知道如何使用，作爲項目管理團隊，一般不管什麼CMMI、IPD、ISO、什麼過程域，他們就關心，該如何管理項目，如何按照項目主線來開展工作，而不是搞一堆過程文件，一看就煩。基於本人歷史實施CMMI的經驗，建議一定要首先定義項目運作主流程（階段如何劃分、涉及哪些角色、設置相應控制點、明確每個角色活動和職責），CMMI的22個過程都是爲了支撐項目主流程的具體方法。
CMMI的常見誤區
1）CMMI比較適合外包公司、軟件企業，我們是做自主產品的，CMMI不適合我們。CMMI其實是規範化產品開發管理的標準方法，雖然起源在軟件行業，但CMMI的規範、方法同樣適用硬件、結構等領域的開發；實踐證明CMMI非常適合產品開發中具體某個模塊的開發管理，整個系統級產品的研發過程需要借鑑IPD的思路，但具體細節模塊的開發就需要借鑑CMMI的方法，因爲CMMI管理的更加精細和具體。
2）CMMI很繁瑣，需要提交大量的文檔、填很多的表、收集海量的數據。CMMI本身是劃分爲5個等級，組織完全可以根據自身實際需要靈活決定朝哪個等級努力，CMMI本身沒有明確要求需要提供哪些表格、需要寫哪些文檔、需要收集哪些量化數據，只是強調要知識沉澱、文檔記錄，至於實際需要寫哪些文檔，完全可以根據公司實際業務需要靈活定義，同時CMMI還強調裁減，可以基於公司流程，結合項目實際情況，靈活定義本項目的運作流程。關於數據收集，實踐證明完全可以藉助信息化手段快速、方便收集工作量、需求、進度、變更、文檔等相關量化數據。
CMMI的實施建議
以項目爲主線條實施CMMI相應過程域。CMMI目的是支撐研發項目的規範運作，22個過程域彼此獨立，同時又密切關聯；本人2000年就在華爲印度所參與CMM的實施，後續幫助10多家企業實施CMMI體系，總結下來發現，一定要以項目爲主線實施CMMI，通過項目主線將CMMI的各個過程域穿插在項目具體活動中，這樣實施的直接好處是項目管理團隊拿到CMMI體系後就知道如何操作了，也更清晰地展現CMMI對項目實際運作的指導價值，不能站在評估認證角度實施CMMI，一定要站在實際研發業務運作角度實施CMMI，這樣的CMMI體系纔會有生命力，纔有廣泛的羣衆基礎。
IPD與CMMI的差異
IPD與CMMI起源和出發點的不同，決定了兩者具有很大的區別。
1） 管理層面不一樣
IPD是企業層面的一套產品開發管理的思想、模式和方法，本質上是一種產品經營管理的模式。CMMI是面向研發的，而且更多是面向軟件、硬件、結構模塊級開發的。
2） 思想高度不一樣
兩者目的的不同也導致了思想的不同。IPD是從投資、競爭、經營層次看待產品開發；CMMI主要倡導通過過程和活動來保證質量，更多是從過程、操作、實現方法層次出發。
3）管理的範圍不一樣
IPD對所有的產品開發活動進行管理，橫向上涉及市場、設計、測試、試製、製造、採購、服務、銷售、財務各功能部門在產品開發中的活動，縱向上涉及決策、管理、執行三個層面。而CMMI主要是面向研發部門的活動，如軟件開發、系統集成、項目管理等。對於軟硬件相結合的高科技產品而言，軟件開發的工作量往往佔整個開發工作量的50－60％，而硬件開發又可能佔到15－20％，所以CMM可以管到50－60％的開發活動，而CMMI可以管到65－80％的開發活動。
4） 關注重點不一樣
IPD不僅關注把事情做正確（do the things right），同時更關注做正確的事情（do the right things），所以IPD既強調執行的重要，也強調決策的重要。CMMI主要關注執行，即把事情做正確（do the things right），而且CMMI對如何執行好開發活動要求更規範、更細。
IPD與CMMI的融合一體化
作爲研發高科技企業，不但要做正確的事情，同時還需要確保把事情做正確；IPD能有效幫助企業確保產品研發方向的正確性，強調市場驅動、投資回報，將市場、財務、競爭、技術有效融合爲一體；CMMI強調規範化、精細化管理，落實爲具體的計劃、流程、制度、模板、控制方法，能幫助企業把事情做正確；所以企業需要構建IPD+CMMI融合一體化的研發管理體系。
IPD管得“寬”（從市場管理到產品開發，再到產品生命週期管理）、定位高（公司級的決策與開發組織與架構、公司級產品開發流程等）；而CMMI把流程分解爲一個個關鍵過程域（KPA），相對離散地來定義流程的，在細節上力求更精更深。儘管IPD與CMMI有衆多的不同，但就對具體流程和活動進行管理而言，兩者所依據的原則、方法和實踐是相通和一致的，所以我們可以形象地將IPD看作產品研發管理流程“十”字的“橫”，將CMMI模型看作“十”字的“豎”，“IPD+CMMI”將是企業產品開發管理體系完美的“十”字組合，從而優化產品開發體系，規範產品開發流程。
案例分享：華爲技術IPD+CMMI一體化研發管理體系
華爲IPD-CMMI管理體系整體產品開發過程按照IPD來運作，從產品立項開始到量產發佈結束，涵蓋概念、計劃、開發、驗證、發佈5個階段，4個商業決策評審點，7個產品級技術評審點；TR2（技術評審2，總體方案+設計需求評審）後，產品劃分爲多個子系統、模塊，每個子系統、模塊進入相對獨立的設計、實現、驗證環節，這些工作就嚴格按照CMMI的規範要求進行；TR4（技術評審4，開發完成評審）後，CMMI過程結束，子系統、模塊集成爲整機，按照IPD的流程規範來執行；華爲的產品開發過程可以概括爲IPD-CMMI-IPD的過程。
後記
IPD確保方向的正確性，CMMI強調規範化、精細化管理，確保把事情做正確；在這個“快魚吃慢魚”的時代，如何加快開發與驗證的速度？這就需要開發工作和測試工作能夠並行展開，從而實現及時發現問題、及時修復、及時交付，實現降低質量成本，縮短開發週期，提升競爭優勢的目的，這就需要藉助敏捷開發的方法。
------完------
（作者： 董奎 （Tiger.dong），青銅器RDM產品經理、華成研發諮詢聯合創始人、青銅器軟件聯合創始人，1998~2004年就職華爲技術，參與電信交換機、數據路由器等核心電信設備的設計與開發，IPD+CMMI+Scrum一體化研發管理體系的踐行者，目前該體系已經被華爲技術、科大訊飛、美的集團、長城汽車、中聯重工、宇通客車、長城汽車、京信通信、聯芯科技、華虹芯片、四維圖新等500多家企業，110多家行業第一名公司所採用。
新浪微博： @董奎Tiger http://weibo.com/dongkui168）