读产品研发管理系列之《培思的力量》

PACE（Product And Cycle-time Excellence）即产品及周期优化法，中文译作“培思”，是美国PRTM公司在上世纪80年代中后期提出的一种产品开发流程，随后IBM基于PACE提出并发展形成的IPD（Integrated Product Development，集成产品开发）在欧美广泛应用，以华为为代表的国内企业也从90年代末开始引进IPD。先看了培思方面的资料，然后了解了IPD方法论，回过头来再读这本《培思的力量》也是颇有感触，本文就结合PACE以及IPD谈谈对产品开发管理的一些理解和思考。

PACE实际体现的就是一种“流程”思想，是一种关于产品开发的流程框架，关注的是面向市场的产品管理而不是技术管理，当然产品管理和技术管理是需要整合的，将市场机遇和技术等融入某一个流程，其结果就是产品。而这个流程是可以被定义、构架及管理的，PACE就是提供了一套被作者们认为是合理、高效的标准或体系，与CMMI面向“正确的做事情”角度相比，PACE更多的是帮追我们及时响应市场需要，做更多“正确的事”。PACE从以下7个方面对产品开发流程进行了阐述：

一.  阶段评审与决策流程

产品开发是由决策流程来推动的，这一流程决定要开始什么产品及产品开发资源的分配，而正确高效的决策就来自阶段评审。PACE认为无法正确作出决策很多时候并不是做决策的人（通常是公司高层）不行，而在于决策流程本身。要做到高效决策，PACE提到要做到两点：首先需要建立产品审批委员会（PAC）。产品审批委员会由为数不多的公司高层组成，有权力提出、取消或重新确定项目优先级并分配开发资源，而判断的方向来源是市场；其次确立阶段评审流程。PACE中的阶段评审分为5个阶段，分别是零阶段（概念阶段）、1~4阶段（计划、开发、测试、推出产品阶段），每个阶段通过评审决定该产品开发是否要改变路线、放弃还是继续执行。通过决策流程形成的是一个漏斗机制，确保“做且仅做正确的事“。

在IPD中我们也有类似PAC的组织结构，称之为IPMT（Integrated Portfolio Management Team，集成组合管理团队）。IPD中我们也把整个产品开发流程分成若干阶段，划分方式虽与PACE略有不同但意义是一致的。IPD中产品开发分成概念、计划、开发、验证、发布和生命周期6个阶段，把PACE中的推出产品阶段从产品运营角度再做了拆分。而且并不是每个阶段都需要评审，评审只在概念、计划、验证和生命周期这四个阶段进行，评审使用DCP（Decision Check Point，业务决策点）这个概念与技术管理中的TR（Technical Review，技术评审）以示区别。

日常研发过程中，如何有效决策确实也是一个关系产品成败的重要因素，很多时候决策也是公司高层几个拍拍脑袋就定了下来，缺少的恰恰是PACE和IPD中提到的阶段评审和决策流程。有些产品从一开始就没有进行概念阶段的规划就直接进入计划阶段，计划也是很武断的理想过程，随着后续开发过程的进行，再回过头来考虑产品的定位和市场价值的场景也时有发生，这些场景中的一部分确实是可以通过评审和决策流程来改进或避免的。另一方面，对于任何流程，根据不同的公司情况和产品特点，对流程做裁剪个人认为是最重要的。产品研发阶段的划分和评审数量和时机的把握上我们可以灵活应用PACE中的思想，例如，如果产品本身不大，那概念和计划阶段可以合并到一个阶段，这样概念和计划评审就合并为一次评审。对于流程而言，流程的实施成本也需得到合理控制。

二. 产品战略流程

虽然产品战略更多是组织级别的主题，但PACE认为产品战略也是一个流程，它把产品战略分成如下四个层次：产品战略愿景、产品平台战略、产品线战略和具体某一个新产品开发，产品战略的运作方向是从上到下，从一般到具体。这些概念在这本书中描述的相对比较抽象，我们还是看看IPD中的做法。

IPD中提到的产品战略和规划分层和PACE是完全一致的，但做了进一步细分，即回答了这些层次从何而来的问题，上文提到的IPMT管理整个产品战略流程。

首先，产品平台是整个系列产品所采用的共同要素的集合，包括共用的系统架构、子系统、模块/组件、关键技术等，产品平台在产品树中的位置如下（摘自汉捷培训资料）：

产品平台战略通常需要考虑的是现有平台、现有平台的衍生平台以及新平台之间的关系和决策。其次，产品线规划从何而来?IPD认为产品线规划应该是市场管理的输出，所以在IPD添加了一个全新的主流程即市场管理流程，该流程通过市场细分、组合分析等手段在产品平台的基础上确立产品线规划。为了有效进行市场管理流程，IPD中引入PMT（Portfolio Management Team，组合管理团队）负责该流程中的决策。市场管理和产品快速推向市场的思想在PACE中也有所体现，但IPD把它上升到一个主流程的地位，是对产品是否能应对快速的市场变化而做出的增强。相较PACE，IPD更加认为产品研发是一项投资行为，更需要基于市场进行创新。

通常的软件研发，产品战略愿景以及市场管理流程通常不是研发团队主要关心的问题，所以这一部分内容理解起来确实比较有难度。但从分层的角度讲，就像软件开发过程的分层架构一下，也是基于业务模型由一般到具体的开发过程。尤其产品战略流程中的产品平台战略基于技术平台，是组织层面需要不断建设和完善的基础。个人认为产品战略流程的推行首先需要比较大型的有底蕴的团队基础，小型团队和产品可能做不到也没有必要做到书中提到的分层结构；另一方面，很多时候并没有进行市场分析，也没有建设基础的技术平台就进入到了具体产品的开发阶段，确实也是产品最后面向市场表现不佳的一个原因。尤其是互联网行业中，闭门造车或者说模仿成功产品的场景很多，如何从流程角度管理产品的战略是需要我们不断实践和提升的。

三. 核心小组法

核心小组法关注的是项目组织结构，即执行流程的团队和人。核心小组通过有效的沟通、协调和决策，达到尽快将产品推向市场的目的。为了达到这一目的，PACE认为要把产品开发过程中传统的职能部门之间的组织结构关系转换为一个核心小组，该核心小组成员来自市场、质量、软件、客服等各个职能组织并由核心小组组长带领，核心小组协调人作为流程工程师则关注流程改进。通过这一转变，核心小组负责产品成功，而传统的职能经理则负责组织内技术水平的提升和团队建设。

IPD参考了PACE的核心小组法并把它进行扩展，IPD整体框架分为4大主流程，分别为产品战略流程、市场管理流程、产品研发流程和技术平台研发流程，每个主流程都有独立的小组负责流程的运作。除了上文提到的IMPT负责产品战略流程、PMT负责市场管理流程之外，还有PDT（Product Development Team，产品研发团队）负责产品研发流程以及TDT（Technology DevelopmentTeam，技术平台研发团队）负责技术或平台研发流程。其中PDT是PACE核心小组法在IPD中的最好体现，PDT由各个职能组织的代表组成，组员完全代表相应的职能组织，执行由IMPT通过阶段评审和决策形成的计划书并对产品的最终上市负责，而PDT内部也通过技术评审和决策进行详细的计划和承偌管理。IPD崇尚“强矩阵“的组织结构形式思想并通过PDT把这一思想发挥到极致。

日常研发过程中，有些组织会形成以职能部门为单位的组织结构，典型的如技术部、项目部、产品部、品质保证部等；而有些组织则根据产品线形成产品事业部，该事业部中包括技术、项目、产品等各个小组。从形式讲，后者比较符合PACE的核心小组法，但具体操作过程中还要从型似转变为神似。通过建立以产品线为单位的组织结构，并在该组织中按职能区分各个小组，然后把各个小组的负责人召集起来形成一个核心小组，小组的其他成员则作为外围人员负责具体的工作的实施，由该组织结构的负责人充当核心小组组长，再配比专门的人员如QA作为协调人，这样的工作方式个人认为是比较高效的。

四. 结构化产品开发

所谓结构化，是指相互关联的工作要有一个框架结构，并要有一定的组织原则来支持它。通常结构化是一个自上而下的层次结构，工作从抽象到具体并且所有工作都有明确的定义。有些组织可能缺少结构化，而有些则又过度结构化，PACE认为应该在非结构化与过度结构化之间达成一种平衡，这种平衡就是PACE所推崇的层次模型。基于PACE理念的结构开发包含四个层次：阶段、步骤、任务和活动，同时提供概念图、步骤日程表和任务日程表这三级进度表作为项目进度的不同视图，体现是实际也是一种范围分解和计划管理的思路。

IPD对于结构化三个字的理解虽然类似，但具体做法上显然有所不同。IPD中的结构化分层并不是从范围分解的角度出发，而是更加关注流程。IPD把整个产品开发分成上文中提到的6大阶段，每个阶段对应一个流程构成了IPD产品研发主流程中的六个阶段流程。6个阶段流程的下面是10个支持性流程或制度，包含常见的项目管理、配置管理、需求管理流程以及文档控制、质量管理制度，个人理解PACE的按范围和时间的分解已被包含在这些阶段流程和支持性流程中，所以没有上升到整个结构化的层次，这可能更加合理。阶段流程和支持流程/制度的下面是文档模板用来指导具体的开发工作。

很难说所谓的“结构化”到底应该长得怎么样，看似简单的分层范围分解和管理实际做起来也是很有挑战，尤其是在产品本身比较大，团队成员也比较多的场景下。很多时候任务、活动等面向开发人员的要素都可以被分解出来，但如何把握这些要素与面向用户的功能之间的关联性，如何控制任务、活动之间的依赖关系，如何简单有效的衡量进度，是我们经常需要面临的难题。通过PACE和IPD中提到的并行工程、结构化平衡等思路以及项目管理、质量管理等子流程，可以为我们的研发管理工作提供一定的实践指导。

五. 技术管理

PACE中的技术管理为我们的产品开发流程补充了两个重要方面：技术开发以及技术转化。技术开发与产品开发有很大程度上的不同，相比产品开发，技术开发的不可预测性更大，过多的流程框架会抑制团队的创造力，所以PACE认为应该把技术开发的管理与产品开发的管理分离开来。在技术开发过程中，TR（Technical Review，技术评审）流程为其提供主要框架，TR与上文提到的阶段评审流程的做法类似，随着TR的推进，由于技术产生的不确定性不断降低，团队对技术的理解总体上在提高。多次TR的最终结果是将技术如何融入到产品开发中，这就是技术转化。PACE认为需要有一个技术过渡小组专门负责技术转化的协调和流程。

IPD中基本沿用PACE中的思想和工作方式。关于TR，IPD产品开发流程中一共包含7个评审点：TR1、2、3、4、4A、5和6，分别分布在产品研发的概念、计划、开发和验证阶段中，每个TR主要关注产品的一个方面，如需求、概要设计、性能等。关于技术转化，IPD设立TDT（Technology Development Team，技术平台研发团队）负责技术或平台研发流程以及技术转化工作，从而对产品开发和技术开发进行了更为彻底的分离。

技术评审在日常研发过程中也是一个比较常见的做法，我们有很多可以使用的评审技术如各种同级评审（Peer Review）技术。TR的关键是如何将技术上的决策更好的转化为产品开发成果，例如组织的一个公共技术平台可能需要同时支持多个产品线的开发工作，那这个技术平台将需要根据各个产品线的不同需求做适配，这通常是一项很有挑战的工作，做的好差与否可能对技术向产品的转换起到决定作用，这从一个侧面也印证了IPD中强调CBB（Common Building Block，公共构建模块）的重要性。

六. 管道管理

阶段评审流程、核心小组和结构化方法能够帮助我们迅速将某个产品推向市场，但很多时候由于产品线众多而资源有限，需要我们超越项目级的管理，而站在组合管理的角度对开发过程进行性能优化。PACE中提到了开发管道（Pipeline）这一概念，管道管理体现的是一种可持续化的平衡。PACE认为要做到管道平衡，需要从两方面入手：一方面我们面对众多机会需要分清产品开发的轻重缓急，也就是要把握事情的优先级，做好人力和资源的合理分配；另一方面要做好职能交接，产品开发要和各职能部门的管理保持一致。

在IPD中，管道管理更多的是和项目管理流程一样作为整个框架的一个支持性子流程，通过加强公司项目的管道管理，提高了研发资源配置效率，在战略产品和利润产品之间进行有效平衡。

管道的思想很好理解，即如果一个管道的大小既定，那同时通过该管道的内容就需要控制：如果同时通过的内容太多，则管道承受的压力太大就可能崩溃，团队发展就是不可持续的；如果同时通过的内容太少就形成浪费。但现实中往往很难准确把握该管道的大小，即便能够把握，如何控制通过管道的内容以达到管道载量均衡也是一项挑战。通过各产品/项目的重要性和优先级动态调整、阶段评审过程中的跨项目信息的全面获取、产品研发团队的有效沟通，很大程度上可以避免出现像书中提到的产品的概念已经通过评审但相关资源却迟迟不能到位的情况。

七. 设计手段和自动化工具

把这一点放在最后是因为时效性而不是重要性，《培思的力量》写在20年前，这20年里无论设计手段和自动化工具已经获得了长足进步，书中提到的一些思路是正确的，但表现形式已经过时。故这一点我们不做展开，相应的IPD中也没有专门的内容对具体的设计和工具做明确的介绍。

书的最后关注产品开发流程演变的阶段，PACE的演变分为4大阶段，分别是非正式的零阶段，以职能为核心的项目管理为特点的第一阶段，以跨职能的项目管理为特点的第二阶段，以及以公司范围的产品开发整合为特点的第三阶段。IPD参考PACE，则把产品研发管理体系演进分为5个水平层次，如下：

看着上面的这张图，不仅让人想起CMMI中的5个等级。这里提到CMMI，也是觉得IPD和CMMI虽然出发点和关注点完全不同，但CMMI和IPD两套框架中都有”集成“这个词，那是否也可以把CMMI和IPD集成在一起使用呢？很多学者认为是可以的，CMMI强调规范化、精细化管理，可以帮助IPD把策略落实到具体的计划、制度、模板和控制方法。个人也觉得至少在以下场景这两者是可以融合在一起并发挥更大效力的：

• 有效评审：无论面向市场的决策还是面向技术的评审，在PACE和IPD中体现的都是一种工作流程，但具体怎么评审，评审的输入产出如何管理，可以借鉴CMMI VER过程域中的具体做法
• 支持性流程：IPD中的支持性流程，如项目管理、配置管理在CMMI都均有对应的完善的过程域可以参考，流程配合过程域的过程和做法是对产品开发主流程的强有力支持