项目管理的四大模型

怎么判断一个人对一件事是否了解透彻？其实就是“知其然”且“知其所以然”。项目管理这个岗位的人也是一样，但因国内企业自身培训较少，很多项目经理都是在没有基础知识的情况下直接上岗，所以可能会对基础知识比较欠缺。
而时代的迅速发展又奠定了管理模式会在原有的基础上更加优化和迭代，所以作为项目经理一定要清楚地知道这几种基本的项目管理模型，才能举一反三、灵活运用，今天我们就来一起学习一下这四种项目管理模型。

1.瀑布模型 —— 按照流程一次性交付

瀑布模型是应用最广泛且最早出现的系统的项目管理模型，后续的模型很多都是在此基础上演变而来的，所以要想透彻地了解各个模型的应用，瀑布模型是根本。
▍瀑布模型的六个阶段

1）软件计划

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

2）需求分析

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

3）软件设计
了解了需求后，就要把需求系统化，根据需求的内容思考怎么呈现，如设计系统构架、设计系统界面、设计数据库、设计开发接口等，最终会形成架构设计文档。
4）程序编码
系统框架已经清晰，接下来就是和程序员沟通，把设计结果通过程序代码变成客户可使用的操作平台。
5）软件测试
编码完成且在其相应的平台上也可操作，这时就需要测试人员站在客户的角度，按照需求文档进行详细测试，对于不合理或者不正常运营的部分提出疑问，然后程序员修复，所有疑问解决，最终形成测试报告。
6）运行维护
软件开发完成即可投入使用。但不可保证客户使用中是否会出现问题，所以项目团队可能需要继续维护，修复错误和增加功能。
▍举例
比如，客户要制造出一个小汽车。
▲首先，客户提出想法，想要一个舒服的、遮风挡雨的代步工具（初步需求）。

▲客户一开始可能并不清楚想要什么样子的（对需求没有那么清晰）。

▲项目经理开始找客户确认：用途是什么，想要几个座位，想要什么风格，什么时间完工，预算多少等（需求确认）。

▲项目经理根据客户需求做商业分析、市场调研、项目成本估算，对比工期和预算，评估是否可做，是否值得做（可行性研究）。

▲评估确定可行，约定价钱和时间，签订合同（制订项目计划）。

▲项目经理和客户确认需求，如几个座位，是否有智能设备等（需求分析）。

▲设计出原型图和客户确认，设计需要什么组成，如轮胎怎么做，方向盘怎么做等（软件设计）。

▲开始正式制作零件和组装（程序编码）。

▲这时客户来看，只能看到零件，如方向盘、轮胎等（中间客户看不到结果，只有最后能看到结果）。

▲这时，客户可能说空间太小，要六个座位的。这意味着设计图要重新调整，做好车壳需要加长等（瀑布模型不能做到随时响应变更，越到后期代价越大）。

▲零件制作好，且组装完成，测试人员进行测试，是否满足质量要求，是否需要修改（测试）。

▲最后，通过验收，客户开走车子。

▍优缺点

优点

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

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

▲质量有保证，每个阶段都有相应的文档留存和评审，可以帮助相关人员在动手之前思考得更清晰。编码结束后，也会有按照需求文档严密的测试，让质量更有保障。
缺点
▲难以灵活响应需求变更，对于最初不清楚需求的客户不友好。

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

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

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

▍适用范围

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

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

2.增量模型 —— 按模块分批次交付

瀑布开发模型是一个一次性交付的过程，也就是说这个项目通过了这六个“软件计划→需求分析→软件设计→程序编码→软件测试→运行维护”开发步骤，整个项目才算完成。

但是增量模型是一个分模块交付的过程，它是把“需求分析→软件设计→程序编码→软件测试”这四个步骤摘出来，运行了多次，然后完成整个项目。

如果拿上面的小汽车为例，先制作轮胎，然后制作方向盘，再制作汽车壳等。而且制作轮胎时也要通过“需求分析→软件设计→程序编码→软件测试”这四个步骤，且如果模块没有依赖关系的情况下，还可以并行开发。

▍优缺点

优点

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

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

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

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

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

缺点

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

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

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

▍适用范围

因为增量模型的基础是模块化，所以这种项目管理模式更适合需求清晰且能模块化的项目。

3.迭代模型 —— 按时间分批次交付

由于市场的快速变化，导致现在很多项目客户自身也不知道需求是什么，所以为了应对这种情况，出现了迭代开发模型，每次只设计和实现产品的一部分，然后逐步完成更多的功能。

每次设计和实现一个阶段叫做一个迭代，整个过程就像一个完整的项目一样，包含软件计划、需求分析、设计、实现与测试验收等过程，就相当于进行了一次小瀑布迭代，迭代结束时都要完成一个可以运行的交付版本。

我们继续拿小汽车举例：在最初客户提出需求是需要一个代步工具，开发团队需求不是很清晰的情况下，做了一个滑板车，客户看过之后觉得不对，我需要让它速度再快点，而且再舒服一点。

那么，第二个版本可能就做了一个电动车让客户使用，客户使用了之后还是觉得不满意，这个不能遮风挡雨，这时团队成员就为这辆车加了棚子，是一个带棚子的电动车，再次提交给客户。

然后，客户再提出需求，再次迭代……就这样一直提出需求，一直迭代完成需求变更解决问题。

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

增量模型与迭代模型的区分

▲增量模型是按照功能模块来拆分；而迭代模型则是按照时间来拆分，看单位时间内能完成多少功能。

▲还用制造汽车来理解，增量模型则是先做轮胎，再做方向盘，这样一个个模块来完成。而迭代模型则是先做一个滑板，主要功能代步满足，然后再升级成电车，代步还有速度，这样一步步迭代成最终的小汽车。

▍优缺点

优点

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

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

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

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

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

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

▍适用范围某些部分来讲，迭代模型就是应对变化而生的，所以它更适用于需求不确定的高风险项目。

4.快速原型模型 —— 低成本、快速地确认需求

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

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

但在原型开发过程中，并没有经过严谨的系统设计和规划，可靠性和性能都难以保障。所以，在实际的软件项目中，针对原型模型的这种快速、低质量的特点，通常有两种处理策略：一种是抛弃策略，另一种是附加策略。

抛弃策略是指原型只应用于需求分析阶段，在确认完需求后，原型将会抛弃，实际开发时将重新开发所有功能。

附加策略则是将原型应用于整个开发过程，原型一直在完善，不断增加新功能、新需求，直到满足客户所有需求，最终将原型变成交付客户的软件，这个策略和迭代模型优点类似。

▍原型设计工具

因为原型制作要求快速，所以并不一定需要像传统代码一样需要重新编码，有很多原型工具支持快速生成原型，比如， Axure、墨刀等，简单拖拽就可以实现简单的界面交互，同样可以达到确认需求的目的。

 ▍优缺点

优点

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

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

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

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

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

▍适用范围

过程明确、涉及面窄的小型系统；大型系统的需求阶段，用于和客户明确需求。