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

用戶運營的本質在于跟用戶有效地溝通。本文作者結合自己工作中的所思所想，對用戶溝通的4個階段展開了分析總結。

做好用戶溝通，了解用戶習慣和用戶目標對于一個B端產品的成功來說十分重要。所以今天我想聊一聊關于用戶溝通我個人的一些思路。在產品迭代中，按照產品的輸出過程，我把用戶溝通可以分為以下幾個階段，需求溝通，方案確認，上線培訓，產品灰測。

01 用戶溝通

從需求方提出需求開始到產品方案的輸出期間產品經理和需求方發生的溝通我將其統稱為需求溝通階段。主要是產品經理和用戶基于當前產品使用過程中發現的問題或者基于本人/本業務的目標期望而對產品提出的需求和想法進行溝通。在這個階段最重要的一點是要明確用戶到底需要什么（用戶需求），他為什么需求（用戶價值）。

1. 用戶需求挖掘

通常用戶需要一些引導才能得出真實的需求。你可能會問，作為用戶，應該是最清楚自己要什么的，為什么要引導，引導什么？舉個實際案例，某天用戶A提出用戶崗位中包含關鍵字“運輸”的用戶在填寫用戶資料時要求強校驗用戶的“運輸工具”是否已經填寫，如果未填寫則提示保存失敗。那么作為產品經理的你要怎么做，是否直接按照用戶提出的要求通過崗位名稱的判斷在填寫頁面增加用戶要求的校驗嗎？

————（此處請思考三分鐘）————

需求方說他想要的真的就是他想要的嗎？NO。

在溝通過程中建議用5W1H來定位用戶場景，使用5Why挖掘用戶真正的需求，同時需要完整了解現狀（這個以后有機會我再展開聊）。

在剛剛的例子中，可以試試通過以下簡單的問答來真正明確需求。

• 問：為什么這些用戶必須要錄入“運輸工具”？
• 答：因為系統需要根據錄入的“運輸工具”進行派單計費，如果他們沒有錄入就會影響工資結算。
• 問：具體是哪些用戶會需要根據運輸工具派單計費呢？
• 答：比如調度司機啊、派單人員啊這些。
• 問：那為什么你提的需求是有崗位名稱中有“運輸”的人員要求必填呢，兩者有什么必然聯系？
• 答：因為現在我給這些人取的崗位名稱都有“運輸”兩個字呀。
• 問：那崗位命名會一直由你來負責嗎，后續如果其他人來處理，他們知道這個規則嗎？
• 答：emmm…也許吧

所以其實用戶的需求是，對于要使用“運輸工具”的用戶進行錄入項目的管控，和崗位關鍵字無關。用戶犯了把最終實現結果作為需求的典型錯誤。

2. 需求價值挖掘

需求價值明確要求需求方在提出需求時明確這個需求為業務帶來的價值，并且最好是可量化的價值。

這個階段需要明確得向業務方問出這個需求的實現能夠幫你解決什么問題，帶來多大的收益。

要知道，和需求量相比開發資源永遠都是不夠的，總是有成堆的需求等待開發。所以，明確業務價值可以有助于產品經理更好的判斷優先級，完成更好的產品迭代。而需求方自身在思考價值的同時，也可以對該需求進行更加深入和完整的思考，可能會有意想不到的發現哦。

對于比較大的項目需求，甚至需要明確到每個功能點的價值，便于產品經理進行需求的拆分。

02 方案溝通

基于用戶需求，產品經理需要根據需求點評估和經驗通過產品方案設計來達成用戶的需求。在方案確認后正式進入開發前，需要和需求方進行最終的方案確認，通過文檔演示的方式向需求方展示需求的實現方式及效果，以確保可以真正解決業務問題。

這里需要注意的是，完整的產品方案除了明確功能實現方式（滿足需求）外還應該包括預計交付時間、交付范圍、項目推進進度（灰測計劃）。

1. 功能需求

功能需求即指能夠滿足業務需求的整體方案設計，其中包括了功能點、頁面、交互等用戶可以直觀看到、感受到的內容，也就是我們通常所定義的需求文檔。

這點其實是屬于基本內容，我就不再過多贅述了。

2. 交付時間及范圍

站在用戶的角度來說，他除了關心自己的需求能否得到解決外，他還關心什么時候可以得到解決，也就是我們提到的交付時間。所以我們在進行方案溝通時，也需要基于實現的難度給業務方一個初步的預估上線時間。

對于實現周期較長的需求，通常需要拆分需求迭代，此時則需要明確每個迭代涉及到的功能點和交付時間。這里通常需要結合功能點價值、業務痛點以及迭代的完整性來指定。前面兩個點比較好理解，迭代的完整性是指此迭代上線后應該是一個完整的、可以使用的功能，而不是需要等下個迭代上線后才可以一起使用，那么分期實現就沒有意義了。

產品經理在接收到需求后即使是對于實現難度大而暫時無法實現或優先級不高需要暫時擱置的需求，也應該明確的給予業務方答復，做到事事有回應、件件有找落，讓需求方可以及時啟動備選方案，避免產品的實現過程成為業務瓶頸。

3. 灰測計劃/運營計劃

在雙方確認好產品方案和上線時間后，產品經理需要確認用戶在項目上線后的灰度計劃/運營計劃。

對于推廣面比較廣的需求，為了避免全面上線帶來的風險，通常會選擇分區域或分用戶群逐步上線，稱之為灰度計劃，簡稱灰測。

灰測計劃往往是由業務方根據需求特性、業務覆蓋面進行定義。并且在產品交付后開始按照灰測計劃進行逐步推進，以確保實施的項目能達到預期效果、收獲項目價值。

產品經理也有責任確保需求價值的實現以體現自身價值，所以在這個階段雙方也需要對后期的運營確定一定的方案。

（悄悄的說，如果需求方無法明確運營推廣計劃，那么對于這個需求，他們可能沒有想象中那么“急”，我們可能需要重新回頭評估下產品的價值，看是否需要把資源安排給其他更有價值的需求了。說實話，我們有時候還是會碰到需求方在需求階段催著上線，而上線后遲遲不開始使用的情況，確實令人頭疼，所以前期的明確還是很有必要的）

03 人員培訓

產品正式上線前，為了確保后用戶可以正確的使用并且達到使用效果。產品經理通常需要進行上線培訓并提供相關功能的操作說明。

1. 上線培訓

公司中，基于溝通層級劃分的問題，通常需求的提報會是通過各部門內部的收口人向產品經理進行提報，同樣的，需求方案的溝通通常也是會由幾個代表或負責人和產品經理進行確認。因此在上線前還會涉及到對其他系統使用方的整體培訓，主要的內容也會是針對于本次上線的功能點、變更點。

（此處也偷偷說一句，注意培訓過程中要把握培訓節奏，不要讓培訓會變成需求收集會，我相信你們都懂的~~）

2. 操作手冊SOP

上線前，千萬不要以為培訓完了就完事兒了哦。不要忘記還有操作手冊的更新。完整的操作手冊可以幫助新用戶快速掌握系統使用，減少大量無效的溝通詢問時間。

04 產品灰測

在上文方案溝通中我們提到了產品經理和需求方都是有責任在前期明確運營和灰測推進方案以確保需求落地。因此在實際灰測階段，產品經理也需要花一定的經歷跟進灰測進度，以確保實施的項目能達到預期效果、收獲項目價值，并確?；覝y過程的異常得到及時處理。

1. 異常跟進、計劃調整

灰測過程一定程度是為了能在全面推廣前處理可能潛在的風險問題，避免問題的擴大化。所以在灰測階段，產品經理需要更多的關注線上的異常問題、及時反饋測試和技術進行異常處理，避免影響正常業務運行。

此外，如果真的不幸發生了比較大的異常，則需要重新評估異常點、提出解決方案、快速迭代上線，并及時和需求方一起調整灰測計劃，確保正常推進上線。

2. 優化點的積累

此外，在這個階段產品經理還需要多傾聽“用戶的聲音”，聽一聽那些“吐槽的聲音”，發現需求中的可優化點，判斷這些迭代時候是需求中的遺漏點、是否會影響業務操作、是否需要加入下一輪迭代。

結合用戶反饋和上線數據進行項目復盤，吸收本次的pros和cons，揚長避短，減少后續迭代中的“坑”。

總結

良好的用戶溝通機制可以幫助產品經理建立和用戶之間穩定的溝通橋梁。

從上面的文章篇幅其實也可以看出，溝通環節中最核心的其實是在于需求溝通和需求挖掘，正確把握用戶痛點了解用戶痛點可以說是成功了一半。最初的方向如果錯了，后面的溝通可能要多走很多彎路甚至于直接走錯路而造成開發資源的浪費。

當然，后續的方案溝通、培訓和灰測時的關注等都能幫助產品經理在用戶心中建立更好更專業的形象。

以上就是本篇的全部內容，希望本文可以對你有所幫助。

作者：麋鹿產品，公眾號：麋鹿產品手冊

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

題圖來自Unsplash，基于CCO協議。