一个失败的项目-CSDN博客

本文链接：https://blog.csdn.net/richard_2010/article/details/5662502

俗话说：失败乃成功之母。

俗话说：没有总结就没有进步。

当我敲下题目的时候，仿佛又回到了当初接手这个项目的时候，深深印在脑子里的是无缘由的错误，无休止的修改，上线时间一次又一次的延期……

项目开始于5月份的某一天，老大安排我写一个串接SAP系统的功能，实现将我们的系统数据抛转到SAP系统和从SAP系统查询、读取数据，顺利完成编码，测试。直到9月份的某一天，老大需要休一段时间的假，让我接手管理这个项目，而项目定在一个星期后上线，麻烦从此开始。

我拿到未关闭的bug文档，发现其中大部分问题出在和SAP系统交换数据的地方，而且好多问题存在差不多一个多月都尚未解决，心里隐隐有些担心自己写的代码。和SAP开发人员仔细沟通和测试后才发现大部分问题在于我们抛转过去的客户、产品资料在SAP系统中不存在，从而造成执行错误，于是重新写程序从SAP系统中读取客户、产品资料。用新的数据抛转SAP系统后又发现SAP系统逻辑有些问题，改好之后再测试终于发现了我们自己系统处理数据的问题，改正。这样一回合下来差不多用了半个月的时间，项目第一次延期。

约定好重新上线的时间后客户重新测试，提出一个新问题，系统得到的退货价钱不对。返回来自己测试，检查代码中的逻辑，没有发现问题。和客户沟通后发现原来系统并没有实现客户需要达到的效果，即卖出去产品A，出现质量问题换成产品B，结果又出现问题换成产品C，之后不管换多少次，假设最终换成产品E，结果最后还是有质量问题，只好退款（BTW，是米国客户，在天朝可能享受不到退款），这时不是要退产品E的价钱（系统返回的就是E的价钱），而是要退产品A的价钱。和客户商量能不能先上线后再补充这样的功能，答曰不行，因为旧系统也没有这个功能，每次退款人工操作很麻烦，不然没必要上线新系统了。没办法只好继续修改，问题又来了，我们的开发人员把所有的业务逻辑写在一个BEAN里面，里面的方法不知道有哪些是共用的，往往出现改了这里而那里出现问题的情况，改好那里这里又有问题的情况。项目自然又延期。

经过我和开发人员的共同努力，系统好歹算是正常跑起来了，不过测试情况不容乐观，开始出现一些不可再现的bug，经三方讨论，一些归结于SAP系统连接不上。重新商量好上线时间后，老大终于回来了，这时时间已经到了10月中下旬。

上线前期有许多正式的数据需要从SAP系统和仓库管理系统中抓到我们系统的数据库中，而这些数据有几百万条，又涉及到一些业务逻辑需要用JAVA程序处理，该死的PC一次又只能处理十万左右的数据……于是我每天的工作变成了手工修改参数，打包WAR档，重复。终于在一个多星期以后全部数据乖乖的躺在我们数据库里面了。这时客户提出用生产机测试，MG，又出问题了，项目第三次延期，我崩溃了。

还好老大替我和客户周旋，又重新商量了上线时间，这时又一个打击来了，金融危机，公司把这个项目唯一的开发人员裁了，留下一堆恐怖的代码（上文有提到）。正好因为接近年终，而我还没有拿得出手给上面看的成绩，老大安排我负责另外一个新项目的开发，将我从水深火热中解救出来。最终这个项目无疾而终。

从这个项目中，我总结出来了一些问题：

1、未重视需求分析，过早着手编码。表现在客户换货的需求直到最后到发掘出来，我们知道，越晚发现的需求修改的代价越大；

2、开发人员技术不足。表现在将所有的业务逻辑写在一个BEAN里面，导致牵一发而动全身；

3、资源调配不充分，其他部门配合不足。表现需要和SAP系统测试确定问题的时候，SAP组才派出一名实习生配合我们；

4、SAP开发人员技术不足。表现在SAP组的实习生对SAP系统学习不到三个月，并且出了问题还无法和自己组的人员讨论；

5、沟通代价过大。表现在和美国那边有时差，每天只有早上刚上班的时候可以打电话找到人，其他时间全靠邮件沟通；

6、项目中没有一个有和SAP系统打过交道的人。表现在唯一一个写串接SAP系统的我也是第一次；

……

等等。针对这些问题，我们可以找到一些解决的方案：

a、认真做好需求分析，尽量推迟编码开始的时间；

b、可以让一个经验丰富的开发人员带一个经历尚浅的开发人员，定期举行code review，防止不规范的编码风格出现；