下载掌阅APP，畅读海量书库
立即打开
在工作中，我们应全面审视现有数据，做到物尽其用。这类数据是已经过归纳整理和筛选的，具有较高的使用价值，使用者经过仔细检查，通常可以发现问题的端倪。将所有的数据检查一遍甚至几遍十分辛苦，但是一些引发问题的真相往往隐藏在那些不为人所注意的细节之中，一旦找到，便会使人受益匪浅。
预先检测全部数据
我们在解析已有数据时，都希望尽可能做到准确无误。在华为，检查工作通常都是由项目主管完成的，负责人往往会预先检查数据，以保证所提交的数据能够真实地对标问题。
2008年2月，华为意大利代表处收到瑞士电信的信息邀请书，参与其全国传输项目的投标。有网络设计经验的段爱国被任命为项目产品经理，前往瑞士督战。
项目标书有1000多页文档，几千条技术问题，这意味着每一个数据都要准确无误，答标难度非常大。
7月后，项目进入标后技术澄清阶段，就客户提出的问题进行答复，确保他们在最终决策前充分掌握华为的方案和产品细节。客户希望华为在一个半月的时间内，针对答标文档的每一个技术问题进行答复，每一个方案细节都要当面逐一澄清核实。在澄清的过程中，对客户随时想到的其他问题华为也要给予快速、清晰的答复。
为了解决和回复这些技术问题，段爱国每天分析各种数据，并在与客户的现场澄清会上给出清晰的答复，之后还要向研发部门反馈澄清遗留问题。为了确保这些数据的准确性，段爱国积极利用后方资源，组织电话会议讨论，确保问题沟通到位。为确保在下一轮技术澄清会上能够答复客户问题，大到技术方案，小到行文格式都要准确无误，稍有不慎，之前的方案就会被推倒重来。
一个月下来，客户关心的技术问题都得到了满意的答复，并用文档明确了下来。
针对问题全面检查，要求的不仅仅是针对已显现的问题，那些隐而未发的问题也是需要关注的。在华为，解决问题通常靠群策群力，这就决定了责任人必须对成员提出的建议进行合理性检查。全面检查中包含几个关键问题，对这些问题进行回答，可以表明某项建议是否可行。许多知名的公司都采用这样的方式，以确保最终解决方案的正确性。
曾经就职于麦肯锡公司，后来到迪克·布里克控股公司担任首席执行官一职的鲍勃·布克斯鲍姆认为，在麦肯锡公司学到的进行全面检查的方法对自己的工作产生了深远的影响。
有一次，一位员工向鲍勃·布克斯鲍姆提议，公司应该根据最低的库存水平而非最高水平确定某种商品是否应该返回仓库。当时在座的其他人都认为这是个不错的提议，值得深入考虑，但鲍勃·布克斯鲍姆并未立刻回应，他用了两分钟来考虑这个提议，之后得出的结论是，在这种提议下预计的40万美元回报将下降为4000美元，这显然不值得公司花费一周的时间重新为商家打印和发送遵循程序的材料。于是，这一提议被迅速否决。
预先检查的意义在于，在问题扩散之前找到不利的因素，然后修正这些数据。有人曾经向伟大的建筑师密斯·凡德罗讨教成功的秘诀，对此，密斯·凡德罗解释道：“细节决定成败。不论我们的设计方案多么恢宏大气，只要有一个人从我们的方案中找出一点不足，那么这个设计方案就会变得一文不值。”换言之，我们必须先于问题爆发前发现潜藏的不利因素，才能避免意外问题对结果造成严重的打击。
敢于质疑不合理的数据
在我们检查数据的过程中，如果发现某个或某些数据存在问题，则应及时提取出来。数据虽然经过层层筛选，可靠度高，但也难免会存在一些瑕疵，若是对有问题的数据不管不顾，必然会影响问题分析。数据服务于既定目的，当数据偏离这一目的时，数据就不再有意义。
贾岭于2002年入职华为，是一名GTS方案架构五级专家，在网络搬迁方面具有丰富的经验。
有一次，非洲N国MTN项目搬迁后的整网话务量仅为原网的60%左右。客户要求华为在一个月内解决这个问题，否则将购买友商的设备，并对华为进行高额罚款。贾岭和同事立刻赶到现场，在对现有数据进行分析之后发现，之前项目搬迁人员按照覆盖下降思路解决话务量下降的问题，且行销人员已经开始准备扩容的数量单，这一举动意味着承认了是华为设备导致覆盖下降，公司将面临巨大的损失。
但贾岭凭借对公司产品性能的信任，认为事实并非如此。于是他领着故障定位组到站点测试话务量的实际覆盖情况。经过大量的数据分析，事情取得阶段性进展，结果显示覆盖并不弱，并且终端客户也没有受到影响。那么损失的40%的话务量是怎么回事？贾岭开始下站做硬件对比测试，终于发现了隐藏的问题。原来是华为设备的话务统计打点方式和友商设备的话务统计打点方式存在差异，导致了统计误差，进而形成“话务量下降”的假象。贾岭将这一情况上报后，研发人员修正了统计方式，话务量指标立刻恢复到搬迁前的状态。最终，客户打消了对华为产品的疑问和误解。
严谨的数据是我们做出判断的重要依据，但过分依赖数据显然又会带来新的问题。如何解决这个矛盾呢？我们不如像贾岭那样，在经验判断的基础上抱持怀疑态度，将经验与实践相结合，再通过数据做出准确判断。
复检数据，确保数据精确性
复核数据是数据分析过程中的一项例行工作，是通过复查确认数据是否存在瑕疵、缺失等。从数据检查的角度而言，这一步骤能够有效防止错误的数据输出。
任正非曾说：“2015年上半年，我们的数据有640万条错误。数据都错了，你们能够实现正确交付吗？合同正确，录入也正确，为什么还不能正确发货？因为我们的库管系统人员理解得不准确，于是把货发错了，造成了巨大的浪费。能做出正确的合同，但如果不能正确录入，也不可能实现正确发货。如果不能正确发货，就不可能正确交付。”由此可见，进行数据复查，保证数据的准确性非常重要。
2015年，由于在巴西的业务量激增，华为希望能够与客户Telefonica拉通订单集成对接。在得到对方的首肯后，华为立即着手实施。客户要求在9月5日完成所有工作。9月4日，也就是上线前一天，IT项目组通过系统验证发现，一些测试场景中出现客户订单无法下达的问题，这可能导致客户订单无法履行。
IT项目组经理带领众人开始对数据进行逐条分析。大家通过深入排查发现了一条规律，即同一个采购条目在采购数量较大时就会出现问题。
项目组认为这些都是表象，还不是问题的根本原因。他们继续针对每个订单字段深入分析，逐一核对几百个字段，包括业务定义、逻辑关系、处理规则等数据，但排查下来都没有发现问题。IT专家侯江坤建议，要从发现的规律着手复查和分析，确认订单数量会影响哪些字段。沿着这条思路，他们又开始重新进行分析，并发现订单数量会影响到采购条目金额、采购条目总金额和订单金额这三个关键字段。
侯江坤将排查范围扩大到数据库底层，在对比这三个字段的差异属性时，他突然发现，采购条目金额的字段长度是7，而另两个字段长度是22。侯江坤指出，会不会是当订单量较大时，采购条目金额会超过7位，进而导致数据无法保存？如果这一猜想属实，那系统为何没有报错？他通过代码的复检发现，系统确实捕捉到了错误但没有报错。
问题定位后，项目组和时间展开赛跑，最终在凌晨4:00解决了问题，保障了订单对接项目于9月5日准时上线。
本案例中，正是底层数据库的信息没有被完整录入，从而导致了问题的发生。对于数据录入的准确性，任正非说：“系统建设好后，每个环节、每个岗位都要高质量地进行信息录入，才能减少问题的发生，进而减少浪费。”