產品經理應該站在 RD 的角度描述產品需求
目錄
Feature 和 User Story 有什麼差別？
TL;DR
- Feature：產品功能，用技術性的「行話」去描述
- User Story：用戶故事 / 使用者故事，說明使用者為什麼想要這個功能
有個細節一定要留意，User Story 並不是需求，它只是從使用者的角度、語言來描述這個功能，藉此來幫助開發團隊快速理解。
和其他同事曾經閒聊過，看產品經理描述的 User Story 和 Feature, 就可以大概知道 PM 到底知不知道客戶的需求。因為只有真正 「理解」 使用者需求 / 痛點，產品經理不僅能夠完整描述簡短、切要的 User Story，在和團隊協作時更可以具體描述有哪些架構、功能及流程。
下面就用幾個實例來探討吧～
－Facebook 平台實例
假設今天是 Facebook 的產品經理，在這個平台上的 Feature(功能) 有這三個：
- 使用者註冊
- 使用者登入
- 顯示豐富資訊的動態牆
而依據這些 Feature 所描述的 User Story(使用者故事) 可能是：
-
使用者註冊：
- 作為使用者，我需要能夠註冊為新用戶，這樣我才能加入這個平台
- 作為使用者，我能夠使用我的 Google / Line 帳戶註冊
-
使用者登入：
- 作為使用者，我需要能夠使用我的帳戶名稱、密碼登入，才有權限進入這個平台
- 作為使用者，我能夠使用我的 Google / Line 帳戶登入
-
顯示豐富資訊的動態牆：
- 作為使用者，我要進入 Facebook 平台的主頁，這樣才能瀏覽好友圈最新訊息或新用戶導覽教學
那 Epic 又是什麼？
來看下面這個例子：
作為使用者，我希望能夠使用 Facebook 登入，我可以與好友分享最新訊息，並在所有設備上擁有我的個人資料。
🥲 這 … 這應該不只一個 Feature 了（吧
之前還是工程師的我，還真的有看過類似上述的 User Story, 是不是很難理解呢？
不過如果秉持「同理心」的角度，我是使用者還真的需要上述這些功能沒錯。問題在於 PM 應該把需求轉換為工程師看得懂、能理解，最好是一看就知道要做哪些功能的具體需求。
上述的實例，其實不是一個 User Story, 而是 Epic !
a film, poem, or book that is long and contains a lot of action, usually dealing with a historical subject（通常指描寫歷史題材的）長篇敍事式電影（或書籍、史詩）
簡單來看，先把它認定為一大段故事，這樣就比較好理解了 😂
Epic 很少出現在 User Story 相關的寫作指南，它和 User Story 很類似，但最大的差別在於： Epic 是一個非 (宇) 常 (宙) 大的 feature，需要分解成獨立的 Task, 然後再透過 User Story 去描述單一功能。
上述的 Epic, 它有幾個必要的功能：
- 註冊
- 登入
- 透過暱稱 / Email 去搜尋好友
- 加入好友
- 同步會員資料
沒有上述這些 Feature, 就無法實踐其他功能，像是分享訊息、Facebook 個人資料。
所以這個 Epic：
作為使用者，我希望能夠使用 Facebook 登入，我可以與好友分享最新訊息，並在所有設備上擁有我的個人資料。
它有以下這幾個 User Story：
- 作為使用者，我需要能夠使用我的帳戶名稱、密碼登入，才有權限進入這個平台
- 作為使用者，登入 Facebook 帳號時，我可以與好友分享最新訊息
- 作為使用者，登入 Facebook 帳號時，我能夠在所有設備裝置上擁有個人資料
什麼時候用 User Story, Epic ?
以一個正在迭代的產品來說，產品經理在規劃中、長期的 Roadmap, 就非常適合透過 Epic 來做溝通。
我的具體做法是這樣，前期先透過一頁式的文件和其他 PM, Stakeholder 分享我的觀點，等定案後再把 Epic 拆解成 User Story 和工程團隊還有其他部門雙向討論。
但我秉持的原則是，每個 Task 若是獨立的，那就要拆分成獨立的 User Story；如果 Task 彼此有相依性，那這就是一個 Epic.
所以其實你可以這樣跟 RD 溝通
從上面可以理解到，一個良好的 User Story, 應該具備 2 個條件：
- 每個任務步驟由單一角色執行
- 每個任務步驟都可以產生具體的可驗證結果
透過 User Story 這個工具僅能描述需求，重要的是需求問題的本身以及需求背後的多層次考量。 在這個階段不需要給予具體的解決方案，畢竟怎麼實踐 RD 絕對比你還要懂(How)，而 PM 只需要描述問題、需求的本身，讓人家知道 What 跟 Why 就好，這樣才能達到有效的溝通。
其次就是「什麼樣的功能、什麼樣的效果」。
需求經過了 Problem Space 要進入到 Solution Space 階段，一定要很清楚地描述這個功能可以幫助使用者解決什麼問題。 例如上面提到的實例，在 Facebook 可以透過 Google / Line 帳戶去做登入，這個功能背後的考察就是提升用戶體驗，然後一定會結合一些質化、量化的研究來佐證為什麼可以提升用戶體驗。
確保技術的可行性符合商業層面的需求，讓 RD 知道 PM 是重視用戶體驗提出這樣的需求，而不是技術實現的方式。
對於工程師來說，把大方向具體、細節化，這樣在進行功能的開發比較有頭緒，也更清楚自己動手做的東西，是誰在使用它、什麼時候會用到、帶來哪些價值，不僅僅是優化整個開發流程，久而久之工程師也會具備 Product-Minded(產品意識) 的思維，共同創造團隊良好的氛圍。