《第五章 结构化的产品开发》.docVIP

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