竞赛系统小结

上周，客户终于还是把问题反馈到领导那里去了。毫无疑问，各种责问向技术部排山倒海袭来。说实话好多问题的确也不是程序代码本身的原因，但是既然出了问题总归是不对的。纵观整个系统开发流程，我想了下还是有很多问题的。

开发前

刚接到任务时，从制定方案到测试上线一共只给了7天，虽然业务模式可以参考之前公司做过的产品，但是系统的负载量我们没法获得一个准确的数字，甚至连个大致范围对方都给不了。我们低估了数据的并发量，也为之后的问题出现埋下了隐患。

虽然题库是由对方提供的，对方发过来的题库理应是准确无误的，但是我在题库格式化完成后并没有将该文件再发予对方确认，导致上线之后题库问题频发，从而降低了系统的体验性。

开发中

系统开发时，有些交互做得也不是很好，由网络原因导致的问题，但是提示的文字却是“ajax error”，导致客户误以为是系统出了问题，虽然我们后来修改了提示语，但是还是给客户留下了不好的印象。

测试

测试版发布之后，我做了流程测试，找出了流程上的一些问题。但是并没有做压力测试，毕竟我也不是专业的测试人员。正式因为缺少了这一环，导致我们对后续的数据高并发并没有准备，只能一次又一次地调整。

上线后

系统上线了，上线第一天就出了问题，但是具体原因只有技术主管才知道。应该是和服务器有关，这个锅我们是逃不掉的。但是我在上线之前并没有和对方把系统的流程清楚地告知他们，导致他们误以为系统出了很大的问题，我是有责任的。在系统运行过程中，出了问题我也只是去沟通解决，并没有实时记录下这些问题，就项目管理而言也是有问题的。记录这些问题一方面可以为项目结束后进行总结提供材料，另一方可以定责，确定哪个问题是谁的责任。

还有在调整服务器资源的时候我们做得也不是特别好，每次都是对方提出网页打开慢，我们这边才做优化，也没有在一开始的时候，在不增加成本的情况下把资源给到最大。从而也大大降低了客户体验度。或许这就是做技术和做销售看问题的角度和眼光的差异吧。

目前活动还在进行当中，系统大问题总算不再发生，我的微信也安静了很多，希望能顺利地结束吧！