批量導入的那些坑,請注意避開!

6 評論 1.2萬 瀏覽 13 收藏 12 分鐘

編輯導讀:對于B端產品來說,批量導入是一個常見的功能。尤其是在歷史數據很多的情況下,批量導入能減少很多工作量。但是,批量導入看似簡單,實則是個大坑。本文作者基于自身工作經歷,梳理了批量導入應該避開的四個大坑,希望對你有幫助。

看了好多文章,都在講如何進行批量導入,不過實在是最近被批量導入坑得太慘了,所以這篇文章是勸退的,沒想好這幾個問題點,建議批量導入的功能先緩緩,您先冷靜冷靜再決定要不要做。

誠然,對于B端產品來說,好像很多地方都會用到批量導入。尤其是在系統冷啟動的時候,商家會有一堆理由與說辭讓你覺得,好像確實有做批量導入的必要,如果不做批量導入對商家很不友好,大批量的歷史數據不能盡快錄入系統的話,那商家可能就會說要考慮考慮要不要用你這個系統了。

這時候,為了讓甲方爸爸們買單,我們就妥協了。然而,你以為做了這個功能就結束了,天真,之后你才會發現,這只是個開始。

以CRM系統為例,歷史客資的導入基本上是避開不了的議題?;蛘呤莻}庫系統,歷史物料的快速錄入也是個不得不考慮的問題。

但不管是哪種,其實做批量導入的大部分場景都是為了解決商家冷啟動的問題,但是由于系統在不斷迭代,批量導入的邏輯也需要一直跟隨修改,基本需要和線上保持完全一致的邏輯,畢竟這是一個可能三五個迭代不會有人用,但是一旦用起來體驗糟糕或者邏輯跑不通那就是死罪了。

所以整理了以下幾個問題點,各位看官好好考慮。

靈魂拷問一:開發資源是否足夠?

其實這是個過于實在的問題了。就問一句,各位產品有沒有經歷過由于開發資源不夠所以需求被延期的情況。

有一說一,迄今為止我碰到的產品就沒有一個說每次功能都是開發說能做但是他自己給砍掉了的。

開發資源在絕大多數公司都是緊張的,所以產品核心能力有一個是排需求優先級,但是批量導入是一個你一旦做了那之后沒有辦法考慮優先級,必須每個版本跟著你迭代邏輯同步修改的功能。這就導致,一旦有涉及到字段調整或者是相關邏輯調整的情況,你必須做同步,這點沒商量,就必須占用一定的開發資源。

如果只是版本微調還好,基本也不會修改太多。但是一旦涉及比較大的功能調整,本身開發任務就是很重的,這時候你還需要考慮批量導入的每個字段邏輯以及導入邏輯是否有關聯影響,需要做對應的調整。

當然,有人會說,這些應該是默認跟著系統邏輯走的,恕我直言,會用批量導入的系統部分邏輯還是比較復雜的,往往做不到完全自適應。除非是最基礎的字段導入,涉及邏輯很少,就只是展示,不關聯導入后數據狀態變更的一些問題,如果這樣,你可以到下一步了。

靈魂拷問二:你準備好因為他加很多特殊邏輯了嗎?

這個問題也是最近幾個月折磨了我好久的問題。

第一次做批量導入就是做CRM系統里的歷史客資導入,本以為這個需求很簡單,無非就是客資字段的導入,如果格式不匹配報錯就好了,第一版上線后,csm小伙伴跑來跟我說,客資導入成功率不足5%,我??(黑人問號臉),我都給示例數據了還看不懂嗎?我都按照各位產品大佬的意見來了呀,注釋也告訴他們什么字段有什么填寫要求了,每一步該干嘛也引導了,為什么還失敗率那么高。

跑去看數據,原來是本身平臺有填寫限制的一些字段直接被商家無視了,比如某個字段,因為涉及到后續內部員工的績效問題,所以填寫的要求是需要商家填入在當前企業的員工。但是,商家給了一份攢了十年的文件來導入。

十年??!兄弟們,都夠從我不認識你,你不屬于我到我們是朋友了。這里面有好多老板都記不起名字的曾經的員工,他表示肯定要導入,而且數據不能亂改啊。

雖然我一度質疑過十年前的數據拿來有什么用,但是一旦被甲方爸爸說出那句“如果你們不能實現這個功能我就要退款?!边@種一聽就想甩手走人的話來就只能妥協了(當然,因為我們平臺剛做不是很久,所以很珍惜每一位甲方爸爸,平臺大一點的話這種要求應該可以拒絕,不過這只是一個示例)。

甲方爸爸都說要了,想辦法加唄,那就正常錄入的時候不能自己填,但是批量導入的時候可以,先校驗這個人是不是在企業里,如果有正常導入,如果沒有,則作為文本字段特殊導入,導入后對應位置需要可以展示,一旦修改則只能修改為當前企業下的員工。

還有我們要求部分字段只能填固定的幾個選項,商家說我就是有另外一個,為了提高導入成功率,加唄,如果識別到沒有,直接在設置里添加,哪怕原來這個字段編輯有權限控制,在批量導入這兒也開放了,不做鑒權……

諸如此類,其實會有很多。大家都應該知道,平臺越復雜,特殊邏輯應該要越少,因為特殊邏輯往往治標不治本,而且等于在平臺上埋地雷,一旦哪天不小心碰到,就是炸。但是批量導入就是為了提升效率,所以往往會做很多兼容,相當于是在挖坑了。

靈魂拷問三:你真的能夠做到不遺漏邏輯嗎?

有些時候吧,甚至覺得開發資源嘛,擠擠總是有的;特殊邏輯嘛,加就加吧,能導入就行。

但是,你每一個版本迭代的內容真的你都能記得往批量導入同步嗎?你這邊可能只是順手改了個字段的格式,沒準兒只是從多行文本變成了單行文本,填入字數限制從100變成了20,或者是限制不能填入某個敏感詞。如果你漏了批量投入,可能導入就報錯,并且可能是之前你沒有考慮到的錯誤原因,商家導入,報錯,錯誤原因,未知,再導入,再報錯……“

什么垃圾功能!”我都能想象到商家的氣憤,并且說了,批量導入很多就是解決冷啟動的問題,所以那時候商家遷移成本很低。因為并沒有太多數據在你平臺里。所以,出現這樣的問題可能讓商家對平臺的初始印象就不好,后續對接真的會耗費更多精力。所以,你必須保證隨時批量導入是可用狀態,因為隨時可能有新簽商家。

所以,批量導入真的是耗費資源的一件事,不止開發資源,還有你的精力。

靈魂拷問四:你認為的簡單真的商家也覺得簡單?

開發資源,有!特殊邏輯,加!迭代內容,跟著走!

到現在了,你覺得商家總該沒有問題了吧。但是,商家真的會看你那一堆文字注釋,按照要求修改每個字段?商家真的能理解,為什么只是導入一批數據而已,設置里卻多了那么多可能是幾年前用的一些選項?商家真的知道每個字段匹配上之后對應的數據狀態會變成什么樣?

在字段沒辦法完全匹配的情況下,商家真的能理解他源文件里的一些字段我們真的無能為力了,就是導入不了,因為我們沒有對應的位置或者功能去使用到這個字段?部分情況下是不會的,商家不會看你的注釋,除非是一些常規搜集的文件,可能按照你的要求來填寫,但是如果是純歷史數據,肯定是大量的情況下商家才會用批量導入,你讓他挨個核對完再導入他不會認為這是個提效的方法。

如果有字段真的導入不了,他會問你,這樣我的數據是不是就有丟失啊……

商家有時候是真的不聰明,有時候是聰明但是懶,懶到他覺得這東西丟給你就是能完全兼容處理,不能處理就是你的問題。如果操作失敗率高,也是你的問題。

你真的準備好接受這些問題的洗禮了嗎?

以上,差不多就是我認為批量導入四個很關鍵的問題了。

當然,不要太悲觀,做好了真的感覺還是很開心的,我從最開始導入成功率不足5%做到現在基本都能成功也是很不容易的,看著導入成功10000條這種感覺還是很棒的,瞬間覺得“哇自己真的給商家省了好多事情誒?!备杏X賊6,還是比較有成就感,雖然這個成就感來得有些艱難。

雖然如此,其實建議大家能不做批量導入的地方最好還是不要做,太多坑了,如果是一個有行業通用點的庫,其實提供給商家所有可選的可能比讓他批量導入更合適,最近準備試驗這個方案!看看能不能脫離批量導入的坑。

 

本文由@一白 原創發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash, 基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 1、歷史,異構系統數據導入,導出,涉及到前臺,后臺,數據庫表,字段,邏輯,約束等,大學問,你要踩的大坑,深坑,還早,,
    2、繼續修煉業務流程和邏輯,場景不精通

    回復
    1. 妥妥的**樣

      回復
    2. 妥妥的zb樣

      回復
    3. 你繼續呆在,元素周期表51號元素位置上, 蜀犬吠日

      回復
    4. 發自己的總結是為了能夠跟小伙伴們討論交流,我確實還有很多需要學習的地方。在不了解對方的時候您說話還請注意,言者志之苗

      回復
    5. 嗯嗯 確實還有很長的路要走,所以開始慢慢總結輸出了

      回復