结构化的产品开发doc171.docx

结构化的产品开发doc171.docx

《结构化的产品开发doc171.docx》由会员分享，可在线阅读，更多相关《结构化的产品开发doc171.docx（23页珍藏版）》请在冰豆网上搜索。

结构化的产品开发doc171

结构化的产品开发

产品开发是复杂的。

因为产品开发人员必须完成成千上万项工作，而这些工

作大部分是与他人工作紧密相关的，协调便成为极其复杂的工作。

为了能管理好

这些庞大而复杂的工作，产品开发过程必须成为结构合理、定义清楚的过程。

所谓结构化，是指相互关联的工作要有一个框架结构，并要有一定的组织原

则来支持它，比如，在一个自上而下的层次构架中，上层结构简单一些，越到下

层越繁杂越具体。

所谓定义，是指每项工作都应清楚楚地明确规定出来。

所有

与产品开发有关的人应该清楚他们所参与的是什么工作，用什么方法去完成。

尽管看起来简单，但令人惊讶的是许多公司并不能真正做到以上这些。

在某

些公司中，这种产品开发过程仍然是无结构的，大部分工作也未清楚地定义出

来。

在术语上没有一致性，即每个项目小组单独地确定自己的工作定义，尽管他

们的许多定义与其它项目小组相类似。

结果，各小组的项目进度表不能互相比

较，因为有的小组定义了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集

成电路和一些支持逻辑是新的。

还有另一家公司，是专为大的防御设施承包商设计预警系统的，错误地把产

品种类多和小批量生产作为成本超支与赶不上进度的借口。

这家公司认为，每个

项目是不同的，这种循环不可能调整过来。

一旦该公司明白，虽然项目可能是不

同的，但也有共同的过程因素，那么，它就能够将过程结构化，提高竞争力。

需要进一步结构化的征兆

公司需要进一步结构化的迹象有很多。

术语和定义不一致

每个公司都有它自己的产品开发语言。

不幸的是，这种语言太类似于巴贝尔塔的情形，即各人有各人的讲法，但都以为别人和他的理解是一样的。

工作的背景和范围由于一个项目间的术语不一致，人们就不能了解工作的背景和范围，在一家公司里，同一个市场评估文件有十个不同的名称。

每个版本都稍有不同，但是时间一长这些差异就变得比较模糊不清了。

最后，没有人能确切地知道这个文件该有些什么内容。

这种混乱导致了大量没有附加价值的活动，因为这些活动是用来理解当人们使用一个术语或说要完成一项任务时它们真正指的是什么。

进度表不准确

产品开发进度表应该和构成它的步骤一样准确，如果对步骤的理解不清楚，

那么就很难估计它们要用多长时间。

如果它的定义不一致，那么，就不可能用过

去的经验作为参考。

没有结构化的过程常常导致进度不准确，因为人们制定进度

表时依据的假设并不为该机构中的其他人所分享或了解。

没有进度表是进度表不

准确的极端现象。

无法估计出资源需求

对资源需求的估计必须和对完成每个步骤所需时间的估计一样准确。

对每个

步骤没有一个好的统一定义，就不可能作出合理的估计。

如果估计不准确，公司

新产品的开发就会连续不断地误期，其项目资源不是不够就是过量。

结构化有助

于首先确定必须做什么和花多长时间，一旦理解了这一点，就会大大提高对资源

需求的准确估计能力。

小组与小组之间的计划不衔接

如果没有结构，就没有做出重要决策的基础。

一个职能部门作的计划并不一

定和其它部门的工作衔接在一起，结果重要的工作给忽略了。

有一家缺乏结构的

电子系统公司因没有统一的构架，统一的术语，和统一的定义而饱受其苦。

结果，领导人员常常被具体细节搞得晕头转向。

每一个项目经理都提出不同的格式、过程和具体标准。

执行经理们一般见树不见林。

他们抓住不太重要的几点就作出决策。

没有从全局上搞清楚它们是如何联系在一起的。

如果没有结构，小组之间的计划协调事实上是不可能的。

因为每个人对必定出现什么样的情况都有不同的理解。

过量的任务间的相互依赖

当开发过程中的任务受到拖延或排队等候另一项任务完成时，就出现了过量

的任务相互依赖现象。

没有结构或结构差的过程就会导致这种大量浪费时间的现

象。

明确过程任务并对每个过程的要求作出定义可以大大地降低任务的相互依赖

性，这样，低成本工作就不会拖高成本工作的后腿。

对职责理解不够

结构差使人们不知道谁或哪个小组负责完成哪些具体工作。

对那些人们并不

能很好地了解重要任务的机构，PRTM常给它们提供咨询。

我们发现在一些人员

饱和的部门中，没有人确切知道这个部门在干什么。

这就是开发过程混乱和工作

职责不明晰的重要标志。

注意力集中在“救火”上

过量的“救火”工作是公司产品开发过程结构欠佳的征兆。

有一家电脑公司

向我们咨询，因为该公司陷入了"救火"的尴尬境地，执行经理热衷于跳将进来，

卷起袖子．帮助解决问题。

他们觉得，在危机间跳来蹦去，比为每个人制定策略

和目标舒服得多。

当执行经理要一个项目小组在每大上午八点和下午五点各做一

次一小时的最新进展汇报时，这种情况就达到了高潮。

每次状态跟踪汇报，小组

都得花一个小时做准备，这样每天就浪费了四个小时的有效工作时间。

开发产品没有一个“统一方法”

有一家电子影像业公司，它的每个项目都缺乏统一性。

对每个项目来说，开发新产品所遵循的步骤是在不同的地点和时间发生的。

许多工作都有不同的命名

方法，这样，即使是在该部门工作多年的人也难以理解正在干什么事。

结果，没有人利用己经开发出来的好方法。

过多的澄清会议

不良的结构过程导致了为澄清工作而召开大量会议。

因为下一个步骤模糊不

清，所以就要求这些会议要搞清楚已经完成了什么，下一步必须完成什么，以及

由谁来作。

过多的会议是不良结构的一种迹象。

中层管理人员太多

如果领导层必须做每一个决策时，就证明需要对新产品开发进行结构。

结构

化过程使人容易了解每个项目与整个产品系列计划的配合、和研究开发或技术策略的结合，以及它在财务上的合理性。

如果没有结构，就需要更多的中层管理人员来处理这种混乱状况。

在具有合适结构层次的一些公司里，中层人员就比较少，因为不需要他们来控制过程。

浪费在没有附加值的工作上的时间。

为了解释术语和意图，不得不做大量的没有附加值的工作。

这种工作量是非

常巨大的。

如果没有结构，沟通上的误解就会使人们把更多的时间花在协调工作

和重做已经完成的任务上。

一个将开发过程结构化了的系统公司就消除了过程中的一些空白（空白是指

所花费的没有给项目带来附加值的时间）。

结果这个公司就把新产品的周期时间

削减了百分之二十三。

一位负责工程的副总裁说，“这件事情的真正价值是我们

现在能够把省下来的时间和资源用在别的地方，使我们能够腾出时间和精力开发

更多的新产品。

”

到什么程度才够？

在对新产品开发进行结构化和定义的时候，通常情况下公司会处于某个极端

（见图5－l）。

如果没有结构化的和定义了的过程，开发工作就会失控。

每个人都忙碌地在周围跑来跑去，但没人有时间思考，而且人们的确不明白他们负责的项目那一小部分怎样与项目整体相衔接。

通常，文字记载的东西很少，高层管理人员必须把他的大部分时间用在与项目有关的“救火”工作上。

在另一极端，一些有着过度结构化过程的公司通常有两个系统。

第一个系统

的表现是：

每个人的书架上都摆着五磅重的开发笔记，领导认为这样的笔记用得

着；第二个系统的表现是：

人们遵循的真正的过程，因为五磅重的过程文件而变

得过于官僚化了，太慢了。

这些公司在定义许多产品开发过程细节方面做了一些

漂亮的工作，但是，由于过分结构化和定义太细，结果，什么都忽略了。

一方面需要具备可重复和可衡量的过程，另一方面需要对新思想和新方法采取灵活和开放的态度，正确的结构层划分可以平衡以上两个方面。

PACE通过提供适当层次的结构和在开发过程的适当时机定义步骤。

PACE实现了上述平衡，

这样，开发过程得到应用，并且可以适当地衡量和不断地改进。

结构化开发的层次

结构化产品开发是产品开发过程的一种层次性蓝图，统一适用于所有产品开

发项目。

在PACE内有四个层次的结构化开发，每一层都是前面一层的总结。

层次结构

PACE下面的结构开发包含四个层次：

阶段，步骤，任务和活动。

图5－2用图形方式说明了这些层次。

如图所示，一般有三至六个阶段，每个阶段里有多个步骤，每个步骤里有多重任务，每个任务里里有多重活动。

结构的最高层是阶段。

正如第三章所述，通常有三至六个阶段。

阶段的终点

是开发过程的里程碑，这时，要就下一阶段的资金拨付作出决策。

每个阶段都由

一些具体的步骤组成。

在结构化开发中，步骤是最重要的。

人们用它为开发活动制定进度表并控制

开发活动的进展情况。

大部分公司的开发过程中有十五到二十个步骤。

虽然某些

项目或许不包括所有的步骤，但是，步骤一直应用于所有项目。

例如，软件开发

步骤虽然在所有的项目中是一样的，但是，没有软件开发部分的项目就会省去这

个步骤。

步骤由多个任务组成。

一般说来，每个步骤有十二至三十五个任务。

一般说

来，如果没有非常合理的理由要作出改变，任务在各种项目中是一致的。

人们用

任务来计算标准周期时间及定义要做的工作。

完成任务是负责具体步骤的核心小

组成员的职责。

任务又可分成一定数量的活动。

每项任务的活动的数额从几个到上百个不

等。

它们是每个项目小组成员每天都在做的事。

与任务不同，活动常常因项目的

不同而有所变化，因为各个项目的实际工作划分可能是不同的。

项目概述

在高层次将开发过程结构化，首先得用一页纸概述一下从概念到批量生产的

整个开发过程。

这种高层次的概述勾勒出了开发过程的各个阶段，定义了开发过

程中的主要步骤，说明了不同步骤的并列情况、优先顺序，以及重叠情况。

根据PACE，产品开发的步骤被定义为通用结构化开发过程的一部分。

图5－3是典型的通用过程的一个例子。

针对一个特定公司，通用开发过程会有所改变，这取决于正在开发产品的类型、产品的目标市场、产品的复杂性、组织结构、文化以及从技术和销售角度来看，产品具有哪些特征。

通用结构是用来为每个项目定义出一个具体的项目概述。

项目概述清楚地划

分出产品开发的主要步骤和每个阶段结束时的阶段评估要点。

这时，对步骤进行

具体的估计，在概述上加上进度日期。

整个公司应该阅读和理解这个高层次的、一页纸的概述，它是项目的前景

图。

如果这个项目不能简简单单地浓缩在一页纸上，那么，项目的工作人员或管

理人员就不可能清楚地理解项目。

从行政管理人员到出道不久的设计人员，每个

人都应该明白过程中的各个步骤以及这些步骤如何完全协调相配。

步骤

在结构化过程中，步骤是最重要的一级。

这些步骤是进度安排的基础，是联

系阶段、具体任务和活动的纽带。

重要的是应对这些步骤恰当地进行定义。

如果

步骤定义不恰当，那么公司就不能大大缩短产品的上市时间。

对过程本身的定义

有可能制约产品开发活动，因为定义不当，对能导致过量的没有附加值的工作，

窒息并行工程和团队合作，或低效率地安排活动顺序。

例如，一个公司请一个有经验的工程师定义产品开发过程中的步骤。

定义完

成后，公司的CEO（首席执行官）下达指示，要求公司每个人都按定义好的步

骤办事。

他的初衷是缩短上市时间，但由于步骤定义不当，上市时间实际上延长了。

结构化开发过程的步骤应定义明确，应用不懈。

以职能部门的技术规范步骤

为例，每个人都应该知道部门技术规范包括什么，全面到什么程度，开发要花多

长时间，以及何时把它列入设计过程。

这已成为共用的术语，而重点可能在于执

行。

步骤界定了其实施过程中或结束时的预期结果，还有作为步骤一部分的评估

点，如设计评估等。

步骤应经常应用于所有的产品开发项目。

例如产品规格应该在进度表上的特

定时间作出，各个项目的规格范围和详尽程度都应相同。

这样，高层管理人员才

能够以作好的规格为依据，理解它的内容。

任务和活动

每个步骤由一定数目的任务组成，这些任务更具体地说明如何完成这一步

骤。

任务流不仅定义需要作什么，而且列出了先后的次序。

图5－4所示的是一个典型软件设计步骤中的一个任务流的范例。

开始时的任务是评估前一步骤对软件的要求，接下来的任务是完成和评估软件设计。

结构化软件开发中的任务层次也定义了开发的操作步骤。

这个软件设计范例

实施的是结构化的软件开发方法，实施的方法是，在模块设计之前，进行概要设

计并对设计进行评审。

这个例子表明，恰当的检测计划应与编码同时完成，而不

是在编码完成之后进行。

这样，公司就能实施更规范的产品开发方法，该方法要

求在编码之前设计己经完成并已评审完毕。

详细的开发指南

为了有效地利用产品开发学习经验，强调“怎样做”很重要。

例如，一个离

散半导体器件制造商有详细的作业指南，但只有最有经验的开发经理知道如何去

执行。

这家公司缺乏足够的高级管理人员帮助员工学习这一过程，导致发展受到

限制。

结果是高级经理们把他们的所有的时间花费在了开发上，而不是管理上。

开发过程的指南给公司带来许多益处，包括：

☐从多个项目中获取经验

☐增强主动性和前瞻性思维，反对出了事再“救火”的做法

☐建立过程检测和改进的出发点

☐根据过程的生产能力而不是根据对过程能力的推想来制定进度表

过程指南的意图是获得人们头脑中或文件柜中的现有知识。

如果利用指南实

施每个项目，那么人们很快就会找到进行产品开发的更好方法。

这些改进又可以

不断更新指南，以便使每个项目都能利用这些新方法。

这些指南有助于不断地获

得学识。

从开发伊始，核心小组就应该运用最新版本的指南作为计划项目的工具。

每

个小组成员应评估自己的指南，找出所有的潜在的问题或危险区域，然后把这些

反映在小组的开发计划中。

公司必须仔细考虑指南的类型，以及指南形成前所要求的详细程度。

开发指

南从简单的一页流程图和检测项到重要工作的详细说明，其类型和深度将取决于

公司的文化、产品的复杂性以及市场。

检验所有指南的方法很简单：

是否可被开发小组马上采用？

是否易于使用？

如果不是每个项目都运用这些指南，那么指南必须改变，因为人们最终会抛弃它们。

而当所有的项目都使用这些指南时，现有方法的问题和瓶颈会很快被发现。

如能一个一个地解决这些问题，将有助于公司在新产品开发方面迈向世界级水平。

结构化开发的进度表

很少有人怀疑制定产品开发进度表和根据此进度表管理开发活动的重要

性，但大部人并不喜欢进度表，也不知道如何成功地编制一个有用的进度表。

一个好的进度表对于抓住市场机遇非常重要。

它成为控制的焦点，也是与整个项

目小组进行沟通的手段。

制定产品开发进度表之所以困难有几方面的原因。

第一，有关开发的许多细

节未确定。

尽管如此，许多公司不等开发小组完成设计规范就催着各开发小组拿

出完工的日期。

一旦小组作出保证，即使它已经作出了种种假设，但领导班子往

往牢牢定住这个预计的日期，不理解为什么到后来，当项目范围进一步明确时，

预计的完工日期不能保证。

我们经常听到管理人员这样对项目小组说：

“你们怎

么还没开始，己经晚了八个星期了。

”

制定进度表困难的另一个原因是，当小组确实需要资源时，资源常常不能到

位。

时间就是这样在等待合适的人或工具时给浪费掉了。

最后，在问道：

你可以在某月某日前完成这项工作吗？

多数人的回答都非常

乐观。

并不是这些人先天不诚实，仅仅是因为我们大多数人在确定日期时，并没

有考虑自己的实际能力。

例如，如果开发人员的一个正常工作周有50个小时，

那么，以每周50个工作小时为基础编制进度表是不现实的，因为还要考虑假期。

病假、培训、管理任务、以及协助其它项目等所占用的时间。

编制进度表时应该

考虑这些因素，剩下的时间才是能用于新项目的时间。

三级进度表

产品开发已经变得非常复杂，已经不可能再由一个人来单独制定、管理和控

制开发项目的计划了。

关键路径法（CPM）和项目评审技术（PERT）等技术对产品开发来说是不够的。

开发从本质上来看是一种信息流，常常直到制造样机阶段才认识到其实体。

由于PERT和CPM等技术主要是为建立物理流而设的，它们对成功地控制产品开发来说是不够的。

PRTM开发出了专门用于产品开发的三级进度编制技术。

它把结构化开发作

为开发和管理进度的基础。

产品开发需要