转发同事总结：一个BUG引发的血案（结果篇）

续《转发同事总结：一个BUG引发的血案（经过篇）》，原文如下：

3. 结果

EVENT5：初验会的爆发 TIME：初验会

初验会开始了，前期埋下的地雷到了爆炸的时候，客户再次核对后发现导入和导出数据还是不一致，于是二话没说，推迟初验。此事件开创了公司的先河，成为第一个初验不通过的初验会。

SOLUTION5：未雨绸缪的重要性

出来混总是要还的，这样的结果对项目组打击很大。但仔细分析过之后，确实是有因必有果。只有把前期的工作做到滴水不漏，初验时才能有十足的把握，而不是抱着撞大运的心态，祈祷不要被客户发现问题。

EVENT6：G部门的突袭 TIME：初验会后4天

经过及时的修改和几天的跟进，C部门用户终于在验收报告上签了字，但是拿到下一个给G部门签字时，初验会并未发表意见的G部门用户也突然又提出系统上显示数据不准确的问题。

猝不及防的我们连忙应战，加班加点分析问题产生原因。因为数据库专家已撤离项目组，数据问题的分析产生了更大的难度。最终又是在远程协助的情况下，明确了问题产生原因，发现原因在于数据源系统本身的数据质量及接口变更导致部分数据未完全同步。

我们整理了一份详细的数据质量分析报告，列出了问题数据的明细，拿给IT部门确认，阐明此问题并非我方引起。终于获得了IT部门的支持，知会G部门通过了验收。

SOLUTION6：细化规范和主动出击

追根究底，为这个问题埋下伏笔的是接口确定初期，接口规范除了具体的字段要求，数据之间内在联系的规范性未详细阐明，导致后期数据源系统提供的数据不符合我方要求。今后涉及到和外围系统接口的时候，制定接口规范时需额外阐明这些逻辑关系。

另一方面数据质量问题我们早有察觉，也已通知源系统厂商和IT部门，并在监控日志中列出。只是因未出具量化的分析报告而且跟进力度不够，导致源系统的数据改造工作一直悬而未决，最终还是砸到了自己的脚。

在初验之前，我们应该主动联系各业务部门，明确他们认为系统还存在的遗留问题，确定哪些是会影响验收的，然后进一步分析原因，及时把问题消灭在萌芽状态。

（未完待续）