中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

一、需求分析

確定目標用戶與使用場景

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

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

需求評估

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

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

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

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

問題示例

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

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

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

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

二、流程方案設計

現狀流程

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

去進行判斷，后續開發為系統功能之后，流程上要優化的幾個點

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

優化后的流程

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

三、系統方案設計

導入模版設計

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

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

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

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

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

導入功能設計

1、導入按鈕

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

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

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

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

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

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

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

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

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

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

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

4、上傳進程校驗結束

1）【上傳成功】

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

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

• 所有數據都校驗通過，才可以上傳成功，否則整個文件全部失?。?/li>
• 文件中校驗通過的數據正常上傳，校驗失敗的數據，單獨生成失敗文件；

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

2）【上傳失敗】

數據校驗未通過

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

校驗邏輯說明

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

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

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

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

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

d）集聯校驗：

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

2）已填寫【A列】時，【B列】為必填并需要寫入【A列】【B列】數據，否則失?。?/p>

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

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

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

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

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

h）……以此類推

失敗信息

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

四、總結

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

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

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