软件外包服务岗前技能训练（二）实施方法论

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

实施方法论的价值：

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

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

一、项目启动：

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

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

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

启动会要达到什么目的？

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

二、需求调研

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

调研计划：

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

调研问卷：

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

调研内容：

业务现状，需求背景，核心痛点，业务流程，数据流向，业务表单(实体表单)，管理诉求(权限/报表/监控等)

调研目的：

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

三 蓝图设计：

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

蓝图设计的目的：

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

蓝图设计的价值：

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

四 系统配置开发

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

五 系统测试

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

相关建议：

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

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

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

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

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

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

六 切换准备：

系统能否如期上线，就要看切换准备这个阶段，各项工作是否做得到位。切换准备这个阶段，需要做历史数据的正式导入，数据库切换，生产系统切换技术方案和评估，切换失败的回滚机制等准备工作，在上线前，需要提前模拟演练系统切换的整个程序过程，步骤，系统切换导致故障的应急处理流程等，确保能顺利切换上线成功。

相关建议如下：

1、数据备份：

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

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

一般大一点的客户都会使用过其他系统，大部分时候都是存在历史数据，且要求导入系统。在系统建设早期，就应当识别客户的导入历史数据的诉求，且提前提供数据模版让客户提前整理数据。从一般项目实践经验来看，大部分因历史数据导入，影响系统切换的，都是没有提前安排进行数据清洗和结构化处理数据导致。很多PM前期可能赶工，在临近上线前一两天才开始准备数据导入的事情，以为导数据很快，可在实际导入数据过程中，临时发现很多数据本身问题，或其他技术问题，或工作量的问题等等，导致项目组通宵导入数据，并因不能导入数据引起项目延期的案例比比皆是。因此大家务必要重视历史数据的导入问题，提前做好历史数据的清洗，结构化处理等，另外在切换前提前验证导入工具，模版，数据格式是否能正常工作。

3、切换方案准备：

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

4、系统培训：

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

七 系统上线：

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

当然，有些人可能会遇到一些这样的情况： "切换上线后，客户方抱怨系统问题太多，影响他们操作效率等要求下线。"

作为PM，你要明白，只要没有系统奔溃，主流程阻塞等问题，如果客户给你多大的压力，你一定要坚持系统保持线上运行，然后积极的协调项目组同事及时修复系统问题和迭代。如果你下线了，你将面临更多的问题，因为你除了要修复系统本身的问题之外，你还要帮客户处理切换过程中产生的历史数据，这些工作量大不说，还可能会导致业务数据出错，影响系统作业流程或财务数据结算，那问题就更大了。

八 验收与持续支持：

按合同或协议约定，一般系统上线一段时间后，需要执行验收流程，对项目进行验收。作为乙方，要在上线后尽快获得甲方的认可和系统的正式验收，越早验收越好。系统验收后，意味着项目实施进行项目收尾阶段。项目组需要尽快与售后的部门进行内部项目交接，进入客户项目的售后运维阶段，由售后部门进行客户后续的项目支持，项目组实施成员逐步撤出。

在内部交接的过程中，一定要注意交付物文件完整，所有实施过程的相关项目文件，如调研纪要，蓝图设计方案，需求设计说明书，流程图，接口文档，业务开发代码等全部交接好。这样，一是便于售后技术支持人员，能支持服务好客户，二是，方便做好项目文件归档，在验收环节可以完整的发送给客户。