CMMI-DEV与CMMI-SVC真的能够高度融合?

来源:岁月联盟 编辑:exp 时间:2014-01-12

  市场竞争日趋激烈,企业如何改进自身运维服务,加强行业竞争优势。这对企业及咨询公司提出了新的要求。在当前我国CMMI咨询公司基本上只能提供CMMI-DEV服务,而无法提供CMMI-SVC服务的大背景下,睿泰集团率先翻译CMMI-SVC中文版,并卓效开展在该领域的系统建设。已为国内多家企业提供了CMMI-DEV与CMMI-SVC模型融合咨询、培训服务,帮助企业打造产品研发核心竞争力、实现运维服务水平的持续提升。

  相信许多咨询公司都会存有这样的疑问:DEV与SVC同出SEI,且二者有共性PA 13个,是否能合二为一成为一套完整的过程改进体系呢?对此,部分同行有这样的观点,DEV是针对研发业务,而SVC是针对服务提供,二者显然无法融合;另外一些同行则认为,两者有共性PA13个,这就为融合提供了可行的基础。

  我们暂且将视线从观点的对与错转移,通过前不久刚为杭州某电力行业客户完成的一项CMMI-DEV与CMMI-SVC融合咨询项目这一视角,重新认识DEV与SVC之间的关系。

  举个例子,项目策划(PP)这个过程域存在于DEV和SVC中,是两者的共性PA,只不过后者更名为工作策划(WP),此处可以表扬一下SEI,至少知道针对“服务”来讲,按“项目”模式来运作是有欠稳妥的。但针对某些桌面端运维项目,其服务提供确实是按“项目制”来提供的,这个很显然和IDC业务有区别。但很庆幸,睿泰的这个客户主营业务是ERP软件的二次开发、部署及服务,由于他们提供了一条龙服务,因此非常关注为客户提供的ERP整体解决方案,而这项方案涵盖从需求、开发、部署、运维的整体过程。可能有些朋友已经划清楚了界限,软件部署之前执行DEV,部署之后执行SVC不就清楚了么?但是这儿有一个问题就是软件研发本身也是一种服务,而从另外一个角度来看,服务提供本身也是一种产品,也是需要研发的!

  睿泰与客户就两者的区别及联系进行了多轮交流,目的就是为了搞清楚两者的界限,因为按照正常的逻辑,任何一个过程改进体系总归是一个范围的,没有搞清楚范围就往下面走很显然会走弯路甚至陷入绝境,事实证明将时间投入其中并不明智,实际上我们脑袋里(包括读者您)早就有答案,因为两者互相离不开对方,继续钻研这个问题只会使您“走火入魔”!

  以下内容为此次项目过程中提取浓缩的三项要点:

  1、以服务为大框架,换言之,以业务驱动研发。业务来自于客户,客户的需求本身就是服务请求,这就是一个“与”门,自然而然线就连起来了;

  2、融合时,不用太在意DEV与SVC本身。按正常的逻辑去梳理业务,很自然的就会发现,两者不谋而合;

  3、部分小细节是需要关注的。应如何设置服务目录、定义服务级别。

  总而言之,睿泰的成长与客户的价值驱动是分不开的,正如我们研发CMMI-DEV与CMMI-SVC模型的融合一样,是希望帮助企业实现软件研发和运维服务的有效结合,建立更加适用于企业的流程体系,使企业更有针对性的实施内部过程改进,达成企业最终的商业目标。