20年研发管理经验谈（六）

本文继 20年研发管理经验谈（五）

如何进行产品研发业务外包？

　　进行产品研发业务外包的方式没有绝对的标准。行业分析师指出,理解其中的差别一般与一家公司管理层的成熟度有关,而不是与公司自己规模或者存在的历史有关。最佳的方式是把产品线和研发分红两类：一类是构成该公司将来竞争力的核心要素,另外一类是非核心要素,把非核心的部分外包。

　　许多状况下,OEM公司倾向于将本身无力承担的工做外包出去,即便是系统中的关键部分。“许多厂商将软件开发外包给印度和其它地方的软件设计商,这并非由于它们不是核心业务,而是由于这些厂商不具有这样的开发能力和团队。”市场咨询公司Pittiglio Rabin Todd & McGrath(PRTM)欧洲创新业务主管David Percival表示,“没有足够的人手致使了许多公司将软件开发这种核心的研发业务外包。”

　　比较适宜的作法应是充分利用本身的内部资源来定义和制订产品规格,监督第三方合做伙伴开发,而后在内部进行测试和验证。Percival认为,这可能要求OEM厂商的开发队伍从新进行技能训练。

　　另外一个厂商常常犯的错误是将一些比较先进的开发工做外包。由于他们老产品的技术档案太糟糕和复杂,只有他们本身内部开发人员才能维护这些文档。“结果致使公司宝贵的研发资源和团队被禁锢起来,公司依赖外部伙伴来开发新的和使人激动的产品,而这些产品正是其竞争力的来源。”Percival说。

　　比较适宜的作法是多花点时间进行正确地设计、调试和对当前设计创建文档,而后再外包,将内部资源集中用于新产品的研发上。Percival强调说：“在你将产品中独特元素外包的同时,你将利润也外包出去了,最后剩下的只有一个空壳。”

 

产品开发流程的七要素

　　引言：PACE在产品开发过程当中的应用和扩展是一种实实在在的挑战，而那些成功运用PACE方法论和工具的企业也必将从这种挑战中获得显著的回报。

　　产品开发流程能够分为七个相关要素，每个要素都有其常见的不足之处。PACE提供了各类方法、技巧和手段，以克服每个要素的不足之处。下文对这七个相关要素做了介绍，对一些常见的不足之处进行了总结，并针对每个要素简单介绍了PACE的解决办法。　　

　　在之后的章节里，将进一步详述PACE的每个要素。

决策

　　全部的公司都有一个新产品决策流程，尽管他们有可能并无认识到这是一个有明肯定义的流程。在决策流程薄弱的公司，因优柔寡断形成的延误很广泛。例如，若是某个实际流程是顺序性的，要求许多经理一一确认某产品设计概念的优劣，那么，起动就会延误。咱们看到，许多良机的错失只是由于产品先驱们不知道如何运用这种不正规的决策流程。

　　咱们曾经帮助过的一家电脑公司有一个效率低下的决策流程，能够说它是咱们所见过的许多流程当中的典型。在这家公司里，项目评审已沦为一系列面向不一样听众的冗长的汇报。参加的人不少，提出的问题也不少，但这些汇报会并非决策会议。评审并无在开发流程的适当时机进行以促使决策，合适的信息也没有提供出来以推进决策。高层管理人员回避了评审，而且没有其余机制来推进适时决策。

　　然而，并不是全部明肯定义的决策流程都是有效的。有些流程要么设计得很糟糕，要么实施不当。在这些状况下，一个正正规规的流程实际上对产品开发构成了管理障碍。花费大量时间，却收效甚微，这样的决策流程早已不能推动产品开发。

　　在产品开发评审中，咱们发现因决策流程不当会引起下列问题：

·因为高层管理人员不知道应该由谁来做出决策，或者须要什么样的一致意见，因此他无心识的延迟决策或修订决策。
·信息不够充分或细节不清楚致使决策质量低劣。
·没有及时解答疑问。
·未定义决策控制点，以致在适当的重要阶段又出现了评审工做。
·须要投入的资源过多，以致没法定期完成任何事情。
·受权审批和设定优先顺序的人没有明确批准给予产品开发项目的拨付资金。
·决策太迟——常常是在产品已经设计出来以后。
·没有用周期指导来证明项目进度。
·高层领导没有做出战略决策，却由开发人员在无奈中做出这种决策。

　　在PACE流程中，新产品决策是经过阶段评审流程进行的，这种阶段评审须要在开发流程中具体定义的点上做出决策。一个产品开发项目必须在预约时间内达到明肯定义的目标，才能获准进入下一阶段。

　　产品审批委员会（Product Approval Committee, PAC）是指在一个部门或一个公司内负责主要新产品决策的高层领导小组。PAC有权在开发周期内的具体决策点经过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品。PAC负责经过产品开发活动实施公司的战略，所以，他们具备资源分配权，以推动新产品的开发。

　　PAC通常经过阶段评审流程来做出决策和进行资源分配。没有这样一个流程，高层领导就难以有效地引导新产品的开发。然而，只有一个评审流程（或相似的一个流程，如把关流程或阶段开发流程）是不够的。定义不清、实施不当或与开发流程中的其余必要要素不协调，均可能使评审流程效率低下。

　　阶段评审流程在产品开发中还扮演着另外一个重要角色。经过它，PAC能够直接明了地受权项目小组分阶段地开发产品。项目小组为产品制定详细的建议，提交产品开发计划，并申请下一阶段所需的资源。若是PAC批准工做小组的各项建议，它会赋予项目小组以权力、责任以及实施小组计划的下一阶段所须要的资源。

项目小组构成

　　在评审中咱们发现，尽管大多数公司有正规的项目小组，但多数并不成功。总的来讲，因为这些项目小组的构成、角色和责任没有明确的定义，结果使沟通、协调和决策效率低下、纷繁混乱。

　　有这么一家很典型的公司，不可胜数的经理们只在他们有空的时候或是有什么特别缘由使会议变得最优先的时候，他们才参加产品开发小组的会议。因为这种方法产生的效果差，因此公司曾尝试用不一样的方法来改变这种情况。他们创建了专门的项目管理www.hi-blue.com部门，负责监督进度和任务的提交，以明确由谁去作什么以及事情作了没有。后来，每一个部门都给每个主要项目指定了本身部门的项目经理。但这些方法效果并不理想，只是增长了毫无价值的劳动，而这种劳动已经太多了。

　　许多公司创建了项目小组的组织形式，但大多数效果不佳。针对这些不成功的案例，咱们发现如下典型缘由：

·若是项目小组和职能部门的责权不明确，将形成困惑。
·项目小组没有获得明确受权去实现目标，于是效率低下；在某些状况下，他们只被赋予了责任，却没有相应的权力和资源。
·缺少并行工程，一些职能和技能没法和谐地融入到项目小组中去。
·项目领导工做效率低，这源于几个因素：项目领导人没有经验；对项目领导人角色不明确；培训不足；项目领导人更换频繁；或者项目小组的组织有缺陷。
·项目小组缺少项目实施所需的人手和技能，于是没法实现目标；各类资源在项目小组间调来调去，缺少明确的决定。
·因为没有明肯定义项目小组和职能部门之间的协做方法，二者之间便有冲突和困扰。
·小组成员任务分配形成的困扰使整个小组效率低下：好比说，小组成员把本身看做职能部门的评估者或记录者，而非真正地帮助进行实时决策。

　　项目小组构成是产品开发流程的一个关键要素。一个高效的项目小组能极大地增进沟通、协做和决策。在评审初期，咱们就发现许多广为接受的项目小组模式效率低下，而低下的缘由与上文所述颇为类似。咱们开发了一个新的模式。这个模式既能发挥项目小组这种组织形式的最佳方面，又能克服上述缺陷。咱们把它称之为项目小组构成中的核心小组模式（Core Team Approach）。

　　核心小组是有权开发特定产品的一个小型跨部门项目小组。一个典型的核心小组有5—8名成员，有权力也有责任管理全部与开发该特定产品相关的任务。这些特定任务分配到核心小组的每一个成员身上，每一个成员都利用相应资源完成这些任务。小组成员们为指定给他们的工做肯定方向，与职能部门打交道，并做为核心小组的一员参与集体决策。PAC则在开发工做的每一阶段经过阶段评审流程赋予核心小组责任和权力。每一个核心小组都有一个指导和引导小组工做的领导人。该小组在执行每一开发阶段时遵照与PAC签订的有关重大项目目标以及可变更的范围的“合同”。

开发活动的结构

　　开发活动是开发新产品的实质性工做。在PACE中，结构化的开发流程明确了应作什么开发工做、相应的前后次序、其间的关联性以及用于开发项目的标准术语。在评审流程中，咱们发现，开发活动的结构中每每存在三类广泛的缺陷：(1)没有任何明确的产品开发结构的公司；(2)有具体流程手册但并没获得遵循的公司；(3)有结构化的流程但并不能改进或加快开发进度的公司。

　　对第一种状况来讲，公司必须在产品开发流程中不断地“从新发明车轮”，即从新定义产品开发流程。每个项目小组都定义其要遵循的流程，结果，每一个项目小组即便在执行相同的或类似的任务时，开发流程也迥然不一样。这种模式延长了开发周期，且整个公司的项目小组都易犯一样的错误。

　　对第二种状况来讲，流程被文档化了，可是并无获得执行。典型的状况是，某个职员在程序手册里定义开发流程，而后把手册散发出去，天真地期待每一个人都会遵照它，结果固然是他们并不遵照。多数状况下，他们不遵照反而好一点。项目小组又各自将本身的那一套流程搬了出来。

　　对第三种状况来讲，开发流程已获得明确和遵照，惋惜这个流程天生就效率低下。使人吃惊的是，许多公司在规范流程时，只是简单地将他们现有的作法写成文件，哪怕这个流程效率低下，其结果天然是把问题制度化了。

　　在评审开发流程时，咱们发现广泛存在下列缺陷：

·无章可循的开发活动致使产品不断更新。
·因为对必须完成什么样的开发活动及什么时候完成有误解，于是形成项目计划不周及准备不足。
·缺少通用术语以及由此引发的理解问题，致使开发工做不理想。
·产品开发定义过于详细，尤为是缺少结构化的定义，使得开发效率不高。
·每一步都须要多个签字盖章的官僚流程延缓了开发工做。
·缺少并行工程，由于它没有被设计到结构化开发流程里。
·缺少开发活动的周期时间指导，致使项目进度不许确。
·因为没有将责任落实下来，致使未能不断地改进产品开发流程。

　　在PACE方法中，核心小组用结构化开发流程开发产品，这将确保一致性，并避免小组创立各自的流程。基于一个通用的结构化流程，就可使用通用的周期时间指南并为持续改进打下基础。

　　按照PACE的方法，一个结构化开发流程包括几个等级。在阶段评审流程所提供的框架中，通常有15—20个主要步骤来定义一个公司的产品开发流程；每一步又分红10—30项任务，规定每个步骤如何在公司里得以实施。这些任务又为每个步骤定义出标准周期时间，所以能够根据这些基本步骤编制进度表、预估资源需求、制定计划及进行管理。

　　每一项任务还可进一步细分红各类各样的开发活动。根据任务的性质，每一步骤的开发活动数量从几个到30或40个不等。总的来讲，各步骤与任务永远适用于各类项目，而开发活动则因项目不一样而不一样。