谈项目上线(9.21)

临近项目上线，各个项目组基本又都到了一级战备的状态，自己做这种集团性的项目也已经多次，也让自己想起这么多年做项目以来遇到的真正让自己感受压力和有记忆的上线场景。

说到第一个，估计要追溯到10多年前还在中兴通讯的时候，自己原来做PDM项目的架构，后转回去担任SRM项目的项目经理，时间应该在04年还是05年PDM项目临近上线的时候，原PDM项目经理提出离职，同时项目本身已经经过多轮的用户UAT测试，领导也给出了周末必须要上线的命令。

可以说自己是临危受命，回去担任PDM项目的项目经理，比较好的就是项目组的同事基本都是原来共事过的，相互自己也都比较熟悉，包括各自的技能和工作能力。但是风险最大的仍然是大量棘手的问题或Bug需要去解决，其次就是整个团队士气较为低下。而这个时候我做两件事，一件事情就是真正将当前遇到的各类问题理顺，分清优先级，搞清楚哪些才是影响到最终上线的关键问题；其次就是鼓舞士气，这个鼓舞绝对不是空喊口号，或者简单的团队聚餐活动就能够解决的，而真正重要的就是首先你回到这个项目，让项目团队的人觉得这个项目仍然还有希望能成功，其次就是自己亲自上阵，解决掉几个关键问题或给出几个关键问题的解决方案，当我把几个关键问题解决掉后，我自己也就清楚，整个上线风险已经化解，更加重要的是团队士气得以回归。

这个也是我一直在讲的，做IT这行没有纯粹的项目管理，而是IT技术+管理，关键时候技术能力比管理更加重要，就像上面说的场景，如何换一个人来，不熟悉PDM，不懂原来的技术框架，估计想真正让项目平稳下来难度极大。估计这也是当时部门领导最终选择我去接这个活的一个关键原因。

09年从中兴离职后，就开始接触类似移动和联通这种大型集团型项目，而自己有影响的仍然是几个关键事情。

时间首先要追溯回10年的中国联通集团大SOA项目，当时项目已经上线，但是遇到一个相对辣手的问题，就是Oracle SOA产品经常出现内存溢出并重启，可想而知，这个故障对业务系统和接口服务调用的影响相当大。虽然说该问题不经常出现，但是给客户的感觉就是整个集成平台产品不稳定，会不定期出现故障重启。

一开始由于我没有在项目组里面常呆，同时由于该问题不是经常出现，因此也没有引起足够的重视，而后面到了大量试点省份上线后，该问题越来越突出，同时问题也被汇报到高层。到了这个时候问题就必须要解决。而这个也给我们一个重要的启示，就是做项目对于自己的问题一定不要藏着掖着，或者存在任何的侥幸心理，任何小问题如果一开始不解决，最终都可能演变成一个大问题或故障。

从报出该问题到引起重视差不多已经过去了半年的时间，而这个问题从我直接介入开始分析处理，差不多用2-3个月的时间才彻底解决。大家可以翻看我10年的博客日志，有专门记录该OC4J重启故障分析和解决的过程。整个过程仍然是相对曲折，不断的去尝试和试错，最终才调整出最优的JVM启动方案。通过最优的JVM启动参数，PermSize和HeapSize内存的设置，并行回收机制的设置，彻底解决了该问题。

还有一件特别印象深刻的就是11年集团型大项目，涉及到ODI大数据传输服务上线的时候，原来的方案传输500万左右的数据量差不多需要1个晚上才能够传输完毕，而这个性能远远无法满足大数据传输和集成的需求。但是项目也是下周就要上线。

项目组也尝试了多种方法去解决，但是没有结果。直接搞定客户都没有脾气。而当时项目经理基本处于死马当成活马医的放弃边缘。当时自己主要精力都在联通项目组，当遇到这个问题后才引起我足够重视，转过去分析和诊断当前的问题。

对于Oracle ODI，自己原来完全没有接触过，到花了不到1周的时间彻底自己亲自重新配置ODI服务，验证新方案可行通过（核心调整对接Sybase数据库，采用原生的BCP知识模块），由10小时缩短到10分钟完成数据传输和集成。在这种紧张节奏下，自己印象里面也是多天都搞到凌晨2,3点才休息。第二天一早又要赶到客户那里进一步验证ODI传输服务的性能，分析新方案的可行性。

所有问题均解决后，自己能够给出一个自己完全验证通过的技术或方法给到最终的开发，那么我的工作也就完成了，剩下的只是工作量的事情。这也是对于关键项目相对重要的一点，真正一个关键项目到了关键时候，剩余的往往一定是最难啃的骨头，最辣手的问题。

这个时候整个团队需要的一定不是什么高谈阔论，什么强压下来的命令，而是需要给出切实可行，同时最好是验证通过的技术解决方案去解决问题。越是关键的项目，决定成败的越是这种关键的技术能力。这也是这么多年下来，为何自己在做项目管理的时候，在技术这块一直跟踪的比较细，亲临一线的关键原因。

对一个项目的判断你如何才能够做到完全有把握，最简单的就是自己对所有关键点都一清二楚，同时经过自己的实证和验证，只有这样你往往才是最有把握的。