结构化的产品开发.doc
《结构化的产品开发.doc》由会员分享，可在线阅读，更多相关《结构化的产品开发.doc（14页珍藏版）》请在冰豆网上搜索。
第五章 结构化的产品开发
迈克尔·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％的时间全浪费在澄清关于正在做什么和由谁做的事情上。
另外，由于术语不一致，使产品的技术规范有四个不同的名称和两套定义。
我们在跨行业的许多公司中调查了好几百个从事产品开发的人，询问他们是
如何从结构化开发过程中有所获益，得到的结果非常有趣：
1．小组间的交接常常出现误解和混乱：
*在所有的交接任务中有30％引起了混淆和困惑，既浪费力气，又误导工
作，不一而足。
换句话说，如果一个项目有三件这种交接任务的话，至少有一件
肯定会是一团糟。
*有趣的是，22％的工作是在明知混淆和困惑的情况下放行的。
原因很多，
比如计划不周、执行仓促和纪律松驰等。
这已经够烦了，但还没完，接到手的工作中还有39％是混乱的。
在交接过程中，混乱的工作怎么会从22％增加到39％（相差17％，几乎是原来22％的两倍）呢？
这是因为开发过程中不同小组之间关系从根本上说被相互误解了。
换句话说，下游部门的需求未能被上游部门理解或欣赏。
例如，CAD（计算机辅助设计）部或许不了解生产部的物料清单上需要什么具体的信息和规格，于是就在把任务交接给搞糟了。
2．由于上游部门出现变化，例如反馈顾客要求太晚、技术规格有错或一些
问题被忽略等，造成42％的工作得重做。
于是，每五个工作日中有两个被浪费了！
如果消灭了重复性的工作，开发机构的生产率将会增加72％（有效工作从58％增加到100％）而不必增加任何人手。
3．至少有48％的开发工作是“救火”，即解决那些出其不意地冒出的必须
立刻加以解决的、无计划的工作。
“救火”式的解决办法往往是“贴药膏”，因
为时间压力大，资源有限，备选方案有限，而且许多设计已经不能更改了。
“救
火”式的工作方式是仓促完成的，常常有很多差错。
4．在开发人员个人制定的计划当中，有48％受到经理们或同级部门的质
询、怀疑、忽视或被经理们或同级部门否定掉。
由于产品开发本身是一个复杂的、
涉及多个部门的过程，整个项目的总体进度表是需大量低级进度表的综合而成
的。
然而，每两个进度表中就有一个被否决。
为什么会这样呢？
很可能是因为早
期的进度表只有45％是准确的！
既然早期的进度表常常不准确，因此根本没有人相信它们。
还有，管理人员常提出不合理的要求，开发小组就只好扩充进度表。
5．令人惊讶的是，只有28％的开发工作是全新的，也就是说，72％的工作
是熟悉的。
如果是这样，为什么上述的问题还出现呢？
因为没有结构化过程，没
能汲取教训。
把开发过程结构化是指把以前所做的72％的工作结构化，因为工
作流程不畅，阻碍重重，使项目难以进行下去。
一旦把这些工作条理化，开发小
组就能把精力集中到28％真正新的有创造性的工作上，这才是最具增值的部分。
这些调查结果表明，把开发过程结构化将会带来巨大的机会。
开发过程结构的要素
革新与创造是无法精确地计划和控制的，但是，把日常工作安排得井井有条
可使注意力集中到更有创造性的产品开发方面。
通常，在纯技术机构中，人们还
很关心开发过程的构架。
许多人把产品开发看作成一个创造性的过程。
不错，产
品开发的部分工作需要有所创新。
重要的是，一旦搞开发创造的人理解了开发过
程结构实际上是把他们从繁杂、单调的任务中解放了出来，使他们能将更多的时
间花在创造性的增值工作上。
例如，如果不让工程师们把时间花在确定某项功能
规范的纲要及格式上，他们就会很有效地把时间用在运用标准格式和定义产品
上。
许多人觉得结构把人限制住了，抱怨说它太死板，缺乏灵活性。
对此我们表
示同意。
错误的结构层次会造成大量的书面工作和官僚主义。
重要的是，应该针
对某种特定产品找到合适它的结构层次。
在与客户的初期交往中，常常听到这样的说法，“结构化开发过程在我们这
儿不会有用的，因为我们从来不重复同样的项目。
”这话绝对站不住脚，因为即
使完全不同的产品也一定有许多共同之处。
而且，如果每次产品开发采用的方式都不同，则会出现两种情况。
第一，没
有积累的经验可参考，没有应学习的榜样，所以当项目做得越来越大时，开发周
期时间也变得越来越长。
第二，当某个人拿出改进方法或窍门时，没有把它标准化并运用于其它项目中。
如果每次开发过程的步骤不是以同样方式进行，便很难衡量它的过程并加以改进。
许多技术人员对结构感到很不舒服，担心受到约束后，会失去灵活性和创造
性。
然而，如果真正理解了产品开发工作，就很容易明白其中大部分工作并不是
新的。
正如前面调查中所述的，大部分产品开发任务并不真正是新的。
如果将重复性的任务进行结构化，技术专家就能把更多的精力集中在真正新的，以前没有做过的工作上。
例如，一家做先进系统的公司，有一个高级技术员不相信产品开发能够结构
化，当问及她正在进行的新设计时，她最初的回答是，“这都是全新的”。
进一
步调查之后，我们发现，从硬件意义上讲，在五十六个电路板中，只有两个是新
的。
然后，在对这两块电路板逐个进行仔细观察后，她确认只有四个ASIC集
成电路和一些支持逻辑是新的。
还有另一家公司，是专为大的防御设施承包商设计预警系统的，错误地把产
品种类多和小批量生产作为成本超支与赶不上进度的借口。
这家公司认为，每个
项目是不同的，这种循环不可能调整过来。
一旦该公司明白，虽然项目可能是不
同的，但也有共同的过程因素，那么，它就能够将过程结构化，提高竞争力。
需要进一步结构化的征兆
公司需要进一步结构化的迹象有很多。
术语和定义不一致
每个公司都有它自己的产品开发语言。
不幸的是，这种语言太类似于巴贝尔塔的情形，即各人有各人的讲法，但都以为别人和他的理解是一样的。
工作的背景和范围由于一个项目间的术语不一致，人们就不能了解工作的背景和范围，在一家公司里，同一个市场评估文件有十个不同的名称。
每个版本都稍有不同，但是时间一长这些差异就变得比较模糊不清了。
最后，没有人能确切地知道这个文件该有些什么内容。
这种混乱导致了大量没有附加价值的活动，因为这些活动是用来理解当人们使用一个术语或说要完成一项任务时它们真正指的是什么。
进度表不准确
产品开发进度表应该和构成它的步骤一样准确，如果对步骤的理解不清楚，
那么就很难估计它们要用多长时间。
如果它的定义不一致，那么，就不可能用过
去的经验作为参考。
没有结构化的过程常常导致进度不准确，因为人们制定进度
表时依据的假设并不为该机构中的其他人所分享或了解。
没有进度表是进度表不
准确的极端现象。
无法估计出资源需求
对资源需求的估计必须和对完成每个步骤所需时间的估计一样准确。
对每个
步骤没有一个好的统一定义，就不可能作出合理的估计。
如果估计不准确，公司
新产品的开发就会连续不断地误期，其项目资源不是不够就是过量。
结构化有助
于首先确定必须做什么和花多长时间，一旦理解了这一点，就会大大提高对资源
需求的准确估计能力。
小组与小组之间的计划不衔接
如果没有结构，
升级会员 