作為一個基礎功能，導入功能在產品中沒有太大的戰(zhàn)略意義，也不是什么核心功能。但這并不意味著就可以隨意應付。能把這些基礎功能做好，反而說明了產品經理的基本功很不錯。

這段時間全身心撲在另一個項目上，一直沒機會繼續(xù)輸出內容，臨近春節(jié)項目也規(guī)劃好了年前年后的各項工作，總算有點空隙來寫點什么，筆者整理了下思路，決定選擇探討“數(shù)據(jù)導入”這一功能，原因主要有兩個方面：

首先，“數(shù)據(jù)導入”是B端產品中一項基礎而通用的功能，不受行業(yè)限制，以此為切入點，記錄自己在分析用戶目的、業(yè)務場景、價值體驗時的思路，這樣更容易被來自各行各業(yè)的朋友所理解和應用，特別是剛入行的讀者朋友，如果有需要可以以此文為基礎，取其精華，去其糟粕。

其次，打磨好常用的方案進行總結和記錄是筆者個人的習慣，這樣不僅是在加深自己的記憶，也是在積累專業(yè)底蘊。在未來面對不同類型項目時，就可以敏銳的察覺到當年走過的坑，然后迅速復用這些經驗。在筆者看來，這也是衡量一個產品經理對于企業(yè)能帶來多少價值的關鍵之一。

一、需求分析

確定目標用戶與使用場景

用戶背景分析：首先要了解你的目標用戶是誰（財會系統(tǒng)-會計、財務，人力資源系統(tǒng)-BP、秘書，呼叫中心-客服），他們通常需要導入什么類型的數(shù)據(jù)（客戶數(shù)據(jù)、訂單數(shù)據(jù)、產品數(shù)據(jù)等）。

使用場景定義：明確用戶在哪些具體情況下會用到導入，以及導入的具體信息。比如系統(tǒng)重構后希望立即遷移舊平臺的數(shù)據(jù)；或是已有用戶想要更新信息；或者日常運營中需要批量加工數(shù)據(jù)。那在現(xiàn)狀沒有導入功能的情況下，對于用戶的影響是什么（沒辦法快速查找數(shù)據(jù)？無法快速對數(shù)據(jù)進行加工？)。

需求評估

1. 需求頻率：數(shù)據(jù)導入發(fā)生的頻率是多少？每天需要導入幾百次，和一年導入十次，那設計方案的思路是完全不一樣的；
2. 需求范圍：有多少用戶受到了這個問題的影響？幾個人需要用導入來加工數(shù)據(jù)，還是有幾百個人需要用導入來加工數(shù)據(jù)，前后兩種場景得出的投入產出比相差可能很大；
3. 業(yè)務價值：實現(xiàn)這個需求，可以帶來多大的價值？是節(jié)省多少個運營工時或者增強數(shù)據(jù)準確性，還是能提高用戶滿意度和轉化率續(xù)簽率等等?；蛘哒f既不節(jié)省工時，又不直接帶來經濟效益，但是要滿足集團的合規(guī)要求或者數(shù)據(jù)管理規(guī)范的要求？

從上面三個維度出發(fā)，我們可以對需求，建立起來粗略二維矩陣模型來宏觀的審視需求(此處僅為方法論，未代入具體案例)

• 高頻率高廣度：這是最高優(yōu)先級的需求，應該盡快解決。
• 高頻率低廣度：雖然影響用戶較少，但如果這些用戶非常重要（如核心用戶或付費用戶），也值得優(yōu)先考慮。
• 低頻率高廣度：雖然不是經常發(fā)生，但由于影響廣泛，也應該給予重視。
• 低頻率低廣度：這類需求優(yōu)先級最低，可以在更重要的需求得到解決之后再考慮。

當然，這也只是方法論的一種，也可以使用其他方法作為分析的依據(jù)，例如MoSCoW方法、Kano模型、RICE評分等等，方法論主要是手段，核心還是分析思路需要跟業(yè)務同頻，盡可能的從用戶身上拿到所有想要的東西，以支撐下一階段的方案設計。

問題示例

因為業(yè)務特殊和篇幅原因，這里不展開寫調研的所有內容，只對核心結論寫幾點：

根據(jù)前期的調研和業(yè)務盤點，并加以分析之后，我們發(fā)現(xiàn)用戶存在長期高頻率的線下做數(shù)據(jù)加工然后讓IT手動導入數(shù)據(jù)庫的場景，并且這個過程中出現(xiàn)的問題如下(僅為示例)：

• 數(shù)據(jù)量大時，審核人員校準文件非常困難，且都在做重復性工作，例如檢查日期格式，檢查數(shù)據(jù)中的人員是否在職，這些都是可以固化的規(guī)則邏輯，完全可以實現(xiàn)自動化，釋放業(yè)務、運營或開發(fā)的精力；
• 人工校準會出現(xiàn)失誤，導致導入錯誤數(shù)據(jù)，需要返工，影響系統(tǒng)對業(yè)務的支持；
• 因為數(shù)據(jù)導入鏈路長，使得業(yè)務數(shù)據(jù)更新的時效性不高，影響系統(tǒng)對業(yè)務的支持；
• 數(shù)據(jù)唯一性無法保證，常出現(xiàn)重復數(shù)據(jù)；
• 因為都是微信或其他辦公軟件在發(fā)送文件，會出現(xiàn)發(fā)錯，或文件過期，IT人員遺漏消息等問題；
• 某些業(yè)務數(shù)據(jù)屬于內部敏感資料，需要多人員去配合完成導入，有泄漏外傳的風險，不符合合規(guī)管控要求；
• 導入之后無法修改，必須刪掉所有數(shù)據(jù)重新走一遍導入流程；
• 一份數(shù)據(jù)多個系統(tǒng)分別需要其中某一部分時，要業(yè)務拆表制作，而拆表后，一旦更新又要重新制作，重新拆表，重新給多方更新，不然會影響數(shù)據(jù)質量，十分繁瑣；
• …….

基于以上調研分析結果，我們開始進一步的方案構思

二、流程方案設計

現(xiàn)狀流程

根據(jù)梳理的現(xiàn)狀導入流程來看，是完全沒有做任何系統(tǒng)支持的，基本上都靠業(yè)務人工審核數(shù)據(jù)，審核之后IT手動用腳本在數(shù)據(jù)庫中直接去寫入，非常原始，我們可以用到筆者在前一篇文章【B端產品經理的流程設計思維（下）實操部分】中寫的流程優(yōu)化方法

去進行判斷，后續(xù)開發(fā)為系統(tǒng)功能之后，流程上要優(yōu)化的幾個點

• 原流程無角色信息，職權不明晰
• 加工業(yè)務數(shù)據(jù)前，可以先按照數(shù)據(jù)庫格式進行要求，避免最后一步返工
• 上級審核的規(guī)則和判斷，固化成一條條的清晰邏輯，用系統(tǒng)校驗替代人工
• 開發(fā)導入這個動作可以完全省略，系統(tǒng)頁面增加導入功能，整體流程由用戶側完成導入不成功返回結果，可以根據(jù)實際需求，做成實時反饋(彈窗或下載報錯數(shù)據(jù))，或者統(tǒng)一反饋（郵件通知）
• …….

優(yōu)化后的流程

流程說明文件的撰寫方法，在前面文章有詳細寫過，這里就不再復述了，在流程方案澄清，評審通過后，我們就可以開始系統(tǒng)方案的設計了，也就回到了我們產品經理的專業(yè)領域上

三、系統(tǒng)方案設計

導入模版設計

我們在流程方案設計時有提到，直接上級審核這個活動環(huán)節(jié)，我們可以將審核的規(guī)則，固化成一條條的邏輯，用系統(tǒng)校驗替代人工，那么這些審核的規(guī)則，我們即要在前端讓運營人員加工數(shù)據(jù)時就知道，也要在系統(tǒng)后端，校驗導入數(shù)據(jù)時用到。這里就需要導入模版的設計了：

• 【模版說明】：通過抬頭第1行告知填寫的人員注意事項；
• 【字段】：來源于前期跟業(yè)務敲定的共識，以后統(tǒng)一使用標準字段；
• 【填寫格式】：來源于前期跟業(yè)務敲定的共識，以后統(tǒng)一使用標準格式，如日期填寫都是用 YYYY-MM-DD，而不是2025/1/1 或 2025.01.1；
• 【數(shù)據(jù)起始行】：寫入數(shù)據(jù)庫的順序起始第1行;
• …….

如果字段填寫的數(shù)據(jù)，是固化的值列表，也可以直接設計在模版中，避免手工輸入時誤填，并且表格本身也會做一道校驗，用戶誤填也能及時知道，而不是等上傳了報錯才發(fā)現(xiàn)，如：

如果字段之間有一定的集聯(lián)關系，也可以在模版中說明并在prd中寫明相應邏輯，如：

• 填寫了B字段，則C字段必填；
• 如B字段中填寫10，則對應校驗C字段填寫必須為1-10之間的整數(shù)；
• 如B字段中填寫20，則對應校驗C字段填寫值必須為11-20之間的整數(shù)；
• ……

導入功能設計

1、導入按鈕

在需要導入的頁面，增加【導入】按鈕，點擊后選擇本地文件進行導入，似乎是最簡單的操作體驗

但是怎么讓業(yè)務知道，我們有設計導入模版，需要滿足模版格式進行導入呢？所以這里需要在點擊【導入】之后，給一個下載模版文件的入口：

方案做這一步已經能簡單滿足導入的需求，但在前期調研的時候，業(yè)務上還有一些細微的問題，比如同時制作的文件很多，容易找不到，或者覺得去系統(tǒng)上一步步點上傳很麻煩，不如以前做好之后發(fā)給IT去導入等等

這不僅僅是實現(xiàn)功能就能解決的，基于這種偏負面的情緒，我們可以在功能體驗上做更多優(yōu)化，降低用戶抵觸心理和學習成本，比如：

• 支持拖動上傳，減少操作步驟；
• 增加上傳過程的提示，緩解用戶等待情緒；
• 上傳成功或上傳失敗，都要有對應的提示告知用戶；
• 可以操作的地方亮起，不能操作的地方置灰；
• 打磨其他細節(jié)，務必做到操作簡潔，體驗清晰，指引準確；
• …….

以上面寫的材料作為依據(jù)，產品方案設計如下

2、點擊導入，彈出導入窗口

• 拖動文件到彈窗中，自動上傳(需要做文件格式識別，拖入word或其他文件無法上傳)
• 點擊彈窗中間區(qū)域，調起本地文件選擇器，選擇文件類型僅支持，xls/.xlsx 格式。
• 點擊【點擊下載模板文件】處，即可下載導入模板；導入模板命名：xxxx_批量導入模板
• 未選擇文件前【上傳】按鈕置灰，不可點擊

3、可【重新選擇】后上傳

也可以在選擇文件這一步，就做一級校驗，即校驗選擇的文件中字段，與模版字段是否一致，如一致則正常選擇，顯示在彈窗中，如不一致，則報錯提示：

選擇文件無誤后，點擊【上傳】按鈕進入上傳進程，上傳進程中【取消】和【上傳】按鈕置灰無法點擊(看實際業(yè)務場景，如果需要上傳中途也能取消，則需要中止進程并對已上傳數(shù)據(jù)進行注釋)：

4、上傳進程校驗結束

1）【上傳成功】

文件信息上傳成功后，頂部浮窗顯示：

注意：這里需要跟業(yè)務對齊原則，上傳校驗邏輯采用以下哪種方案

• 所有數(shù)據(jù)都校驗通過，才可以上傳成功，否則整個文件全部失敗；
• 文件中校驗通過的數(shù)據(jù)正常上傳，校驗失敗的數(shù)據(jù)，單獨生成失敗文件；

這里為了方便報錯文件生成，二次上傳避免重復數(shù)據(jù)，避免拆表，故選擇a）方案，上傳成功后可點擊【繼續(xù)上傳】即可調起本地上傳彈窗，繼續(xù)上傳內容。

2）【上傳失敗】

數(shù)據(jù)校驗未通過

• 上傳數(shù)據(jù)中，若上傳數(shù)據(jù)中有數(shù)據(jù)未通過校驗時，全部數(shù)據(jù)都無法正常導入，對應有問題的數(shù)據(jù)按字段分別生成原因在“失敗說明”列；
• 點擊“點擊下載失敗信息”將下載上傳失敗的表格到本地；模板名稱：xxxx_批量導入失敗信息

校驗邏輯說明

根據(jù)前期調研到的業(yè)務規(guī)則進行梳理和標準化，與業(yè)務代表達成一致后，形成固化邏輯并交付開發(fā)，以下均為示例，僅做參考：

校驗原則：校驗所有字段信息，如有錯誤數(shù)據(jù)僅做記錄，不中止校驗，在上傳失敗文件中統(tǒng)一呈現(xiàn)失敗說明(數(shù)據(jù)較多時，對系統(tǒng)性能要求較高，慎用)

a）必填項校驗：校驗數(shù)據(jù)行中必填字段是否為空，為空則失敗。失敗說明：【對應字段】缺少必填信息；

b）權限校驗：校驗導入員工數(shù)據(jù)，是否為操作人同一組織部門，不為同一組織則失敗，失敗說明：無員工組織范圍權限

c）重復項校驗：以員工ID+開始派駐日期+結束派駐日期 為基準，檢驗本次導入數(shù)據(jù)+系統(tǒng)中已存在的數(shù)據(jù)，一個員工在同一時間內僅可存在一條派駐數(shù)據(jù)，否則失敗，失敗說明：【員工ID】存在重復數(shù)據(jù)；

d）集聯(lián)校驗：

1）未填寫【A列】時，【A列】【B列】字段都不校驗，不寫入該列數(shù)據(jù)；

2）已填寫【A列】時，【B列】為必填并需要寫入【A列】【B列】數(shù)據(jù)，否則失??；

e）【員工ID】：校驗填寫的ID是否為集團在職員工，失敗說明：【姓名】員工不存在

f）【派駐場景】：僅支持導入當前系統(tǒng)中已配置的派駐場景，否則失敗，失敗說明：【派駐場景】填寫內容不存在

g）【派駐開始/結束時間】：

1）校驗導入的派駐時間段格式是否正確，錯誤時失敗說明：【派駐開始/結束時間】格式錯誤

2）數(shù)據(jù)的派駐時間段是否有誤（結束時間需大于開始時間），錯誤時失敗說明：【派駐開始/結束時間】開始時間大于結束時間

h）……以此類推

失敗信息

下載失敗信息表，進行報錯詳情查看后修正并重新導入，如下增加【失敗說明】列：

四、總結

導入只是個很基礎的功能，實際并不具有戰(zhàn)略性的業(yè)務價值，也不足以成為核心功能進行賣點宣導，但是做基礎能力的態(tài)度和思維，往往決定了一個產品的下限。一些細枝末節(jié)的角落，能不能設計到讓用戶幾乎是趨于本能性的進行使用，讓操作體驗無阻，業(yè)務流程銜接順暢，這非常考驗產品經理的設計思維。

本篇文章為了更具體的說明邏輯，筆者簡單舉了一些業(yè)務場景的例子，這里只是為了能夠擴大通用性，讓讀者朋友能代入后去清晰的閱讀，也是給未來的自己留下一些面對不同領域業(yè)務也能復用的材料。實際上根據(jù)系統(tǒng)架構、業(yè)務需求、產品定位、用戶群體等等不同，這里面可以做的差異化設計還有很多很多，再寫幾篇文章也寫不完。包括導入的報錯，數(shù)據(jù)量小，怎么更快捷的進行數(shù)據(jù)修正，數(shù)據(jù)量過大，怎么進行拆表修正等等。還有財會系統(tǒng)、薪酬系統(tǒng)，對數(shù)據(jù)精度要求極高，需要犧牲很大一部分用戶體驗做多重校驗，對導入時可操作的數(shù)據(jù)權限控制設計、導入數(shù)據(jù)本身的分層校驗設計也十分復雜。

還是那句話，以上內容并非絕對的行業(yè)標準，各位讀者可以去其糟粕，取其精華，根據(jù)現(xiàn)在所面臨的處境按需取用，也歡迎大家進行良性討論和補充完善。