统的六段式项目管理方法

文件类型：论坛分享存档编号：发放范围：公开1统一的六段式项目管理方法----从经济学角度改进软件项目管理过程（作者：EzraThomad）摘要：软件工程项目，归根到底是一种经济生产活动，它应该遵循经济的规律，以更趋近经济利润和成功满足需求为目标。软件项目瀑布、敏捷、螺旋、迭代模型的纷乱，可以借鉴上千年来人们在建筑工程上的经验，使之更规范、科学、有益于项目的成功。将项目管理统一为六个阶段，并提出每个阶段的本质与目标特征，能将建筑、软件等所有项目管理统一在一个框架下，更加符合人们的认知和工程项目管理的合理化。六段式管理方法，规避风险、高效实用、断点清晰。系统的分析与设计独立出来，将会成为软件工程项目的核心，系统分析者职业化是未来软件工程的亟需和趋向。目录一、软件工程项目与建筑项目管理的统一.............................................................................................2二、统一的六段式项目管理过程.............................................................................................................2六阶段分别定义、特征、实践注意点.....................................................................................2三、六段式项目管理与传统方法的对比和优势.....................................................................................7六段式项管与早期分段法、瀑布模型.....................................................................................7六段式项管与产品迭代模型.....................................................................................................9六段式项管与RUP..................................................................................................................10四、六段式项目管理与常见问题辨析...................................................................................................12六段式项管与需求变更...........................................................................................................12六段式项管与敏捷开发...........................................................................................................16系统分析师和软件架构师、PdM和PjM..............................................................................21五、六段式项目管理规范化...................................................................................................................22六、未来软件工程和系统分析之路.......................................................................................................26文件类型：论坛分享存档编号：发放范围：公开2一、软件工程项目与建筑项目管理的统一软件工程越来越成为技术发展和现代社会建设的重要支脉，随着x8086、ARM等通用硬件架构的进一步完善，软件工程甚至逐渐普及和加强为IT和通信的主要内容和核心驱动力。但是，一直以来，软件工程都缺乏一种有效公认统一的管理方法，使得工程高利润、可控制的顺利实现目标。相反的，经常见到小如APP，大到电网集散控制系统，经常不能完美达到用户需求、预算超支、工程延期等问题甚至合同违约或项目失败；与客户理想的人机交互不同，更是屡见不鲜。有没有一种管理方法可以解决？瀑布模型、敏捷开发、演化模型、RUP和螺旋模型，轮番上阵，虽然都在各个领域取得一些效果和有一些最佳实践，却始终没有一种被证明绝对有效、被人们长期公认科学的项目管理模型。由于曾负责建筑工程的特殊经历，使我考虑能不能将建筑工程经验借鉴；或者将建筑管理与软件工程项目过程相统一。建筑项目是项目，软件项目，也是项目，两者绝不仅仅只名称相同；有“一次性”目标性等许多项目的共同特征。项目过程与标准化生产过程不同，他的一次性独特性很明显。经济中除了生产、就是项目；应该有一个共同框架来统一项目过程。建筑项目，俯拾皆是；国家的建设如火如荼，那么多项目，总有营养汲取。何况中外建筑史有数千年，中国大型建筑项目也已经有二千年历史，有许多经验。实际上建筑业早已形成统一的规范的过程模式。一般的，建筑过程有规划草图和勘探、设计、土建安装、监理验收等多个环节，两相类比，软件项目缺少一个独立、明显的设计过程；设计过程往往被前置到需求交流、或以“详细设计”名义实际融入开发过程中了。由于缺少成型、明确的设计，使得开发与用户理解有潜在差异，成本预估不确切，开发变更修改反复进行而工期延迟，这就是导致项目管理最终失控的主要原因。经过更详细的分析与研究，和对整个项目过程的对比筹划思考，尤其是对项目成败起决定作用的前期过程的不断思辨，形成了统一的六段式项目管理方法。二、统一的六段式项目管理过程将软件工程项目管理过程划分为六个阶段，并明确其特征和分隔点，在实践中确定有效。六阶段分别定义、特征、实践注意点1、提案阶段。由提议人完成，通常是1-3人；这一阶段要：确定进行之目的，明确项目的初步范围，确定“做什么”。完成时输出《xxx项目建议书》，批准结束。这个过程非常快，通文件类型：论坛分享存档编号：发放范围：公开3常1天或几天内迅速完成，或不断讨论逐步形成定案；这个阶段花费在总成本中不超过1%~2%。在实践中，由产品经理提出，或有时直接由老板口述指定。由于此阶段短促，经常见到这个过程被省略，或不形成定议文案。但实际上，这是不对的，必须坚决反对。有些项目彻底超出预算，实质就是变更巨大，甚或完全推翻，以致漫无目的地发散，自己搞不清最初的目标了。这是一个必须经由的阶段，而且必须形成正式文档，经过评议并保存。对于一个创新性项目，须要适当详细的建议书，以明确大致范围；对于产品化的项目，每个项目只是产品演进发展的一阶段，建议书可以简明扼要，明确当前版本要达到的主要目的目标即可。甚至可以一页纸但这一阶段不可或缺，尤其涉及变更时；这也是帮助管理者，厘清思路，明确优先次序的过程。2、调研阶段。由筹备小组完成，这一阶段要：确定项目整体是否可行，筹备所需人力、资财，组建核心团队，解决“能否做”。完成时要输出《可行性分析报告》《立项申请书》，通过了评审，正式批准是阶段结束标志，有时称“立项阶段”。这个阶段花费在总成本中通常不到5%。实践中一些软件项目还没有明显的立项过程；但是，厂矿、建设项目可行性研究明显，有人认为软件项目不涉及环评、土地、审批等不需可行性研究；其实是没有理解，可行性研究的核心在于，理清实施的主体架构、主要步骤、核心内容。主体架构决定整个走向，主要步骤是资源运筹大方向，两者确定是否可行，他们确定以后才谈到如何实施和可行性。建筑项目中，这个阶段会画出规划草图、进行勘探以确定设计参数和可行性等。因此，设计并不是从设计阶段开始、而是总体设计在提案、调研阶段即开始，在设计阶段细化和完善、完成。立项基于可行性分析，可行基于架构和步骤。可行性报告，通常包括政策可行性、经济可行性、技术可行性、法律、环境、可持续性等部分。但重点是技术、经济可行性，对软件项目而言尤其如此。软件项目可以省略不必要的可行分析部分，只重点描述技术实现方案、经济可行；一些产品化的项目，甚至可以将可行报告合并在立项确认书中，甚至可以不须计算经济可行性（完全产品化的软件收入估算复杂），只需明确技术实现方案、和市场用户（竞争对手优势）预估。《立项申请书》中，应载明当前版本的主要任务、整体范围界定、实施成本及人力预估、工期安排和估算，有些还需要附带测试验收标准。立项申请应在批准确认后，以文本形式备档，作为后期变更的基准线和管理考核、项目考评的依据。需要强调说明，设计、测试、框架开发等专项工作，并非仅在其名义阶段上进行；实际上，他们是渗透在各个阶段上进行的。比如，设计在提案阶段就已经有大致范围和初步架构，在调研阶段设计主体架构，在设计阶段完成详细设计和明确；与一般理解不同，设计（已经评审和批准）在实施阶段仍在继续，包括尚未完成的一部分设计（一部分先通过评审的需求先实施）、对实施文件类型：论坛分享存档编号：发放范围：公开4中发现不清晰、不合适的进行细化设计和补充设计、因变更引起的重新设计。再如，开发可能在提案前已经有现成组件、中间件或构件，在调研等阶段预进行一些核心和长周期的开发，设计阶段甚至进行一些部分已确认的细节开发。再如更明显更为大家熟知：测试中的单元测试，实际是在开发阶段完成的，而不是在验收阶段；验收只是系统测试和性能测试。所以这与直接的表面理解不同，在RUP模型出现之后，业界普遍认同了不同工作的进行时间是互相叠合的，因此，必须首先理解一项工作内容，并非仅在其名义阶段上进行；划分阶段的名称只是当前阶段的主要工作、核心工作，而不是全部工作或纯粹工作。RUP的四个阶段都分别含有不同比例的分析、架构、设计、实施工作内容，而不是在设计阶段只做设计、实施阶段只做开发，这些工作是不同子团队并行推进的，而不是串行进行由同一团队完成。下图描绘了在RUP中，不同工作在项目时间轴推进中不同阶段的工作数量。图1另外说明，这个阶段的工作是由筹备小组完成，这在工程、厂矿中很常见，软件项目中较少见，实际上是筹备组是隐式存在的，只是未使用名称，人员可能分散并行着多个项目。软件项目中，通常可以虚拟组成，人员可以由不同部门员工虚拟组成团队，员工可以同时存在多个项目的筹备组中，少量需要实设组织架构。筹备组并非是单一的分析师和项目管理者组成，而是发起者、分析师、面向开发的架构师、界面美工、几个程序员甚至测试共同组成的混合团队；立项后，分别面向不同子工作团队，成为其不同层级的骨干。当立项申请获批，项目即得到了资源、财务的支持，人力投入认可，筹备组即转化为项目组，其成本自然进入项目成本。非立项筹备成本是可施行性比率下合理的沉没成本。有时这过程也称“立项阶段”，但调研更确切描述阶段的本质。3、设计阶段。由分析设计人员完成，有时是规范的产品团队；这一阶段要：确定项目完成最终实现的目标，软件成品的详细描述，包括系统交互、状态变化和处理逻辑、数据和部署等。即解决“做成什么样”。完成时要输出《需求规格说明书》，并通过三方评审。这个阶段时间占到总过程30%，但成本仅占15%。文件类型：论坛分享存档编号：发放范围：公开5当前，在许多软件项目实践中，这一阶段都不明显，甚或消失。这导致开发承担者、与使用用户（需求方）对成型后成果，有显著理解差异；并最终导致开发人员对工程量无法