什么样的系统算是坑——后传

自从《什么样的系统算是坑》公众号文章发布之后，很多人留言问我接下来会怎么处理，表示会持续关注。

现在一年过去了，也许是应该好好说一下了。

 

艰难时刻

没错，刚接手的时候，是真的很艰难。这套系统是真的很坑，不仅用户操作繁琐，而且系统功能和数据出错率极高，运行速度很慢。曾经用JMeter做过压测，20个用户登录的登录响应差不多要85秒，查询一个画面响应时间要5分钟以上。

系统里面到处是代码写死，稍微有一点业务变动或者Bug修复就要做大量的程序修改，而且还只能得让供方来做。比如新增一个库位代码，ERP这边是分分钟的事情，在这套系统上面就要前后改一个月。那个时候我最怕的是用户提Bug修改和新增需求，因为任何的改动都需要供方来做，没有两个月是搞不定。

接手之后我花了半个月的时间，召集用户部门关键用户梳理了几版业务需求和Bug清单，形成文档跟业务领导和供方确认。但确认之后的系统改动进展缓慢，四个月之后才交付新版本发布，也只是修改了2个需求而已。

后来一直在催促供方加快开发进度，期间系统也陆陆续续出现过不少的低级错误，如人为配置错误导致测试数据对接到其他系统的生产机了，跟供方交涉，但他们死猪不怕开水烫，一脸满不在乎，甚至回复：出现这种情况在所难免，建议甲方把其他系统的网络屏蔽掉，这样可以杜绝类似的事情发生。

被我回怼了之后，供方公司的项目总监和PM从此没再理我，也几乎不在交流的群和邮件里吭声，无论我如何嗷嗷叫，如何要求他们，甚至讥讽责骂他们都是无动于衷。碰到问题只让唯一一个留在甲方的支持人员打打酱油。

后来系统又发布了一版，惊讶得发现供方私自拿我们的测试系统当小白鼠，虽然有修复部分Bug，但在上面还修改了好多底层架构，加了不少的功能，而这些功能在我们看来是不需要的东西，反而增加了用户的工作量。一开始供方答应用户上线初期会帮忙维护数据，但到后来这部分工作都落在用户的头上了，用户和IT是被折腾得没脾气，大家都敢怒不敢言，默默承受着。

所以接手之后很长的时间里，对这套系统的运维和开发，甲方的参与度很低，干预的程度很有限。供方有恃无恐，对甲方的项目不紧不慢，需求也满不在乎，也妄想像血蛭持续趴在甲方的身体上贪婪地吸着血，期望着有三期四期的运维！

 

 

也许你会说干嘛不在项目款项上扣款甚至不付款，这个方法我当然想过，可如果供方从此撂摊子不干，万一出了问题，业务玩不转，个别业务领导会很恐慌！

 

逆风翻盘

最后实在看不下去了，还是我们IT大领导有魄力和远见卓识，果断决策内部在其他平台自行开发一套新系统。我拿到这柄“尚方宝剑”之后，开始着手系统替换的工作。

其实原来系统的功能很简单，在现成的开发平台上，我们只花了3-4个月的时间就开发完成了，并召集用户进行三轮大量的测试。前后只有一个开发人员，开发费用差不多是之前那套系统开发费用的十五份之一。

用户知道我们开发了一套新系统，天下苦秦久矣，都非常的期待，测试配合度非常高。

此外我们还添加了非常多的功能，极大简化了用户的操作，物料主数据原来需要人工录入数据的工作现在都是系统对接大中台商品中心了，上线的时候再把旧系统的数据全部迁移过来，诟病已久的SAP系统入库数统计功能经过完善也都准确无比。

上线之后，除了部分物料数据有问题之外，就是一些系统UI和操作上的小改动，几乎当场就能解决，上线仅2天之后系统就非常稳定了，可以说上线是非常成功的。

从此那套满是坑的系统就这样被我们扇到历史垃圾里去了。

 

角色互换

供方自知自己水平差，项目做成这个样子，要款变得很困难，再加上我比较强势，更别提什么之前规划的三期四期的项目了，所以他们就把唯一驻留甲方的人员撤走了，开始提验收付款的工作。

当然，这个时候有恃无恐的已经变成是我们了。

因为他们合同里面一些需求没有办法完成，而我也是要求他们按合同规定款项来做验收付款，不然就扣款。中间也是来来回回扯了很久，验收过程经常哭着喊着嗷嗷叫。当然，这个时候着急的反而是他们了。

所以还是那句话：不要作，迟早会作到自己身上！