新旧系统切换与项目小结

        话说，互联网这个行业，日新月异。需求改了又改，架构调了又整。开发完了，还没上线，就废弃了等等。那对于新旧系统到了切换的时候，会出现什么样的问题，这样的问题我们是否已经有方案呢？或是都还未曾考虑过呢？又或是，对于系统切换，我们有什么指导的原则或是步骤呢？

       项目收尾了，是否需要一个小结呢？需要一个什么样的小结？可以用它做什么？

一、新旧系统切换

尽量去摈弃各个系统之间的异处以及过于细节的问题。想一想，有没有什么共性可以指导呢？网上搜搜，多搜一下。会发现还真有貌似的共同特性。

1.1、准备工作

a） 动员

动员，需要将相关人员的那种基情，那种意识，调高一个级别。

b）人员培训

包括，部署，使用，等相关人员，熟悉新系统特性，哪些功能与旧有的不一致，操作手法等。

c）文档准备

升级切换指导文档，操作手册，使用手册等，注意事项

d）数据准备

包括但不限于，数据迁移，静态数据准备，基础数据准备，动态数据准备等

e）切换方案

选择什么样的一个方案，是直接替换，还是并行一段，还是分阶段。

1.2、应急措施

         既然是要应急，当然需要成立一个应急小组，同时还有各种预备方案，以便解决升级，切换过程中出现的各类问题。类似成立一个临时指导办公室，当然需要选择一个领导，足以根据现场情况决定一些重大问题的调整。当然是需要负责的。

1.3、验证

       升级切换有木有问题，那赶快去验证啊。有问题再调整，或是再应急。

1.4、小结

       搞个升级，切换就要小结么？需要么？有木有必要。。。。当然是，有！！！这个是个最为宝贵的资产啊。所有的前期准备工作，以及推着继续向前，一直到开发，设计，测试，等所有的问题，在切换这个节骨眼上，反映出来。你的项目开发计划，你的开发设计代码，你的测试结果，可能都能蒙混过关。但问题往往在这里会是一股脑地拥挤出来。所以，切换过程的顺利与否很大程度上是检查你前期工作的质量，协同如何的一个最为强有力的指标。

       既然，出现了这么多问题，那就记录下，统一善后调整吧。妹的，那不是要作为项目小结了？看上去。

二、项目小结

       项目收尾了，钱款收到了，好开心。老板加工资了，哇，好爽。妹的，等下，又一个新的项目或是新的story来了，搞起，搞起，那边已经开始吆喝起来了。码农们，醒醒，开始干活了。

       经历很多这样的项目，也时常听有人讲到这些项目的结尾过程。可往往人们看到成功或是失败，很少去总结里面的漫漫过程。为什么，因为成功足以让你忘却中间过程的痛。而最终失败与那点疼比起来，那点疼还算是什么。。。。所以，我们常常忘记这个本应重视的，特别是与指导，乃至影响下一个项目开发的因素相关成功与否的工作。

有人说了，不同的项目，不同的人员构成，不同的环境，不同的。。。。。不同的，，，，是的，不同的。你每时每刻都是不同的。有木有共性，有米有。。。

      好啦好啦，光说废话了，那项目小结都小结什么玩意啊？

2.1项目开发结果

项目规模总结

项目人员总结

进度与工作量总结

等

2.2项目评价

生产率评价

质量评价

技术方法评价

等

2.3  经验和教训

可以从以下几方面总结开发中获得的经验及纠正错误或缺陷等问题的教训。

1）    管理人员的管理水平；

2）    开发人员的合理分工；

3）    项目软件经理P/S M及开发人员的技术水平；

4）    开发人员的更换；

5）    开发人员的配合及协作；

6）    用户的密切配合；

7）    需求及设计的更改；

8）    开发过程中计划的合理调整等等。

总结也总结完了，总结文档就放在那里，你在于不在，都在那里。什么鸟用，要召集大家开会学习，研讨啊，。。分享啊。。。。

本文完（想起曾经的一个项目，新系统上去了，数据没了，，，真的没了，，，总经理那个，，，欲哭无泪。）