小白也能看懂的项目实施方法论（项目实施方法论是什么）

背景：

最近很多小伙伴说让我分享一下项目经验，比如问我的问题有，如何做一个项目？考了PMP能做项目经理吗？范围控不住怎么办？项目一直验收怎么办等等。在选题的时候，想来想去不知道选先写哪一块的内容，最后还是选了一个PMBOK里面预测式项目生命周期的方法来展开，进行讲述软件项目软件师傅交付流程，阐述瀑布式项目项目实施方法论。如果你没做过软件项目，也希望你能有耐心看完，如果看不懂请反馈我在迭代迭代，哈哈哈。

下面是正文：

软件项目实施交付流程：

项目启动—需求调研—蓝图设计—系统配置开发—系统测试—上线切换—验收–持续支持

实施方法论的价值：

• 快速实施：更有效的实施交付框架，指导顾问快速完成交付工作。
• 降低风险：利用提炼出的经验与标准模板，来降低项目风险。
• 节约成本：聚焦关键交付工作，减少无效返工的投入。

下面分别阐述实施方法论每个阶段具体要做的事，目的，价值或相关建议，供参考。

一、项目启动：

项目实施为什么要做项目启动会？

按照PMBOK这本书对项目的定义：“项目是为创造独特的产品，服务或成果而进行的临时性工作。”我们尝试简单解读一下，项目有2个特点，临时性和独特性。临时性是指的是有明确的开始时间和结束时间，不一定是项目的时间周期短。独特性是指每个项目都不尽完全相同，都有每个项目的独特之处，比如交付的产品，服务，成果，程序版本，团队成员，设备，环境因素等存在一定的独特性，每个项目都不完全相同。正是项目具有临时性和独特性，所以项目有风险。

一般来说，我们所说项目实施是指乙方给甲方交付某个项目或产品系统或履行某项服务等。假设你是项目交付的乙方，你应该知道甲方即将要新上一个系统，它很可能涉及到甲方的核心业务流程和数据。所以在实施进场后，一般是需要经历一个“漫长”（视项目大小而定）的需求调研过程，需要和甲方多个部门的关键需求方进行系统需求调研，流程沟通和流程梳理等，这些过程不仅在短期内将改变甲方员工的工作方式，增加了他们的工作量，甚至在调研过程中甲方的组织架构调整，原本需求方的负责人发生变化，需求决策人也可能跟着发生变化，权责利再分配等等问题，都会导致你按时成功交付项目的阻力重重，处处都是风险。

启动会要达到什么目的？

• 认识客户方高层
• 吸引高层注意，提升关注度，重视项目进展。
• 分析和判断客户方对项目具有决策力的关键人物
• 了解客户关键决策人对项目的期望
• 要求客户明确参与项目的关键角色以及职责
• 了解和认识客户方接口人对项目的影响力
• 识别客户方的项目支持者与反对者
• 明确项目范围

启动会要提前准备哪些内容？

根据个人准备启动会的经验，已经把启动会的会前准备和启动会PPT等事项，主要内容，输出等做了详细的整理，以下供参考：

二、需求调研

需求调研是针对SOW里面约定的需求范围进行逐一沟通与澄清，记录调研访谈的内容，为后续的需求蓝图设计方案打好基础。

调研计划：

在入场前你要规划好一份详细的调研日程计划，然后和甲方项目经理并协调人按计划参与需求调研。

调研问卷：

在实际调研前，请提前准备要调研的问卷，并提前下发给客户方项目经理和相关需求方，让他们提前准备和梳理你要开始调研的需求或问题。

调研内容：

业务流程，数据流向，业务表单(实体表单)，管理诉求(权限/报表/监控等)

调研目的：

进一步细化了解SOW中的需求内容，并为蓝图设计提供设计依据，讲得清楚说的明白。

需求调研CheckList:

根据个人准备需求调研的经历，已经把需求调研的相关事项，主要内容，输出的交付物等做了详细的整理，以下供参考：

三 蓝图设计

蓝图设计是根据前期的需求调研，SOW等内容进行综合需求分析，在理解了客户方系统业务需求，管理诉求之后，输出的一份系统建设方案的汇报材料。主要内容涵盖项目的背景，本期目标，长远目标，前期的工作成果，设计方案展示等内容。蓝图汇报之后，双方需要尽快进行蓝图确认，以便基于蓝图方案进行下一步配置开发和系统落地。

蓝图设计的目的：

主要阐述下一阶段将参照蓝图方案中的《业务流程图》，《系统流程图》，《系统集成设计方案》等进行系统配置开发，将宏观的系统规划切实落地到实际系统建设的中。

蓝图设计的价值：

给客户方的决策层和管理层重申项目目标，项目范围，展示蓝图方案等，再次塑项目价值，调动高层信心，持续甚至更强有力的提供各类资源和支持，保障项目顺利推进下去。

蓝图设计方案汇报PPT应包含的内容CheckList：

四 系统配置开发

配置开发我这里合二为一，它实际应该为系统配置和系统开发两个环节。如果是系统标准功能实施，一般只需要根据需求方案进行系统配置即可。如果是含有系统集成等相关非标功能的开发等，需要进行配置及开发两个环节。

系统配置开发清单：

五 系统测试

一般系统测试分为单元集成测试和用户UAT测试，单元测试主要是项目涉及的双方项目组或多方项目成员内部做集成测试，保证集成的功能，流程 ，数据等测试正常，测试点主要偏重系统接口，系统性能，数据交互等是否符合标准。用户UAT测试，主要是客户方关键用户参与使用测试和验收测试，测试点主要偏重系统业务流程，各角色操作人员的操作是否便利，管理人员是否能监控和查看报表等，偏重业务功能和流程等。如果要求严格的甲方，还会强制要求进行渗透测试等进行系统安全性等考量，作为乙方应当配合甲方完成安全性等其他的相关测试。

相关建议：

在实际项目实施过程中，根据项目大小，实施的范围，功能标准与非标，安全性等实际情况进行适当的裁剪。

如果是简单的标准化功能实施配置，只需要进行简单的系统功能测试，就立即进入UAT测试阶段。

如果是较大的集成项目，且对测试要求比较严格的，就按照标准的测试要求严格执行保障测试结果符合要求。

另外当甲方测试反馈了很多问题，要求你需要在上线前进行整改完毕，遇到这种情况要妥善处理，不要完全听从甲方的要求，要合理和甲方谈判，对测试问题分好优先级，哪些问题上线前必须解决，哪些问题可以上线后陆续解决，哪些问题甚至可以上线后不解决等等。

总之，既要要保证测试充分，暴露所有系统问题，也要保证系统主流程能跑通，不影响核心业务，要及时推进按时交付上线，然后迅速迭代。

千万不要想着解决所有问题在推上线，千万不要这样追求完美。只有成功的项目，没有完美的项目。

六 切换准备：

系统能否如期上线，就要看切换准备这个阶段各项工作是否做得到位。切换准备这个阶段需要做历史数据的正式导入，数据库切换，生产系统切换技术方案和评估，切换失败的回滚机制等。

相关建议如下：

1、数据备份：

在系统升级切换前，应联系专业运维人员进行系统程序，数据库等相关数据备份，以免系统升级异常导致故障且不能恢复数据的问题。

2、历史数据导入的问题：

一般大一点的客户都会使用过其他系统，大部分时候都是存在历史数据，且要求导入系统。在系统建设早期，就应当识别客户的导入历史数据的诉求，且提前提供数据模版让客户提前整理数据。从一般项目实践经验来看，大部分因数据导入影响系统切换的都是没有提前安排进行数据清洗和结构化处理数据导致。在临近上线前一两天，以为导数据很快，可在实际导入数据过程中发现很多数据本身，或其他技术问题，或工作量的问题，导致通宵导入数据且上线延期的案例比比皆是。

3、切换方案准备：

提前准备好系统切换方案，切换步骤，切换时间 ，切换故障紧急联系人，应急问题处理机制，切换失败回滚机制等等，准备好召集双方的项目团队成员进行评审，并切换方案进行修正，达成一致后，邮件抄送所有的项目相关方，让他们知悉。

4、系统培训：

在上线前，要组织对关键用户进行系统培训，然后协助关键相关方对所有系统用户做好系统培训，并收集用户的使用反馈，及时对系统进行优化。

七 系统上线：

按照评审通过的项目上线切换方案执行系统切换，切换后密切关注系统运行情况和用户反馈，积极的处理系统问题，保障系统平稳运行，至少不出现系统奔溃，主流程阻塞等致命问题。

八 验收与持续支持：

按合同或协议约定，一般系统上线后一段时间后，需要执行验收流程，对项目进行验收。作为乙方，要在上线后尽快获得甲方的认可和系统的正式验收，越早验收越好。系统验收后，意味着项目实施进行项目结束阶段。项目组需要尽快与售后的部门进行内部项目交接，进入客户项目的售后运维阶段，由售后部门进行客户后续的项目支持，项目组成员逐步撤出。在内部交接的过程中，一定要注意交付物文件完整，所有实施过程的相关项目文件，如调研纪要，蓝图设计方案，需求设计说明书，流程图，接口文档，业务开发代码等全部交接好，一是便于售后技术支持人员能支持服务客户，二是，方便做好项目文件归档及交付物文档在验收环节发送给客户。

以上就是我对项目管理实施方法论以及一些个人相关经验的总结分享，希望对你有帮助。如果有用，谢谢你用发财的小手点一下右下角的“赞”和“在看”，分享给更多的人看。