软件实施方法论(通用)
软件项目实施交付模型
很多领域流传着'别人家'的传说：别人家的孩子学习成绩好才艺多还长得帅，别人家的客户钱多人傻速来，别人家的公司不加班产品做得好工资还发的倍儿高。这一切事情实际上都有'常量'和'变量'，比如你的竞争对手突然一夜之间，转型去做房地产了这种变量，可遇不可求而且不受自身控制。一家公司无论是经营还是优化经营模式，都是从控制'常量'开始。在企业软件部署实施中，这种常量（稳定的事情，或者变动但是可控制，可预测的）的控制，就是具体的实施模型和方法论。
没有模型
时间：未知
资源：未知
风险：未知
产出：未知
如果在使用量上来讲，软件部署使用中最多用到的应该是'没有模型'。也就是用户/软件设计者想到了什么，或者一时心血来潮有了新的创意，就马上告诉软件部署人员/开发人员自己的想法。然后一边想，一边做。做了觉得不满意，又开始想新的想法；亦或者是发现之前想打的疏漏，又马上想新的点子去补救。虽说大道至简，但是往往需要一定的功力才能至简的了。往往按这种情况发展下去，需求方会觉得焦头烂额，开发方会觉得叫苦不迭，最后别别扭扭的产出个四不像，或者是什么都没有产出，甚至是大打出手（咳咳），所以这种粗放式的所向即所得模式，个人可以试试，团队协作的话效果往往不会很好。
瀑布模型
时间：一般
资源：一般
风险：一般
产出：一般
1970年就诞生的模型，对于软件部署中的情境做了最理想的串行假设：我们首先选好什么软件/用什么样的方式来开发，然后呢，跟用户谈一下他们的所有需求，分析一下，写成文档，然后就可以按文档开始做了噢。做完了交付测试一下。好吧？没问题了吧？那我们开始正式使用了，顺便再维护一下。瀑布模型逻辑简单，结构清晰，就是一个字：稳。一件事情完成才能做另一件，而且必须有文档记录和验证。但是在2017年的今天，稳已经不是主旋律了，快才是。工程师不再愿意写长长的流水账设计文档，公司往往需要需求的功能可以马上实现，用户希望他们的想法往往可以马上看到。瀑布的水还在半空中，上游下游就可能已经面目全非。时代在发展，理所当然也会慢慢变成匪夷所思。
喷泉模型
时间：短
资源：多
风险：大
产出：良
相比于串行的瀑布模型，喷泉模型对软件部署做了并行的假设：小张你们BI哪块程序出来了吧，赶快安排用户做单元测试。小王上次财务部谈了需求功能设计出来了没有，没有赶快出。小K人力那边测试完了觉得薪酬哪块可以再细化一下具体你找他们谈。团队面对的是一个个具体的功能块，每块都有快速迭代，又没有明显边界的'子项目'，像一个喷泉一样源源不断，周而复始，各自独立而又统一。这种方式灵活度满分，可以高效快速的拥有可见的成果。但是并行意味着更多的人员需求，同时灵活也意味着更难管理。想要让喷泉源源不断而又一致稳定，管控水平是一个核心。
快速原型模型
时间：中等偏长
资源：多
风险：一般
产出：优
快速原型的核心就在于原型。围绕着原型，伴随着原型从0%到100%的完成度，用户和程序设计人员满满一起认识到需求到底是什么，我们怎么样的方式来实现这个需求是最优的，未来可能的发展方向又是什么。快速原型的方式在应对模糊需求的时候有奇效。老板说，我要一个CRM，你去设计一下。？（黑人问号）。用快速原型的方式，做几个简单的区块，甚至是用Axure仅仅停留在设计阶段的展示，都能对模糊的需求有一个快速的，通过前20%对后80%工作的定位。但是原型的品控，方向的把控也是这个模型的核心，是区别与原型一步步迭代和反反复复做一件同样的事情和核心点。抓住核心，看到本质，是做快速原型而不是无头苍蝇的基本要素。
螺旋模型
时间：很长
资源：多
风险：低
产出：一般
前人栽树后人乘凉，螺旋模型是瀑布模型和快速原型模型集合风险控制的新理论。螺旋模型从风控角度出发，以瀑布模型为框架来实现产品的快速原型化。一小段一小段的来构建系统，并且在每个'段'都进行具体的风险识别，控制&分析工作。从而使工作进度像螺旋一样一层一层，一级一级的来到核心。螺旋模型按段来分项目，并且每段都有严格的风控，一方面产出更直观，另一方面这种每个阶段的回顾和评估，也能保证方向不会南辕北辙。由于这方面的特性，因此一般是高风险，强风控的项目会用到螺旋模型，使用场景比较局限。而且风险识别能力是一门独到的学问，对人员的素质要求也不一般。
软件项目实施交付流程：
实施方法论的价值：
- 快速实施：更有效的实施交付框架，指导顾问快速完成交付工作。
- 降低风险：利用提炼出的经验与标准模板，来降低项目风险。
- 节约成本：聚焦关键交付工作，减少无效返工的投入。
下面分别阐述实施方法论每个阶段具体要做的事，目的，价值或相关建议，供参考。
一、项目启动：
项目实施为什么要做项目启动会？
按照PMBOK这本书对项目的定义："项目是为创造独特的产品，服务或成果而进行的临时性工作。"我们尝试简单解读一下，项目有2个特点，临时性和独特性。临时性是指的是有明确的开始时间和结束时间，不一定是项目的时间周期短。独特性是指每个项目都不尽完全相同，都有每个项目的独特之处，比如交付的产品，服务，成果，程序版本，团队成员，设备，环境因素等存在一定的独特性，每个项目都不完全相同。正是项目具有临时性和独特性，所以项目有风险。
一般来说，我们所说项目实施是指乙方给甲方交付某个项目或产品系统或履行某项服务等。假设你是项目交付的乙方，你应该知道甲方即将要新上一个系统，它很可能涉及到甲方的核心业务流程和数据。所以在实施进场后，一般是需要经历一个"漫长"（视项目大小而定）的需求调研过程，需要和甲方多个部门的关键需求方进行系统需求调研，流程沟通和流程梳理等，这些过程不仅在短期内将改变甲方员工的工作方式，增加了他们的工作量，甚至在调研过程中甲方的组织架构调整，原本需求方的负责人发生变化，需求决策人也可能跟着发生变化，权责利再分配等等问题，都会导致你按时成功交付项目的阻力重重，处处都是风险。
启动会要达到什么目的？
- 认识客户方高层
- 吸引高层注意，提升关注度，重视项目进展。
- 分析和判断客户方对项目具有决策力的关键人物
- 了解客户关键决策人对项目的期望
- 要求客户明确参与项目的关键角色以及职责
- 了解和认识客户方接口人对项目的影响力
- 识别客户方的项目支持者与反对者
- 明确项目范围
启动会要提前准备哪些内容？
根据个人准备启动会的经验，已经把启动会的会前准备和启动会PPT等事项，主要内容，输出等做了详细的整理，以下供参考：
二、需求调研
需求调研是针对SOW里面约定的需求范围进行逐一沟通与澄清，记录调研访谈的内容，为后续的需求蓝图设计方案打好基础。
调研计划：
在入场前你要规划好一份详细的调研日程计划，然后和甲方项目经理并协调人按计划参与需求调研。
调研问卷：
在实际调研前，请提前准备要调研的问卷，并提前下发给客户方项目经理和相关需求方，让他们提前准备和梳理你要开始调研的需求或问题。
调研内容：
业务流程，数据流向，业务表单(实体表单)，管理诉求(权限/报表/监控等)
调研目的：
进一步细化了解SOW中的需求内容，并为蓝图设计提供设计依据，讲的清楚说的明白。
需求调研CheckList:
根据个人准备需求调研的经历，已经把需求调研的相关事项，主要内容，输出的交付物等做了详细的整理，以下供参考：
三 蓝图设计
蓝图设计是根据前期的需求调研，SOW等内容进行综合需求分析，在理解了客户方系统业务需求，管理诉求之后，输出的一份系统建设方案的汇报材料。主要内容涵盖项目的背景，本期目标，长远目标，前期的工作成果，设计方案展示等内容。蓝图汇报之后，双方需要尽快进行蓝图确认，以便基于蓝图方案进行下一步配置开发和系统落地。
蓝图设计的目的：
主要阐述下一阶段将参照蓝图方案中的《业务流程图》，《系统流程图》，《系统集成设计方案》等进行系统配置开发，将宏观的系统规划切实落地到实际系统建设的中。
蓝图设计的价值：
给客户方的决策层和管理层重申项目目标，项目范围，展示蓝图方案等，再次塑项目价值，调动高层信心，持续甚至更强有力的提供各类资源和支持，保障项目顺利推进下去。
蓝图设计方案汇报PPT应包含的内容CheckList：
四 系统配置开发
配置开发我这里合二为一，它实际应该为系统配置和系统开发两个环节。如果是系统标准功能实施，一般只需要根据需求方案进行系统配置即可。如果是含有系统集成等相关非标功能的开发等，需要进行配置及开发两个环节。
系统配置开发清单：
五 系统测试
一般系统测试分为单元集成测试和用户UAT测试，单元测试主要是项目涉及的双方项目组或多方项目成员内部做集成测试，保证集成的功能，流程 ，数据等测试正常，测试点主要偏重系统接口，系统性能，数据交互等是否符合标准。用户UAT测试，主要是客户方关键用户参与使用测试和验收测试，测试点主要偏重系统业务流程，各角色操作人员的操作是否便利，管理人员是否能监控和查看报表等，偏重业务功能和流程等。如果要求严格的甲方，还会强制要求进行渗透测试等进行系统安全性等考量，作为乙方应当配合甲方完成安全性等其他的相关测试。
相关建议：
在实际项目实施过程中，根据项目大小，实施的范围，功能标准与非标，安全性等实际情况进行适当的裁剪。
如果是简单的标准化功能实施配置，只需要进行简单的系统功能测试，就立即进入UAT测试阶段。
如果是较大的集成项目，且对测试要求比较严格的，就按照标准的测试要求严格执行保障测试结果符合要求。
另外当甲方测试反馈了很多问题，要求你需要在上线前进行整改完毕，遇到这种情况要妥善处理，不要完全听从甲方的要求，要合理和甲方谈判，对测试问题分好优先级，哪些问题上线前必须解决，哪些问题可以上线后陆续解决，哪些问题甚至可以上线后不解决等等。
总之，既要要保证测试充分，暴露所有系统问题，也要保证系统主流程能跑通，不影响核心业务，要及时推进按时交付上线，然后迅速迭代。
千万不要想着解决所有问题在推上线，千万不要这样追求完美。只有成功的项目，没有完美的项目。
六 切换准备：
系统能否如期上线，就要看切换准备这个阶段各项工作是否做得到位。切换准备这个阶段需要做历史数据的正式导入，数据库切换，生产系统切换技术方案和评估，切换失败的回滚机制等。
相关建议如下：
1、数据备份：
在系统升级切换前，应联系专业运维人员进行系统程序，数据库等相关数据备份，以免系统升级异常导致故障且不能恢复数据的问题。
2、历史数据导入的问题：
一般大一点的客户都会使用过其他系统，大部分时候都是存在历史数据，且要求导入系统。在系统建设早期，就应当识别客户的导入历史数据的诉求，且提前提供数据模版让客户提前整理数据。从一般项目实践经验来看，大部分因数据导入影响系统切换的都是没有提前安排进行数据清洗和结构化处理数据导致。在临近上线前一两天，以为导数据很快，可在实际导入数据过程中发现很多数据本身，或其他技术问题，或工作量的问题，导致通宵导入数据且上线延期的案例比比皆是。
3、切换方案准备：
提前准备好系统切换方案，切换步骤，切换时间 ，切换故障紧急联系人，应急问题处理机制，切换失败回滚机制等等，准备好召集双方的项目团队成员进行评审，并切换方案进行修正，达成一致后，邮件抄送所有的项目相关方，让他们知悉。
4、系统培训：
在上线前，要组织对关键用户进行系统培训，然后协助关键相关方对所有系统用户做好系统培训，并收集用户的使用反馈，及时对系统进行优化。
七 系统上线：
按照评审通过的项目上线切换方案执行系统切换，切换后密切关注系统运行情况和用户反馈，积极的处理系统问题，保障系统平稳运行，至少不出现系统奔溃，主流程阻塞等致命问题。
八 验收与持续支持：
按合同或协议约定，一般系统上线后一段时间后，需要执行验收流程，对项目进行验收。作为乙方，要在上线后尽快获得甲方的认可和系统的正式验收，越早验收越好。系统验收后，意味着项目实施进行项目结束阶段。项目组需要尽快与售后的部门进行内部项目交接，进入客户项目的售后运维阶段，由售后部门进行客户后续的项目支持，项目组成员逐步撤出。在内部交接的过程中，一定要注意交付物文件完整，所有实施过程的相关项目文件，如调研纪要，蓝图设计方案，需求设计说明书，流程图，接口文档，业务开发代码等全部交接好，一是便于售后技术支持人员能支持服务客户，二是，方便做好项目文件归档及交付物文档在验收环节发送给客户。
