(呈上篇)

但不是每個專案的需求訪談都需要到這樣的地步阿，那這些落在微妙程度中的需求訪談該怎麼辦?

後來我們將scope都拉回來”人”的身上，想辦法將事情簡單化，且成立一個 ”技術顧問” (要收費) 的角色，將回答的範圍問題做切割

我PM跟技術顧問的回答差在哪邊?

我去針對”使用情境”與”操作流程”(UX)做回答 (不懂技術也可以回答)

技術顧問去針對”技術開發”做回答 (懂技術才能回答)

使用情境與操作流程講白就是跟客戶一同站在”使用者”的角度去討論這件事，一切的經驗都從日常生活對於軟體使用體驗中得來，UX好不好會有一些指標性的規則，最少步驟/最少層數/最直覺操作等，這個議題很多人寫~大家有興趣可以去研究看看

某些軟體/產品/流程到底好不好用，統計上都會有個大方向，有個普遍大家認同的中位數存在，是一個既定事實，大家都會有共鳴

比方說：台新的APP大家普遍都覺得很讚，花旗的APP大家普遍都覺得很幹 (辣ㄍAPP工程師去找工作敢不敢把花旗APP寫在履歷上辣蛤：DDD)

PM要做的就是平日就要不斷去觀察且累積這些資料庫，去分析理解，哪些產品是UX至上超好用但很難開發，哪些產品是UX還好，但基本問題有被解決用戶也可以接受

比方說一些做大的產品，使用者人數眾多(用法不同意見也多)，在使用情境上勢必就有一些妥協，最吸引用戶來用的不是操作好不好用而是其他原因 (可能人多/便宜/只有這個管道…等) ，但他們可以砸錢做客戶管道解決問題，也可以砸錢開發自己的一套金流或操作流程

那今天如果客戶要做一個受眾小群針對性很強的產品，規模不像樓上這麼大錢也不多，那拿這些做大的產品的”使用情境”與”操作流程”來討論，就會很不妥

簽約前的需求訪談，PM要最大化壓縮溝通時間，因此在此階段PM要用已經有的產品去類比(所以才說平常就要累積資料庫)，且不要做錯誤的類比，可以讓問題停留在「這個”使用情境”與”操作流程”是可行的」但如果要接下來講細節那我們就要收費了 (吐槽一下，通常客戶都會有錯誤的類比，小錢想要騎大車，這點在報價前ㄉ需求訪談時PM也需要跟他們說唷(但怎ㄇ說就是各憑本事>.o))

這些才是PM要看的、要懂的全盤性的考量，在簽約前只針對大方向去討論，做正確的類比給正確的期待，也才是在(還不知道要不要做時ㄉ)需求訪談時可以最高壓縮溝通成本的手法

寫手法之一好了，因為我感覺應該可以再進化再進步，但這個大方向我目前實驗到現在都蠻有用的，跟大家分享一下，也歡迎大家一起討論看看

插播一下：之後我想寫一篇關於講”PM要不要懂技術”這件事，大家很常在問這個問題，好像PM懂技術可以解決很多事情，PM不懂技術可能會造成一些災難，但我不這麼認為，比起PM要不要懂技術，在此之前我更想跟大家傳教與洗腦的是 "PM可以不用懂技術，但PM絕對要懂架構概念與UX阿阿阿阿阿阿阿阿阿阿阿阿阿阿” 拜託~~~PM不懂概念與UX才是天大的災難好嗎！！！！！

當PM有能力跟在這個第一階段aka(還不知道要不要做時ㄉ)需求訪談去跟客戶討論操作流程與使用情境時，PM就能在這裡抓出一個大致的開發方向

而且是好用且好開發的方向

(相信我，你ㄉ開發團隊也會非常感謝你der)

接下來如果客戶真的有興趣想要繼續進行的話，就可以開始跟他談，阿我們技術諮詢要收費內~~ 不過你們想像中的使用情境我們都可以做阿~~ 還是我們要先簽約~~ 簽啦簽啦簽啦~~

回到我們的標題

“需求訪談”到底要報價前做還是報價後做?

報價前要做，但不要做太多，僅針對大方向範圍去討論，可以分割角色，PM僅做針對”使用情境”與”操作流程”(UX)做回答，如果要問技術，就告知客戶”技術顧問” 要收費

要做到什麼地步?

當然是越少越好啊~~ 還沒簽約前的付出一切都有風險，所以PM平常就要累積資料庫，沒事多研究點UX，多逛靠北社團看人家說哪個東西很難用，哪些狀況很雷，懂UX是基本，懂架構概念是基本，想往上爬再來考慮要不要懂技術吧