使用者故事的定義和目的

使用者故事是一種以使用者為中心的工具，幫助團隊開發有價值的軟體，重點在於通過對話和共識建立對開發目標的共同理解。它從使用者的角度簡潔描述他們希望達成的目標，強調需求和價值而非技術細節，促進團隊共識。使用者故事應像「度假照片」一樣，喚起細節和背景，而非僅是文字描述。開發的目標是為使用者創造價值，解決問題，因此團隊應關注軟體的成果和影響，而非僅僅開發速度。

使用者故事的格式

Connextra 公司提出了一個簡單的使用者故事模板：

身為一個 [使用者類型]，我想要 [做某件事]，以便 [獲得某種好處]。

這個模板可以幫助團隊思考使用者故事中的「誰」、「做什麼」和「為什麼」。 然而，這個模板只是一個起點，團隊需要透過更深入的對話和圖像來完善使用者故事的細節。

除了 Connextra 的模板之外，作者還提供了一個他個人偏好的模板：

標題：

誰：

做什麼：

為什麼：

這個模板提供更多空間讓團隊在討論使用者故事時，可以添加額外的資訊和註記。

使用者故事的討論

使用者故事的討論應該是一個豐富且互動的過程，團隊成員可以使用白板、便利貼和圖像來輔助溝通。

以下是一些使用者故事討論的重點：

  • 團隊應該使用「說和記錄」的策略，將討論的重點記錄下來，方便日後參考。
  • 團隊可以使用圖像和便利貼來表達想法，並透過重新排列來調整優先順序和結構。
  • 團隊應該關注使用者體驗、功能品質和程式碼品質，並在開發過程中不斷反思和改進。

使用者故事的討論不僅僅是關於軟體功能，還應該涵蓋以下內容：

  • 使用者類型和他們的目標。
  • 使用者使用軟體的步驟和流程。
  • 軟體如何幫助使用者解決問題並創造價值。
  • 軟體的細節、替代方案、變化和例外情況。
  • 軟體的開發成本和可行性。

使用者故事地圖的定義和用途

使用者故事地圖是一種視覺化工具，用於組織和排列使用者故事，展示使用者完成目標的完整流程。這一方法強調以使用者為中心，幫助團隊達成共識。使用者故事地圖能促進團隊共識、聚焦使用者體驗、簡化產品規劃並推動持續學習。其核心概念是將使用者達成目標的過程分解為一系列步驟，並按時間順序排列，縱軸則呈現每個步驟的細節和例外情況。

使用者故事地圖的建構步驟

建構使用者故事地圖的過程，就像是在講述一個使用者使用產品的故事：

  1. 逐步寫出故事： 從使用者開始使用產品的第一步開始，逐步寫出他們完成目標所需的每個步驟，並將每個步驟寫在一張便利貼上。
  2. 探索替代方案： 思考使用者在每個步驟中可能遇到的不同情況、替代方案和例外，並將這些資訊也寫在便利貼上，放置在對應步驟的下方。
  3. 整理敘事流程： 將所有便利貼按照時間順序排列，形成一個完整的使用者旅程。
  4. 提煉出主幹： 將相似的步驟歸類成更高級別的活動，並將這些活動寫在不同顏色的便利貼上，放置在地圖的頂部，形成地圖的主幹。
  5. 切分出特定成果： 根據不同的目標，切分出完成特定成果所需的步驟和細節。

使用者故事地圖的優點

  • 促進團隊共識： 使用者故事地圖可以幫助團隊成員以視覺化的方式，共同理解使用者旅程和產品功能。
  • 聚焦使用者體驗： 使用者故事地圖以使用者為中心，強調使用者完成目標的過程，有助於團隊打造更優質的使用者體驗。
  • 簡化產品規劃： 使用者故事地圖可以幫助團隊識別最小可行產品 (MVP) 或最小可行方案 (MVS)，並規劃產品開發的優先順序。
  • 促進持續學習： 使用者故事地圖可以幫助團隊在開發過程中，不斷反思、驗證和調整產品方向，以確保產品符合使用者需求。

作者對最小可行方案 (MVS) 的定義

作者多次提到最小可行產品 (MVP) 和最小可行方案 (MVS)，並指出業界對這兩者的定義常常混淆。他認為組織內對這些詞的理解可能不同，並指出最小可行方案 (MVS) 是需不斷探索的概念，而最小可行產品實驗 (MVPe) 是實現這一目標的關鍵手段。團隊應透過構建和測試 MVPe，獲取市場回饋並調整產品方向，最終打造符合使用者需求的產品。

作者對 MVP 的定義經歷了三個階段：

  1. 不好的定義： 作者認為把 MVP 理解為「你能發布的最爛產品」是錯誤的。這種產品只能在最簡單的情況下使用，而且使用者必須忍受很多不便才能使用它。他經常看到組織用「有人可以使用這個產品」來合理化他們糟糕的產品決策，但事實上，很明顯，使用者並不會選擇使用這樣的產品。
  2. 較好的定義： 作者認為，最小可行方案 (MVS) 是指能夠成功達成預期目標的最小方案版本。 他更喜歡使用「方案」而不是「產品」，因為他與組織合作的項目通常不是全新的產品，而是新功能、新能力，或是對現有功能的改進。 作者強調，「最小」是一個主觀的詞彙，所以要明確說明這個詞彙是對誰而言的，因為它不是針對開發團隊，而是針對客戶和使用者。
  3. 最新的定義： 作者認同 Eric Ries 在《精益創業》一書中提出的觀點，即 MVP 其實是一個實驗。Eric 透過自身經驗意識到，我們對 MVP 的預測只是猜測，直到真正發布產品並觀察市場反應，才能知道它是否可行。因此，作者認為，最小可行產品也是指為了驗證或推翻某個假設，而可以創造或執行的最小事物。 他建議將 Ries 的 MVP 稱為最小可行產品實驗 (MVPe)，即「為了學習某些東西而可以構建的最小事物」。 透過不斷地構建和測試 MVPe，最終才能理解在目標客戶和使用者眼中，什麼才是真正可行的方案。

作者認為，不論是哪一種定義，我們在切分出一個版本並稱之為 MVS 時，其實並不真正知道它是否可行。 因為在產品真正發布之前，我們無法觀察到預期的成果。因此，我們必須對客戶是否會購買產品、使用者是否會選擇使用它、產品是否易於使用以及在限定時間內是否可以構建完成等方面做出假設。這種猜測的風險在於，如果我們猜測的規模太小，就無法達到最小標準，也就意味著失敗；如果猜測的規模太大，就會浪費過多成本，甚至可能導致項目無法完成。

「最小」是什麼意思：

  • 聚焦於目標使用者： 在切分 MVS 時，要明確目標使用者是誰，以及他們需要完成什麼任務。
  • 達成預期目標： MVS 應該包含達成預期目標所需的最少功能和特性。
  • 驗證關鍵假設： MVS 應該能夠幫助團隊驗證或推翻關於產品和市場的關鍵假設。

驗證式學習：透過 MVP 構建與使用者回饋驗證產品假設

驗證式學習是一種以使用者為中心的產品開發方法，通過構建最小可行產品 (MVP) 並收集使用者回饋來驗證假設，進而不斷迭代和優化產品，以滿足使用者需求。該過程與最小可行方案 (MVS) 和最小可行產品實驗 (MVPe) 密切相關。開發軟體的目標不僅是構建產品，而是為使用者創造價值和解決問題，驗證式學習旨在確保產品符合使用者需求並帶來預期成果。

驗證式學習的核心步驟

驗證式學習的過程可以概括為以下幾個步驟：

  1. 提出假設： 開發團隊需要對目標使用者、使用者需求、解決方案以及預期成果提出明確的假設。
  2. 構建 MVPe： 根據提出的假設，構建最小可行產品實驗 (MVPe)，用於驗證這些假設。 MVPe 可以是產品原型、著陸頁，甚至是手繪草圖，其目的在於以最低的成本和最快的速度收集使用者回饋。
  3. 收集使用者回饋： 將 MVPe 交付給目標使用者，並透過觀察、訪談、問卷調查等方式收集使用者回饋。
  4. 分析回饋並調整方向： 分析收集到的使用者回饋，判斷最初的假設是否成立。 如果假設被證實，則可以繼續開發產品；如果假設被推翻，則需要調整產品方向，甚至放棄原有的產品理念。
  5. 迭代循環： 驗證式學習是一個迭代的過程，開發團隊需要不斷重複以上步驟，直到找到真正符合使用者需求的產品。

來源中提到的相關案例

書中提到的 Gary、Globo.com 團隊和 Eric 的案例，都體現了驗證式學習的思想。 他們都透過構建 MVP 或 MVPe，從使用者那裡收集回饋，並根據回饋調整產品方向，最終打造出成功的產品。

  • Gary 使用使用者故事地圖釐清產品願景，專注於特定使用者及其活動，逐步拆解產品並與使用者互動以調整方向，最終成功打造電子郵件營銷平台。

  • Globo.com 團隊面臨嚴苛的上線期限，利用使用者故事地圖規劃開發優先順序，制定最小可行方案 (MVS)，逐步交付並優化產品，成功按時上線。

  • Eric 採用精益創業方法，將開發過程拆解為最小可行產品實驗 (MVPe)，與早期使用者合作檢驗方向，重視回饋及數據分析，最終成功推出產品。

驗證式學習的優點

  • 降低開發風險： 透過早期驗證產品假設，可以避免將時間和資源浪費在構建不符合使用者需求的產品上。
  • 提高產品成功率： 透過不斷收集使用者回饋並調整產品方向，可以提高產品的市場適應性和成功率。
  • 促進團隊學習： 驗證式學習可以幫助團隊成員更深入地理解使用者需求，並培養以使用者為中心的思維方式。

如何規劃才能少做、學得更快、準時完成？

規劃要少做：聚焦 MVP，逐步迭代

開發團隊應聚焦於構建最小可行產品 (MVP) 或最小可行方案 (MVS)，並透過迭代逐步添加功能。作者認為業界對 MVP 和 MVS 的定義常混淆，更偏好使用「方案」一詞，因為其合作項目通常涉及新功能或現有功能的改進。此外，「最小」一詞是主觀的，應根據目標使用者及其需求來定義。

如何找出 MVP 或 MVS？

  1. 明確目標使用者和預期成果： 首先，開發團隊需要明確目標使用者是誰，以及他們希望透過產品達成什麼目標。
  2. 找出使用者旅程： 使用使用者故事地圖或其他工具，描繪出使用者完成目標所需的步驟和流程。
  3. 切分出最小方案： 從使用者旅程中，找出達成預期成果所需的最少步驟和功能，這就是 MVP 或 MVS。

透過迭代的方式逐步添加功能

  • 建立 MVP 或 MVS 後，開發團隊可以透過迭代的方式，逐步添加新的功能和特性。
  • 每次迭代都應該聚焦於解決特定的使用者問題或達成特定的目標。
  • 每次迭代後，開發團隊都應該收集使用者回饋，並根據回饋調整產品方向。

規劃要學得更快：運用 MVP 和驗證式學習

來源中提到了驗證式學習的概念，這是一種透過 MVP 或 MVPe (最小可行產品實驗)，從使用者那裡收集回饋，並根據回饋調整產品方向的過程。

  • 作者認為，開發團隊在構建產品時，其實是在對使用者需求、解決方案和預期成果做出假設。
  • 驗證式學習的目的就在於透過 MVPe 來快速驗證這些假設，並儘早發現和解決問題。

如何運用 MVP 和驗證式學習？

  1. 提出明確的假設： 開發團隊需要對產品的各個方面提出明確的假設，例如目標使用者是誰、他們有哪些需求、產品如何解決這些需求等等。
  2. 構建 MVPe 來驗證假設： 根據提出的假設，構建 MVPe 來驗證這些假設。 MVPe 可以是產品原型、著陸頁，甚至是手繪草圖，其目的在於以最低的成本和最快的速度收集使用者回饋。
  3. 收集和分析使用者回饋： 將 MVPe 交付給目標使用者，並透過觀察、訪談、問卷調查等方式收集使用者回饋。 分析回饋後，判斷最初的假設是否成立，並根據回饋調整產品方向。
  4. 不斷迭代循環： 驗證式學習是一個迭代的過程，開發團隊需要不斷重複以上步驟，直到找到真正符合使用者需求的產品。

規劃要準時完成：拆解任務，迭代構建

將大型產品或功能拆解成較小的可交付部分，並使用迭代的方式逐步構建。作者以藝術家創作繪畫為例，說明了逐步迭代構建的優點。他認為，如果試圖一次性完成所有工作，很容易迷失在細節中，並且難以在期限內完成任務。

如何拆解任務和迭代構建？

  1. 找出產品或功能的關鍵步驟： 使用使用者故事地圖或其他工具，將產品或功能拆解成一系列的步驟。
  2. 根據風險和優先級切分迭代： 將這些步驟進一步拆解成更小的可交付部分，並根據風險和優先級來安排迭代。 例如，可以先構建一個功能骨架，再逐步添加細節和完善功能。
  3. 每次迭代都進行測試和回饋： 每次迭代完成後，都要進行測試和收集回饋，並根據回饋調整後續迭代的計劃。
  4. 持續追蹤進度和調整計劃： 在開發過程中，持續追蹤進度和成本，並根據實際情況調整計劃。