「User Story Mapping」讀書筆記 (2)

Ch. 1 The Big Picture & Ch. 2 Plan to Build Less

這兩章主要在講產品開發的時候，想做的功能一定會超過自己有限的時間和資源。如何把自己想開發的功能都先寫下來（幾個有步驟性的大活動和在活動底下，更細節的功能等），然後透過寫下想達成的目標、四個評定重要度的標籤、和哪些使用者相關，有邏輯地排出功能開發的優先順序。

宏觀的開發視野

敏捷開發精神

作者一開始提到「敏捷開發宣言」，並假設大家都知道內容是什麼，但我還是先列出來：

1. 個人與互動重於流程與工具
2. 可用的軟體重於詳盡的文件
3. 與客戶合作重於合約協商
4. 回應變化重於遵循計劃

基本上敏捷開發的精神在於希望能提早開發出有價值的產品，有任何需求變化，也樂於做變化更動。希望無論是客戶，或是團隊中每一個人，都可以經常面對面溝通互動、密切合作，建立一個資訊透明、即時有效率的溝通和合作方式。並在開發過程，不僅不斷優化產品，希望不斷往達成商業與顧客的目標推進，也同時思考如何優化整個團隊運作方式，不停測試、反省學習、調整修正，形成一個正向循環。

寫故事的目的

作者並沒有特別解釋「故事 (Story)」是什麼意思，假設大家都知道。故事就是要開發的功能，最簡單的解釋。那為什麼會有這個名字？我覺得應該是說光講一個單詞（功能），其實有點空泛，所以定義一個要做的功能時，最好是有主詞＋動詞＋受詞，（誰）想（做什麼）以完成（什麼目的），當然有時候就直接簡化成一個動詞（搜尋歌曲），因為可能不只單一個使用者想做這件事。

再回來，其實會把故事（功能）寫下來，主要的目的還是可以讓大家可以討論，看看這個故事是不是太大，是不是可能要花好幾個月才能完成。而 故事地圖（Story Maps）其實就是把想做的事情寫下來，讓大家比較容易感覺整個產品或是功能是不是很合理，大家可以討論、補足遺漏，然後再把這些大故事（功能）切得成幾個小一點的故事，方便在一定的時間（可能一週或兩週）內可以實作出來。最常見使用故事的方法，就是把所有故事都列出來、排序、討論，然後把它們一步一步實現，開發出軟體。

Story mapping is a pattern. It’s what sensible people do to make sense of a whole product or whole feature. It’s what they do to break down large stories into smaller ones.

A common way to use stories is to build a list of them, prioritize them, and begin talking about them and then turning them into software one at a time.

如何製作故事地圖？

會建議把這些故事寫在便利貼或小卡上，可以把自己腦袋中的想法，具體化。會建議你想到什麼，就趕快用簡單的字先寫下來。然後當之後要解釋你的想法的時候，你可以在畫更多的圖，好好說一個完整的故事。然後再把這個便利貼放上去，大家之後都還可以添加、移動這些便利貼，讓這些故事有一個完整的流程。而這些便利貼，要放在一個大家都會一直看見的工作場所。

Talk and doc: write cards or sticky notes to externalize your thinking as you tell stories.

當大家在構思點子的時候，可以問問自己幾個問題：

1. 為什麼你想要建這個功能？
2. 它對你或是對使用者有什麼好處？
3. 它解決了什麼問題？

同時，你也要把你的顧客或使用者寫下來。可能你有幾個不同類型的使用者會使用你的產品，可以討論他們使用你的產品有什麼好處、他們為什麼要使用你的產品、他們會拿來做什麼。在便利貼或小卡上，寫出使用者的類型，然後再簡單羅列他們想要做的事情，一張卡就是一個人。

接下來，我們就開始敘述某個使用者怎樣使用我們的產品，他可能會先做什麼事，然後再做什麼等等。當大家一起在重組卡片、規劃流程時，其實這個過程也在幫助大家建立共識（Shared understanding），然後也幫忙看看產品或自己的思考有沒有遺漏的地方。我們先確保廣度（大活動）沒有問題之後，再去拓展細節。（大活動像是：註冊、改變我的服務、觀看樂團敘述、編輯演出行事曆、宣傳演出活動…，宣傳演出算是大活動，可能還可以細切成：開始一個宣傳活動、客製化傳單、預覽傳單）

Reorganizing cards together allows you to communicate without saying a word.

Mapping your story helps you find holes in your thinking.

Focus on the breadth of the story before diving into the depth.

在拓展細節時，可以問問自己一些問題：

1. 在這個活動，有什麼特別要做的事情？
2. 有什麼其他替代可以做的事情？
3. 有什麼可以讓它變得很酷？
4. 如果出錯，會發生什麼事情？

例如剛剛講的客製化傳單，就還可以細分為上傳圖片、上傳語音檔、嵌入影片、添加文字、改變排版等。

少建一點的計畫

想要建造的東西，「總是」會超過我們的人力、時間和金錢。所以我們怎麼決定哪些功能要先做，哪些功能晚點做，或是哪些功能要先捨棄，這樣的問題就會變得重要，本章節就是討論如何排定功能的優先順序。

剛剛有談到我們可以使用故事地圖，把會有的活動、想要的功能都寫上去便利貼，然後再依照流程做排序，同時把使用者，貼在對應的活動上方。把整個過程視覺化的好處，就是可以讓不同部門的人，可以看到哪些功能或是哪些合作，會是互相依賴有影響的。

先訂出目標成果，再排出功能優先級

如何排序功能？其實要思考的，並不是功能本身、系統內的問題，而是要思考在系統外的問題。你想透過這個系統，達成什麼目標？想幫助使用者什麼事？想達成什麼商業成果？或是想拿來測試什麼？

你要先專注在目標成果（Outcomes）上，使用者需要用你的系統做什麼、看到什麼？然後你再去切分每周或每兩週想要或是有機會發佈哪些功能，一步一步達到你想要的成果。當然公司內可能也會有很多想要達成的目標，所以我們也應該去排序我們想要達成的成果，去訂出我們的 Road Map，鎖定幾個比較重要的目標，再用這些成果目標，去檢視哪些功能、故事可以幫助我們達成這些成果。如果有功能偏離我們想要達成的成果時，可以先移出使用者故事地圖，把它移到下方。

可以用來評估功能重要性的四個面向：

1. Differentiator：和其他競爭者不同的地方
2. Spoiler：競爭者的獨創功能
3. Cost reducer：可以減少組織花費的功能
4. Table stakes：想在市場上競爭的必備功能

藉由思考這四個面向，我們可以去決定我們的 MVP。

Map for a product release across multiple teams to visualize dependencies.

Focus on what you hope will happen outside the system to make decisions about what’s inside the system.

Focus on outcomes — what users need to do and see when the system comes out — and slice out releases that will get you those outcomes.

Focusing on specific target outcomes is the secret to prioritizing development work.

MVP 的不同定義

每個人談論 MVP 時，好像都有自己的定義。作者提出三個常見的定義 ，第一個最爛，後面兩個還不錯：

1. 最小可行性產品不是我們有機會發佈的爛產品（Minimum viable product is not the crappiest product you could possibly release.）功能不是有即時做出來就好，而是這個功能應該要有人用，很快做出一個爛東西，也沒用。
2. 最小可行性解決方案，是能成功達成我們理想成果的最小解決方案（The minimum viable solution is the smallest solution release that successfully achieves its desired outcomes.）有時候它不一定是要產品，只是需要一個簡單的方案。
3. 最小可行性產品也是一種你可以拿來驗證假設是否為真的最小東西。A minimal viable product is also the smallest thing you could create or do to prove or disprove an assumption. 它不一定是一個產品，可能是一個 prototype，只要能做實驗、拿來測試我們的假說，獲得驗證的一個小東西，就可以稱作 MVP。