结构化的产品开发.docx
《结构化的产品开发.docx》由会员分享，可在线阅读，更多相关《结构化的产品开发.docx（23页珍藏版）》请在冰豆网上搜索。
结构化的产品开发
结构化的产品开发
产品开发是复杂的。
由于产品开发人员必需完成不可胜数项任务，而这些工
作大局部是与他人任务严密相关的，协调便成为极端复杂的任务。
为了能管理好
这些庞大而复杂的任务，产品开发进程必需成为结构合理、定义清楚的进程。
所谓结构化，是指相互关联的任务要有一个框架结构，并要有一定的组织原
那么来支持它，比如，在一个自上而下的层次构架中，下层结构复杂一些，越到下
层越冗杂越详细。
所谓定义，是指每项任务都应清楚楚地明白规则出来。
一切
与产品开发有关的人应该清楚他们所参与的是什么任务，用什么方法去完成。
虽然看起来复杂，但令人惊讶的是许多公司并不能真正做到以上这些。
在某
些公司中，这种产品开发进程依然是无结构的，大局部任务也未清楚地定义出
来。
在术语上没有分歧性，即每个项目小组独自地确定自己的任务定义，虽然他
们的许多定义与其它项目小组相相似。
结果，各小组的项目进度表不能相互比
较，由于有的小组定义了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开收回了专门用于产品开发的三级进度编制技术。
它把结构化开发作
为开发和管理进度的基础。
产品开发需求信息在三个级别
升级会员 