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

編輯導讀：復盤是每一個優秀的職場人都應該具備的一項技能，產品經理也不例外。本文作者以一份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. 促進用戶轉化

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

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

4. 促進IT方案本質化

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

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

5. 3方共贏的良性閉環

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

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

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

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

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

題圖來自 Unsplash ，基于 CC0 協議