一份B端產品上線的深刻總結，不要再走彎路

今年6月由於公司需要，作為B端產品經理人，參與設計並上線了一款B端新APP產品，用於給公司業務部門及銷售人員提供銷售及管理服務，並採用了試點方式進行優化和減少問題影響面，目前仍在試點中。

這兩天想了下，還是有必要思考下由新APP產品試點引申的一些流程上和心態觀念問題，也算對未來的一個警戒，爭取逐步優化。因此總結分享給大家，無論是B端產品經理，還是前、後端產品經理或項目經理、牽頭方等，供個人參考吧。

目前雖然新APP作為IT部門來説算上線成功，業務線領導同事也認可了大家的艱辛，但實際用户口碑、使用效果可能並不是十分理想，如果業務部門就是投資的客户，我們就是促進客户成功的合作方，而不單單是IT系統的上線成功，也許能總結些經驗，下次避免並做得更好。

一、好的經驗

1. 上線1個多月前大家便完成了任務細化分工、責任到人、細化都操作步驟，以及發佈、驗證計劃、權限收集、範圍、驗證賬户、業務方支持人員等梳理，充分的準備使得當天晚上升級十分順利，沒有臨時性的重大問題。提前準備、細化、思考清楚確實十分重要。
2. 提前做好了試點期間安排，包括風險措施、問題處理優先級、骨幹人員上線當晚與第二天的主備替換等其他資源協調及風控，十分成功，職責清晰明瞭，負責對應模塊的人也能立馬跟進並優先處理核查問題。對IT項目來説十分成功。

二、潛在問題——系統方面1. 部分僥倖心理與判斷不全

任務拆解後，個人負責自己模塊，但在開發細節和測試上因人而異，個人判斷全面性有限，受制於對需求背景、目的、系統定位、用户等的理解，容易出現邏輯漏洞、功能偏差、或不利於生產核對，造成特殊場景發生問題、運維核對的困難耗時增加。

測試程序愛你的部分偶發性問題，容易被認為是隨機事件（網絡不好、測試環境不穩定、手機問題等、很偶爾出現），在時間要求下可能直接跳過。

可能的心態：自己看了沒問題，測試沒問題，那生產應該不會有問題，有問題了再解決，如果能集思廣益一開始就儘量理清楚也許能避免一些問題。

2. 生產環境的敬畏心不夠

生產就是生產，生產的本質就是儘量不要發生問題，要麼問題不致命、要麼有快速替換方案，更不應該習慣性生產有問題再解決，為什麼一開始沒發現？

生產數據也應當有所敬畏，為了試點問題的解決要求修改打卡時間和範圍（為什麼不用測試環境？可能因為不順暢導致生產驗證更便捷更快），生產驗證髒數據也一直暫未處理。

合理的做法是修改數據前，評估修改影響面及時間是否合適，驗證完後最快速度恢復原狀，測試環境至少有一套能快速配置和驗證問題。

3. 個人決定面較大

任務拆解後，重要的開發細節邏輯設計，個人可能部分判斷不全，測試組也儘量看到表面結果，難以深入看到背後數據變化判斷是否正常。不像之前做合同監控，有會議評審流程，共同指出漏考慮的情況，其他人也能熟悉鍛鍊思維，而不是自己決定所有細節邏輯後測試沒問題就上線，導致生產未考慮的問題發生、缺少部分運維核對數據、跨系統運維複雜度提升等。

一種更好的方法，較重要較複雜的邏輯設計，最好公示出來，由大家共同判斷，提出疑問，設計由個人做，但要理清楚邏輯細節，避免漏洞（離散型需求的邏輯思考方式可參考我的《從考勤管理需求説起，聊聊場景的思維“工具”》）。

4. 郵件美好的表面下是暗流湧動

郵件內容是美好的，都不願意暴露問題。但背後看不見的是問題的臨時性處理、次數寫死，測試的偶發問題，有人提醒卻沒得到重視，好像1人要説服其他人一樣困難，於是只能放棄，缺乏影響範圍和致命性分析。

於是生產發生了“偶發性問題”，再吭哧吭哧的回頭排查原因和修改，確實很辛苦也很盡心，但，也許一開始就引起重視，或者先記錄後續主動跟進優化，也不至於被動響應用户，每天小心翼翼的擔心別出問題。

5. 暫缺進一步優化節奏

到目前為止10多天，暫未聽説有上線前或者上線後的主要優化計劃，部分優化措施也是有意思，之前考勤定位採用的百度插件，結果新APP上線出現偶爾異常，找不到原因就換成了高德，那舊APP用百度同樣的插件為什麼就沒問題，是否有足夠的評估和理由？換了第三方就100%一定行？是否完整評估過？

另外切換成新的第三方插件包後，為什麼沒做詳細測試？百度與高德由於座標基礎體系的參照不同，在定位獲取上存在經緯度偏差問題就沒有人想到過？想當然參數對就不會有錯，先上線再説的心態是否屬於僥倖心理？

再者，打卡性能優化、新APP切換優化、提示語優化可能還有待安排計劃，不然只能通過強制的方式要求用户使用新APP，這可能不太符合互聯網式思維，也可能降低用户動力、增加心理負擔。新APP本身設計美觀、快捷、更人性化（也許以後會有），就應該打出自己的特色來吸引用户。聆聽用户聲音，優化可能是常態。

6. 割裂型組織的弊端開始出現

由於戰略需要，目前是按照職能劃分小組而非項目產品線。開發人員在一塊、需求人員坐一起、測試人員圍一圈，運維人員獨立開，按職能割裂，導致開發人員需要的信息在需求和運維處，開發只能根據文檔製作，最終效果可能並不是客户所想要，測試只能根據文檔測試出明顯界面和功能異常，難以理解背後數據的變化和流轉異常，運維在揹負用户催促壓力的同時也無從下手，最終導致所有人都在催開發人員的進度、問題處理進度、質量不夠好等，用户嫌運維處理不夠快，客户嫌需求太慢，測試回覆開發有問題後就可以不管，缺少了整體聯動性。

這種組織下，誰也不願意多考慮一步，也不方便插手別的小組工作，劃分職責界限的後果就是，任何事情分清責任後，只負責各自模塊，其餘的流程推進、問題排查、整體性優化都難以提升效率。

即使由產品經理逐步開始牽頭整體流程，但由於權限、跨組、崗位要求難以真正牽頭，現象仍然存在。這種割裂組織在溝通和理解上容易產生偏差並擴大，因此協調處理時效性下降，用户體驗下降，雖然專注力得到提升，但容易造成職能割裂，很簡單快捷的小事也被流轉拖延。

三、潛在問題——用户方面1. 試點用户口碑未有效維護

口碑維護不光是運維的工作，還有需求、開發、業務同事的共同支持。但這次試點仍然是問題答疑式思路，並沒有看到口碑的維護。

試點的目的也許除了確保新APP功能的可用和順暢，讓用户來驗證發現問題外，還應當與試點用户形成良性互動，成為新產品的間接代言人，輔助口碑宣傳和推廣，而不是完全依賴自上而下的強制性要求使用。就像家長與青春期的孩子，沒有孩子喜歡總是被強迫、被管理，哪怕為他們好，尤其是自由業務員，激發、鼓勵、理解、共同參與感也許更有效。

目前試點羣更多同其他微信問題羣一樣，羣裏官方式解答，問題在羣裏被放大，沒有影響面解釋、現象解釋、協助內勤主動登記補打卡、切換舊APP等臨時性措施，導致業務領導認為新APP穩定性極差，羣裏天天是問題，用户以為自己是使用順利的個例，原來系統問題這麼多，就更沒有用户口碑、用户鼓勵、對新APP的認可、界面的美觀、對付出結果的肯定了。

2. 缺乏關懷與温度的用户運營

用户情緒未有效照顧到，試點用户是協助我們發現解決問題以及試用反饋，他們最擔心因為試點問題導致打卡失敗工資扣款，所以8點半是個敏感時間（8點半是上班打卡時間，遲到、打卡失敗影響出勤率），情緒容易波動、抱怨，除了標準式解答外，缺少交流、溝通、安撫，理解感受，讓用户放心有補打卡，並解釋互相理解後重拾信心，共同參與解決問題，聆聽建議，反饋操作習慣，才能提升更高的參與感和信息收集。

問題處理後也可以第一時間告知指定用户，有反饋、有聆聽並採納，才被尊重，才有意願提其他建議和問題，反饋很重要。

3. 準備的緊急措施未充分使用的總結

緊急打不上卡時可切換回舊APP打卡措施未啓用，而只是上報給內勤，試點內勤的壓力可想而知，比原來增加更多工作量，以及業務員可能騙補卡給內勤帶來的壓力（上報原則？證據？要求？都沒有，業務可不一定想這麼細緻，出了錢就希望我們能幫忙解決問題）。

以及下載、安裝等緊急措施是否執行順利，有機會做個回顧總結能避免下次的手足無措，緊急措施也許更符合實際需要。

4. 缺乏數據跟蹤分析與策略調整

（由於數據敏感，不方便放上來，實際根據數據趨勢需要做細化分析）

例如截止7月15日，試點範圍的半月累計打卡人數N萬，至少有一次打卡成功的有N/3萬人，而在試點實施前的近兩個月內，半月累計打卡人數基本為2N萬人左右。於是發現了自從試點後，試點範圍的打卡人數遠低於試點前的打卡量。

7月2日到7月3日鋭減，是因為業務工作安排原因？還是業務員利用試點期間的異常補打卡規則或其他原因而不出勤？補打卡規則應該有要求：只能登記當天結果，以照片或當面方式證明人在現場，避免規則漏洞。

每天打卡失敗的人，是以前一直失敗的，還是第1次出現的？是否獲取了賬號和原因

除了打卡，其他功能使用情況如何？邀約入司、信息查詢等是否有其他問題

目前看打卡和IOS安裝問題已暴露和優化（IOS企業證書籤字及APPStore審核是通病），因此接下來需要更多人來試探壓力、併發、時效性等能力，才能進行全國推廣。

四、參考建議（初步，暫不展開）1. 設計邏輯公開

由產品經理牽頭開發與需求人員做需求設計，個人可以設計細節邏輯，但需要郵件發到同組人一同查閲，或組織會議説明思路，避免個人盲點，發揮不同人的理解與經驗，吉意保這塊邏輯我可以協助分析，排查開發漏考慮的潛在場景。

2. 傳達理解需求目的目標

產品經理牽頭，需要需求人員傳達文檔時，介紹需求背景和業務大致目的，理解後的設計才是符合業務心裏需要的設計。以共同的需求目的結合文檔來開發、測試、運維（一點發散狀），比僅以文檔為標準和理解的開發流程更不容易走偏。

3. 用户體驗的可行性

無論開發、需求、測試、運維等人提的優化建議，都應當有合理的分析，並能説服大多數人認可（得到用户認可更佳）。

五、關於B端產品的用户理解1. B端產品的相關方

• 客户：業務部門或甲方，投資以滿足他們的目的，即通過對銷售渠道、人員管理以及採用任何能促進收入的工具方案，最終提升渠道收入和利潤。有的依賴業務員，有的依靠中介機構，有的直接線上銷售。
• 用户：使用產品服務的人，包括業務員（移動端）、顧客（移動端）、機構內勤（PC端為主）、客户自己（PC端為主）。業務員的目的是能出更多單來賺錢，顧客的目的分人羣較複雜（見另一篇產品經理的能力方向思考），機構內勤的目的是提升工作效率減少工作量，客户目的就是業績收入和利潤。
• IT：接受投資，以客户最終目的來拆解階段目標、結合不同用户的目的和習性，從整體方案設計、確認、實施、測試上線、售後運維等提供一站式打包服務。如何幫助客户，激勵用户、促進客户收入。

2. 促進客户成功

抓住需求背後的目的，並以最終收入和利潤（降成本）為價值衡量標尺，為客户提供合適綜合方案和長期規劃供選擇。開發過程隨時確保相關人員理解需求背後的目的再行動，再設計，避免走偏、重做、不合需要等（客户花錢買服務和產品，是為了渠道能收入更多）。

3. 促進用户轉化

業務員永遠是來賺錢的，業務員的產品服務需要更簡潔直觀、收入清晰、幫助促進銷售等理念（如獲客工具、打消顧客疑慮等所有能促進成交收入的服務）。顧客因人羣而異，但公司的目的是促進顧客轉化成交更多業績收入。

機構內勤是想盡量減輕工作量、提升效率、滿足領導和制度管理要求。客户則是想了解更多信息以知道該如何調整策略，促進更多收入。用户體驗的提升也是為了間接讓用户爽，從而激勵、促進轉化等間接提升業績收入（培訓學習、出勤早會、考試的目的、佣金利益直觀反饋等都是）。

4. 促進IT方案本質化

針對需求的用户不同，設計的原則理念也不同。業務員用户，滿足快捷簡單、與我有關、動力促進、付出反饋激勵、能幫助促進投保的需要，顧客用户需要分羣分析。

機構內勤，滿足人工計算替換為系統計算人工核對、無紙化、簡單快捷獲得想要的結果、問題能快速解決等。客户，滿足促進渠道業績收入的各種工具和產品服務、支持管理需要從而間接提升業績收入、快速獲取信息及方案進展等需要。而不再單單實現提出的文字類需求，考慮更本質。

5. 3方共贏的良性閉環

商業的本質是賺錢，是促進公司業績收入和利潤，所以IT的產品服務直接間接的本質也是為了促進公司收入，只有促進客户、用户、IT 達到3方共贏，客户有收入，用户賺到錢或提升自動化效率或解答了顧客疑慮，客户才更願意投資，用户才更願意使用，IT才更能發揮專業價值並獲取更多請求，形成閉環。

所以，像大家經常提到的單純的業務員留存率、人均銷售量、人均業績這類宏而大的統計意義不太大，大而空的用户體驗也意義不大，就好比全國人均收入一樣，對個人並沒有什麼價值，並不能發現問題並想出辦法解決，反而小組內銷售排名、出勤排名、活動排名、銷售精英留存率、新人3個月內二次銷售率（排除自己購買單）顯然更能發現人員健康問題和趨勢。

精細化方向可能會越來越明確，基於企業收入本質和相關方共贏的設計理念可能越來越需要。

仔細想想，是否大家也有這類問題現象？有任何疑問歡迎留言。

本文由 @瀟傑 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash ，基於 CC0 協議