其實我要講的有一半是來自於使用者故事對照這本書的讀書心得。上週，有次小主管帶我去聽演講 (Epoch-MIT ILP 專題演講)，其中一場是 PicCollage founder John Fan 為主講人，他就問台下觀眾，什麼是 MVP，當時還聽的不是很清楚，回家也有忘了。接著週末，我就拿起這本書開始讀，結果我發現 User Story Mapping 提到 MVP 還有一些 Lean Startup，與我那天聽到演講的內容很有相關性。
MVP 也就是 "Minimum Viable Product" 最小可行產品。
為什麼需要 MVP 呢?! 我在猜想某部分原因是因為當我們在策劃一個解決問題的產品的時候，大部分情況是我們在“猜想”使用者會遇到什麼問題，所以當我們想出了一個 solution 時，(也許我們要想非常多個 solution)，我們要做出一個 MVP 跟使用者互動，驗證我們是不是在對的方向，也用來驗證我們的猜測是不是越來越接近需求。所以會一直維持一種循環『build->measure->learn』 (看圖片) 不斷的試驗，不斷的學習，這樣的 iteration (循環)，能夠越快越好，能夠越接近使用者的想要的產品，iteration 也不要太久，差不多一次的 sprint 衝刺時間約兩周，這樣一個月可以 iteration 兩次（sprint 的週期主要還是看公司的步調是什麼狀況...）。
實現想法不急著產出設計稿
其實 wireframe 我研究不多，但那天聽演講覺得要點就幾個:
- 討論快速
- 修改也快速
- 去除任何顏色，單純線稿，單色色塊表現 (因為顏色會影響判斷能力，也會增加很多考慮易用性的變因)
這些列的是我看書的學習心得 :P, 也許對看文章的你沒什麼很直接的幫助，我建議你可以直接買書，會比較好理解，因為有些細節要搭配照片看比較了解。或是看 YouTube，這裡有這本書的作者的演講: User Story Mapping with Jeff Patton
- Story Mapping 幫助開發時聚焦在 user 跟使用經驗上，促成更好的流程(討論出來的)。
- 故事對照 Mapping 是很容易的一件事情，基本上我們只需要準備便利貼(如果你不嫌貴的話，公司又願意花錢買便利貼...)，由左而右的排序，寫下整個使用者在使用產品的故事。而細節是沿著每個步驟的下面，往下貼，也就是水平排序為故事的流程，而垂直的便利貼，表示該流程的一些細節。(看 slides) ，一個人也可以練習如何 User Story Mapping，基本上你可以把你某一天的早上所做的所有的事情透過便利貼描述出來，這是一種練習方式，書本某一章節有提到如何練習~
- 『分享文件不是分享共識. p.XXX』 這句話還慢令人有所感觸的 XD，為什麼呢？！因為寫 spec 的人跟看 spec 的人可能認知不同，如果沒有確認大家對於這份文件所講的某件事情有相同的認知，那麼 spec 跟實際做出的東西可能會有很大的落差。即便大家都在 spec 上面簽了名... 也不代表大家想的是同一種預期的結果。
- 呈上點，個人結論是: spec 別寫得太完美... XD (其實我以前是開發完才補文件.... )
- 當在敘述故事的時候，所有的對話記錄，寫在白板上，貼在牆壁上的便利貼所有討論，過程照片，都可以任何形式記錄下來，如拍照等等，因為重要的不是被寫下來的文字，而是你看這些記錄可以讓你想起什麼討論的細節。
- 千萬要記住，User Story 絕對不能代表需求，而是利用文字, 圖像，透過大家共同討論, 述說故事，建立大家對 User Story 的共識。
- 大故事可拆解成好幾個小故事。(我覺得這樣做的好處也適合拿來拆成要製作的功能，但感覺又不能這麼工程師一面的想法... )
- 『在探索深度之前，先聚焦於使用者故事的寬度』 p.12，這句話的意思是，討論得很 high 的時候不要一直往細節討論，要拉回來照顧一下整體的 story 以及繼續往後面的 story 前進，書上的說法叫做"整體圖像"，討論細節之前請先以達到故事尾端為重，『思考寬度一英里，思考深度一英寸』 (我好喜歡這句話 :P)
- Ron Jeffries 的三個 C: Card, Conversation, Confirmation
http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/ - 魚缸協同合作模式 (人多未必好辦事)，這模式挺有趣的，意思就是，有興趣的人就加入對話，沒興趣的就離開魚缸的範圍 (其實是類似在一個房間界定魚缸的範圍)，如果你的團隊有人開會時表現的興趣缺缺，滑手機之類的症頭....==。類似的文章: https://blog.itcilo.org/2009/02/16/facilitate-a-fishbowl-discussion/
- 基本上想做的事情，跟擁有的時間，有很大的落差。但 User Story 會談到很多細節，可以拉出一條線，在線以上叫做 in，線下叫做 out，in 表示在某個階段之內可以先完成的，也許是一些必要的功能，out 則是暫時先不做，不代表捨棄那個流程的 detail. 可能在這個流程上會有一些便利貼會被移動 XD (感覺很像在走 scrum)
- 我也好想玩玩看但我公司應該沒有這種 project 可以玩這種流程 QQ
有興趣的話建議買書來看看吧! 要不是這本書，我真的沒聽過 User Story Mapping.
關於 User Story Mapping 你也可以參考:
- gotop 使用者故事對照｜User Story Mapping
- (博客來) 使用者故事對照：User Story Mapping
- http://jpattonassociates.com/user-story-mapping/
- http://jpattonassociates.com/storymappingslides/ 書籍作者的投影片
- Ruddy 老師的 slide http://www.slideshare.net/ruddylee/user-story-mapping-43373448
- User Story Mapping 使用者故事對照
- vividadada的技術筆記 使用者故事對照/地圖演講摘要 (User Story Mapping)
如果有寫錯什麼內容，還麻煩留言指正指正，謝謝!
若有問題，或是有任何不妥的文字，歡迎來信 yiyingwu.1990小老鼠gmail[.]com
非常謝謝您提供的好資料！對我非常有幫助！
回覆刪除好文章
回覆刪除好文章！！
回覆刪除