每周一篇文章的讀書會心得報告摘要與筆記，主要段落分成：
1. 為什麼選這篇文章分享?
2. 作者為什麼要寫這篇文章?
3. 內容重點
4. 心得
原文網址：產品管理流程中，使用者故事（User Story）常見的三種使用情境
為什麼分享這篇文章？
- 產品經理、UI/UX設計師常用的方法論：使用者故事 User Story
- 對使用者故事有個基本概念
作者想表達甚麼？
- 何謂使用者故事 User Story？
- User Story常見的三種使用情境
- User Story 常見問題
重點內容
什麼是使用者故事（User Story）？- 是一種描述問題與需求的方式
- 「先討論問題/需求、再討論解法」的產品工作方式
- User Story 的建立方式
- 建立的源頭從 User 來
- 使用者研究與使用者訪談中得到的資訊來討論與整理。
- 通常是在產品團隊已經有目標、想改善的指標/使用情境後
從使用者身上抓到的幾個重點要素，作為過渡到「實際解決方案」前的溝通工具。
- User Story 的形式通常為一句話：
- As a ______, I want to ______, so that ______.
身為 ______，我需要一個方法來 ______，因為 ______。
- 使用者（who）
- 可以加上形容詞、情境詞來描述
- 除了實際使用產品的人之外
- 有時候我們也會為我們自己寫 User Story —
- 身為產品經理（或是公司內部的人）
- 希望可以看到什麼數據、或是在後台手動做什麼事
- 總之就是為那個使用者受詞解決問題、滿足需求。
- 需求（what）
- 要什麼、做什麼
- 盡量用「動詞」的形式表達
- 背後的原因（why）
- 為什麼可能是想要看到的成果、想要得到的價值、對使者來說很重要的洞見
- 盡量用一句話表達
User Story 的三種使用情境
- 建立 User Story 困難的地方在於
- 到底要寫得多細？怎樣才算是夠清楚？
- 在不同情境下會因為目的不同而有不同的作法。
使用情境１— 做中長期的優先級排序
- [ 溝通對象 ] 利益關係人、產品團隊
- [ 出現場合 ] 產品路線圖（Product Roadmap）、產品待辦清單（Product Backlog）
- [ 細節程度 ] 方向大而模糊
- 如果要處理的目標問題較大、還在非常初步的探索階段、還需要幾輪的探索或討論
- User Story 的用途比較像是跟利益關係人與產品團隊建立共識
- 確認優先級並決定要先處理哪一個問題/需求。
- 當確認好方向與順序後，就可以持續針對那個問題/需求去做研究
- 並拆解成更小的 User Story 方便產品團隊開始發想解決方案。
使用情境２ — 過渡到「實際解決方案」前的溝通工具
- 同一個問題或需求可能會有好幾種不同的解決方案
- [ 溝通對象 ] 設計師、產品團隊
- [ 出現場合 ] 產品需求文件（PRD）
- [ 細節程度 ] 中等
- 確保這時候的 User Story
- 足夠清晰到心中可以浮現出幾種不同的解決方案
- 不會太細節到我們只能看到單一的功能樣貌。
- 發想的一個開始，讓大家可以開始構思畫面、背後的邏輯，用一句簡單的話，在心中埋下一棵種子。
每個人心裡的畫面可能會有所不同
- 主要發想解決方案的人通常會是設計師
- 產品經理、工程師或其他利益關係人也可能會適時參與討論
- 在討論階段，當有異議、或是設計太發散時，可適時檢視產品設計是否有符合最一開始定義的 User Story 的情境、是否有機會解決使用者的問題。
使用情境３— Sprint Planning、產品或功能的最小品質控管、上線管理的單位
- [ 溝通對象 ] Scrum Team、QA、利害關係人
- [ 出現場合 ] 產品需求文件（PRD）、專案管理工具中的 Scrum/Kanban Board
- [ 細節程度 ] 範圍小且細節
- 當解決方案已經確認，功能細節夠清晰
- 在 Sprint Planning 時：可以選擇將功能切分成更小的 User Story。
- 方便規劃跟估時、估點數，決定哪幾個 User Story 可以在下個 Sprint 中完成
- 方便工程師開發、QA 驗收。
- 另一種作法則：不去延伸與切細 User Story 本身
針對每個 User Story 列出 Acceptance Criteria（驗收標準）或是 Deliverables（可交付的成果） 作為最小顆粒單位
對於開發資源較少、時間較趕、流程較彈性的團隊
- User Story 本身就足夠作為驗收單位
- 亦即可以幫助使用者達到某個目的與需求就算是完成
如果產品團隊規模較完整
- 想要讓工作流程更精細與嚴謹，提供工程師與 QA 明確的規格（Spec）會更好。
- 上線管理的部分（與Sprint Planning 很像）
- 主要是讓整個團隊知道接下來要上的版本包含哪些功能與改動
- 同時用「人話」告訴商業團隊、利益關係人們下個版本我們可以讓使用者或客戶達成哪些事情。
不同團隊會有不同的作法
- 只在 (1)(2) 中使用
等解決方案確認就直接寫詳細的規格書。
- 只在 (2) 中使用
- 最早期排序時就直接直白地描述問題或需求
- 最後期等解決方案確認就直接寫詳細的規格書
- 介於 (2)(3) 之間
- 第一個版本的 User Story 是為了讓產品團隊能夠好好思考解法
- 因為產業成熟、解法直白，常常可以直接延伸與轉譯成開發的功能細節與驗收標準。
- 從頭到尾都沒有寫過 User Story
直接從問題、使用情境下手來討論解決方案，然後寫功能需求給工程師。
User Story 常見問題
- User Story 是 PRD、Spec 嗎？No
- 他可以是 PRD 中的一部分，是討論產品解法時的一個過渡工具
- 在討論完解決方案與功能後，還是會需要寫下詳細的 Spec 給工程師來實作。
- User Story 要寫多細？
取決於你在跟誰對話：根據不同的時間點、目的、溝通對象，會有不同的細節程度
- 大故事包含許多小故事，小故事又包含更多更小的故事
- 在某些情境下，你可能必須將對話「收攏」到較高的層級。
- 只要團隊覺得好溝通、能夠建立共識就夠
- 在《使用者故事對照 User Story Mapping》章節「岩石分解」，針對「規模」提出分類方式：
- 商業觀點：幫助企業達到某種商業成果的故事
- 使用者觀點：滿足某個需求的故事。
- 開發團隊觀點：花幾天時間即可建造及測試的故事
- User Story 由誰來產出？不一定
- 看團隊的分工方式，有可能是產品經理、設計師、甚至是工程師
- 看誰是發起專案的人就由誰來寫、主導討論
如果是產品經理從其他單位收到的需求、並發起這個專案，就由產品經理寫；
如果是設計師在做使用者研究時發現的洞見，就由設計師來寫；
在乎這件事情的人來產出並引導團隊一起討論；
有些團隊會有一個 User Story Mapping 的會議或工作坊：
- 拿出便利貼，讓整個產品團隊的人一起來發想與討論
- 甚至有人會在排序優先級的階段邀請客戶、使用者一起參與。
- 每次有新的需求、或是做新功能時都一定要寫 User Story 嗎？不一定
- User Story 就只是一個工具、一種敘述事情的方法
- 像是系統層面的問題、只是要解一個 Bug、解法已經非常明確的情境下可能也不太適用。
- 近年來也有人在詬病 User Story
拆解方式中需要太多假設，不夠符合產品團隊的需求。
個人心得
- Use story跟User Journey Map差別
「從使用者的行為找出關鍵點」的概念：都使用「故事線」當主幹
- Use story
- 目的在從使用者的操作行為裡找到各種功能、並排出優先順序
- 可以探討使用者想要什麼功能、重要的先開發、達成團隊共識
- 沒辦法確定這樣做下去後使用者是否滿意
- User Journey Map
- 關心使用者在各階段互動的情感並想辦法改良、提升滿意度
- 只會告訴你使用者因為什麼原因所以覺得不高興
- 無法提供讓使用者高興的解法
- Use story用途多多
- 產品路線圖（Product Roadmap）
- 產品待辦清單（Product Backlog）
- 產品需求文件（PRD）
- 專案管理工具中的 Scrum/Kanban Board
- Use story的廣度與深度可根據想解決的問題調整
- 大專案由許多小專案組成，小專案可以根據細節再分成更多節點
- 主線任務分出支線，支線還會有小旁枝
