記一次B端產品的改版

08-15

記一次B端產品的改版

來自專欄產品經理成長之路5 人贊了文章

這篇文章主要是復盤之前做的一次系統改版。時間已經過去一年，回過頭來看，當初那個非常tough的項目，帶給我的成長和收穫也是巨大的。

去年我剛剛接觸To B系統，對業務還不甚了解，就突然接到了系統改版的任務，迷茫且慌張，但還是硬著頭皮上了。幸好。

現在重新梳理項目，於是有了這篇文章。

這次改版的系統主要負責借款的流轉，整個流程包括：進件（即提交客戶基本資料）→風控審核→簽約→放款。以下簡稱為Borrow系統。

這次改版是所謂的「設計主導」，也就是說，沒有需求方來主動下達任務，而是由設計師去主動發掘改版需求，提出改版目標並探究其必要性。所以，首先要通過調研來確定改版目標。

我的調研方式主要包括：

1.與產品經理溝通了解產品概況；

2.在現場觀察用戶的使用情況，並進行一對一訪談；

3.查閱系統的歷史演變過程，並了解與之有數據交叉的其他系統。

我主要對以下幾個方面進行了調研：

用戶

首先要搞清楚，到底是誰在使用這個系統。

通常我們面對的系統，都是滿足某一類用戶的需求，用戶在系統里的工作流也是確定的。

但是我發現，在Borrow系統中，有幾類不同的用戶都在使用。主要為：分公司門店的線下客服（以下簡稱門店客服）與電銷中心的電銷（以下簡稱中心電銷）。

除此以外，還有少量的其他用戶，比如主要服務其他業務線的兼職電銷也會階段性地做這部分業務，比如線下銷售也偶爾會在系統里查看相關數據。

通過進一步跟產品經理溝通發現，在這些用戶中，線下客服是使用數量最多，且貢獻價值最大的用戶（為公司賺錢最多）；其次為電銷中心的電銷。所以我決定此次改版，將線下客服定為主要用戶，同時考慮電銷的使用。忽略其他群體。

工作流與工作目標

確定主要用戶後，我就申請到分公司做現場調研：現場觀察用戶的日常工作和使用系統的情況，並針對發現的問題作一對一訪談。

因地理條件所限，我選擇了同城的門店客服進行線下調研；對中心電銷採取了線上採訪的方式。（如果條件允許，建議大家申請出差到核心用戶身邊進行現場調研，收穫真的很大。）

門店客服：

門店客服的工作主要由三部分組成：M1階段的催收（逾期一個月以內的借款的催收），進件（將銷售提交的紙質資料錄入系統），簽約（當錄入系統的借款通過審核，走到簽約環節的時候，需要來到門店進行線下籤約）。其中，與Borrow系統產生交互的部分主要是進件。

想要做出用戶喜歡使用的系統，就要知道用戶的工作目標，最直接的體現就是「錢」。為此，我仔細詢問了門店客服的工資績效，發現：門店客服的績效是直接與簽約量掛鉤的，簽約客戶的逾期會影響績效；而進件只是一個基本工作任務，不計入考評。

然而不合理的是，「進件」作為不計入考評的任務，卻因系統的不便，佔用了門店客服大量的時間。由此，我決定，將「進件流程」的改版，作為整個大改版的切入點。這樣的話，在缺乏強有力推動的現實制約下，花少量人力，去解決一個痛點，更容易增強業務方對改版的接受程度。（業務方對技術部發起的改版並不都是支持的態度，這涉及到業務方和技術部對產品期望不同，下一部分將會進一步闡述。）

需要注意的是，在線下的業務中，門店各自保持著相對的自由度，譬如不同的績效考評方式，不同的簽約條件等。所以在後期，我們又專門挑選了幾家逾期率最低的幾家門店，進行了一對一採訪。

中心電銷：

與門店客服相比，中心電銷的工作更多地在「借款前」這個階段，比如對意向客戶進行產品介紹，比如輔助意向客戶完成借款流程。而且因為與門店客服負責的業務不同，中心電銷也不涉及「催收」的工作。

中心電銷的主要工作是：每天被分配到一定的客戶，然後依次撥打電話，了解客戶意向以及推薦借款產品，並協助完成借款流程。其中，中心電銷會通過手動篩選客戶來優先聯繫「高質量客戶」（這屬於電銷為了業績的個人行為）。

中心電銷的績效主要也是看最終的放款量（即簽約量），會考慮通時通量以及語音質檢結果，但不是主要因素。

產品期望

不同的角色對於產品的期望是不同的，而權衡不同角色的期望，最終決定改版的目標，就是我們調研階段最重要的任務。

從技術的角度出發，我們更希望系統能夠體現技術的價值，比如，通過一些自動化行為，替代部分一線業務人員的機械勞動；但是業務方卻並不想自己的人員被削減。類似這樣的改版除非是有強大的來自上層的壓力去推，否則非常容易因為業務方的不配合而失敗。

所以，在前面提到的，用一個引起痛點的小模塊的改版來贏得業務方的信任，後續再進行更大的改動，是非常重要的。

通過訪談和觀察，我了解到：

產品經理對Borrow系統的期望是，在滿足業務需求的基礎上，可以提供通用的解決方案，早日將系統Saas化；

業務方leader的期望是，加強數據報表的建設，能直觀準確地得到各個環節之間的轉化率，以便及時調整策略；得到員工相關的多維度信息，更全面客觀地評價員工的工作情況，合理安排人員、分配任務。

一線業務同學的期望比較瑣碎，我提煉了一下，大概就是高效（優化交互流程，減少不必要跳轉）、準確（減少誤操作的概率）、流暢（系統響應速度加快）的系統。

產品經理的期望相對理想化，我認為應該當作綱領一下去看，是不能偏離的方向；而業務同學的期望，正是我們改版的著眼點。

最終，「高效「，」準確」，「流暢」，「數據」，成為了我們這次改版的四個關鍵詞。

歷史演變

在改版動工之前，關注系統的歷史演變情況，能幫我們有效避免不少前人走過的坑。

如果公司內部有良好的文檔留存習慣，在公司的wiki上，應該能看到不少關於項目的歷史紀錄。比如歷史版本變更記錄，歷史需求文檔，每一季度的產品map，甚至還有一些重大改版的復盤討論。

即使沒有較多的有效文檔留存，也可以通過與產品經理和項目核心成員的聊天中，挖掘一些歷史修改信息。

通過了解系統的歷史，能對如何開展改版有更客觀的認識，對遺留太久太深的歷史問題，要逐漸改變而不是推翻重來；而另外一些我們以為很不合適的方案，可能已經是經過數版改動而妥協的方案，剛愎自用，任性推新，反而會造成人力財力的浪費。

另外，了解相關聯的其他系統，了解在整個業務中，不同系統的權責劃分，能夠讓我們站在更高的高度上去思考問題。另外，當我們當前系統的數據無法支持設計目標時，也可以尋找對應系統的負責人去尋求幫助。

改版流程

在改版過程中，我以「進件流程」為切入點，做了一次控制項的優化。例如：輸入框，針對輸入內容顯示做優化，比如銀行卡按四位數一個空格的標準顯示；輸入框根據輸入字元數或基本格式（比如身份證號，手機號等有基本格式的字元）增加前端判斷，前端可以判斷的，直接報錯，以免進入流程，浪費時間；上傳文件交互優化，減少點擊次數等。

這部分改動較小，但是對操作者的幫助較大。上線後快速贏得比較好的反饋。

後期我們又進行了更深入的信息架構的優化，以及核心工作流的優化。但是因業務方向變動，最終這部分被剝離出業務，成為了飛機稿。