DMA01
【產品規劃系列(一)】軟體 PM 撰寫規格書的三大工具之一,User Story

【產品規劃系列(一)】軟體 PM 撰寫規格書的三大工具之一,User Story

朱騏

「User Story」的目的是以簡單的敘述,用不同角色來傳達一個產品的價值,讓其他人快速了解產品/功能存在的目的。簡單而直觀的性質,非常適合作為產品功能分析的第一步。

前言

在軟體開發中,PM 會先撰寫產品規格書 (Spec)後再交由工程團隊進行開發,一份好的 Spec 可以讓開發團隊事半功倍,也能讓其他團隊成員快速了解產品/功能開發的背景。

然而現實狀況是,PM 在還沒有寫完整 Spec 時就直接進入開發階段,導致工程師必須邊開發邊確認需求、甚至要靠自己通靈腦補未被定義清楚的邏輯,一次又一次的來回討論消耗了產品團隊相當多的開發動力,甚至導致團隊之間的不信任。

對於軟體 PM 工作者,讓我們回到根本來了解一個問題:究竟 Spec 應該要包含哪些文件,這些文件應該要怎麼寫呢?

網路上有許多人討論過這個問題,但每家公司的狀況都有所不同。我認為:

產品文件可以多寫,但不能偷懶不寫,最基本至少要包含 3 樣東西:User Story、 Functional Map、UI Flow。

這篇先來說 User Story。

 

一、User Story 是什麼,該怎麼寫?

首先提到的是 User Story,其定義是:

簡單功能敘述,以不同角色的觀點去表達一個有價值的產品。

撰寫 User Story 並不困難,其公式如下:

  • 【角色】作為一個… As a
  • 【需求】我想要… I want
  • 【價值】才能… so that

讓我們以網站上最常見的「登入」功能為例,其 User Story 是:

作為一個使用者,我想要登入會員,才能記錄個人資料。

這一句短短的話,告訴了產品團隊「為什麼我們要給使用者開發這個功能」。在每個使用者故事後面,我們可以再加上驗收測試 (Acceptance Criteria),即:

  • 登入成功:輸入正確的帳密,成功登入會員畫面
  • 登入失敗:輸入錯誤的帳密,跳回登入畫面並顯示登入失敗

 

二、User Story 的問題

當 User Story 寫得愈多,我們可以逐漸發現 3 個問題逐漸產生:

  • 規模不一
  • 功能零散
  • 目標模糊

比較下方兩個例子:

  1. 作為一個使用者,我想要瀏覽產品,才能找到我想購買的商品。
  2. 作為一個使用者,我想要依類別尋找商品,才能更快找到需要的商品。

這兩個例子都符合 User Story 的撰寫公式,但需求的程度有所不同,第 1 個例子的規模比第 2 個大了許多,怎麼辦呢?

Jeff Patton* 提出的「User Story Mapping (使用者故事對照)」可以幫助我們解決這個問題。

註:Jeff Patton是一位獨立顧問,敏捷開發與產品設計的導師和教練,擁有十五年以上的軟體設計與建造經驗。

 

三、學習 User Story Mapping

User Story Mapping (使用者故事對照) 的目的是能夠將 User Story 結構化,進而解決上述 User Story 的問題。

方法是這樣的,我們將 User Story 再區分成三個層級:

  • 使用者行為 (User Activity):目標 → 最高層,最模糊
  • 使用者任務 (User Task):步驟 → 中間層
  • 使用者故事 (User Story):功能 → 最低層,最詳細

參考《UI 設計入門:畫出有程式邏輯的設計稿》,讓我們以「線上購物」這個情境來舉例:

  • 「線上購物」是一個模糊的概念,放在第一層
  • 跟「線上購物」相關的子功能有「瀏覽產品」、「加入購物車」、「結帳」
  • 這三個子功能又可以拆分細項功能

按照階層關係可列成下表:

圖片來源:《UI 設計入門:畫出有程式邏輯的設計稿

將其列成圖形的樣子如下:

圖片來源:《UI 設計入門:畫出有程式邏輯的設計稿

最後整理成 Jeff Patton 在「User Story Mapping (使用者故事對照)」中的樣式,多出了不同時間階段可以完成的功能項目:

圖片來源:《UI 設計入門:畫出有程式邏輯的設計稿

 

結語

「User Story」的目的是以簡單的敘述,用不同角色來傳達一個產品的價值,讓其他人快速了解產品/功能存在的目的。

簡單而直觀的性質,非常適合作為產品功能分析的第一步。

下一篇文章來談談寫 Spec 的第二項工具 — Functional Map 。

【產品規劃系列(二)】軟體 PM 撰寫規格書的三大工具之二,Functional Map

 

 

原文出處:【產品規劃系列(一)】軟體 PM 撰寫規格書的三大工具之一,User Story

第二篇:【產品規劃系列(二)】軟體 PM 撰寫規格書的三大工具之二,Functional Map

第三篇:【產品規劃系列(三)】軟體 PM 撰寫規格書的三大工具之三,UI Flow

朱騏
朱騏

一個組織能力超強的軟體產品經理,喜歡研究軟體產品、生產力工具、時間管理方法

可提供軟體產品管理、時間管理、生產力工具的相關諮詢

歡迎講座邀約或跟我喝杯咖啡聊聊天,我的信箱是 [email protected]

淺談移動應用商業化變現手段:如何把訂閱模式做好提升營收 ARPU?
訂閱模式成功變現的關鍵在於使用者願意付錢購買,要促成此轉化事件包含非常多複雜的因素。
【OKR 實戰手冊】第 0 章
如何把目標管理,從0開始規劃,最終落實到每一天?除了OKR的簡易說明,我會花更多時間在其他的理論與實務,才可以讓目標管理最後落實在一天的行動中。
如何做好專案需求調查?
在系統工程及軟件工程中,需求分析指的是在創建一個新的或改變一個現存的系統或產品時,確定新系統的目的、範圍、定義和功能時所要做的所有工作。本篇即是有技巧教你做出最好的需求分析。