针对报告某一数据，开发了一个自动取数小程序。

前期考虑了所有的复核公式，对所有产品的年度数据进行对比测试。

半年报的时候很放心地使用了。结果有同事反馈结果数据有误。

1、发现问题的同事有复核意识。

她在使用前，对数据进行了简单的复核。而不是直接使用结果。

我们所处岗位的每一项具体操作都有可能被系统化取代，只有对数据的敏感性，数据的复核意识这些习惯和思维是替代不了的。

2、问题反馈给程序人员，数据进行了更新。有两个选择。

一是给报告编制人员自己排查，一个是排查好了再告诉报告编制人。

我先进行了排查。挑出数据有差异的部分。我不好意思把问题扔给别人。

每次都是因为这种不好意思。进一步做了一些事情。体会到一些感受。

想想别人，责任心。

3、有39个表。排查的数据，目测可以判定。

使用了笨办法，两台电脑同时打开更新前后的数据，确定是否有数据更新。

其实有沟通开发人员，能否将39个表的数据整合在一张表中。这样核对就方便了。

各种原因，没有沟通好。判断了一下工作量，就用笨办法一个个去核对了。

自己理解偏差的问题，别人认识的问题，时间的问题等，不是想要什么就有什么。

沟通不畅的时候，要退一步。不把问题扔出去，能力范围内可以解决的，就多做一点。

目的就是让事情进行下去。沟通时退一步，做事情往前走一步。

4、知道了问题所在，简单重复去核对。慢慢地找到了有差异的规律。

再反向观察没差异的数据，来确定规律是否准确。意外发现了问题的症结。

表面上的原因是公式中对数据截取小数点1位出现问题。

实质上是因为对报告内容理解上有偏差。公式本身不恰当，不是截取位数的问题。

与程序人员沟通。然后找到了一个直观无歧义的方法。又与事务所沟通无疑义。

核对更新前后各39张表，硬着头皮去做的。

但是做完后，对数据的提取有了新的认识。

对开发人员的职责，使用人员的职责有了新的认识。

这些认识建立在做的基础上。 别人告诉你，哪里出问题了，和你自己做的过程看到问题。 两者的理解不一样。