您现在的位置是：主页 > 招投标学堂 >

项目管理的四大模型，项目经理必知！！！

2022-02-19 08:43:051113人已围观 0

怎么判断一个人对一件事是否了解透彻？其实就是“知其然”且“知其所以然”。项目管理这个岗位的人也是一样，但因国内企业自身培训较少，很多项目经理都是没有基础知识的情况下直接上岗，所以，可能会比较欠缺这块的知识。

而时代的迅速发展又奠定了管理模式会在原有的基础上更加优化和迭代，所以，作为项目经理，一定要清楚的知道这几种基本的项目管理模型，才能举一反三的灵活运用它，今天我们就来一起学习一下这四种项目管理模型。

瀑布模型 —— 按照流程一次性交付
瀑布模型是应用最广泛，且最早出现的系统的项目管理模型，后续的模型很多都是在此基础上演变而成的，所以要想透彻的了解各个模型的应用，知道瀑布模型是根本。
▍瀑布模型的六个阶段

1）软件计划通过市场调研以及和需求方的沟通，确定项目目标，进行可行性研究，以确定项目是否可行，利益几何，用于判断企业是否接受该项目。2）需求分析深挖需求方的所有需求，进行分析，以确定需求方最终想要达到的效果，进而保证做出客户想要的产品。一般这个步骤需要和客户反复确认，最终形成需求文档，作为开发的依据。

3）软件设计

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

4）程序编码

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

5）软件测试

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

6）运行维护

软件开发完成，即可投入使用。但不可保证用户使用中是否会出现问题，所以项目团队可能需要继续维护，修复错误和增加功能。
▍举个例子
比如，客户要制造出一个小汽车。

首先，客户提出想法，想要一个舒服的挡风遮雨的代步工具（初步需求）。
客户一开始可能并不清楚想要什么样子（对需求没有那么清晰）。
项目经理开始找客户确认：用途是什么，想要几个座位，想要什么风格，什么时间完工，预算多少等等（需求确认）。
项目经理根据客户需求做商业分析，市场调研，项目成本思考，对比工期和预算，评估是否可做，是否值得做（可行性研究）。
评估确定可行，约定价钱和时间，签订合同（细想，制定项目计划）。
项目经理和客户确认需求，例如几个座位，是否有智能设备等等（需求分析）。
设计出原型图和客户确认，设计需要什么组成部分，例如轮胎怎么做，方向盘怎么做等（软件设计）。
开始正式制作零件和组装（程序编码）。
这个时候客户来看，只能看到零件，比如方向盘、轮胎等（中间客户看不到结果，只有最后能看到结果）。
做到这客户可能说，空间太小了，四个座不够要六个座。这意味着设计图要重新调整，做好的车壳需要加长等（瀑布模型不能做到随时响应变更，越到后期代价越大）。
零件制作好，且组装完成，测试人员进行测试，是否满足质量要求，是否需要修改（测试）。
最后通过验收，客户开走车子。

▍优缺点
优点：

计划性较强，每个阶段都有其明确的任务，让软件开发过程可控。
很好的分工协作，产品经理、项目经理、开发、测试等都有其相应的工作。
质量有保证，每个阶段都有相应的文档留存和评审，可以帮助在动手之前思考的更清晰。编码结束后也会有按照需求文档严密的测试，让质量更有保障。

缺点：

难以灵活的响应需求变更，对于最初不清楚需求的客户不友好。
工作量分布不均匀，项目安排是阶段性的，很多工作人员不能同时做事，可能会导致人力的浪费，比如导致程序员开发时，测试人员需要等着结果。
进度控制难度加大，若前期进度受阻，就不得不压缩后续各阶段时间。
不能及时给客户反馈，到最后才能看到结果。

▍适用范围

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

增量模型 —— 按模块分批次交付
瀑布开发模型是一个一次性交付的过程，也就是说这一个项目通过了这六个“软件计划→需求分析→软件设计→程序编码→软件测试→运行维护”开发步骤，整个的项目就算完成了。
但是增量模型是一个分模块交付的过程，它是把“需求分析→软件设计→程序编码→软件测试”这四个步骤摘出来，运行了多次，然后完成的整个项目。
如果还拿上面的小汽车作为例子的话，就是先制作轮胎、然后制作方向盘，再后面是汽车壳等。而且制作轮胎时也要通过需求分析→软件设计→程序编码→软件测试”这四个步骤，且如果模块没有依赖关系的情况下，还可以并行开发。

▍优缺点

优点：

系统模块化，可以分批次的交付产品，用户可以及时得到反馈，了解项目的进展。
分批次开发降低了开发的风向，一个开发周期的问题不会影响整体开发进度。
开发顺序灵活，可以根据组件优先级，成员的时间进度进行优先级排序。
很好的分工协作，产品经理、项目经理、开发、测试等都有其相应的工作。
质量有保证，每个阶段都有相应的文档留存和评审，可以帮助在动手之前思考的更清晰。编码结束后也会有按照需求文档严密的测试，让质量更有保障。

缺点：

难以灵活的响应需求变更，对于最初不清楚需求的客户不友好。
要求待开发的项目可以进行系统化模考划分。
模块并行进行，很可能导致成员工作的并行进行，例如，在做某一模块内容的同时，需要更改另一模块的bug内容。

▍适用范围

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

迭代模型 —— 按时间分批次交付
由于市场的快速变化，导致现在很多项目客户自身也不知道需求是什么，所以为了应对这种情况，出现了迭代开发模型，每次只设计和实现产品的一部分，然后逐步完成更多的功能。
每次设计和实现一个阶段叫做一个迭代，整个过程就像一个完整的项目一样，包含软件计划、需求分析、设计、实现与测试验收等过程，就相当于进行了一次小瀑布，迭代结束时都要完成一个可以运行的交付版本。
我们继续拿小汽车举例：在最初客户提出需求是需要一个代步工具，开发团队需求不是很清晰的情况下，做了一个滑板车，用户看过之后觉得不对，我需要它速度再快点，而且再舒服一点。
那么第二个版本可能就做了一个电动车让客户使用，客户使用了之后呢？还是觉得不满意，这个不能遮风挡雨呀，这个时候团队成员就为这辆车加了棚子，是一个带棚子的电动车，再次提交给客户。
然后，用户再提出需求，再次迭代......就这样一直提出需求，一直迭代完成需求变更解决问题。
注意：在迭代模型中，整个项目会被拆分成一系列的小迭代。通常一个迭代的时间都是固定的，不会太长，例如 2-4 周。每次迭代只实现一部分功能，做能在这个周期内完成的功能。

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

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

▍优缺点
优点：

灵活的响应需求变更，做最符合客户需求的产品。
快速交付产品，降低了产品无法按照既定进度进入市场的风险。
有频率且短时间内持续有产品交付，用户可以及时得到积极的反馈。
团队成员并行工作，有利于节省时间和人力

缺点：

项目的整体时间不好预估，只能短时规划项目进度。
对项目经理和团队成员的要求较高，需要快速应对变化的能力，且一精多专。

▍适用范围

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

快速原型模型 —— 低成本快速的确认需求
由于种种原因，在需求分析阶段得到完全一致、准确、合理的需求说明是很困难的，所以为了解决这个问题，让双方的理解达成一致，出现了快速原型模型方法，也叫原型模型。
它是指得到需求后迅速建造一个可以运行的软件原型，给到用户测试，搜集反馈，然后反复修改确认，直至开发出的软件能真正反映用户的需求。
但在原型开发过程中，并没有经过严谨的系统设计和规划，可靠性和性能都难以保障。所以在实际的软件项目中，针对原型模型的这种快速、低质量的特点，通常有两种处理策略：抛弃策略和附加策略。
抛弃策略是指原型只应用于需求分析阶段，在确认完需求后，原型将会抛弃，实际开发时，将重新开发所有功能。
附加策略则是将原型应用于整个开发过程，原型一直在完善，不断增加新功能新需求，直到满足客户所有需求，最终将原型变成交付客户的软件，这个策略和迭代模型优点类似。

▍原型设计工具

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

▍优缺点

优点：