全面檢查已有數據，不放過任何細節

在工作中，我們應全面審視現有數據，做到物盡其用。這類數據是已經過歸納整理和篩選的，具有較高的使用價值，使用者經過仔細檢查，通常可以發現問題的端倪。將所有的數據檢查一遍甚至幾遍十分辛苦，但是一些引發問題的真相往往隱藏在那些不為人所注意的細節之中，一旦找到，便會使人受益匪淺。

預先檢測全部數據

我們在解析已有數據時，都希望盡可能做到準確無誤。在華為，檢查工作通常都是由項目主管完成的，負責人往往會預先檢查數據，以保證所提交的數據能夠真實地對標問題。

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日準時上線。

本案例中，正是底層數據庫的信息沒有被完整錄入，從而導致了問題的發生。對于數據錄入的準確性，任正非說：“系統建設好后，每個環節、每個崗位都要高質量地進行信息錄入，才能減少問題的發生，進而減少浪費。”