PM必懂的项目管理的四大模型思维导图模板

瀑布模型

定义

用瀑布模型做项目就像古代匠雕刻玉石，先有完整的设计图，然后按部就班往前推进，中间不能出一点差错，追求的是“一次成型”。这就是瀑布模型，最基本也最常用的一种项目管理模型，又称线性模型。

瀑布模型的六个阶段

1）软件计划

通过市场调研及与需求方的沟通，确定项目目标，进行可行性研究，以确定项目是否可行、利益如何，用于判断企业是否接受该项目。

2）需求分析

深挖需求方的所有需求并进行分析，以确定需求方最终想要达到的效果，进而保证做出客户想要的产品。一般这个步骤需要和客户反复确认，最终形成需求文档，作为开发的依据。

3）软件设计

了解了需求后，就要把需求系统化，根据需求的内容思考怎么呈现，如设计系统构架、设计系统界面、设计数据库、设计开发接口等，最终会形成架构设计文档。

4）程序编码

系统框架已经清晰，接下来就是和程序员沟通，把设计结果通过程序代码变成客户可使用的操作平台。

5）软件测试

编码完成且在其相应的平台上也可操作，这时就需要测试人员站在客户的角度，按照需求文档进行详细测试，对于不合理或者不正常运营的部分提出疑问，然后程序员修复，所有疑问解决，最终形成测试报告。

6）运行维护

软件开发完成即可投入使用。但不可保证客户使用中是否会出现问题，所以项目团队可能需要继续维护，修复错误和增加功能。

优缺点

优点

计划性较强，每个阶段都有其明确的任务，让软件开发过程可控。

很好地分工协作，产品经理、项目经理、开发、测试等都有其相应的工作。

质量有保证，每个阶段都有相应的文档留存和评审，可以帮助相关人员在动手之前思考得更清晰。编码结束后，也会有按照需求文档严密的测试，让质量更有保障。

缺点

难以灵活响应需求变更，对于最初不清楚需求的客户不友好。

工作量分布不均匀，项目安排是阶段性的，很多工作人员不能同时做事，可能会导致人力的浪费，如导致程序员开发时，测试人员需要等着结果。

进度控制难度加大，若前期进度受阻，就不得不压缩后续各阶段时间。

不能及时给客户反馈，到最后才能看到结果。

适用范围

客户对需求非常清晰，且在开发过程中没有或很少变化；或者市场上已经有稳定的开发流程，项目进行过程中很少有变化。

客户对实时看到的效果没有要求。

增量模型

定义

增量模型是通过对用户需求的判断，在定义了用户要求和系统需求,进行总体构架设计后，采用序列化地创建产品的方法进行开发的过程。

增量模型本质上是迭代的，但其强调：<b>每一个增量均发布一个可操作产品</b>。

优缺点

优点

系统模块化，可以分批次交付产品，用户可以及时得到反馈，了解项目的进展。

分批次开发降低了开发的风险，一个开发周期的问题不会影响整体开发进度。

开发顺序灵活，可以根据组件优先级、成员的进度进行优先级排序。

很好地分工协作，产品经理、项目经理、开发、测试等都有其相应的工作。

质量有保证，每个阶段都有相应的文档留存和评审，可以帮助相关人员在动手之前思考得更清晰。编码结束后，也会有按照需求文档严密的测试，让质量更有保障。

缺点

难以灵活响应需求变更，对于最初不清楚需求的客户不友好。

要求待开发的项目可以进行系统化模考划分。

模块并行进行，很可能导致成员工作的并行，例如，在做某一模块内容的同时，需要更改另一模块的漏洞。

适用范围

用户核心需求非常清楚

项目人员不足

产品可以分割成不同的阶段分别完成

迭代模型

定义

迭代模型项目就是数个小而快的瀑布式项目组成的。

每一次开发迭代都是一次完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。

每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

使用迭代模型进行软件开发，项目活动阶段

初始阶段为系统建立商业案例并确定项目的边界。

细化阶段细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。

构造阶段在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。

交付阶段交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。

优缺点

优点

灵活响应需求变更，做最符合用户需求的产品。

快速交付产品，降低了产品无法按照既定进度进入市场的风险。

有频率且短时间内持续有产品交付，客户可以及时得到积极的反馈。

团队成员并行工作，有利于节省时间和人力。

缺点

项目的整体时间不好预估，只能短时间规划项目进度。

对项目经理和团队成员的要求较高，需要快速应对变化的能力，且一精多专

适用范围

选择迭代模型的项目，通常属于高风险项目，且需求不确定，用户能在整个开发过程中不同程度地参与。

注：在迭代模型中，整个项目会被拆分成一系列的小迭代。通常一个迭代的时间都是固定的，不会太长。每次迭代只实现一部分功能，只做能在这个周期内完成的功能。

原型模型

定义

在需求分析阶段得到完全一致、准确、合理的需求说明是很困难的，所以为了解决这个问题，让双方的理解达成一致，出现了快速原型模型方法，也叫原型模型。

得到需求后迅速建造一个可以运行的软件原型，给客户测试，搜集反馈信息，然后反复修改确认，直至开发出的软件能真正满足客户的需求。

原型模型根据其最终保留情况分为非抛弃型和抛弃型两种

非抛弃型原型：先根据用户的最主要的要求，开发出能实现系统最基本功能的一个原型，再根据用户对原型使用与评价的意见，反复修改完善原型，直到等到用户满意的最终系统为止。

抛弃型原型模型：一般用来描述和验证用户需求，可以采用与实际开发所不同的开发工具，建立模拟的数据库系统，从而达到与用户交流的最好效果。到用户需求确定之后即不再继续开发此原型。

原型设计工具

Axure、墨刀等，简单拖拽就可以实现简单的界面交互，同样可以达到确认需求的目的。

优缺点

优点

开发速度快，客户意见实时反馈，对需求精准把控，可以减少设计中的错误和开发中的风险，同时也减少了对客户的培训难度，提高了系统的实用性。

因为和客户交互方便，有利于提高客户的满意度，所以有助于短时间内产品的推广。

缺点

所选用的开发技术和工具不一定符合主流的发展。

快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。

抛弃策略中的模型，可能会出现“模型可以，但真正实现有困难”的情况，再和用户沟通更改较难。

适用范围

处理简单过程明确、涉及面窄的小型系统；

大型系统的需求阶段，用原型去跟用户交流，需求分析会更加明确和细化

针对不同类型的项目。选择什么样的开发模型，应从以下两方面进行慎重考虑

实施推广的难度

项目管理团队的管理能力和系统开发团队的技术能力决定了所选择开发模型的实施难度。选择一个适合项目团队特点的开发模型尤为重要。

项目管理的侧重点

项目不同，其侧重点也不同，如侧重于进度、质量、成本控制、风险管理等等。根据项目的侧重点，可以选择不同的开发模型。