如何快速响应市场的变化，如何推出更有竞争力的产品，如何在竞争中脱颖而出，是国内研发企业普遍面临的核心问题，为了解决这些问题，越来越多的企业开始重视创新与研发管理，加强研发过程的规范化，集成产品开发（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来运作，从产品立项开始到量产发布结束，涵盖概念、计划、开发、验证、发布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）