统一的六段式项目管理方法

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

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

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

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

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

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

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

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

10、对的，必必须坚决决反对。有有些项目目彻底超超出预算算，实质质就是变变更巨大大，甚或或完全推推翻，以以致漫无无目的地地发散，自自己搞不不清最初初的目标标了。这是一个必必须经由由的阶段段，而且且必须形形成正式式文档，经过评议并保存。对于一个创新性项目，须要适当详细的建议书，以明确大致范围；对于产品化的项目，每个项目只是产品演进发展的一阶段，建议书可以简明扼要，明确当前版本要达到的主要目的目标即可。甚至可以一页纸 但这一阶段不可或缺，尤其涉及变更时； 这也是帮助管理者，厘清思路，明确优先次序的过程。2、调研阶阶段。由筹备备小组完完成， 这一阶阶段要：确定项项目整体体是否可可行，筹筹备所需需人力、资资

11、财，组组建核心心团队，解决“能否做做”。完成成时要输输出可可行性分分析报告告立立项申请请书，通过了了评审，正正式批准准是阶段段结束标志志，有时时称“立项阶阶段”。这个个阶段花花费在总总成本中中通常不不到5%。实践中一些些软件项项目还没没有明显显的立项过过程；但但是，厂厂矿、建建设项目目可行性性研究明明显，有有人认为为软件项项目不涉涉及环评评、土地地、审批批等不需需可行性性研究；其实是是没有理理解，可可行性研研究的核核心在于于，理清清实施的的主体架架构、主主要步骤骤、核心心内容。主体架架构决定定整个走走向，主主要步骤骤是资源源运筹大大方向，两两者确定定是否可可行，他他们确定定以后才才谈到如如何实

12、施施和可行行性。建筑项项目中，这这个阶段段会画出出规划草草图、进进行勘探探以确定定设计参参数和可可行性等等。因此此，设计计并不是是从设计计阶段开开始、而而是总体体设计在提案、调调研阶段段即开始始，在设计阶阶段细化化和完善善、完成成。立项项基于可可行性分分析，可可行基于于架构和步步骤。可行性报告告，通常常包括政政策可行行性、经济可可行性、技技术可行行性、法法律、环环境、可持续续性等部分。但重点点是技术术、经济济可行性性，对软软件项目目而言尤尤其如此此。软件件项目可可以省略略不必要要的可行行分析部部分，只只重点描描述技术术实现方方案、经经济可行行；一些些产品化化的项目目，甚至至可以将将可行报报告合

13、并并在立项项确认书书中，甚甚至可以不须计计算经济济可行性性（完全全产品化化的软件件收入估估算复杂杂），只只需明确确技术实实现方案案、和市市场用户户（竞争争对手优优势）预预估。立项申申请书中，应应载明当当前版本本的主要要任务、整体范围界定、实施成本及人力预估、工期安排和估算，有些还需要附带测试验收标准。立项申请应在批准确认后，以文本形式备档，作为后期变更的基准线和管理考核、项目考评的依据。需要强调说说明，设设计、测测试、框框架开发发等专项项工作，并并非仅在在其名义义阶段上上进行；实际上上，他们们是渗透透在各个个阶段上上进行的的。比如如，设计计在提案案阶段就就已经有有大致范范围和初初步架构构，在调

14、调研阶段段设计主主体架构构，在设设计阶段段完成详详细设计计和明确确；与一一般理解解不同，设设计（已已经评审审和批准准）在实实施阶段段仍在继继续，包包括尚未未完成的的一部分分设计（一一部分先先通过评评审的需需求先实实施）、对对实施中中发现不不清晰、不合适适的进行行细化设设计和补补充设计计、因变变更引起起的重新新设计。再再如，开开发可能能在提案案前已经经有现成成组件、中中间件或或构件，在在调研等等阶段预预进行一一些核心心和长周周期的开开发，设设计阶段段甚至进进行一些些部分已已确认的的细节开开发。再再如更明明显更为为大家熟熟知：测测试中的的单元测测试，实际是是在开发发阶段完完成的，而而不是在在验收阶

15、阶段；验验收只是是系统测测试和性性能测试试。所以这与直直接的表面理理解不同同，在RRUP模模型出现现之后，业业界普遍遍认同了了不同工工作的进进行时间间是互相相叠合的的，因此此，必须须首先理理解一项项工作内内容，并并非仅在在其名义义阶段上上进行；划分阶阶段的名名称只是当前前阶段的的主要工工作、核心工工作，而而不是全全部工作作或纯粹粹工作。RUPP的四个个阶段都都分别含含有不同同比例的的分析、架架构、设设计、实实施工作作内容，而而不是在在设计阶阶段只做做设计、实实施阶段段只做开开发，这这些工作作是不同同子团队队并行推推进的，而而不是串串行进行行由同一一团队完完成。下图描描绘了在在RUPP 中，不同

16、工作在项目时间轴推进中不同阶段的工作数量。图1另外说明，这这个阶段段的工作作是由筹筹备小组组完成，这这在工程程、厂矿矿中很常常见，软件项项目中较较少见，实实际上是是筹备组组是隐式式存在的的，只是是未使用用名称，人员可能分散并行着多个项目。软件项目中，通常可以虚拟组成，人员可以由不同部门员工虚拟组成团队，员工可以同时存在多个项目的筹备组中，少量需要实设组织架构。 筹备组并非是单一的分析师和项目管理者组成，而是发起者、分析师、面向开发的架构师、界面美工、几个程序员甚至测试共同组成的混合团队；立项后，分别面向不同子工作团队，成为其不同层级的骨干。当立项申请获批，项目即得到了资源、财务的支持，人力投入

17、认可，筹备组即转化为项目组，其成本自然进入项目成本。非立项筹备成本是可施行性比率下合理的沉没成本。有时这过程也称“立项阶段”，但调研更确切描述阶段的本质。3、设计阶阶段。由分析设设计人员员完成，有有时是规范的产品团团队；这一阶阶段要：确定项项目完成成最终实实现的目目标，软软件成品品的详细细描述，包包括系统统交互、状状态变化化和处理理逻辑、数数据和部部署等。即解决决“做成什么样”。完成成时要输输出需需求规格格说明书书，并并通过三三方评审审。这个个阶段时时间占到到总过程程30%，但但成本仅仅占155%。当前，在许许多软件件项目实实践中，这这一阶段段都不明明显，甚甚或消失失。这导导致开发发承担者者、

18、与使使用用户户（需求求方）对对成型后后成果，有有显著理理解差异异；并最最终导致致开发人人员对工工程量无无法确切切评估（实实际上，出出于赢得得好感，多多数都倾倾向评估估或给出出较短的的数字），和和实施后后又反复复修改成成品导致致延期和和超支。在在建筑项项目中，这这阶段是是由专业业的“建筑设设计院”、专业业建筑师师和结构构师完成成，并以以出图（蓝蓝色图）为为基础，设设计中都都遵循严严格的设设计规范范、支撑撑结构原原则、公公认范例例等规则则（当然然也是受受建筑安安全国家家法律限限制）。与建筑一样，设计阶段将逐步独立出来和更加规范。一些项目，由于甲方领导无经验，又重视细节，反而自然而然的要求进行了图形

19、界面设计或demo演示。在实践中，有有些项目目有设计计，但是是仍然导导致承建建方无法法实施、或或项目彻彻底失败败。是因因为设计计没有建建立在系系统分析析之上，设设计没有有基础。我们经常讲OOA/OOD（object oriented analysis/design），可以发现这两个词都是一起出现；分析是设计的前提，设计是分析的结果输出；两者异常紧密，之间完全映射而不是须要沟通，两者合而为一才是最高效和合理的，分析者即是设计者。只有面向系统的分析-需求分析，才能导致可实现的、最佳成本和高体验的设计。分析师需要一定的进入门槛和如建筑设计师的专业素质，以确保设计是基于合理可靠的分析，面向系统实现和用

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

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

22、并在清晰全部成果后详细估算成本，检验可实现性。当然，更详细设计稿更好，但这一阶段的成本需要严格控制在总成本的15%不超过20%，否则会挤占开发成本，就会出现设计得很好，做出来却差距很大，而且浪费时间进度。设计输出要重新修正立项时确定的开发成本，使逼近20%内，并在通过三方评审后确立。4、实施阶阶段。主要由实施、开开发团队队完成， 这一阶阶段是主主要承担担项目实实施、开开发完成成的阶段段；也是是资金成成本投入入最密集集的阶段段，通常常占总成成本600%-770%，有有时也称称开发阶阶段。在这个个过程中中，要解解决“怎么做做”；在调研研阶段，我们解解决“能否做做”时，实际际上已经经讨论怎怎么做的的

23、主体思思路；但但具体每每个单元元怎么做做并未涉涉及，此此阶段进进行中会会解决。除输出成品，为确保实施阶段的，可控、可督促、管理的及时和有效，应该输出定期项目实施报告和实施日志。实践中，有有很多项项目是外外包单位位实施完完成；这这时对需需求规格格说明书书和两两个输出出文档就就显得尤尤为重要要。需求求描述是是开发的的基础，当有良好的需求描述时就可以将整个开发实施阶段外包，如建筑业做法一样；而实施报告和实施日志则是实施过程中的保障，以确保进度、质量合乎项目的规划，成本在可控预算内。两者区分在于报告是用于管控的，日志是用于清查的。虽然我们希望报告督促开发实施的勤恳，但并不是越多越好。实施组对管理层的开

24、发报告，每周一次即可；开发日志可以每天记，但不须详细、也不须每人记，一个小组有一份日志即可，简单数语扼要即好。如要确保人人进度，可日例会轮流口头汇报进度。5、验收阶阶段。由测试、验验收团队队完成，这这一阶段段要：确确定项目目是否达达成目标标，是否否达到预预期可正正常运作作，和结结束实施施。完成成时要输输出系系统测试试报告和和验收报报告。这这个阶段段花费在在总成本本中通常常在10%内，时间间占155%左右右。理论上讲，验验收报告告 通常常由所有有方出具具，或由独立的的第三方方出具（以以确保、公公正），验收应应该是全全面的、详细的检测；系统测试和性能测试是由测试团队完成，独立的过程。但实践上，由于

25、甲方的强势、和减少重复劳动及成本分担的考虑，通常会与系统测试合并，这样只需要一份系统测试报告，和一个简明扼要验收报告。当这样做时，应注意验收测试并不是完全消失了，验收只做，核心功能和应用活动流程的测试，而不需要重复ST中每一步骤、细节；这是两个互相独立的工作，ST的是测试团队，验收则可由产品团队代表所有方实施，不能因合并而完全依赖单一ST，保证制衡与复核。这样通常可以有效控制成本在10%。这样做原因，同样是基于软件研发也是一项经济活动，我们不是为做而做，而是为了更好、更有效率的改造世界，美化人们的生活。有些公司很很重视测测试，把把测试作作为一个个重要的的关卡和和检验标标志，这这是好事事。但是是

26、要注意意软件的质质量是开开发出来来的，甚甚至是设设计出来来的，而而不是测测试出来来的。这里说说明，单单元测试试和中间间集成测测试是由由开发为为主和测测试组共共同完成成，且在在开发实实施阶段段做；而而系统测测试报告告和性能能测试则则由测试试团队完完成。一一些无明明确要求求的项目目，可以以减省或或模糊地地施行压压力测试试和负载载测试。6、维护阶阶段。每一个个项目，实实际上都都涉及到到项目结结束后的的持续维维护问题题。虽然然维护过过程或显显著、或或微弱；实际上上都存在在。如MMS wwinddowss xpp一直在在打必要要补丁；tenncennt微信信软件，一些小版本是维护更新；有些项目完成后虽几

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

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

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

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

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

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

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

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

35、功能、可用性和更优秀的体验。这大幅地节省整个社会的成本、提高软件质量和可用性。这时，许多软件开始产品化，比如MS office， Photoshop，Donald的TeX、一些ERP系统等。软件公司对一个软件在前次版本基础上，做新的需求规划、立项、系统分析设计、开发、测试；产品上市后又开始新一轮需求规划，周而复始。迭代模型就在这种背景下得到认可。软件的产品品化，极极大的推推动软件件业进步步和社会会的发展展。但应应该了解解，每一一个软件件版本，是是经过了了立项进进行开发发的，是是一个独独立的软软件项目目，而不不能将软软件不断断发展演演进过程程，视为为一个大大项目。只只有把这这大“项目”拆解成成一

36、个一一个小独独立过程程，我们们才能对对其中阶阶段进行行标准化化、把项项目管理理演变成成一个科科学、标标准、可可控的方方法；否否则，复复杂庞大大的大项项目没有有纯粹共共同点，我我们无法法提炼其其中的规规律，项项目管理理就变成成一个人人治的、主主观的、失失控的过过程。这这也是分分析、分分解的基基本思想想。当我我们视为为一个个个独立版版本的项项目过程程后，就就发现周周而复始始的螺旋旋上升，就就是一个个一个软软件需求求项目的的首尾相相接，不不断上升升发展的的过程。谈到软件的的持续开开发和多多个项目目交替，可能就就会想到到，由于于项目团团队成员员的分工工专业化化，虽然然不同子子工作之之间有并并行推进进、

37、和时时间重叠叠；但在在不同阶阶段仍然然造成大大量人力力闲置和和浪费。如如在实施施阶段，主主要是开开发人员员在工作作，测试试和分析析设计人人员是较较空闲的的。 这这样会导导致整个个社会成成本的增增高，即即使通过过报价弥弥补了这这部分成成本，也也仍造成成人力的的浪费。 因此，实实践上，成成熟的软软件团队队，一般般都是同时时负担22个项目目或软件件版本，或或3-44个项目目。比如如甲团队队，正在在编码开发发某软件件3.111版本本，同时时在调研研、设计计软件的的3.220版本本；再如乙团团队，正正在设计计的是水水电DCCS系统统，同时时进行着着某企业业erpp系统的的测试和和bugg修改。因此，一个

38、个产品化化软件的的生命周周期过程程，是由由一个个个独立开开发项目目组成，这这样才具具有一次次性、目目标性等等项目的的典型特特征；才才是标准化化、可科科学管理理和提高高效率成成功率的的项目。产产品化的的软件，每每一个新新特性版版本都应应该立项项，以确确定市场场目标和和投入，按按标准项项目过程程操作，提提高资金金使用效效率、人人力使用用效率。对对每一个个版本项项目，应应该进行行投入效效益的考考核，和和总结反反思，效效益不仅仅是收入入、利润润的经济济指标，也也要包括括：活跃用用户数、用用户体验验、竞争争对手差差距等。产品化，才是软件行业的主流，由于软件复制几乎无成本，一个好的软件在跟普通质量的软件市

39、场竞争中，价格、产品都处于绝对优势，更何况差的软件。很多软件如OS、通用APP都会形成几家独大，普通研发项目几乎无法生存，产品化才是软件业未来。另外还要说说明，软软件开发发是一个个项目，软软件的安安装部署署也是一一个独立立的项目目；而不不能将两两者混淆淆。软件件部署也也同样有有调研、设设计、实实施、验验收的过过程；只只是部署署项目通通常很小小，过程程被微缩缩了。比比如，某某erpp产品部部署项目目，部署署目标很很明确，所所以提案案即是某某软件的的安装部部署；调研是是试安装装、调试试的过程程；经过尝尝试确定定了在oonliine环环境中正正式安装装的步骤骤、次序序、人员分分工/机机器分布布、失败

40、预预案，就就是对安安装过程程的设计计；正式安安装就是实施施；完成成后应该该进行测测试检验验，作为为验收；后续发发现遗漏漏还需维维护。顺顺便说明明一点，部部署也是是项目，建建筑也是是项目，因因此我们们把主要要核心过过程的名称定定为“实施”而不是是“开发”。但对于于大型的的设备的的部署安安装项目目，如大大型水电电机组安安装，则则有很明明显的六六个阶段段过程。安安装项目目，与机机组制造造、系统开发发，是两两个独立立的项目目过程。六段式项管管与RUUP细心读者可可能发现现，六段段式管理理，与RRUP具具有非常常多的相相似之处处，那么么为什么么还要再再发展六六段式管管理，与与RUPP相比有有什么优优势和

41、区区别。六六段式项项目管理理方法的的发现很很早且是是独立的的，并没没有参考考RUPP的过程程。首先先说，RRUP是是众多工工程师的的实践结结晶和经经验总结结，并由由Rattionnal（IIBM收收购）最最先发布布推广，是各模式的发展和软件开发经验的集成；两者相似只是“智谋之士，所见略同”的必然。RUP明确认识了各个阶段中不同种工作并存，率先将概设详设等从开发实施中独立出来建立了对应“设计”的细化过程，建立了循环的四段过程对软件不朽贡献，对行业产生重大影响；六段式方法在发展过程中也参考学习了RUP过程；从这个意义上说，六段式方法是对RUP的发展和演进。那么，六段式管理与RUP 有哪些不同：1、

42、六段式式管理重重新整理理了初始始阶段的的过程，根根据不同同本质，对对项目成成本至关关重要的的前期阶阶段，进进行了更更细化、规规范化的的整理。RUP 有四个过程，Inception（初始）、Elaboration （细化）、Construction（实施）、Transition（交付）阶段；其中Construction阶段就是六段式的【实施阶段】，有时称【构建阶段】，Transition阶段对应于【验收阶段】，细化大致相当于【设计阶段】。对于初始的Inception阶段RUP描述非常模糊，我们把提案独立出来，以最快明确项目的主要目的和大致范围，并要形成文档，避免漫无目的地发散，或本质性变动导致的

43、成本、时间失控。对于初始阶段的其他部分，我们把它明确为可行性研究，而作可行性研究先要有要做的框架、主要步骤、范围；就是说整体架构、设计这个阶段就已在进行了，说明和解读了这阶段要做的目的。最后作为可行性的输出，要完成立项申请报告，获得项目进行所必需的人力和资金。（图3 RUPP）2、六段式式过程提出出了每阶阶段的时时间控制制和成本本标准，输输出等目目标特征征。虽然六六段式与与RUPP的主要要阶段都都大致对对应，但但RUPP并没有有提出每每阶段的的时间、成成本占用用比例；导致一一些项目目虽按RRUP进进行，但但各阶段段严重不不成比例例，如仅仅对部分分架构和和界面美美观研究究时间太太长，却却忽略甚甚

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

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

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

47、一步规范。4、六段式式过程的的阶段性性，真正正有效规规避了风风险，提提高了项项目成功功性和对对需求的的满足。 我们提出软件项目过程模型的目的，是为提高项目成功率和更确切满足需求。但是，项目失败率（或与需求偏差）显著偏高，如对比生产，怎么才能控制项目过程中的风险，提高成功率或尽早发现风险减少损失？我们知道项目是个一次性的有目的的过程，由于它的一次性没有可借鉴经验，怎样提高成功的可靠性，只有逐步投入、渐次逼近目标，发现风险后及时弥补和中止，才是真正降低风险，保证项目成功的依靠。这是通用的唯一的方法。六段式项目过程，是逐步扩大投入的过程，如同喇叭口，这种扩大并不是线性扩大，而是指数级增长（如4的x-

48、1次幂）。在扩大的每个阶段，都会进行review评审，当发现风险时就可以及时控制、改进；必要时中止项目以防止损失扩大。要知道，项目实施人员基于工作量酬劳的原因，即使发现风险也有继续完成项目的冲动。提案评审批准、立项评审批准、规格三方评审，每个主要环节都进行了严格的风险控制，团队外的评估。 软件过程，或建筑项目过程，本质上都是“社会生产”过程，是为了让人们生活得更好，工作更有效率，解放人力用于享受幸福，都是一种经济活动。经济活动就要符合经济活动的规律，最大化追求利润，或成本一定的情景下最大化满足需求；而不是追求过程看起来有对称、整齐或理论深奥。保障项目的成功率，用最少投入完成项目目标，防范风险、

49、降低重复就是节省成本，转化和增加了利润；在项目开发总成本未增加的情况下，做出的成品更加贴近用户需求或用户理想状态、提高使用效率何乐而不为？ 六段式方法，用最简单最直接的方式，清晰的控制风险，避免了繁杂评审过程中反复和浪费，本质上是对项目经济性的诠释。四、六段式式项目管管理与常常见问题题辨析六段式项管管与需求求变更1、怎样控控制变更更进而控制制项目有人问我需需求变更更怎样控控制？他他们使用用了CCCB（CChannge conntrool bboarrd）、变更更控制流流程等种种种管理理措施，仍仍不能有有效的控控制变更更的数量量，需求时在在变、编编码中变变、编码码后还在在变。首先，需求求变更是是

50、一种客客观存在在，没有有人是诸诸葛亮，可可以准确确预测所所有可能能出现的的情况、实实施过程程中的问问题。因因此，没没有变更更的项目目是不正正常的；重要的的是怎么么对待变更更。如果需求不不断变化化，那说说明提案案时还没搞搞清要干什什么，就就匆忙施施行；或或者没有有充分确确定可行行性和优优先次序序，过后后才发现现架构要要改；或或者没有有一个确确定的设设计，结结果边干干边设计计，一面面涂抹一一面实施施。 总总之就是是没有确确定想法法 或想想法没有有经过系系统地分析，没没有项目目的过程程管理、成成品的设设计（管管理学术术语，没没有制定定计划）；解决办办法也很很简单，就就是严格格按照六六段式项项目过程程

51、进行即即可。 但是计划没没有变化化快，总总是有细细节不在在计划内内，这很很正常；在编码码中，或或编码完完成后出出现变更更也是合合理的。这在建筑工程中也很常见，举一个亲身经历例子，2004年为某单位建设居民楼，设计院的图纸都经过评审、答疑、交底，无异议后才实施；数月后施工单位向我汇报要求变更一个下水PVC管位置，侧移10cm，原因是管子会遮挡一些卫生间窗口的视线，且造成用户开关窗口略不便；基于为居民着想这变更很合理，而且在图纸上审议时很难预想到观窗视线的细节，经与设计院协商，其修订了图纸（未全部重晒）。像这种成本很少、基于用户需求的都可以变更。但是一定要控制变更的度。 就是在实施阶段，进行变更，

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

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

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

55、直接进行，决策者签字确认或集体决策的通过讨论汇签确认。提案书被确认后就是筹备组工作的依据批文，立项申请书，被确认后就是立项确认书。这如同审建筑图纸，决策层重点审户型、框架、满足需求，而不是专业的细节。不同的是设计阶段，设计阶段的评审，叫做“三方评审”，前面评审可以是一个时间点，而三方评审可能是需求规格说明书一套文档，内容多且专业，不是一次会议可完成的。往往分多次陆续评审，评审通过的先进入开发，如果一定要找时间点，那么以首次80%需求规格通过评审为准。所谓“三方”，是指用户方代表、开发方代表、独立第三方专家。产品化的软件，无法找到全面用户代表，可由产品团队和专业需求分析人员组成代表组，但不能仅仅

56、是设计者本人。开发方代表，可由开发经理和系统架构师组成，具有否决权，重点审核设计能否实现，成本如何。多数项目聘请第三方专家很难，可由具备开阔民众平常心和知识远见的公司领导来代表。评审须要三方通过，不通过的需阐明理由和需改进点。为了评审效率，通常产品、系统分析师会与研发、系统架构师预先会面口头沟通。因设计是从用户中来，因此评审倾向于通过，需改进不超15%的，可直接改进后进入下一阶段，不重评审。实施阶段的的评审，是是个大规规模评审审，实际际就是验验收。验验收的评审就就是验收收报告评评审会。 我们划分各阶段的标志就是评审点；可以想象这是一个时间轴直线，五次评审就是5个刻度分隔点，把直线分成了六个区段

57、。3、变更和和测试的的误区变更也会出出现在测测试中。测试中，也经常会提出些改进，要求变更需求和软件设计。首先，我们要分清bug和需求变更。原则上，bug是需求和设计中有要求（或隐含），而开发未达到的；需求变更是原需求文档和设计中没有的。不过，有些时候仍很难分请bug和需求变更。不论bug或需求，只要合理合适的，都应该更改；但如果涉及需求，同样的，要返回设计阶段，由分析设计团队分析讨论确定了新设计，再开发改进。这样做的理由同样是软件专业人员不是用户，不能保证确切的理解用户需求；没有经过全面分析、规划软件长期演进，可能会在将来反复改回；分析人员调研需求代表用户。 要强调的是，测试的依据是需求规格说

58、明书，而不是理解中用户正确需求，即使测试的意见是正确的，原设计不合理，也不能直接作为bug直接提交开发，这涉及到开发团队，对一个定稿设计的开发效率和工作考核。需求描述也也会引起起变更。常见的情况是需求规格说明书描述得不细、或有歧义（对不专业的分析设计团队尤其是），这会增加bug的量和变更。有些是分析设计人员没有掌握规范的规格说明书的写法；也有些是正常的沟通和表达理解习惯问题。 因此，好的产品团队和开发团队要经过磨合一段时期，才能达到配合默契、理解相通，开发才对设计理解更清晰、准确，整个团队的效率才更高。但再次强调需求规格说明书（SRS）绝不是越细越好，文档比代码还多；也不是用几句描述性的语言说

59、明使用目的就是需求（前者极限靠近净室模型，后者是多数非专业人员常犯的错误）； 而应该追求最少的文档，准确表达设计成品和使用意图。 这里开发人员要注意一点是，遇有描述不细、或有理解歧义的，开发人员要主动提出来，要求分析设计人员“交底”、“澄清”，而不是按照自己的理解自行开发或被动等待，之后导致变更或bug。因为分析人员要预估开发人员的理解的歧义难得多。 通常在实施阶段，要提供途径给开发和设计之间，快速、口头、准确地沟通，设计要及时响应开发询问，使便捷询问。一般而言，分析设计人员的固定薪酬部分是低于技术开发、系统架构人员的固定薪酬的，一是因为开发人员，尤其系统架构师主要依靠技术门槛、计时和工作量来

60、计算绩效，这个部分非常稳定；二是因为分析设计人员还有市场效益变化的绩效薪酬。由于对分析设计的评价经常很难进行，存在公说公有理婆说婆有理，而且分析设计团队是要对市场和用户负责的，因此以用户和市场变化作为优劣客观评判是最好的激励。 对用户需求的分析，没有最好、只有更好，通常都没有一次设计最完美不再改进的软件；有时细节用例的遗漏也属正常，但核心用例的遗漏和核心流程缺失，就是分析设计师的责任。同时，分析设计人员也有责任确保一次性提交经过深入分析的设计，以节省开发工作量，如果实施时经常返回前阶段大规模地变更，重新评估可行、重设计，那就要考虑项目分析团队、系统分析师，是否没有足够能力担当、没有足够资格及资