上一篇主要把使用者故事卡片介紹的差不多了，我想在這一篇談及一些實際的應用與執行，以及在概念介紹之外的補充。
前篇筆記講了許多關於使用者故事怎麼用，但實際上更值得注意的事情是，「使用者故事」時常會面臨到的誤解與問題。
這本書有一個有趣的特色是一開始就寫了結論，我認為是非常重要的當頭棒喝：
- 寫使用者故事的目標不是為了寫出更好的使用者故事
- 產品開發的目標不是為了製造產品
我們之所以會寫使用者故事，主要的目標是在於傳遞需求，讓產品變得更好。
所以不應該把寫出完美的使用者故事作為目標，重要的事情是我們怎麼去找到那些需求，與怎樣去判讀重要的需求是什麼。
很多人往往會誤解這類的產品文件是為了要分享共識，記錄下大家覺得「使用者故事」應該如何。但實際上，分享文件不是為了分享共識，通常你分享文件的對象也都還沒有與你達成共識，而已經達成共識的東西也不一定需要特別被記錄下來。
實際開發產品的是團隊成員，實際討論需求的也是團隊成員，因而真正有效的使用者文件不是寫得非常詳細的逐字稿，而是可以很精鍊地抓出討論的重點，並且讓其他團隊成員看到該使用者故事卡片時，便能想到當時對於產品的討論。這裡作者又舉了一個我很喜歡的例子：
「好的文件是度假照片，實際上度假的時光所發生的一切不會全部都顯示在一張照片上，但是看著那張照片時我們往往都會回想起整段度假時光」
另外，產品開發的目標也不是在於把產品製造出來。
對於懷有產品開發熱忱的人而言，這樣的老生常談應該不陌生：「產品是要來解決問題的」，所以做與產品相關工作的人不是為了收集與傳遞用戶資料或製造產品本身，而是改變世界，你為產品所提出的解決方案與每一個絕妙的想法都應該以某種程度改變世界，影響使用這個產品的用戶。
另外，在第一章就提及了「使用者故事」很常遇到的另一個問題。由於使用者故事是陳述一個個需求，因而很多人往往會迷失在「個別功能」中，而失去了整體圖像。最後產品會長什麼樣子反而讓人無法想像，甚至對於PM而言專案的進度難以掌握。
因此在創造一個使用者故事時，這本書提供了一些檢查清單，撰寫的同時需要同時討論以下的項目，讓PM可以更快地掌握每一個使用者故事（任務）應會付出的時間與開發成本：
1. 實際談論誰
2. 實際談論做什麼
3. 實際談論為什麼
4. 談論軟體外發生什麼事
5. 談論出什麼錯
6. 談論問題與假設
7. 談論更好的解決辦法
8. 談論如何做
9. 談論費時多久
但切記，不要讓使用者故事卡片成為樣板，重要的是上面的內容而不是它用什麼樣的方式寫出來。
在Scrum的開發團隊，通常會以以下程度來劃分每項產品任務：史詩（Epic）、Stories（使用者故事）、Theme（主題），在我自己的解讀中，「史詩」是有某一概念與想法，但目前尚未想到該如何執行，或是主題太大還未被明確分出可執行的小任務；「使用者故事」即是形容一個需求或一個使用情境；Theme（主題）是指一群使用者故事的集合，通常由於共同的目標而被分類在一起。
我自己其實沒有碰過Theme（主題），但在我參與的開發專案中，我們會有Bug（問題）與Task（小任務）兩種不同的形式，來記錄每天不小心又發現的產品問題，與突然想到的任務。
「使用者故事」有一個相當特別的地方是，其實大家對於它的定義都不相同：
從使用者觀點來看，規模合適的使用者故事是滿足了一個需求的故事，
從開發團隊的觀點來看，規模合適的使用者故事是花幾天即可建造與測試的故事，
從商業觀點來看，規模合適的使用者故事是幫助企業達到某種商業成果的故事。
所以對於PM來說，如何讓三種角色都能對User story取得共識並且執行是非常重要的，特別是開發者與使用者的觀點。在書中提到一個例子：「開發過程中應該要交出的東西是一半的烤蛋糕，而不是烤一半的蛋糕。」這是產品敏捷開發非常重要的概念，產品當然不是一天一夕可以被製造出來，設定能夠隨時看到明確進度的目標並且時時檢證，而不是累積了一大堆需求到最後才發現「方向錯誤」。
• 核心：一邊建造一邊開發，敏捷開發
◦ 常態性的故事對話「我昨天做了什麼、我今天正在做什麼、我明天要做什麼」
讓我們退回一步，說了這麼多關於使用者故事的話題，那麼這到底該由誰負責呢？
可以確定的事情是，這絕對不應該由「一個人」獨立負責。
書中說，撰寫使用者故事絕對不是Product owner的責任，也不應該由PO撰寫全部的使用者故事，或參與所有的對話。「使用者故事」應是由多方設想與討論出來的，涵蓋了團隊每個成員自己是如何理解與看待這產品、站在不同使用者的觀點會想要什麼功能，因而絕非一個人肩負的任務。產品負責人是音樂製作人，不一定是寫歌寫曲的人，也不一定是歌手，最重要的角色是幫助你的隊友邁向成功的路。
另一個很好的建議是，產品的設計會議也不應該是委員會形式。所謂的委員會會議指的是參加的人每個人都有話語權，都有平等的決定權。在這種形式之下，大家往往會思考其他人所提出的建議對自己想法的影響，導致最後不願意提出自己最理想的產品面貌而只能為了有一致的討論結果而妥協。
作者說在最早期的產品發掘會議時，其實最核心的三個成員應該是：使用者經驗設計師、產品負責人與資深工程師。基於個人經驗，我認為討論使用者故事的時候，至少也應涵蓋這三個人才能提供更準確的內容與時程，「使用者故事」討論的會議不在於效率或很快地被完成，建議是2–4人可以隨意聊天的人數，才能夠針對產品做涵蓋性的討論。
另外，在產品發掘討論時應該要決定四個重點：
◦ 從商業觀點構思想法
◦ 瞭解客戶跟使用者
◦ 具體設想你的解決辦法
◦ 最小化與計畫識別最小可行方案，以及如何建造的發想
我當時在看到這一段的時候並不是很了解，認為很難在早期的產品發掘會議上就設想到「使用者是誰」「具體解決辦法」，但我後來覺得即便不是產品發掘會議上討論，也應該在產品實際開發前就有基本對於上面四項重點的認識。這是整趟產品開發流程中應該一直反問自己的問題。且有一件事情應謹記於心：真正可行的功能是能夠帶來價值的功能，先針對商業具體目標、客戶與使用者排定優先順序，才針對功能本身排定優先順序。
自己身為做產品開發的人，時常會對於產品抱有自己的熱情與野心，但也忘了公司的商業利益與價值才是一個產品應該最先被注重層面，如果今天打造了一個非常貼近使用者的產品，但在商業面上的定位卻不明的話，這個產品一定不會是成功的。
最後，「使用者故事」其實就是一個工具，我希望再一次提醒大家也提醒自己，並不要因為作者建議了許多撰寫方式而受限於「形式」，重要的事情是開發產品，或說，改變世界上那些使用你產品的人。我過去曾於Coursera上過一門課叫“Design thinking in innovation”，讓我印象最深刻的一段是：
「Design thinking的核心精神是：一切都是學習。你今天將產品測試推出去之後發現客戶不喜歡，那就是個學習 — — 拿回來再繼續修正。」
Lean startup思維：
- 大膽假設/列出假說
- 列出有風險的假設
- 設計/建造小測試（盡量讓原型小，甚至原型本身根本只是一張紙？）
- 與客戶一起測試
- 重新修正解決方案與假設
提醒自己，我們其實很難在一開始的最小可行方案就成功或得到市場強烈的迴響。
產品的最小可行方案是一個假說，是讓我們測試我們的想法的，所以隨時抱有來回修正的心理準備，且相信修正才是讓產品變得更好的關鍵。
最後，再用書中最開頭的Read me first作為筆記的結論：
1. 寫使用者故事的目標不是為了寫出更好的使用者故事
2. 產品開發的目標不是為了製造產品
閱讀資料：
https://www.scrumalliance.org/community/articles/2014/march/stories-versus-themes-versus-epics
* 有任何問題，歡迎在留言區直接回饋讓我知道，文章是個人的筆記與心得整理，可能有誤。歡迎討論。
