谁都希望我们所做的项目能够一帆风顺地完成，但还多时候，现实往往不像我们期待的那样完美。在软件工程实施的过程中，我们的团队除了会遇到软件工程技术方面的问题还会遇到很多跨学科的问题，如：团队建设的问题，如何提高团队绩效?干系人的问题，如何获得客户的理解，我们又是否已经理解我们的客户?如何控制我们的工作范围的问题?如何控制我们的成本的问题等等。我们也许正是经历坎坷、挑战、甚至意外后才得以历练与成长。下面根据我个人的项目经历，谈谈自己的看法。
1、暗藏风险的开局
作为A市政府十二项惠民工程之一，“E-Study”是本年度A市为促进教育资源共享最为重要的一个信息化实施项目，投资规模近2亿元。我司教育事业部有幸参与项目的前期设计中，承担了整个系统软件平台的搭建工作。由于项目庞大，总共有十家分包商，此前，主管单位也没有做过类似规模的项目。并且，该项目是当年预算、当年审批、当年收效的项目，整体回顾起来项目中的很大决策从现在看来均显得仓促，在立项阶段，很多工作做的不够扎实，前期的调研，可行研究工作等做的不够充分。
2、泰山压顶的局面
由于本项目是一个面向公网的公共系统，最终用户又是整个A市的中小学生，因此系统崩溃后，项目组面临的巨大压力，尽管教委下发的只是修改密码的任务，但社会上传出了很不好的声音。教委的座机几乎被打爆了，每个人都能感受到学生和家长的抱怨，甚至恼怒。我司高层领导紧急抽调精干力量及时赶赴现场，制定排查计划，开展问题的排查工作。
3、突入起来的危机
经过大半年的努力，9月项目一期交付上线。但部分硬件还没到位，只好协调市委其他硬件。另一方面，客户对全市中小学前期宣传不多，系统自9月到10月试用期间一直运行稳定，每天5承载千人的访问量。11月硬件到位，二期上线，就在上线前2小时，项目组得到客户发出的一条重要信息：市委已下发文全市中小学，要求在本周登陆系统，完成用户初始密码修改任务。这个消息意味着系统将面临100万的数据访问高峰，无疑为2小时后的系统埋下一颗“定时炸弹”。时间一分分过去，整个项目组异常紧张，晚上6点访问量陡然上升到80万，系统崩溃了!
4、一波三折的排查
系统出现问题项目组先后对项目架构进行调整，并逐一解决代码上的问题。但即使是架构调整以后，问题依然没有得到解决，通过进一步的排查发现，当时客户采购的硬件存在着一定的问题。通过客户向硬件厂商的实压，IBM、EMC也指定了服务人员来到现场予以排查，经进一步排查，一台IBM小型机的内存确实存在问题，但是该问题排除之后，系统还是有问题，通过日志分析发现存储也可能存在问题，现场服务文员也不停向美国总部反映情况，但依然找不到原因，最后，通过逐一试错的方式，发现来连接存储的光纤似乎不够稳定，更换光纤后，问题成功解决，其原因主要是在项目的一个分包商在采购时为了节约成本使用了低价劣质光纤。
5、患难与共的信任
尽管这次意外的发生，在一定程度上，为客户和最终用户带来了诸多不便，但我司清晰的处理危机的方案和态度给客户留下了非常深刻的印象。领导层保持与客户的良好沟通和交流，并在事故后项教委高层进行了汇报，还顺势将新的信息化规划介绍给客户，获得了客户极大的认可，将一次不利的危机转换为新的合作契机。由于我司在危机中表现的与客户患难与共的积极姿态，客户讲我司列为市教育信息化建设的顶级合作商。
6、危机过后的反思
反思整个项目，由于整合多大十几
个厂商的接口与软件架构难度较大，同时，前期准备仓促，在硬件规划，审查等方面，没有一个良好的机制进行督查，也导致了后期问题的发生。尽管在各方的共同努力下我们度过了这次危机，但此次教训足以为我们身边每个进行中的项目敲响了警钟，只有充分关注项目中的其他厂商，以客户为中心，建立良好的监督机制，并切实加强与客户接口部门的沟通，积极关注测试中的每一个细节，才能做大程度的避免将来可能发生的潜在危机。
此外，在与教委信息中心的沟通方面，指导系统快要上线的时候，项目组才获知即将面临的访问高峰，此时已经基本上没有反应时间。在技术细节上，虽然客户所采购的存储器属于相对高端的设备，但在交付前的测试阶段，项目组还是发现数据不能达到很到的交互量的问题，由于当时客户方认为问题不大，项目组也就没有在系统上线前予以彻底排查。