筆者鼓勵致力于從事數據行業的去參加一些人工智能，機器學習的培訓，然后有人說：其實很多企業不喜歡培訓出來的人，認為培訓不貼近實際，紙上談兵。我倒不這么看，其實即使在企業內干數據挖掘的人，很多也出不了活，這個不僅僅涉及業務和技術，更是管理上的問題。任正非說，華為最后能留下來的財富只有兩樣：一是管理框架、流程與組織支撐的管理體系；二是對人的管理和激勵機制，什么是流程化組織，簡單的說，就是基于流程來分配權力、資源以及責任的組織。為什么這么說？筆者的粗糙理解就是：好的做事的方法，靠人的口口相傳是沒有用的，寫成書也是沒人看的，只有把這些東西固化到企業的生產流程中去。你要干活就必須遵循這個流程，才能讓這些方法成為企業的基因，無時不刻發揮出其應有的價值，阻止突破底線事情的發生，流程讓新人做事一開始就站在巨人的肩膀上。創新型的公司往往是傳統流程和機制的破壞者，但當初公司在建立這些流程和機制的時候，其實符合當時的大多利益，而且這些機制和流程確保了企業最基本的利益，所以后來要被顛覆，只是因為跟不上變化了而已，絕不是說機制和流程本身就是個問題。可惜的是，對于數據挖掘這么復雜的、不確定性的工作，我們竟然很少去制定符合其特點的相關的流程和規范，有些數據挖掘美其名曰立項建設，大多采用放飛的方式進行，失敗是大多數的，投資浪費是很多的，偶偶的亮點不能說明問題。數據挖掘工作定義的六個階段，業務理解、數據理解、數據準備、模型構建、模型評估、模型部署，被大家簡單的理解為純粹的技術步驟，從來沒想過這些階段跟管理有什么關系。但正是管理的缺位，導致大量的數據挖掘工作事倍功半，新人來到一個團隊，歷經千辛萬苦作出的東西，往往一文不值，這到底是新人的問題還是團隊的問題？數據挖掘工作其實根本不可能靠閉關三日來給出什么驚喜，這是為實踐所證明的。如果你是一支數據團隊的管理者，改變不了整個企業的環境，比如數據驅動業務的思想，公司的政策等等，但應該在你的職權范圍內，在有限的資源條件下，用更好的管理手段讓數據挖掘工作變得更有效。最近，我跟團隊正在思考擬定數據挖掘的管理流程和規范，共5個關鍵節點希望新人做的數據挖掘工作，能夠按照規定的流程走，從一開始就能站在一個較高的起點上，并一直處在一個較為正確的，方向上，直到成功或者快速的失敗。

一、需求分析團隊大了，工作多了，每個人的自由權就相對大了，這個時候團隊就要明確一些做事的原則，什么樣的數據挖掘可以做，什么樣的數據挖掘不要做，這個不能靠拍腦袋，以下給出了4個原則，如果不滿足就要退回：

1、公司或部門重點工作（比如OKR）、領導安排的重點需求、日常運營分析和一線反饋的重點需求，杜絕不計原則的去接收挖掘需求，數據挖掘不是買菜，要耗費企業最珍貴的數據分析或挖掘資源，少而精是原則。

2、判斷是否已有相關模型或標簽滿足需求，有則推薦現有模型和標簽，如果有相關模型或標簽但無法滿足現有需求，則需優化原模型和標簽，這其實也是數據治理的要求，很多挖掘其實是原來做的不好或者未有效推廣，不能重復造輪子。

3、雙方明確數據挖掘目標，初步評估技術可行性及大致所需工期，包括度量成功的指標（精確率、召回率）、定義成功的基準（小樣本驗證、AB測試等），業務側可能的主觀評估標準（覆蓋用戶數、納入業務生產流程）等等。

4、聯系業務方明確驗證方案，如果對方無法承諾驗證環境，比如政策和外呼資源等等，則要特別謹慎，根據經驗，由于配合不到位導致的模型延期上線或者失敗的案例比比皆是，究其原因，還是因為業務方不夠重視或者級別不夠，調動不了相關資源去推進這個事情。除了以上原則，我們還制定了升級領導的原則，包括與業務方無法在目標上達成一致，實施周期超過XX人天等等，這些都是為了制止盲目的開啟一個數據挖掘課題。

二、方案設計這一過程看似簡單，有些人甚至只是腦子轉了下就倉促跳過，但很多建模失敗就栽在這個階段。在方案設計階段要善于換位思考，承認自己的認知有限性，始終想著如何才能獲得最強的“業務大腦”和“數據大腦”來幫助你更好的理解業務和對應的數據，包括三個方面的工作：

1、明確所需數據及必要的特征：對于較為復雜且重點課題，一般都要組織相關利益方開展頭腦風暴，集思廣益進行特征的有效選擇，大量的數據挖掘工作失敗在于建模者僅憑自己有限的業務知識和有限的調研（包括有限的通識理解，特別是不諳世事的新人）就倉促選定變量，然后直接跳到自己以為擅長的數據建模階段在調參上耗盡心血，最后事倍功半，代價不可謂不大。

2、明確所需模型及技術實現步驟：一般跟著經驗走就可以了，關于技術實現步驟相信每個企業都有自己的經驗做法，比如我們就發現隨機森林在很多情況下好用，新人不清楚就問導師，這一步其實是比較簡單的。

3、進行方案設計的匯報：要向利益相關者及你的領導匯報方案，領導可能技術上不如你，但人生經驗比你足，業務視野比你開闊，擁有的資源比你多。因此，要努力爭取到他的看法，領導支持你去做這個事情不代表他就支持你的設計，不要試圖跨過領導等有了建模結果后再向他匯報，因為一旦結果不好，領導的團隊成本已經花出去了，他不看好你的設計方案可以直接說NO，你要給他這個機會。

三、建模開發這個階段大致可以分為三個子過程：

1、寬表開發及數據預處理：誰都知道這個步驟，大家都喜歡建立自己的寬表為自己的數據挖掘服務，但如果你對企業的數據資產局理解不夠全面的化，就會在寬表處理上重復造輪子，效率很低。因此，對于數據資產的全局掌握進行定期的培訓和考試是有必要的，很多人做了好長時間數據挖掘卻對于融合模型不清楚，這是管理上出現了問題。

2、模型基線開發及訓練評估：參數調優、交叉驗證、效果評估都是需要反復進行的過程，但如果發現難以達到滿意的結果就不要一路走到死，召集相關人員進行一次技術討論是非常有必要的。

3、模型和標簽上線發布：模型和標簽上線要遵循嚴格的標準，包括是否滿足當初設定的技術指標要求，是否滿足數據治理要求，是否滿足運維性能的要求等等。

四、試點驗證

1、效果驗證：跟功能開發不同，模型上線不代表就結束了，因為實際的生產環境跟你的訓練環境會有很大的差別，你需要協調業務方按照當初的承諾盡快的進行效果驗證，這個時候你要承擔起連接者的角色，推進各方盡快反饋生產的效果，如果無法達到當初的設定目標，就要考慮重新優化模型，試點推進不利很多時候是業務方的原因，比如外呼排期延后等等，這個時候就要推動領導協調。

2、試點匯報：一旦達到要求，就要組織業務方和自己方的領導進行匯報，明確模型是否具備全面推廣或納入生產的條件，這個涉及到業務方相關政策和資源的配合，不是簡單的模型的問題。組織這種會議其實是向各方領導表明，我已經完成了任務，但要讓這個模型產生價值，接下來你們得給我資源配合完成剩余的非功能性工作，好的模型最后不了了之往往是溝通出了問題，業務方的領導跟你的領導很多時候信息是極度不對稱的，你要干成事情就得多做協調的事情。很多試點的結果并不理想，匯報的另一個目的就是及時止損，一方面是由于市場變化很快，總有意外的情況發生，另一方面是現有的模型的確達不到業務要求，你不能被一個看似無前途的事情拖死，你需要領導幫你做決策，繼續干還是放棄。

五、總結匯報

1、你要跟蹤模型的生產運行效果，及時發布運營報告，讓你的領導和業務的領導知道你干成了這個事情，很多時候，試點的效果很好，但一旦納入生產情況并不理想，因此要持續的跟蹤一段時間。

2、如果模型的效果保持穩定，則可以將其移交給統一運營團隊（如果有的話），代表你交給公司的是一個可用的模型，從而進入常態化運營階段，這個時候自己才可以全身而退。后續如果運營團隊發現模型有問題，可以向你提交優化需求，由此迭代。數據挖掘最怕的就是只管殺不管埋，比如訓練結果很好，但其實試點情況很差，試點情況還好，但生產情況很差，開始生產的時候還行，但持續一段時間就不行了。模型師一定要記住，模型的上線絕對不是你工作的終點，而僅僅是起點，只有模型進入穩定的生產階段以后你才算完成了工作，大量的外包數據挖掘工作所以失敗，就是因為他們把數據挖掘工作當成了簡單的功能開發。你會發現，筆者從需求分析講到總結匯報，都不在談技術，而是在談管理，我在談進入每個階段時要采用的質量控制的手段，其實每個階段的周期也要控制，一般來講，如果某個階段超過了二個禮拜（可以根據企業實際調整），就要反思和對外暴露問題。根據以上的內容很容易就畫出數據挖掘的管理流程，可以貼在墻上成為軍規。當然每個企業的情況不同，流程可能不一樣，但一定要沉淀出這種流程，它們保證了基本的做事的效率，不會由于人員的變動而導致效率的下降，這就是任總所說的流程化組織要干的事情吧。這是我最近的一點思考，大家一起加油吧。