科新咨询助力企业建立完善研发管理体系！

编辑导读：本文对基于CMMI、基于IPD和基于敏捷模式这三种不同的研发体系进行了梳理介绍，并分析了产品研发的流程以及每一个流程中的要点，与大家分享。

纵观各类科技企业，由于自身所处环境不同，因此其软件研发管理模式也不尽相同，这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系，也有基于IPD集成产品研发框架指导下构建的研发管理体系，当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。

01 基于CMMI的研发体系

CMMI能力成熟度模型相信大家都不陌生，从一级到五级，覆盖了22个过程域，一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。

当然，这里主要是指企业能够确实按照CMMI模型去实践，这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。

虽然老谭所在的公司通过了CMMI5的级别，但是实际执行的过程中，我们并不会完全按照CMMI5进行，需要根据实际情况进行裁剪，相比于它对实际研发过程的指导作用，我感觉CMMI认证更多的为公司增加一种重要资质，以期在招投标中获得更好的加分。

对于互联网企业，特别是To C的互联网企业，CMMI认证的意义并不是特别大，因为在C端你无需依赖这些资质证明能力，而是以产品制胜。

02 基于IPD的研发体系

IPD的核心内容是以市场为导向的产品开发，关注客户需求，将产品开发看成一项投资（商业价值），通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品（各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付）。

去年开始负责研发时，我在公司更倾向采用IPD的模式构建研发体系，把技术团队和产品开发团队做了分离，也融合了近几年比较火的中台思想，其目的是将过去分散式的研发体系做适度的统一和整合，加强技术能力建设。

但经过这段时间的运行来看，其实也出现了水土不服的现象，其根本原因是IPD是是一个相对重量级的体系，要落地执行往往需要从整个公司层面去整体考虑和推动，而不仅仅是研发团队内部的变革，需要高密度的跨部门协作，所以对于中小企业来说，IPD也并不一定适用，因为：

IPD需要对产品拆分为技术开发、平台开发和产品开发，一般中小公司没有这么复杂和巨大的产品；

IPD的流程繁琐复杂，虽然可以裁剪，但也很多，针对众多研发项目，需要方方面面考虑周到，对中小公司来说管理成本太高；

IPD的关键要素，无论是跨部门团队、管道管理，还是优化投资组合等都是针对市场，一般中小公司的市场驱动较弱。

IPD研发管理体系的主要内容、指导原则及基本思路

企业能否有效地掌握投入资金的对策，取得好的产品资金效果，提高资金运营效率，是一个大的战略问题，也是企业业务投资组合计划的任务。而IPD强调的正是对产品开发进行有效的投资组合分析。产品战略及规划体系、业务决策评审体系关注的是“做正确的事”，IPD组织体系、IPD流程体系和IPD绩效管理体系关注“把事情做正确”并高效地完成。文章将从五个管理体系的主要内容、需要贯彻的指导原则、构建的基本思路为您详细介绍IPD研发管理体系，以供参考。

1. 产品战略及规划体系

（1）、主要内容：

①　产品战略流程

②　市场管理及产品规划流程

③　技术规划流程

④　市场需求管理流程

⑤　市场需求数据库

⑥　市场调研及情报系统

⑦　集成组合管理团队(IPMT)

⑧　组合管理团队(PMT)

⑨　技术管理团队(TMT)

（2）、指导原则：

①　基于市场的原则(从市场的角度做规划)

②　前瞻性原则

③　明确定位原则

④　平台化及系列化规划原则

（3）、基本思路：“四化”——团队化、流程化、信息化、工具化，即成立跨部门的团队负责制定产品战略及规划并进行决策，建立完善的规划流程，基于充分的数据和信息进行分析并获得对市场的洞察，强调采用一系列专业的方法及工具。

2. 业务决策评审体系

（1）、主要内容：

①　业务决策评审点(DCP)

②　业务决策评审流程及运行规范

③　业务计划书编制规范

④　研发合同编制规范

⑤　产品退市计划规程

⑥　集成组合管理团队(IPMT)

⑦　IPMT秘书机构

⑧　产品开发团队(PDT)

⑨　生命周期管理团队(LMT)在DCP中的角色及职责

（2）、指导原则：

①　业务(投资)控制风险

②　及时决策原则

③　承诺及授权原则

（3）、基本思路：在产品开发过程中，分别设立概念决策评审、计划决策评审、可获得性决策评审(量产决策评审)，由PDT提出业务计划书及决策建议，供IPMT决策;在产品生命周期中，由LMT提出(如果没有LMT，可由PMT或产品经理)产品退市建议及退市计划，提交IPMT决策。

3. IPD组织体系

（1）、主要内容：

①　企业组织架构图

②　产品线组织结构及职责划分

③　跨部门团队(IPMT、PMT、PDT、TDT等)角色及职责

④　运行机制

⑤　职能部门划分及职责

⑥　职位体系

⑦　资源池运行规范

（2）、指导原则：

①　跨部门团队协同原则

②　扁平化原则

③　充分授权原则

④　产品线与资源

⑤　能力线并重原则

⑥　资源平衡原则

⑦　文化导向原则

（3）、基本思路：在公司或事业单位(SBU)层面上，设立“产品线+资源线”的重度矩阵结构，根据具体项目情况适当结合项目型结构或职能型结构，采用各方面的配套措施，使矩阵结构有效运行。

4. IPD流程体系

（1）、主要内容：

①　IPD体系流程框架

②　IPD产品开发流程(袖珍卡、阶段流程、角色及职责、活动说明、模板)

③　TPD(技术平台开发)流程(袖珍卡、阶段流程、角色及职责、活动说明、模板)

④　支撑性子流程及相关规范、模板，包括系统工程(SE)、硬件/软件等领域设计

⑤　项目管理

⑥　文档管理

⑦　技术评审

⑧　质量保证

⑨　CBB重用

⑩　需求管理

⑪　物料选型及认证

⑫　支撑流程体系运行的IT系统(PDM系统、协同平台等)。

（2）、指导原则：

①　结构化原则

②　并行原则

③　平衡原则

④　全流程责任原则

⑤　持续优化原则。

（3）、基本思路：

①　自上而下，先构建整体框架，然后层层展开和细化;

②　先主后从，先构建主流程，再识别和划分支撑性子流程，使主流程与子流程有效衔接;

③　由外及内，以客户的要求和需求为出发点，明确流程的关键活动及内部逻辑关系;

④　先流程重组(BPR)后IT化，在流程构建过程中，不是简单地把现在的做法变成流程，而需要实施流程重组或优化，然后实施IT系统，使流程固化并高效运行。

5. IPD绩效管理体系

（1）、主要内容：

①　IPD度量指标及KPI指标体系

②　绩效管理流程及制度

③　部门绩效考核办法

④　项目绩效考核办法

⑤　绩效与薪酬挂钩方案

（2）、指导原则：

①　公平合理原则

②　定量与定性相结合原则

③　目标导向原则

④　SMART原则

⑤　过程管理原则

⑥　激励为主原则。

（3）、基本思路：

①　关注绩效目标及计划环节，从KPI和定性工作两个方面制定目标;

②　强化绩效辅导环节，做实过程监控;

③　优化绩效考核环节，淡化评分，适度区分考核等级(如区分为A、B、C三级)，做好绩效反馈;

④　简化绩效结果运用，避免绩效考核结果与工资、奖金频繁而紧密地挂钩，加强在绩效管理过程中信任、授权、认可、荣誉等非经济激励因素的运用。

03 基于敏捷模式的研发体系

在这个快鱼吃慢鱼的互联网时代，对用户和环境越来越要求要快速响应。

敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系，主要理念就是敏捷迭代、小步快跑，快速改进、拥抱变化，用户参与等等。

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发，而不是一次性完成项目的交付；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发或者可以理解为小步快跑的开发模式，一次只交付客户一部分的特性或功能，如下图：

传统的外部客户的项目如果更适合CMMI管理的话，那么对于产品研发，不论是互联网产品研发还是To B的软件产品研发，敏捷模式都是更加适合的。

敏捷的交付是持续的一个过程，软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长；敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品。

老谭在负责一块互联网业务时，更多的是采用敏捷的开发模式，基本两周一个迭代的快速改进。

敏捷模式下，迭代的节奏是非常重要的，基于统一的节奏，产品、开发、测试、发布等不同岗位的人员就像建立了生物钟一样有规律的执行，团队间的协同能力得到极高的体现。

在这个研发体系里，敏捷团队负责人的主要工作除了执行例行的会议、任务分派以外，我认为最核心的就是对于sprint backlog的控制，既要照顾到需求方的关切，又不能轻易破坏节奏。

下面就敏捷开发分享一些应该着重注意的点，解决这些问题我想对任何开发团队都会有很大的帮助。

需求在开发中的重要性

大量的开发过程告诉我，需求在软件开发过程中是极其重要的。传统的开发强调初期的需求调研及需要分析，这个过程对于一些正规的团队会产生大量的文档，而后交由开发展开产品生产。

然而，事实却不是想象这么简单，无数的例子说明了一点，仅仅在需求调研过程中了解到的需求是无法保证的。数不清的例子告诉我们，需求是会变的，变的原因很多。在极端的情况下，有些客户签字的需求在开发完后，有需要变更也很正常。

所以需求是影响软件开发的第一重要因素，需求来源于业务，我们开发的产品不就是因为这些业务才去做的吗？如何需求都无法把握好，还谈什么开发出好用的产品？

然而如何做好需求呢？我想首先要确立需求的地位，然后只有通过不断的沟通、尝试、反馈向真实需求迈进。

强调人与人的交流

不管怎么样开发过程中主要还是靠人的，而且软件开发是个复杂的团体工程，一个小些的产品也会涉及到各类人：客户、业务分析、管理人员、程序员、测试员等等。这么多人在一起做事情，有一方没有处理好结果肯定就会有问题。

有这样一个例子：客户提出了一个会员管理功能需求，需求人员了解后组织了解决方案，于是交付了开发实现。而经过二个月无尽的黑夜之后交付，需求一看有个模块做的有偏差，但是已经来不及修改了。交给客户看后，发现这不是他们要的会员管理功能相差较大，另外在功能开发的这一段时间，客户又有了新想法，要对原先需求做调整。

这种例子可能大家经常经历吧？

这种问题在敏捷开发方法中提出了解决方法，就是通过不断的交付可用的制品。看起来很抽象，其实很简单。同样是上面的例子：
Ø 客户提出会员管理功能需求
Ø 需求人员在了解需求后与开发负责人商量，确定一个快迭代的开发计划，每二周向客户演示一次，并将这个计划与客户确认
Ø 确认后需求人员向全体成员讲解需求背景故事
Ø 开发负责人组织并确定迭代计划内容，明确每个迭代提交的产品目标、开发任务安排、测试跟踪计划
Ø 每个迭代过程中都由需求及测试进行确认每个任务的实现结果是否跑偏
Ø 后面就是每二周向客户演示一次产品，并获得客户的反馈
Ø 根据客户的反馈调整下个迭代计划，并继续下一个迭代
Ø 直到产品交付

通过上面的步骤，就不至于在开发完成后才知道用户的真实想法，因为很多用户对软件开发是没有概念的，他只知道自己有某种需求，但最开始是没有一个完整的概念的。所以就要通过不断的让用户看到产品的模型，这个过程用户才会逐步的对产品产生概念。同样的在过程中客户的提出需求变更也是在一定的可控制范围之内，这样一来可以大大的减少软件返工的情况，自然就不会拖延计划了。

而这个过程中，需求已经完成了一个真正的过渡，不再是一头重的情况了。他让需求从客户那快速的反馈到开发团队中。同样的，在开发不断的交付制品时，需求也更加及时的了解到产品的进度，把握开发人员开发的功能是否符合需求。
当然这并不是一个标准做法，不同的团队可以有不同的处理方式。这里只是想强调需求需要更多的投入到开发过程中去，及时的与客户沟通交流，了解到客户的真实想法。

强调文档的作用

我觉得很多对敏捷开发的一个误解就是不需要文档，敏捷开发并未抛弃文档。只是更强调更有效的方式使用文档。在很多传统开发方法中，特别是很多很正规的开发团队对文档的要求非常苛刻。然而事实是文档不易管理，最痛苦的是不好维护，文档需要随着变化而变化，比如需求调整、技术架构升级、产品维护等等。如果要保证文档的一致性，太难了。特别是对于一些无法进行有效管理的开发团队就更加明显，经常是软件已经几个版本了，文档却是两年前的。

但敏捷真的不需要文档吗？我想不是的，如何把文档做到好维护我想才是最重要的。文档到底指的指的什么？什么样的算文档？

提出上面两个问题，我们先想想经常说的文档的作用是什么？不就是一个传播工具吗？可以用作记录、给他人看、用于以后查看。有很多方法可就解决了这个问题，比如wiki系统。维护一个wiki系统，可以随时写，随时维护，可以方便的查找。嗯，多方便。

另外一个问题就是什么样的工作需要形成文档呢？

记得在前一家公司，维护一个10多年的老系统修改一个公式计算的BUG，但是怎么也不知道这个复杂的公式是什么意思，问过了公司大部分的人也无人可解。这时想，如果当初有那么一份文档，谢天谢地。

像这种关键的内容有份文档还是很重要的，否则随着时间推移，谁也不能保证能记得住当时为什么会这么干。

记得多年前一次记笔记的经历，我看了一篇文章了解了DELPHI实现单实例模式的方法，这种方法很酷。于是整理成了笔记写在了wiki上，第二天就得到了回复，帮助到了别外产品开发组的同事。

嗯，文档就是这样他具有传播性，你不可能跑去跟所有人说出你的想法，但是文档却更容易达成。他也有传承性，有些文档也许10多年后又起了重要作用。

团队协作

1、减少对开发人员的干扰

曾经接手一个产品的开发，最初遇到一个很头痛的问题，原先写好的迭代计划，而且工作量也较大，大家都在忙着。即便在这样的状态下，客服人员却经常跑来找某个程序员A维护各种系统问题，程序员A在一次维护中竟然导致了系统数据出现大面积错误。程序员A心理上承受着巨大的压力，而每天的这些问题又不得不解决，加之新版本又有很重的开发任务无法完成，最终导致整个开发计划变更。

我无法再忍受，找到了需求及客服的负责人，沟通后发现这些问题很多都是重复性的，主要是因为原先系统的不足。于是回去组织人员做了几个后台临时功能，并交付给了客服人员，之后就没有再来找过这位程序员A。后续我又找到了客服负责人，要求不能直接找开发人员解决这类问题，并与负责人约定了处理过程。

这是个例子，在实际情况中还有很多这种事情，甚至有很多开发人员要直接面对客户。我想对于职能型团队来说，开发团队最好是减少这些方面的干忧。当然对于一个人包干的情况就不讨论了。

大部分的人都不是超人，在一个时间段内处理超出自己负荷的工作是很难做好保质保量的。所以对于开发管理人员一定要考虑到这点，尽量让开发人员有比较好的工作进度环境，通过外界的方式来解决一些开发团队的干扰。

我接触过的很多程序员都很反感这种干扰，虽然有些人在这种全面的工作强度下成长很快，但是并非所有人都适应，长期下来会有怨恨和不快，工作效率会下降。心情舒畅还是很重要的，记得有一次迭代总结时，有个程序员总结说：发现心情舒畅自己的工作效率很高。呵呵。我想你也有同感吧。

2、不要忽略测试人员在开发阶段的作用

曾经多少次在项目发布前加班到深夜2点的情景还历历在目，那种感觉即快乐又痛苦。由于和客户签定的合同的交付日期就要到了，产品却迟迟未集成完成，测试只能干等着上网聊QQ。就在下班前的一刻发布了，测试开始了紧张的测试，在屏幕闪动中，一个个的BUG提交，直到流程都无法都走不下去，测试无奈了。第二天就要发布，实施人员就等着制品第二天出差。只有不断的改，再发布，无尽的循环。直到大家都憔悴的看着老大，终于老大说：还剩下的这几个问题无关紧要，大家回去吧。

几个月的开发过去后在总结会上，只能抱怨测试资源不足，时间太短，需求更改太多，需求更改后测试不知道。无数的问题一次一次的出现在同样的总结会议上。

上面的这个例子很多人应该经历过，真的测试只有最后一刻才能体现价值吗？我想不是的。

在后面的项目中我总结了这个问题的，针对每个开发任务要求进行测试验证。而测试如何验证呢？他需要知道这个开发任务的需求是如何，提前做好测试计划及测试用例，在接到开发制品后测试并提交BUG，这个工作是可以开发过程中就能不断的进行的。保证每一个任务的质量，可以大大减少后期集成的错误量。

另外根据敏捷开发的思想，测试团队在开发过程中也需要加强与开发团队的交流，甚至有必要组成虚拟团队，位置调整到一起，这样可以及时快速的交流，参加开发团队的站立会议同样可以及时了解到开发的实际情况及进度，反过来把握测试计划及测试内容。

特别是测试从另一个角度来审视需求，这样也可以一定程度上发现或者改善需求上的不足。

3、发挥团队人员的潜力

敏捷开发比较提倡开发任务由开发自己评估并认领工作任务，这样可以激发开发的潜在动力。

之前在做一个新产品时，需要使用java，而我们团队是使用C#的，面临转型问题。而有一位同事很感兴趣，于是我就让他负责前期的框架探索与搭建。结果就是这位小伙工作效率很高，我最初给他的目标全部都完成了。最有意思的是后面产品开始研发时，这位小伙已经成为了团队的大牛，大家有问题都找他解决。也正是因为这个过程，这位小伙被全面激活，也在大家面前展示了能力。甚至在小伙离职时也被领导给予大幅涨薪来挽留。只不过谁又能想象到这位小伙进入我团队之前是因为被定为裁员的目标而调剂过来的呢!

所以充分发挥好每个人员的特点，让人能够在自己感兴趣的工作中，效果会很多。减少指派方式的任务的分配，充分发挥个人的主动性，这个团队精神面貌也会好很多。

4、管理者不要离团队太远

作为团队的Leader要参与到团队的工作中去，比如一个开发主管一定要写写代码，参与架构等对项目有关的事情，而不是在那里分分任务。这样团队成员才会觉得这个Leader很亲近感。

特别是有些开发主管在带队后离团队越来越远，有时对于开发进度不如意时就说：“这么个简单功能怎么会搞了这么久？”，其实每天都在加班的同事心里想着：“有本事你来？”，即使这个小组长有这个能力，但对于团队来说也不是一件好事，因为大家都抱有怨恨之心，还谈什么好好工作呢？这个小组长就是失职的。所以这种情况下应该主动去了解进度滞后的原因，并且自己要加入到解决问题的工作中去，而不是在边上抱怨别人。

5、小组织不要搞太多的官

中国几千年的文化，官本位一直影响着我们，大家都想坐在那指挥，自己啥事也不用干，想想都惬意。在我们这个行业是不是发现也很类似？大家都想着干几年当个小组长，然后升个部门经理，当上CTO迎娶白富美。

团队的管理基本是事与人的管理，非常的伤脑和心。如果一个组织内，特别是小组织内“官”太多，协调就会非常的难，大家就会经常性的扯皮。

结束

与敏捷开发结缘也有几年，从开始的抵触到后面的认可经历了许多，这个过程并不是一蹴而就的，需要花时间花精力，特别是要去实践、总结。

还有我觉得是不能太教条，很多事情都要有怀疑的心，然后去实践总结，找到合适自己团队的方式方法。

04 总结

这三种开发模式中，IPD的层级最高，既包括了“做正确的事”，又包括了“把事情做正确”，是公司级的运营级流程，CMMI和敏捷是同一个层级流程，是工程方面的实践级流程。CMMI和敏捷不具备高层决策能力，而一种“把事情做正确”的开发模式。

华为公司早在2009年正式发文在全公司现在流程IPD、CMMI的基础上，所有产品线的软件开发团队全面推行敏捷开发，可见这三个体系并不是孤立存在的，而是可以相融互补的。

由上图所示IPD关注整个产品的开发管理，包括市场、开发（软件、硬件）、结构、生产、采购、财务等各个方面，CMMI/Agile流程关注其中的软件研发过程的管理，CMMI是在研发过程中走瀑布模型，而敏捷是走版本迭代的模式。

对于每个公司和项目来说，采用研发体系应该因地适宜，并没有标准答案，这和团队的发展趋势、项目规模大小、业务形态等方面都有影响。并且研发体系也是一直在发展的，只有适合的才是最好的。