【2018.4】基於架空場景討論如何搭建滿足高準確率、高性價比的策略團隊——談「滿滿運」地圖團隊應有的特點

05-11

TL;DR

業務上量化每個badcase造成的損失和未來損失估計，團隊和個人的KPI是修復的badcase減少的損失合計。
所有數據變更都視作獨立的工單，在各個策略抽象層面可以獨立的進行半自動的增量更新和人工干預，最終獨立上線、評估與分攤收益。

題外話

估計這是我寫過的脫離我核心能力圈最遠的話題了，因為這其實是一個組織架構的問題，而不是一個演算法策略問題。而且也可能是最有爭議的一篇文章，希望我這篇文章的影響不要是負面的……

為什麼選地圖業務是因為地圖業務足夠複雜，地圖也正好符合本文討論的內容，也是因為我對此比較熟悉。本來就不懂組織結構設計，如果討論的業務也不懂那估計這文章就沒法看了。

為什麼說「滿滿運」是因為：

大家知道的知名地圖的組織都太大了，BAT三家的地圖、滴滴地圖這些部門承載的職能都太多了，和本文想討論內容相去甚遠。所以還是希望找一個麻雀雖小五臟俱全的場景來討論。
運滿滿在一般人看來是能夠理解和想像和地圖關係比較緊密的，而且我孤陋寡聞也沒有聽說它有一個很大的地圖團隊，討論不存在的東西大家才會比較接受。
貨運場景的badcase造成的單均損失比打車還要高，更適合本文的主題。
這只是一個架空的場景，我沒有調研過運滿滿的產品形態，也不了解運滿滿的組織結構。只是作為一個外人的視角來分析這個場景，所以才叫「滿滿運」，一個架空的和運滿滿業務類似的公司。

前言

本文是上一篇文章【2018.4】那些目標4個9準確率的業務場景的實操版本。這方面光說道理的話似乎很難讓人能夠應用，所以找了一個相對複雜的場景按照這個思路來分析。

下面描述的這個設計據我所知沒有任何公司是這樣的，是一個基於前文思路的一個非常激進的設計，並不是說建議已有的組織向這個方向轉型。事實上我也覺得往這個方向轉型勢必要經歷劇烈的鎮痛，說會流失一半的人我也不奇怪。

如果有同學真的見過這種設計的落地版本，那麼請務必告訴我~

下面明確一下這個「滿滿運」公司的業務方便討論：

貨主端：可以發貨運單，可以看到價格和時間預估。
司機端：司機指定接單範圍，系統自動分單。
其他服務和文本無關不再列舉。
地圖方面的增值功能：

規劃城際和城內路線，綜合考慮時間、收費、合理的休息安排、意外風險。
估計運達時間，考慮各城、各道路的貨車禁行時間
預估整體路線的高速費
為司機推薦城外和城內的休息區、加油站等服務場所。
攝像頭、非法攔路收費、偷盜頻繁等位置的提醒。

成本最低的方案——不組建

做什麼的之前都要考慮下為什麼要做，是不是可以不做。這個話放在地圖這也是成立的，且不說自建地圖團隊的成本有多高，圈內有這麼多公司，去談一個外包合作肯定是可行的，畢竟所有互聯網爸爸都有自己的地圖嘛。

至少一些成本最高的問題都可以通過這種方式解決：路網數據維護和更新、通用場景的路徑規劃、司機端導航界面。

剩下的一些相對容易的問題可以外包，也可以自己做，主要就是一些位置數據的採集、維護，一些回歸類問題。前者可以自己做，畢竟數據源也是自己的司機和地推人員。後者如果只要1個9的準確率用ML學一個，數據是調用外部更貴的地圖服務，或者簡單做一個緩存都好。還可以爬取競品的數據，這都是快速達到1個9準確率的方案。

但在朝著2個9邁進的時候就會遇到很多問題：

外包的服務迭代未必能趕得上業務發展，或者對方不重視。
自己爬取的數據如何修長尾badcase，信息源怎麼來？
ML模型沒法快速適應環境數據變化，變化的信息源怎麼來？特別是，路徑規劃還是一種牽一髮而動全身、一處關鍵道路修改可能影響大面積請求的問題。

所以有些公司就會繼續向著自建地圖能力的角度來邁進，修復更長尾的badcase。

不只是挖掘歷史軌跡數據，還要能夠真正理解地圖數據、根據最新的數據來實時產出最新的結果，但代價是技術很重，線上服務成本很高，養的人很多。成本遠比前面爬一下數據或者學個ML模型要高好幾個數量級。

有不少人在考慮一個問題，那就是這種很重的地圖技術的業務價值究竟是什麼，我想大家看到這後會有些啟發。

數據源

相信看過我前面系列文章的同學會認識到O2O場景乃至互聯網很多場景其實歸根結底最初都是一個數據問題，沒有數據就沒法談後面的一切。

而對於地圖來說，數據的時效性是非常重要的，去年的新聞可能還有人看，但一年前道路施工之前的情況估計完全沒有人會關心了。所以這裡有兩個問題，第一是初始數據的批量獲得，二是地圖數據的長期維護工作，前者的成本基本是九牛一毛。

初始數據的批量獲得有兩個主要方式：

初始數據的一次性購買，不少小公司都有四維圖新的路網數據。但缺點是四維本身數據更新較慢（相對於互聯網的節奏），道路屬性也不太滿足各種奇怪服務的O2O互聯網公司的需求。
從同行爬取數據。

數據更新

本文討論的滿滿運是可以通過GPS獲得司機的實際形式軌跡的，此外還可以通過地推人員、司機主動上報/投訴、其他眾包形式來獲取線下地圖數據情報的。

數據團隊內部勢必要有一個數據運營平台，可以人工的更新路網數據，而這個工作本身可能又會需要外包員工和人工審核。

一般來說，這類和地圖強相關的公司本身自己的業務就是這方面地圖數據最好的數據來源，基本上沒法從別的公司低成本獲取，除了競對。

團隊的KPI

回到本文的主題，如何構建一個高準確率、高性價比的地圖策略團隊。

前文已經提到，很多時候快速修復badcase可能是更為重要的問題。在滿滿運的場景下也是如此，如果你沒有及時發現某個省際高速公路的關閉，那可能就會導致某些訂單的實際費用和時間大幅增加，這導致的損失可不是像uber那樣隨便給你全額退款花個幾十塊就能抹平的。

當然也不是說提昇平均效果不重要，但滿滿運公司考慮的更多是先如何消除這些長尾badcase帶來的影響的問題，然後才顧得上提升路線規劃質量的問題。這方面的話題後面有空會再開文討論。

那麼在這種場景下，如何高效得在一個不小的地圖團隊里讓業務價值充分傳遞，避免各個組之間出現邊界指標不合理導致的全局浪費呢？

一是要充分量化價值，二是要全流程的改進都能自動關聯到業務收益。

那麼就是：業務上量化每個badcase造成的損失和未來損失估計，整個團隊的目標就是修復badcase，KPI是修復的badcase減少的損失合計。這個指標可以分解到崗位、到人，由於badcase很多，一個badcase涉及多方時候可以做相對簡單的均攤。

這樣無論是策略變更批量修復、還是人工修復單個badcase，其價值都可以被衡量和比較。

覆蓋全流程的數據發布平台

地圖的各種策略不只是基於基礎的路網數據，往往各個抽象層面會逐層構建自己的特徵，基礎的路網數據更新了，上面這些策略或數據也需要能夠及時更新。而這裡就往往涉及各種策略之間的耦合，解決思路是：

根據前面系列文章的討論，能數據化的策略都數據化，在數據層面也盡量向最底層移，移動到底層的同學已經沒法做相關的內容的位置。這樣數據變更的成本最低。
當數據變化時，每層的策略自己可以根據變更產生各自層面的數據變更結果，這個結果是可以被人工干涉、人工或半自動審核的。
當一個新數據修改發布時候，要等到全流程所有策略的結果都完成變更的處理時，該處變更才能上線。
數據修改沒有全局順序概念，不同位置的數據修改可以獨立修改、獨立的在每層被處理，獨立的上線評估，獨立的被核算業務收益並自動分攤。

解釋下為什麼數據化的結果要移到盡量低的層：

首先這裡不是說策略不要了，對於新增數據和需要先嘗試低成本自動映射數據變更來說，生成策略是必要的。
移到盡量低的層是為了減少一個數據修改所引發的上層數據的變化和映射種類和次數，多一次處理就多一份成本和風險、也拖慢了數據上線的速度。所以最好的辦法就是在修改數據時候直接修改業務上的所有附加欄位，上層直接使用即可。

這樣就算是對路徑規劃這種各要素充分耦合的場景，也可以實現：對每個變更看是否命中，如果發現結果包含該數據時，再評估下如果不包含該數據時會得到什麼樣的結果，以此來對該修改的收益做出評估。

後記

寫完上面主要的兩點之後，似乎想不起來還有哪些要寫了。雖然並沒有講述具體各種地圖策略的拆解和邊界，但我想本文舉例的目的應該達到了。

後面想起什麼和一般不一樣的再來編輯吧。

遺留問題：

如果單個badcase這麼重要，那麼數據上線和策略變更如何做A/B test？