统的六段式项目管理方法

1、文件类型：论坛分享存档编号： 发放范围：公 开 统一的六段式项目管理方法从经济学角度改进软件项目管理过程（作者：Ezra Thomad）摘要：软件工程程项目，归根到到底是一一种经济济生产活活动，它它应该遵遵循经济济的规律律，以更更趋近经济利利润和成成功满足足需求为为目标。软件项项目瀑布布、敏捷捷、螺旋旋、迭代代模型的纷纷乱，可可以借鉴鉴上千年年来人们们在建筑筑工程上上的经验验，使之之更规范范、科学学、有益益于项目目的成功。 将项项目管理理统一为为六个阶阶段，并并提出每每个阶段段的本质与与目标特特征，能能将建筑筑、软件件等所有有项目管管理统一一在一个个框架下下，更加加符合人人们的认认知和工工程项

2、目目管理的合理化化。 六段式管管理方法法，规避避风险、高效实实用、断断点清晰晰。系统的的分析与与设计独独立出来来，将会会成为软软件工程程项目的核核心，系系统分析析者职业业化是未未来软件件工程的的亟需和趋向。目录TOC o 1-2 h z u HYPERLINK l _Toc380857278 一、软件件工程项项目与建建筑项目目管理的的统一 PAGEREF _Toc380857278 h 22 HYPERLINK l _Toc380857279 二、统一一的六段段式项目目管理过过程 PAGEREF _Toc380857279 h 2 HYPERLINK l _Toc380857280 六阶段分分

3、别定义义、特征征、实践践注意点点 PAGEREF _Toc380857280 h 2 HYPERLINK l _Toc380857281 三、六段段式项目目管理与与传统方方法的对对比和优优势 PAGEREF _Toc380857281 h 7 HYPERLINK l _Toc380857282 六段式项项管与早早期分段段法、瀑瀑布模型型 PAGEREF _Toc380857282 h 7 HYPERLINK l _Toc380857283 六段式项项管与产产品迭代代模型 PAGEREF _Toc380857283 h 99 HYPERLINK l _Toc380857284 六段式项项管与RR

4、UP PAGEREF _Toc380857284 h 110 HYPERLINK l _Toc380857285 四、六段段式项目目管理与与常见问问题辨析析 PAGEREF _Toc380857285 h 12 HYPERLINK l _Toc380857286 六段式项项管与需需求变更更 PAGEREF _Toc380857286 h 12 HYPERLINK l _Toc380857287 六段式项项管与敏敏捷开发发 PAGEREF _Toc380857287 h 16 HYPERLINK l _Toc380857288 系统分析析师和软软件架构构师、PPdM和和PjMM PAGEREF

5、_Toc380857288 h 20 HYPERLINK l _Toc380857289 五、六段段式项目目管理规规范化 PAGEREF _Toc380857289 h 222 HYPERLINK l _Toc380857290 六、未来来软件工工程和系系统分析析之路 PAGEREF _Toc380857290 h 226一、软件件工程项项目与建建筑项目目管理的的统一软件工程程越来越越成为技技术发展展和现代代社会建建设的重重要支脉，随着着x80886、AARM等等通用硬硬件架构构的进一一步完善善，软件件工程甚甚至逐渐渐普及和和加强为为IT和和通信的的主要内内容和核核心驱动动力。 但但是，一一直

6、以来来，软件件工程都都缺乏一一种有效效公认统统一的管理方方法，使使得工程程高利润润、可控控制的顺顺利实现现目标。相反的的，经常常见到小小如APPP，大大到电网网集散控控制系统统，经常常不能完完美达到到用户需需求、预预算超支支、工程程延期等等问题甚甚至合同同违约或或项目失失败；与客户户理想的人机交交互不同同，更是屡屡见不鲜鲜。有没有一一种管理理方法可可以解决决？瀑布布模型、敏捷开开发、演演化模型型、RUUP和螺螺旋模型型，轮番番上阵，虽然都都在各个个领域取取得一些些效果和和有一些最最佳实践践，却始始终没有有一种被被证明绝绝对有效效、被人人们长期期公认科科学的项目管理理模型。由于曾曾负责建建筑工程

7、程的特殊殊经历，使我考考虑能不不能将建建筑工程程经验借借鉴； 或者将将建筑管管理与软软件工程程项目过过程相统统一。建建筑项目目是项目目，软件件项目，也是项项目，两两者绝不不仅仅只只名称相相同；有有“一次性性”目标性等许多多项目的共同特征征。项目目过程与标标准化生生产过程程不同，他的一一次性独独特性很很明显。经济中中除了生生产、就就是项目目；应该有有一个共共同框架架来统一项项目过程程。建筑项目目，俯拾拾皆是；国家的的建设如如火如荼荼，那么么多项目目，总有营营养汲取取。何况况中外建建筑史有有数千年年，中国国大型建建筑项目目也已经经有二千千年历史史，有许许多经验验。实际上上建筑业业早已形形成统一一的

8、规范的的过程模模式。一一般的，建筑过过程有规规划草图图和勘探探、设计计、土建建安装、监理验验收等多多个环节节，两相相类比，软件项项目缺少少一个独独立、明明显的设设计过程程； 设设计过程程往往被被前置到到需求交交流、或或以“详细设设计”名义实实际融入入开发过过程中了了。由于缺少少成型、明确的的设计， 使得得开发与与用户理理解有潜在差异异，成本本预估不不确切，开发变变更修改改反复进进行而工期延延迟， 这就就是导致致项目管管理最终终失控的的主要原原因。经过更详详细的分分析与研研究，和和对整个个项目过过程的对对比筹划划思考，尤其是是对项目目成败起起决定作作用的前前期过程程的不断断思辨，形成了了统一的的

9、六段式式项目管管理方法法。二、统一一的六段段式项目目管理过过程将软件工工程项目目管理过过程划分分为六个个阶段，并明确确其特征征和分隔隔点，在实践践中确定定有效。六阶段分分别定义义、特征征、实践践注意点点1、提案案阶段。由提议议人完成成，通常常是1-3人；这一阶阶段要：确定进进行之目的，明确项项目的初步范范围，确确定“做什么么”。完成时输出xxxx项项目建议议书，批准结结束。这这个过程程非常快快，通常常1天或或几天内内迅速完完成，或或不断讨讨论逐步步形成定定案；这这个阶段段花费在在总成本本中不超超过1%2%。在实践中中，由产品品经理提提出，或或有时直直接由老老板口述述指定。由于此此阶段短短促，经

10、经常见到到这个过过程被省省略，或或不形成成定议文案案。但实实际上，这是不不对的，必须坚坚决反对对。有些些项目彻彻底超出出预算，实质就就是变更更巨大，甚或完完全推翻翻，以致致漫无目目的地发散，自自己搞不不清最初初的目标标了。这是一个个必须经经由的阶阶段，而而且必须须形成正正式文档档，经过过评议并并保存。对于一一个创新性性项目，须要适适当详细细的建议议书，以以明确大大致范围围；对于产产品化的的项目，每个项项目只是是产品演演进发展展的一阶阶段，建建议书可可以简明明扼要，明确当当前版本本要达到到的主要要目的目目标即可可。甚至可可以一页页纸 但但这一阶阶段不可可或缺，尤其涉涉及变更更时；这也也是帮助助管

11、理者者，厘清清思路，明确优优先次序序的过程程。2、调研研阶段。由筹备备小组完完成， 这一阶阶段要：确定项项目整体体是否可可行，筹筹备所需需人力、资财，组建核核心团队队，解决“能否做做”。完成成时要输输出可可行性分分析报告告立立项申请请书，通过了了评审，正式批批准是阶阶段结束束标志，有有时称“立项阶阶段”。这个个阶段花花费在总总成本中中通常不不到5%。实践中一一些软件件项目还还没有明明显的立项过过程；但但是，厂厂矿、建建设项目目可行性性研究明明显，有有人认为为软件项项目不涉涉及环评评、土地地、审批批等不需需可行性性研究；其实是是没有理理解，可可行性研研究的核核心在于于，理清清实施的的主体架架构、

12、主主要步骤骤、核心心内容。主体架架构决定定整个走走向，主主要步骤骤是资源源运筹大大方向，两者确确定是否否可行，他们确确定以后后才谈到到如何实实施和可可行性。建筑项项目中，这个阶阶段会画画出规划划草图、进行勘勘探以确确定设计计参数和和可行性性等。因因此，设设计并不不是从设设计阶段段开始、而是总总体设计计在提案、调研阶阶段即开开始，在在设计阶阶段细化化和完善善、完成成。立项项基于可可行性分分析，可可行基于于架构和步步骤。可行性报报告，通通常包括括政策可行行性、经济可可行性、技术可可行性、法律、环境、可持续续性等部分。但重点点是技术术、经济济可行性性，对软软件项目目而言尤尤其如此此。软件件项目可可以

13、省略略不必要要的可行行分析部部分，只只重点描描述技术术实现方方案、经经济可行行；一些些产品化化的项目目，甚至至可以将将可行报报告合并并在立项项确认书书中，甚甚至可以不须计计算经济济可行性性（完全全产品化化的软件件收入估估算复杂杂），只只需明确确技术实实现方案案、和市市场用户户（竞争争对手优优势）预预估。立项申申请书中，应应载明当当前版本本的主要要任务、整体范围围界定、实施成成本及人力预估估、工期期安排和和估算，有些还还需要附附带测试试验收标标准。立立项申请请应在批批准确认认后，以以文本形形式备档档，作为为后期变变更的基基准线和和管理考考核、项项目考评评的依据据。需要强调调说明，设计、测试、框架

14、开开发等专专项工作作，并非非仅在其其名义阶阶段上进进行；实实际上，他们是是渗透在在各个阶阶段上进进行的。比如，设计在在提案阶阶段就已已经有大大致范围围和初步步架构，在调研研阶段设设计主体体架构，在设计计阶段完完成详细细设计和和明确；与一般般理解不不同，设设计（已已经评审审和批准准）在实实施阶段段仍在继继续，包包括尚未未完成的的一部分分设计（一部分分先通过过评审的的需求先先实施）、对实实施中发发现不清清晰、不合适适的进行行细化设设计和补补充设计计、因变变更引起起的重新新设计。再如，开发可可能在提提案前已已经有现现成组件件、中间间件或构构件，在在调研等等阶段预预进行一一些核心心和长周周期的开开发，

15、设设计阶段段甚至进进行一些些部分已已确认的的细节开开发。再再如更明明显更为为大家熟熟知：测测试中的的单元测测试，实际是是在开发发阶段完完成的，而不是是在验收收阶段；验收只只是系统统测试和和性能测测试。所以这与与直接的表面理理解不同同，在RRUP模模型出现现之后，业界普普遍认同同了不同同工作的的进行时时间是互互相叠合合的，因因此，必必须首先先理解一一项工作作内容，并非仅仅在其名名义阶段段上进行行；划分分阶段的的名称只只是当前前阶段的的主要工工作、核心工工作，而而不是全全部工作作或纯粹粹工作。RUPP的四个个阶段都都分别含含有不同同比例的的分析、架构、设计、实施工工作内容容，而不不是在设设计阶段段

16、只做设设计、实实施阶段段只做开开发，这这些工作作是不同同子团队队并行推推进的，而不是是串行进进行由同同一团队队完成。下图描描绘了在在RUPP 中，不同工工作在项项目时间间轴推进进中不同同阶段的的工作数数量。图1另外说明明，这个个阶段的的工作是是由筹备备小组完完成，这这在工程程、厂矿矿中很常常见，软件项项目中较较少见，实际上上是筹备备组是隐隐式存在在的，只只是未使使用名称称，人员员可能分散散并行着着多个项项目。软件项项目中，通常可可以虚拟拟组成，人员可可以由不不同部门门员工虚虚拟组成成团队，员工可可以同时时存在多多个项目目的筹备备组中，少量需需要实设设组织架架构。筹筹备组并并非是单单一的分析师师

17、和项目目管理者者组成，而而是发起起者、分分析师、面向开开发的架架构师、界面美美工、几几个程序序员甚至至测试共共同组成成的混合合团队；立项后后，分别别面向不不同子工工作团队队，成为为其不同同层级的的骨干。当立项项申请获获批，项项目即得得到了资资源、财财务的支持，人力投投入认可可，筹备备组即转转化为项项目组，其成本本自然进进入项目目成本。非立项项筹备成成本是可可施行性比率率下合理理的沉没没成本。有时这这过程也也称“立项阶阶段”，但调调研更确确切描述述阶段的的本质。3、设计计阶段。由分析设设计人员员完成，有时是规范的产品团团队；这一阶阶段要：确定项项目完成成最终实实现的目目标，软软件成品品的详细细描

18、述，包括系系统交互互、状态态变化和和处理逻逻辑、数数据和部部署等。即解决决“做成什么样”。完成成时要输输出需需求规格格说明书书，并并通过三三方评审审。这个个阶段时时间占到到总过程程30%，但成本本仅占115%。当前，在在许多软软件项目目实践中中，这一一阶段都都不明显显，甚或或消失。这导致致开发承承担者、与使用用用户（需求方方）对成成型后成成果，有有显著理理解差异异；并最最终导致致开发人人员对工工程量无无法确切切评估（实际上上，出于于赢得好好感，多多数都倾倾向评估估或给出出较短的的数字），和实施施后又反反复修改改成品导导致延期期和超支支。在建建筑项目目中，这这阶段是是由专业业的“建筑设设计院”、

19、专业业建筑师师和结构构师完成成，并以以出图（蓝色图图）为基基础，设设计中都都遵循严严格的设设计规范范、支撑撑结构原原则、公公认范例例等规则则（当然然也是受受建筑安安全国家家法律限限制）。与建筑筑一样，设计阶阶段将逐逐步独立立出来和和更加规规范。一一些项目目，由于于甲方领领导无经经验，又又重视细细节，反反而自然然而然的的要求进进行了图图形界面面设计或或demmo演示示。在实践中中，有些些项目有有设计，但是仍仍然导致致承建方方无法实实施、或或项目彻彻底失败败。是因因为设计计没有建建立在系系统分析析之上，设计没没有基础础。我们们经常讲讲OOAA/OOOD（oobjeect oriientted an

20、aalyssis/dessignn），可可以发现现这两个个词都是是一起出出现；分析是是设计的的前提，设计是是分析的的结果输输出；两两者异常常紧密，之间完完全映射射而不是是须要沟通，两两者合而而为一才才是最高效和和合理的的，分析析者即是是设计者者。只有面面向系统统的分析析-需需求分析析，才能能导致可可实现的的、最佳佳成本和和高体验验的设计计。分析析师需要要一定的的进入门门槛和如如建筑设设计师的的专业素素质，以以确保设设计是基基于合理理可靠的的分析，面向系系统实现现和用户户的。需求规规格说明明书（Sofftwaare Reqquirremeentss Sppeciificcatiionss），有时

21、时也笼统统的称为为需求求描述，实际际上需求求规格说说明书，有非常常规范的的写法；其中，包括明明细的用用例，“一图顶顶千言”的界面面，对象的的状态变变化等。以用例例分析系系统，以以用例引引领用户户活动，活动确确认交互互，把界界面作为为UMLL9图的的补充；状态和和时序确确定逻辑辑。与传传统不同同，我们们强调设设计输出出是以“图”为主要要表现方方式，辅辅以文字字说明，这更像像建筑业业的图纸纸，实际际上所有有工程都都应该是是以图为为指导的的。图的表表达方式式，更直直观、信信息量更更大、更更容易清清晰。要注意意，在产产品化大大规模的的项目中中，SRRS并不不是一份份文档；而是几几个文档档组成的的一个文

22、文档组，由许多多分析师师协作完完成，每每人负责责一定模模块或模模组，由由一个总总体说明明文档统统领；对对产品化化的，总总体文档档会说明明下一版版本开发发任务的的主要内内容、组组成文档档、基线线版本。*注曾有个阶阶段，业业界认为为软件模模型应该该每个阶阶段成果果，逐步步逐层映映射到最最终成品品，因此此设计应应该越详详细越好好；至今今仍有不不明真相相者这样样想。现现实中，也见到到在设计计阶段即即过分追追究视觉觉细节、追求设设计与开开发的映映射；甚甚至有尝尝试将UUML直直接映射射为代码码，而这这些项目目都失败败了。实实际上设计阶阶段的主主要目标标，是在在最小成成本下明明确成品品做成什什么样；这可以

23、以消除需需求方与与开发者者之间理理解差异异，开发发者内部部之间理理解差异异（包括括有子团团队的大大项目），清晰晰项目目目标成果果，并在在清晰全全部成果果后详细细估算成成本，检检验可实实现性。当然，更详细细设计稿稿更好，但这一一阶段的的成本需需要严格格控制在在总成本本的155%不超超过200%，否否则会挤挤占开发发成本，就会出出现设计计得很好好，做出出来却差差距很大大，而且且浪费时时间进度度。设计计输出要要重新修修正立项项时确定定的开发发成本，使逼近近20%内，并并在通过过三方评评审后确确立。4、实施施阶段。主要由实施、开发团团队完成成， 这这一阶段段是主要要承担项项目实施施、开发发完成的的阶段

24、；也是资资金成本本投入最最密集的的阶段，通常占占总成本本60%-700%，有有时也称称开发阶阶段。在这个个过程中中，要解解决“怎么做做”；在调研研阶段，我们解解决“能否做做”时，实际际上已经经讨论怎怎么做的的主体思思路；但但具体每每个单元元怎么做做并未涉涉及，此此阶段进进行中会会解决。除输出出成品，为确保保实施阶阶段的，可控、可督促促、管理理的及时时和有效效，应该该输出定期期项目实实施报告告和实实施日志志。实践中，有很多多项目是是外包单单位实施施完成；这时对对需求求规格说说明书和两个个输出文文档就显显得尤为为重要。需求描描述是开开发的基基础，当当有良好好的需求求描述时时就可以以将整个个开发实实

25、施阶段段外包，如建筑筑业做法法一样；而实施施报告和和实施日日志则是是实施过过程中的的保障，以确保保进度、质量合合乎项目目的规划划，成本本在可控控预算内内。两者者区分在在于报告告是用于于管控的的，日志志是用于于清查的的。虽然然我们希希望报告告督促开开发实施施的勤恳恳，但并并不是越越多越好好。实施施组对管管理层的的开发报报告，每每周一次次即可；开发日日志可以以每天记记，但不不须详细细、也不不须每人人记，一一个小组组有一份份日志即即可，简简单数语语扼要即即好。如如要确保保人人进进度，可可日例会会轮流口口头汇报报进度。5、验收收阶段。由测试、验收团团队完成成，这一一阶段要要：确定定项目是是否达成成目标

26、，是否达到到预期可可正常运运作，和和结束实实施。完完成时要要输出系统测测试报告告和验收报报告。这个阶阶段花费费在总成成本中通通常在10%内，时间间占155%左右右。理论上讲讲，验收收报告 通常由由所有方方出具，或由独立的的第三方方出具（以确保保、公正正），验收应应该是全全面的、详细的的检测；系统测测试和性性能测试试是由测测试团队队完成，独立的的过程。但实践践上，由由于甲方方的强势势、和减减少重复复劳动及及成本分分担的考考虑，通通常会与与系统测测试合并并，这样样只需要要一份系系统测试试报告，和一个个简明扼扼要验收收报告。当这样样做时，应注意意验收测测试并不不是完全全消失了了，验收收只做，核心功功

27、能和应应用活动动流程的的测试，而不需需要重复复ST中中每一步步骤、细细节；这是两两个互相相独立的的工作，ST的的是测试试团队，验收则则可由产产品团队队代表所所有方实实施，不不能因合合并而完完全依赖赖单一SST，保保证制衡衡与复核核。这样通通常可以以有效控控制成本本在100%。这样做做原因，同样是是基于软软件研发发也是一一项经济济活动，我们不不是为做做而做，而是为为了更好好、更有有效率的的改造世世界，美美化人们的的生活。有些公司司很重视视测试，把测试试作为一一个重要要的关卡卡和检验验标志，这是好好事。但但是要注注意软件件的质量量是开发发出来的的，甚至至是设计计出来的的，而不不是测试试出来的的。这

28、里说说明，单单元测试试和中间间集成测测试是由由开发为为主和测测试组共共同完成成，且在在开发实实施阶段段做；而而系统测测试报告告和性能能测试则则由测试试团队完完成。一一些无明明确要求求的项目目，可以以减省或或模糊地地施行压压力测试试和负载载测试。6、维护护阶段。每一个个项目，实际上上都涉及及到项目目结束后后的持续续维护问问题。虽虽然维护护过程或或显著、或微弱弱；实际际上都存存在。如如MS winndowws xxp一直直在打必必要补丁丁；teenceent微微信软件件，一些些小版本本是维护护更新；有些项项目完成成后虽几几乎不牵牵扯，但但必要的的严重bbug仍仍需修正正。因此此是必要要的阶段段。其

29、实实，建筑筑也一样样，验收收交付后后，仍会会存在漏漏水、裂裂缝空鼓鼓等，进进行修补补、后续续维护是是必要的的、合理理的步骤骤。维护护阶段的的成本，通常不不会计入入项目成成本预算算；这是是因为维维护时长长、难度度都弹性性很大，无法预预估或高高值掩盖盖开发成成本。一旦验收收合格，理论上上后续成成本都应应另计为为维护成成本，因因此许多多项目会会预留一一年质保保期和质质保金，这部分分可作为为第一年年维护成成本。建建筑项目目的维护护约在总开发成成本5%，系统统集成项项目通常常包括一一些软件件的改进进而不仅是安装部部署成本本，属于于新需求求开发，因此有有可能110%/年。维维护团队队通常由由原开发发团队兼

30、兼任，注注意产品品化项目目存在上上一版本本维护，和新版版本开发发两个相相关任务务，日常常性运行行维运则则可以组组织专职职团队。维护阶段段不包含含在项目目预算范范围，并并不表示示维护阶阶段是可可有可无无的，或或是独立立于项目目外的；应该必必须认识识到维护护是必然然存在，和作为为项目自自然延伸伸和整体体的组成成部分，是项目目本身价价值体现现。项目过程程中，实实施、验验收、维维护阶段段的管理理已经在在实践中中有较成成型规范范，而前前期阶段段则相对对混乱；尤其是是，前期期阶段是是决定项项目成败败的关键键。因此此前三阶阶段是重重点，投投入单人人密度也较高。三、六段段式项目目管理与与传统方方法的对对比和优

31、优势 六段式式项目管管理方法法，与传传统的软软件开发发模型和和方法相相比，有有什么优优势和改改进呢六段式项项管与早早期分段段法、瀑瀑布模型型在上世纪纪90年年代，软软件开发发通常分分为：需求分析析、总体设设计、详细设设计、编码、测试和验收等阶阶段；就就是传统统的瀑布布模型。如下图图（缺图22）现存大多多数模型型，都从从瀑布模模型发展展演变而而来，六六段式也也不例外外；那么么相比瀑瀑布模型型有什么么优势呢呢？回答答这问题题，要从从更早期期的软件件开发说说起。在在电子软软件渡过过五六十十年代的的蒙昧期后后，整个个70年年代多数数软件，都是为为了软件编编译、科科研计算算、数据据处理和显显示而发发展的

32、，显然这这些软件件的使用用者几乎乎就是开开发者，所以不不存在需需求方和和开发方方分离的的状况；一方面面这些使使用者都都是有极极客倾向向的专业人人士，对对非图形形界面和和苛刻交交互都是是高手，没有客客户体验验概念，他们深刻刻了解系系统；另另一方面面，开发发者直接接了解应应用情景景（usse sscennariio），理解使使用的目的。这个时期期的团队队也较简简单，有有时甚至至是一个个人独立立开发，一般团团队可能能5-88人，少则则2-33人，最最大的团团队也不不过十几几人。软软件非常常重视性性能和资资源耗用， 团队成成员都是是从独立地开发软件件成长起起来的，能独立立负担软软件过程程中任何何阶段；

33、 由于于人少，也可以以集体参参观使用用环境，了解用用户需求求。因此此，从设计到到编码都都是同一一组人在在做，不不存在专专业分工工。这情情况一直直持续到到80年年代早期期。而现在在的软件件业界，发生了了质的变变化。首先，硬硬件快速速发展，性能和和资源占占用不再再是第一一位的，软件的的体验和和可用性性，代替替性能和和可处理理性成为为重点，编译器器进步、Pythhon语语言等的的发展，对编码码的质量量要求有有所降低低。 其其次，软软件从面面向信息息业界和和极客，迅速扩扩展到各各行各业，面向向几乎全全社会用用户；而而行业也也深入到到开发者者完全不不熟悉不不理解、甚至不不清楚具具体使用用的领域域，及有些

34、日日常难得得一见的非非常专业业的领域，开开发者无无法再自自然地理理解需求求； 880年代代以来GGUI取取代旧界界面，系系统的作用更更倾向业业务应用用、引导导、交互互而不是是单纯地处处理运算算，可用性性和用户户体验提提高到前前所未有有的高度度。 同同时，这这种情况况下的行行业跨越越发展，大量新新手涌入入，短时间间内他们们来不及及从始至至终了解解每一个个开发环环节、了了解用户户使用情情景和真真实需求求，多数数都为某某一专业业具体工工作而培培养，而而不再是是初期基基础牢固固的全面面型人才才；工作作分工职职业也越越来越细细越专业业化。在早期期的团队队中，成成员统称称系统工工程师，并无系系统分析析师、

35、系系统架构构师、测测试专家家之分，现在则则不同。 数十十、数百百人的项项目团队队，须要要更有组组织化；调研需需求再也也不能集集体到现现场，高效化化的结果果是，委委派几位位需求分分析师调调研用户户需求；沟通传传递需求求的方式再再不是反反复开会会讨论，而是高高效的专专业分析析，和形形成文档档由开发发者随时时查阅。这样一一来项目目团队变变得分工工更专业业，更加加有机层层次。软件早期期和瀑布布模型时时代，由于开开发团队队强大的的可适应应性，和和集体同同步工作作，软件件可以从从需求、转变为为系统设设计、逐逐级替代代为代码码，形成成顺序的的流程，如同一一个直流流而下的的瀑布。而现在在，需要要人员专专职于自

36、自己的分分工，多多个子工工作并行行的推进进，互相相协作完完成。因因此，六六段式项项目管理理方法更更加适应应大规模模、高效效率的现现代项目目开发。六段式项项管与产产品迭代代模型软件产品品发展到到现在，涌现许许多模型型，其中中迭代模型型是最成成功的模模型之一一。因为为迭代模型型符合了了自由软软件的思想，让软件件充分地地复用，和更优优化、更更具体验验、更先先进。在在冯诺依依曼程序序存储思思想下，硬件通通用后软软件具有有几乎无无成本复复制生产产的优势势。 当当人们通通过一个个项目开开发了一一款好软软件后，希望充充分复用用之， 而不是是不同用用户重新新成立项项目组进进行重复复的开发；同时，人们还还希望软

37、软件在原原有的基基础上，不断的的改进、更新，使具备备更多功功能、可可用性和和更优秀秀的体验验。这大大幅地节省整整个社会会的成本本、提高高软件质质量和可可用性。这时，许多软软件开始始产品化化，比如如MS offficee， PPhottoshhop，Donnaldd的TeeX、一一些ERRP系统统等。软软件公司司对一个个软件在在前次版版本基础础上，做做新的需需求规划划、立项项、系统统分析设设计、开开发、测测试；产产品上市市后又开开始新一一轮需求求规划，周而复复始。迭迭代模型型就在这这种背景景下得到到认可。软件的产产品化，极大的的推动软软件业进进步和社社会的发发展。但但应该了了解，每每一个软软件版

38、本本，是经经过了立立项进行行开发的的，是一一个独立立的软件件项目，而不能能将软件件不断发发展演进进过程，视为一一个大项项目。只只有把这这大“项目”拆解成成一个一一个小独独立过程程，我们们才能对对其中阶阶段进行行标准化化、把项项目管理理演变成成一个科科学、标标准、可可控的方方法；否否则，复复杂庞大大的大项项目没有有纯粹共共同点，我们无无法提炼炼其中的的规律，项目管管理就变变成一个个人治的的、主观观的、失失控的过过程。这这也是分分析、分分解的基基本思想想。当我我们视为为一个个个独立版版本的项项目过程程后，就就发现周周而复始始的螺旋旋上升，就是一一个一个个软件需需求项目目的首尾尾相接，不断上上升发展

39、展的过程程。谈到软件件的持续续开发和和多个项项目交替替，可能就就会想到到，由于于项目团团队成员员的分工工专业化化，虽然然不同子子工作之之间有并并行推进进、和时时间重叠叠；但在在不同阶阶段仍然然造成大大量人力力闲置和和浪费。如在实实施阶段段，主要要是开发发人员在在工作，测试和和分析设设计人员员是较空空闲的。 这样样会导致致整个社社会成本本的增高高，即使使通过报报价弥补补了这部部分成本本，也仍仍造成人人力的浪浪费。 因此，实践上上，成熟熟的软件件团队，一般都都是同时时负担22个项目目或软件件版本，或3-4个项项目。比比如甲团团队，正正在编码码开发某软软件3.11版版本，同同时在调调研、设设计软件件

40、的3.20版版本；再再如乙团团队，正正在设计计的是水水电DCCS系统统，同时时进行着着某企业业erpp系统的的测试和和bugg修改。因此，一一个产品品化软件件的生命命周期过过程，是是由一个个个独立立开发项项目组成成，这样样才具有有一次性性、目标标性等项项目的典典型特征征；才是是标准化化、可科科学管理理和提高高效率成成功率的的项目。产品化化的软件件，每一一个新特特性版本本都应该该立项，以确定定市场目目标和投投入，按按标准项项目过程程操作，提高资资金使用用效率、人力使使用效率率。对每每一个版版本项目目，应该该进行投投入效益益的考核核，和总总结反思思，效益益不仅是是收入、利润的的经济指指标，也也要包

41、括括：活跃用用户数、用户体体验、竞竞争对手手差距等等。产品品化，才才是软件件行业的的主流，由于软软件复制制几乎无无成本，一个好好的软件件在跟普通通质量的的软件市场场竞争中中，价格格、产品品都处于于绝对优优势，更更何况差差的软件件。很多软软件如OOS、通通用APPP都会会形成几几家独大大，普通通研发项项目几乎乎无法生生存，产产品化才才是软件件业未来。另外还要要说明，软件开开发是一一个项目目，软件件的安装装部署也也是一个个独立的的项目；而不能能将两者者混淆。软件部部署也同同样有调调研、设设计、实实施、验验收的过过程；只只是部署署项目通通常很小小，过程程被微缩缩了。比比如，某某erpp产品部部署项目

42、目，部署署目标很很明确，所以提提案即是是某软件件的安装装部署；调研是是试安装装、调试试的过程程；经过尝尝试确定定了在oonliine环环境中正正式安装装的步骤骤、次序序、人员分分工/机机器分布布、失败预预案，就就是对安安装过程程的设计计；正式安安装就是实施施；完成成后应该该进行测测试检验验，作为为验收；后续发发现遗漏漏还需维维护。顺顺便说明明一点，部署也也是项目目，建筑筑也是项项目，因因此我们们把主要要核心过过程的名称定定为“实施”而不是是“开发”。但对于于大型的的设备的的部署安安装项目目，如大大型水电电机组安安装，则则有很明明显的六六个阶段段过程。安装项项目，与与机组制制造、系统开发发，是两

43、两个独立立的项目目过程。六段式项项管与RRUP细心读者者可能发发现，六六段式管管理，与与RUPP具有非非常多的的相似之之处，那那么为什什么还要要再发展展六段式式管理，与RUUP相比比有什么么优势和和区别。六段式式项目管管理方法法的发现现很早且且是独立立的，并并没有参参考RUUP的过过程。首首先说，RUPP是众多多工程师师的实践践结晶和和经验总总结，并并由Raatioonall（IBBM收购购）最先先发布推推广，是是各模式式的发展和软软件开发发经验的的集成；两者相相似只是“智谋之之士，所所见略同同”的必然。RUPP明确认认识了各各个阶段段中不同同种工作作并存，率先将将概设详详设等从从开发实实施中

44、独独立出来来建立了了对应“设计”的细化化过程，建立了了循环的的四段过过程对软软件不朽朽贡献，对行业业产生重重大影响响；六段式式方法在在发展过过程中也也参考学学习了RRUP过过程；从从这个意意义上说说，六段段式方法法是对RRUP的的发展和和演进。那么，六段式式管理与与RUPP 有哪哪些不同同：1、六段段式管理理重新整整理了初初始阶段段的过程程，根据据不同本本质，对对项目成成本至关关重要的的前期阶阶段，进进行了更更细化、规范化化的整理理。RUUP 有有四个过过程，IInceeptiion（初始）、Ellaboorattionn （细细化）、Connstrructtionn（实施施）、TTranns

45、ittionn（交付付）阶段段；其中中Connstrructtionn阶段就就是六段段式的【实施阶阶段】，有时时称【构构建阶段段】，TTrannsittionn阶段对对应于【验收阶阶段】，细化大大致相当当于【设设计阶段段】。对对于初始始的Inncepptioon阶段段RUPP描述非非常模糊糊，我们们把提案案独立出出来，以以最快明明确项目目的主要要目的和和大致范范围，并并要形成成文档，避免漫漫无目的的地发散散，或本本质性变变动导致致的成本本、时间间失控。对于初初始阶段段的其他他部分，我们把把它明确为为可行性性研究，而作可可行性研研究先要要有要做做的框架架、主要要步骤、范围；就是说说整体架架构、设

46、设计这个个阶段就就已在进行行了，说说明和解解读了这这阶段要要做的目目的。最最后作为为可行性性的输出出，要完完成立项项申请报报告，获获得项目目进行所所必需的人力和和资金。（图3 RUUP）2、六段段式过程程提出了了每阶段段的时间间控制和和成本标标准，输输出等目目标特征征。虽然六六段式与与RUPP的主要要阶段都都大致对对应，但但RUPP并没有有提出每每阶段的的时间、成本占占用比例例；导致致一些项项目虽按按RUPP进行，但各阶阶段严重重不成比比例，如如仅对部部分架构构和界面面美观研研究时间间太长，却忽略略甚至跳跳过了细细化阶段段； 设设计时间间过长和和反复纠纠结太多多，没有有给实施施阶段留下下足够时

47、时间和成成本。对对每个阶阶段的成成本控制制，绝不不是小事事；而是是一个必必须进行行控制的的事。整整体上这这是一个个循序渐渐进，逐逐步扩大大的投入入过程，1%，5%，115%，65%，这一一过程实实际上降降低了项项目过程程中的风风险。这这是六段段式项目目管理最最重要的的一点。各阶段段的成本本控制也也是用于于衡量设设计与开开发间成成本配比比和工作作效率的的依据之之一，就就软件而而言优秀秀的过程程设计与与实际实实施开发发，单位位时间投投入大约约在1:3到11:4，而实施施时长通通常比设设计多50%左右。3、六段段式过程程清晰化化各阶段段规范，尤其是是设计阶阶段的工工作方式式和输出出标准。在RUUP中

48、，Inccepttionn和Elaaborratiion的的里程碑碑描述不不很清晰，其实它它就是立项确确认书。而设设计阶段段是整个个项目成成败的关关键，RRUP并并未明确确其过程程。六段段式明确确了这一一阶段主主要目的的，就是是完成项项目的应应用设计计。而设设计，绝绝不是肆肆意画图图、想象象、任性性设定，想怎么么设计就就怎么设设计；设设计必须须以分析析为基础础，实际际完成设设计的人人员不叫叫设计师师，而是是系统分分析师；需求分分析并非非对需求求的简单单想想、分析分分析，需需求分析析是专业业人员作作的，必必须是基基于系统统面向系系统开发发的。需需求分析析人员不不但要有有很强理理性思维维能力、把自

49、己己代入用户户情境（usee sccenaarioo）的能能力，而而且要有有全面、坚实、深刻的的IT和和CT系系统知识识，对系系统梳理理、分析析的能力力 ；最后后要掌握握表述规规范用标准的图图、文表表达出来来。实际际上，六六段式管管理，借借用改良良UMLL，确立立了规范范的需需求规格格说明书书写法法和图形形语言，因为图图的表达达能力更更强。因因此，它它重新定定义了设设计阶段段的工作作细节，和输出出设计稿稿的标准准。同时时，更规规范化了了一些标标准，如如维护是是测试验验收后，虽然有时时投入几几乎为00，但是是考虑整整体性，不宜将将之抹除除。在六六段式管管理中，各阶段段“输出”也更加加明确；可以说

50、说六段式式是RUUP进一一步规范范。4、六段段式过程程的阶段段性，真真正有效效规避了了风险，提高了了项目成成功性和和对需求求的满足足。 我我们提出出软件项项目过程程模型的的目的，是为提提高项目目成功率率和更确确切满足足需求。但是，项目失失败率（或与需需求偏差差）显著著偏高，如对比比生产，怎么才才能控制制项目过过程中的的风险，提高成成功率或或尽早发发现风险险减少损损失？我我们知道道项目是是个一次次性的有有目的的的过程，由于它它的一次次性没有有可借鉴鉴经验，怎样提提高成功功的可靠靠性，只只有逐步步投入、渐次逼逼近目标标，发现现风险后后及时弥弥补和中中止，才才是真正正降低风风险，保证项项目成功功的依

51、靠靠。这是是通用的的唯一的的方法。六段式式项目过过程，是是逐步扩扩大投入入的过程程，如同同喇叭口口，这种种扩大并并不是线线性扩大大，而是是指数级级增长（如4的的x-11次幂）。在扩扩大的每每个阶段段，都会会进行rreviiew评评审，当当发现风风险时就就可以及及时控制制、改进进；必要要时中止止项目以以防止损损失扩大大。要知知道，项项目实施施人员基基于工作作量酬劳劳的原因因，即使使发现风风险也有有继续完完成项目目的冲动动。提案案评审批批准、立立项评审审批准、规格三方方评审，每个主主要环节节都进行行了严格格的风险险控制，团队外外的评估估。 软软件过程程，或建建筑项目目过程，本质上上都是“社会生生产

52、”过程，是为了了让人们们生活得得更好，工作更更有效率率，解放放人力用用于享受受幸福，都是一一种经济济活动。经济活活动就要要符合经经济活动动的规律律，最大大化追求求利润，或成本本一定的的情景下下最大化化满足需需求；而而不是追追求过程程看起来来有对称称、整齐齐或理论论深奥。保障项项目的成成功率，用最少少投入完完成项目目目标，防范风风险、降低重重复就是是节省成成本，转转化和增增加了利利润；在在项目开开发总成成本未增增加的情情况下，做出的的成品更更加贴近近用户需需求或用用户理想想状态、提高使使用效率率何乐而而不为？六段式式方法，用最简简单最直直接的方方式，清清晰的控控制风险险，避免免了繁杂杂评审过过程

53、中反反复和浪浪费，本本质上是是对项目目经济性性的诠释释。四、六段段式项目目管理与与常见问问题辨析析六段式项项管与需需求变更更1、怎样样控制变更更进而控制制项目有人问我我需求变更更怎样控控制？他他们使用用了CCCB（CChannge conntrool bboarrd）、变更更控制流流程等种种种管理理措施，仍不能能有效的的控制变变更的数数量，需求时在在变、编编码中变变、编码码后还在在变。首先，需需求变更更是一种种客观存存在，没没有人是是诸葛亮亮，可以以准确预预测所有有可能出出现的情情况、实实施过程程中的问问题。因因此，没没有变更更的项目目是不正正常的；重要的的是怎么么对待变更更。如果需求求不断变

54、变化，那说说明提案案时还没搞搞清要干什什么，就就匆忙施施行；或或者没有有充分确确定可行行性和优优先次序序，过后后才发现现架构要要改；或或者没有有一个确确定的设设计，结结果边干干边设计计，一面面涂抹一一面实施施。 总总之就是是没有确确定想法法 或想想法没有有经过系系统地分析，没有项项目的过过程管理理、成品品的设计计（管理理学术语语，没有有制定计计划）；解决办办法也很很简单，就是严严格按照照六段式式项目过过程进行行即可。但是计划划没有变变化快，总是有有细节不不在计划划内，这这很正常常；在编编码中，或编码码完成后后出现变变更也是是合理的的。这在在建筑工工程中也也很常见见，举一一个亲身身经历例例子，2

55、20044年为某某单位建建设居民民楼，设设计院的的图纸都都经过评评审、答答疑、交交底，无无异议后后才实施施；数月月后施工工单位向向我汇报报要求变变更一个个下水PPVC管管位置，侧移110cmm，原因因是管子子会遮挡挡一些卫卫生间窗窗口的视视线，且且造成用用户开关关窗口略略不便；基于为为居民着想想这变更更很合理理，而且且在图纸纸上审议议时很难难预想到到观窗视线线的细节，经经与设计计院协商商，其修修订了图图纸（未未全部重重晒）。像这种种成本很很少、基基于用户户需求的的都可以以变更。但是一一定要控控制变更更的度。 就是是在实施施阶段，进行变变更，包包括设计计更改，也包括括工期调调整、预预算追加加，不

56、能能超过评评审通过过的需求求规格的的15%。如果果超出、或发现现将来会会超出，必须立立即报告告决策层层，预算和和工期都都一样，并重新新修订预预案。 要特别别强调的的一点，对设计计变更，必须要要通知设设计团队队并征得得其同意意（代表表产品、需求方方）不论其其节省预预算或超超支；编编码变更更和设计计变更可可以同步步同时进进行，但但设计团团队要对对变更留留底。有人说，他们刻刻意遵照照RUPP过程，但是公公司管理理层强势势改变、尤其增增加了很很多需求求，仍然然导致变变更超出出了预算算，或实实现需求求不理想想；时间间也有延延期。在六段式式管理或或RUPP中， 如果一一个变更更是本阶阶段内的的，（变变更的

57、原原方案是是本阶段段内才提提出来的的，只影影响阶段段内），可以直直接变更更，不需需要申请请、审批批流程。 如果果变更的的是上一一阶段的的输出（如通过过评审的的需求规规格、立立项书），则必必须要返返回上一一阶段进进行修改改，并重重新评审审批准。 而不不是直接接在本阶阶段变更更，虽然然那样看看起来更更简洁，但是却却蕴藏了了巨大风风险和不不可持续续性；为为将来软软件改进进和未来来着想，必须回回上一阶阶段。如如：实施时时发现要要增加一一个很大大项需求求；这时时要返回回立项阶阶段（甚甚至提案案）重新新确定立立项，书书面明确确更改后后的预算算、和工工期，然然后作这这部分的的设计；或者可可以这样样想，实实施

58、时的的问题，返回设设计，设计能能解决则则解决，若发现现还不符符合上一一阶段输输出，那那还要继续续返回调调研阶段段。由于于六段式式管理每每阶段都都有评审审，实际际上这样样也可以以避免，不懂技技术的领领导乱拍拍板，一一些糊涂涂领导不不认账。 变更更的结果果必须在在阶段输输出文档档中保留留；变更更原因和和原设计计尽量保保留。 这样可可以不用用严格按按照申-评评-决-施-验验-存六步变变更控制制流程处处处存档档，避免免许多人人最反感的文档化化和繁文文缛节，简化流流程提高高效率。2、三方方评审、质控减少变变更关于评审审。每个个阶段结结束时，都要进进行评审审（评价价及审批批），实实际上是是阶段性性质量控控

59、制，通通过评审审将阶段段性控制制后期变变更的风风险。变更越越早发现现、越早早进行，成本越越低。提提案和调调研的评评审，都都由决策策层（或或需求投投资方）直接进进行，决决策者签签字确认认或集体体决策的的通过讨讨论汇签确认认。提案书被确认认后就是是筹备组组工作的的依据批批文，立立项申请请书，被被确认后后就是立立项确认认书。这这如同审审建筑图图纸，决决策层重重点审户户型、框框架、满满足需求求，而不不是专业业的细节节。不同同的是设设计阶段段，设计计阶段的的评审，叫做“三方评评审”，前面面评审可可以是一一个时间间点，而而三方评评审可能能是需需求规格格说明书书一套套文档，内容多多且专业业，不是是一次会会议

60、可完完成的。往往分分多次陆陆续评审审，评审审通过的的先进入入开发，如果一一定要找找时间点点，那么么以首次次80%需求规规格通过过评审为为准。所所谓“三方”，是指指用户方方代表、开开发方代代表、独独立第三三方专家家。产品品化的软软件，无无法找到到全面用用户代表表，可由由产品团团队和专专业需求求分析人人员组成成代表组组，但不能仅仅仅是设计者者本人。开发方方代表，可由开开发经理理和系统统架构师师组成，具有否否决权，重点审审核设计计能否实实现，成成本如何何。多数数项目聘聘请第三三方专家家很难，可由具具备开阔阔民众平平常心和和知识远见见的公司司领导来来代表。评审须要三方方通过，不通过过的需阐阐明理由由和