《（产品管理）第二章PACE：产品及周期优化法的融合过程》由会员分享，可在线阅读，更多相关《（产品管理）第二章PACE：产品及周期优化法的融合过程（12页珍藏版）》请在金锄头文库上搜索。
1、第二章第二章 PACE 产品及周期优化法的融合过程 产品及周期优化法的融合过程 迈克尔 E 麦克哥拉斯 辛地 L 阿齐亚玛 目目 录录 1 1 产品开发过程的七要素 2 1 1 1 决策 2 1 1 2 项目小组构成 4 1 1 3 开发活动的结构 5 1 1 4 开发工具与技术 6 1 1 5 产品战略过程 7 1 1 6 技术管理 8 1 1 7 管道管理 9 1 2 PACE 系统结构 9 1 3 PACE 的独特方面 12 产品优势的唯一可持续源泉是优越的产品开发过程 以某项卓越设计 天 赐良机 对手的某个失策或某一次的幸运为基础的优势是不可能长久的 要长 期地不断地开发成功的产品 就
2、不能依赖这些因素 低劣的开发过程将依靠这 些因素而取得的优势在很短的时间内丧失殆尽 而优越的过程则始终能够发现 最佳的产品机遇 定义有竞争力的产品 并以更快的速度把这些新产品投入市 场 产品开发是一个过程 它主要将眼光放在顾客的需求和需要上 并把这种 需求和需要与公司的技术与技能结合起来 然后把机遇转化为产品 通常 对 一个公司开发的所有产品来说 其过程都是相似的 虽然产品各有不同 但项 目小组的构成 项目管理 决策 计划 以及许多具体步骤的实施方法是一致 的 事实上 不同公司的产品开发过程也具有很大程度的相似性 这种相似性使得产品开发过程可以进行规范 定义和管理 与其它商业过 程一样 你可以
3、设计一个高水平的过程 这样 就不需要每个项目小组再制定 自己的过程 然后 就可以投资来改进过程 使所有项目都能从中受益 最好 的实践经验可以应用于许多公司 而产品开发的总结构可根据每个公司的具体 情况具体分别予以制定 Pittiglio Rabin Todd McGrath PRTM 的产品及周期优化法 PACE 是一个为产品开发制作的过程参考模式 它是经过检验的 以广泛的经验和对 最佳实例的理解为基础的方法 PACE 将产品开发中的关键因素综合在一起 并解决许多现有产品开发过程的缺陷 1 1 产品开发过程的七要素产品开发过程的七要素 产品开发过程可以分为七个相关要素 每一要素都有其常见的不足
4、之处 PACE 提供各种方法 技巧和手段 供你用来克服每一项要素的不足之处 下文对这七个相关要素作了介绍 对一些常见的不足之处作了总结 并针对每 一个要素简单介绍了 PACE 的解决办法 在以后的章节里 再详述 PACE 的每 一要素 1 1 1 决策决策 所有的公司都有一个新产品决策过程 尽管他们有可能并没有认识到这是 一个有明确定义的过程 在决策过程薄弱的公司 因优柔寡断造成的延误很普 遍 例如 如果某个实际过程是顺序性的 要求许多经理一一确认某产品设计 概念的优劣 那么 起动延误就会发生 我们看到 许多良机的错失 只是因 为产品先驱们不知道如何运作这种不正规的决策过程 我们曾经协助过的一
5、家电脑公司有一个效率低下的决策过程 它是我们所 见到的许多过程当中的典型 在这家公司里 项目评审己沦为一系列面向不同 听众的冗长的汇报 参加的人很多 提出的问题也很多 但这些汇报会并不是 决策会议 没有在开发过程的适当时机给出项目评审以供决策之用 也没有拿 出适当的信息帮助决策 高层领导回避这些评审 同时 也没有其它机制来强 行做出适时决策 而且 并非所有明确定义的决策过程都是有效的 有明确定义的决策过程 也可能无效 有些过程要么设计得很糟糕 要么实施不当 在这种情况下 一 个正正规规的过程实际上对产品开发构成了一个管理障碍 这样的决策过程不 是推进产品开发的鼓点 而是花费大量时间去做但收效甚
6、微的工作 在我们的产品开发评审中 我们发现了因决策过程不当引发的下列问题 由于高层管理人员不知道应该由谁来做出决策或者需要什么样的一致意见 所以他无意识地延迟决策或修订决策 信息不足或细节不清楚导致决策质量低劣 没有及时解答正确合理的疑问 未定义决策控制点 以至在适当的重要阶段又出现了评审工作 资源投入过多 以至无法按期完成任何事情 受权审批和设定优先顺序的人没有明确批准给产品开发项目的拨付资金 决策太迟 经常是在产品已经设计出来之后 没有用周期指导来证实项目进度表 高层领导没有做出战略决策 却由开发人员在无奈中做出这种决策 在 PACE 过程中 新产品决策是通过阶段评审过程实施的 这种阶段评
7、审 需要在开发过程中一些具体定义点上做出决策 一个产品开发项目必须在预定 时间内达到明确定义的目标 才能获准进入下一阶段 产品审批委员会 PAC Product Audit Committee 是指在一个部门或一个 公司内负责主要新产品决策的高层领导小组 PAC 有权在开发周期内的具体决 策点通过给新产品拨付资金或修改新产品的途径来批准或拒绝新产品 PAC 负 责通过产品开发活动实施公司的战略 所以 具有资源分配权 以推进新产品 的开发 PAC 通过阶段评审过程来做出决策和分配资源 没有这样一个过程 高层 领导就几乎不可能有效地引导新产品的开发 然而 只有一个评审过程 或有 类似的一个过程 如
8、把关过程或阶段开发过程 是不够的 定义不清 实施不 当 或与开发过程中的其它必要要素不协调 都可能使评审过程效率低下 阶段评审过程在产品开发中还扮演另一个重要角色 通过它 PAC 可以直 接明了地授权项目小组分阶段地开发产品 项目小组为产品制定详细的建议 提交产品开发计划 并申请下一开发阶段所需的资源 如果 PAC 批准工作小组 的各项建议 它会赋予项目小组以权力 责任 以及实施小组计划的下一阶段 所需要的资源 1 1 2 项目小组构成项目小组构成 在评审中 我们发现 大多数公司有正规的项目小组 但多数并不成功 总的来说 这些项目小组的结构 角色和责任并没有明确的定义 结果 沟通 协调和决策便
9、显得效率低下 纷繁混乱 有这么一家很典型的公司 不计其数的经理们只在他们有空的时候或是有 什么特别原因使会议变得最优先的时候 他们才参加产品开发小组的会议 由 于这种方法产生的效果差 所以公司尝试用不同的方法来改变这种状况 他们 建立了项目管理部门 负责监督进度和参与问题 以明确由谁去做什么以及事 情做了没有 后来 每个部门都给每一个主要项目指定了自己部门的项目经理 但这些方法效果并不理想 只是增加了毫无价值的劳动 而这种劳动己经是太 多了 许多公司建立了项目小组的组织形式 但大多数效果不佳 对不成功的案 例 我们发现了以下典型原因 如果项目小组和职能部门的责权不明确 将造成困惑 项目小组没有
10、实权去实现目标 所以效率低 有时候 他们只被赋予责任 却没有相应的权力和资源 缺乏并行工程 一些职能和技能无法和谐地融入到项目小组的工作中去 项目领导工作效率低 这源于几个因素 项目领导人没有经验 对项目领 导人角色不明确 培训不足 项目领导人更换频繁 或者项目小组的组织有缺 陷 项目小组缺乏项目实施所需的人手和技能 因而无法实现目标 各种资源 在项目小组间调来换去 对于资源该调拨给哪个项目小组没有明确的决断 由于没有明确定义项目小组和职能部门之间的协作方法 两者之间便有冲 突和困扰 小组成员任务分配造成的困扰使整个小组效率低下 比如说 小组成员把 自己看作职能部门的评估者或记录者 而非真正地
11、帮助进行实时决策 项目小组的构成是产品开发过程的一个关键要素 一个高效的项目小组能 极大地增进沟通 协调和决策 在评审初期 我们就发现许多广为接受的项目 小组模式效率低下 而低下的原因与上文所述颇为相似 我们开发了一个新的 模式 这个模式既能发挥项目小组这种组织形式的最佳方面 又能克服上述缺陷 我们把它称之为项目小组构成中的核心小组模式 Core Team approach 核心小组是有权开发特定产品的一个小型跨部门项目小组 一个典型的核 心小组有五到八个成员 有权利也有责任管理所有与开发该特定产品相关的任 务 这些特定任务分配到核心小组的每个成员身上 每个成员都利用为该项目 服务的人员完成这
12、些任务 小组成员们对指定给他们的工作进行引导 与职能 部门打交道 并作为核心小组的一员集体做出决策 PAC 则在开发工作的每一 阶段通过阶段评审过程赋予核心小组人员责任和权力 每个核心小组都有一个 指导和引导小组工作的领导人 小组在执行每一开发阶段时遵守与 PAC 签订的 合同 该合同规定出重大项目目标以及可变动的范围 1 1 3 开发活动的结构开发活动的结构 开发活动是开发新产品的实质性工作 在 PACE 中 结构化的开发过程明 确了应做什么开发上作 相应的先后次序 其间的关联性 以及开发项目的标 准术语 在评审过程中 我们发现 开发活动的结构中有三种一般性的缺陷 1 没有任何明确的产品开发
13、结构的公司 2 有具体过程手册但并没得到 遵守的公司 以及 3 有结构化的过程但并不能改进或加快开发进度的公司 对第一种情况来说 公司必须在产品开发过程中不断地 重新发明车轮 即重新定义产品开发过程 每一个项目小组都定义它要遵循的过程 结果 不 同的项目小组即使在执行相同的或相似的任务时 开发方式也迥然不同 这种 模式延长了开发周期 整个公司的项目小组都易犯同样的错误 对第二种情况来说 过程被文档化了 但是并没有得到执行 典型的情况 是 某个职员在程序手册里定义开发过程 然后把手册散发出去 天真地期待 着每个人都会遵守它 结果当然是他们并不遵守 多数情况下 他们不遵守反 而好一点 项目小组又各
14、自将自己的那一套流程搬了出来 对于第三种情况来说 开发过程已得到明确和遵守 可惜这个过程天生就 效率低下 令人吃惊的是 许多公司在规范过程时 只是简单地将他们的现有 做法写成文件 哪怕这个过程效果差 结果是把问题制度化了 在评审开发过程时 我们发现普遍存在着下列缺陷 无章可循的开发活动导致产品不断更改 由于对必须完成什么样的开发活动及何时完成有误解 因而造成项项目计 划不周 及准备不足 缺乏通用术语以及由此引起的理解问题 导致开发工作不理想 产品开发定义过于详细 尤其是缺乏结构的定义 使得开发效率不高 每一步都有多个签字盖章的官僚过程延缓了开发工作 缺乏并行工程 因为它没有被设计到结构化开发过
15、程里 缺乏开发活动的周期时间指导 导致项目进度不准确 由于没有将责任落实下来 导致未能不断地改进产品开发过程 在 PACE 范围内 核心小组用结构化开发过程开发产品 这将确保一致性 并避免各小组创立各自的过程 一个通用的结构化过程也可以使用通用的周期 时间指南并为持续改进打下基础 按照 PACE 的方法 一个结构化开发过程包括几个等级 在阶段评审过程 所提供的框架中 一般有 15 到 20 个主要步骤来定义一个公司的产品开发过程 每一步又分成 10 到 30 项任务 规定每一步如何在公司里得以实施 这些任务 又为每一步骤定义出标准周期时间 因此可以根据这些基本步骤编制进度表 预估资源需求 制定
16、计划及进行管理 每一项任务还可进一步细分成各种各样的开发活动 根据任务的性质 每 一步骤的开发活动数量从几个到二十或四十个不等 总的来说 各步骤与任务 永远适用于各种项目 但开发活动则因项目不同而不同 1 1 4 开发工具与技术开发工具与技术 各种设计技术 例如质量功能布置 QFD 装配设计 DFA 和可制造 性设计 DFM 能促进产品成功并达到相应的运作效率 然而 这些技术中 没有哪一个能单独地解决产品开发的所有问题 举例来说 一个规模宏大 部门众多的高科技公司选择 QFD 作为其最终 的解决方案 公司投入巨资来培训全公司人员的设计技术 内部 QFD 专家和顾 问也培养出来传播其好处 九个月后 产品开发仍不见起色 项目小组也就解 散了 QFD 技术受到不公正的指责 因为人们期望有一项技术能弥补所缺乏的 整体综合方法 在过去的五年至十年中 许多新型自动设计工具己被开发出来 可以极大 地辅助产品开发过程 这些工具包括计算机辅助工程 CAE 面向对象的软件 开发工具 产品数据管理系统 模拟工具 以及用于项目计划 进度和决策的 工具 同样 也没有单独一种工具能提供一个完整解决办法 每种工具可
