week4——產品與用戶接觸的方案

基于以前是偏中臺現(xiàn)在是后臺產品的實際現(xiàn)實，這里會說一下后端產品的用戶接觸方案。

我們一般把“B端產品”分為“大B”和“小B”，以淘寶舉例，在淘寶上開店的賣家們所使用的操作后臺我會稱之為“小B”產品，而阿里員工自身操作的系統(tǒng)稱之為“大B產品”，我現(xiàn)在主要負責的模塊更傾向于“大B”平臺產品。大B產品的和用戶接觸的便利就是用戶就是自己的同事，對于小創(chuàng)業(yè)公司而言（譬如我現(xiàn)在），很有可能我的用戶就坐在我對面的工位上（經常和需求方懟的天翻地覆~~~）

以我當前的工作經驗來看，主要是兩種形式的接觸：日常工作吐槽和特定的會議

兩種方式大多數(shù)情況下已經涵蓋了我作為B端產品需求的來源方式，當然對于兩種方式的需求形式和質量不太一樣。

首先是日常工作吐槽的模式，這樣的需求往往都是你在和業(yè)務方溝通的時候，對方比較不經意吐槽發(fā)現(xiàn)的，譬如說你和同事交流過程中，對方會吐槽某個UI很難看，某些功能找不到的時候，作為產品，就要好好思考下了~是否對方說的訴求是否合理？他的訴求通常是為了解決什么問題？如果判定對方所言合理，那其實可以按照需求的緊急程度和優(yōu)先級進行后續(xù)的迭代規(guī)劃。

這種用戶提供的需求好處顯而易見，由于用戶是一線的同事，所以很多時候會發(fā)現(xiàn)很多產品在設計之初未曾發(fā)現(xiàn)的漏洞，并進行完整的補全。問題的話在于當產品思考這個問題的時候，切忌忽視了其他，我就層經歷過自己上線了某功能之后結果影響其余產品的一項功能，導致整個頁面掛掉了~~~~~慘不忍睹~~~

其次是大型的需求會議，這種通常是項目部的客服同事或運營同事發(fā)起，當出現(xiàn)某些狀況，僅僅依靠客服人員無法解決需要從功能層面去解決的時候，這樣的會議便應運而生，通常這樣的需求溝通會比較正式，會前需求方會發(fā)需求草案，會后會發(fā)會議紀要，這時候作為產品需要細致的和我們的用戶——客服or運營溝通，為什么需要這個需求，實際場景是什么（這點尤其重要），當前的功能為什么無法滿足他，如果有必要的話，對于這樣的會議我建議錄音。等需求會議開完之后，別急著說什么時候能上線之類的，應該仔細在會后重新梳理需求，需求是否合理，是否有更好的解決方案，這些都是需要會后自己甚至組內溝通的（保證你向其他組員轉述需求時需求的完整性）。

最后，切忌，B端需求上線前 ?請千萬記住發(fā)需求上線通知及操作文檔。