05结构化产品开发.pdf

第五章 结构化产品开发 迈克尔·T ·安东尼 产品开发是复杂的。因为产品开发人员必须完成成千上万项工作，而这些工 作大部分是与他人工作紧密相关的，协调便成为极其复杂的工作。为了能管理好 这些庞大而复杂的工作，产品开发过程必须成为合理构架的、定义清楚的过程。 所谓结构化，是指这些相互关联的工作要有一个框架结构，并要有一定的组 织原则来支持它，比如，在一个自上而下的层次构架中，上层结构简单一些，越 到下层越繁杂越具体。所谓定义，是指每项工作都应清清楚楚地明确规定出来。 所有与产品开发有关的人应该清楚他们所参与的是什么工作，用什么方法去完 成。 尽管看起来简单，但令人惊讶的是许多公司并不能真正做到以上这些。在某 些公司中，这种产品开发过程仍然是无构架的，大部分工作也未清楚地定义出来。 在术语上没有一致性，即每个项目小组单独地确定自己的工作定义，尽管他们的 许多定义与其它项目小组相类似。结果，各小组的项目进度表不能互相比较 因为有的小组定义了20 项任务，有的小组却定义了1000 项任务。这样就无法一 致地衡量其进度，也不能用标准的周期时间估算方法来制定进度表。这对那些支 持多个项目的人来说就更困难。没有一个共用的构架，产品开发过程便很难得到 改进。 有些公司的作法完全相反，它们详细地定义了产品开发过程过于详细了。 为了控制每一细节，他们把每项工作应如何完成以及工作完成后应该是什么样子 都一一设定好。这种方法最典型的特点是以文档资料为基础；对每项任务都需要 准备一套详细编制的文档资料，并获得批准。每项任务的完成情况都受该文档的 准备情况和批准情况的控制。这种官僚的管理方法经常采用发布厚厚一本的规章 制度，并带有详细检验标准，规定这些项目应如何完成。幸运的是，多数情况下， 人们并没有真的这么做。按照他们这种做法，开发一个产品就要多花一倍的时间。 许多公司由于匆匆定义产品开发过程而忽略了对构架的需要。对有些公司来 讲，构架本身并不合适。不是层次定得不对，就是任务放错了位置；通常体现为 在太短的时间内需要太多的信息。 在PACE 中，结构化产品开发在原则和创造力之间达成一种平衡。一个深思 熟虑的过程并不会阻碍创造力，它允许开发小组把精力集中到开发产品这个实际 问题上，并不需要每次重新建立开发过程。 在PACE 中，开发活动是以一个层次结构来构架的：从阶段 （从最高和最广 的一级）到步骤，到任务，最后再到各项活动 （最具体的一级）。阶段对所有的 项目来说都是一样的。正如第三章中所述，这是第一个决策层次。步骤对所有的 项目也是一样的（虽然某些项目可能省略一些步骤），这是第一个制定计划和进 度表的层次。任务就某个步骤如何完成提供指导原则。如果合适的话，核心小组 可以按照这些执行。各项活动则完全由核心小组确定。这几点综合起来形成了一 个决策、项目进度制定、资源规划、过程衡量以及持续改进的基础。 开发过程需要结构和定义 由于多数公司没有把新产品开发视为一个过程，他们从不按照开发新产品的 需要给要做的工作下定义，甚至连基本术语也没定义，例如，每个项目包括一份 职责说明书。说明书的定义对参与项目的每一个人都应该清楚，而不应该被某个 工程师认为是一份10 页纸的小结，也不应该被另一个工程师看作一份60 页的文 件，更不应该被第三个工程师看作一份400 页的文件。 缺乏统一的术语导致大量的时间和精力被浪费掉了，因为使用这些晦涩难懂 过程的人极力想把它搞明白。通常，会议可能开了不少，但没有什么效果，开会 的目的只是了解目前进行的工作。诸如此类的时间浪费，完全是由于缺乏构架所 致。 例如，一家数据通信公司，由于缺乏结构化过程，不得不为进行中的开发工 作多花一倍的资源。根据调查，我们发现人们有30% 的时间实际花在了产品设计 上，而另外70%的时间全浪费在澄清关于正在做什么和由谁做的事情上。另外， 术语不一致，从而使产品的技术规范有四个不同的名称和两套定义。 我们在跨行业的许多公司中调查了好几百个从事产品开发的人，询问他们是 如何从结构化开发过程中有所获益，其结果非常有趣： 1. 小组间的交接常常出现误解和混乱： * 在所有的交接任务中有39%引起了混淆和困惑，结果浪费了力气，误导了 工作，等等。这意味着，如果一个项目有三件这种交接任务的话，至少有一件肯 定会是一团糟。 ● 有趣的是，22% 的工作是在明知混淆和困惑的情况下放走