今天先簡單聊聊吧！來聊聊與 Story 相關的經歷。

User Story

我曾前公司導入使用者故事，但是那時候其實我沒有現在那麼明白他的用法，我只是把它當作把一個需求重要元素寫出來的形式、工具，而不是像現在一樣認為它是一個建立共同理解的工具。

但儘管是這樣，要把這件事做好也不容易。更多人甚至不暸解這樣的形式是為了凸顯什麼樣的目的。現在的我會好好解釋：我們要解釋為什麼會有這樣的需求、這樣需求是基於誰的角度而有需要、那基於這樣的需求我們預期要用哪一種解決方案、為了驗證我們對解決方案的理解一樣，來聊聊彼此會怎麼驗收。

所以更多只是淪為形式，只是把需求換一個格式去寫而已。但還好，我們在 Planning 時還是會釐清，甚至去界定了我們常會用到的數種角色。所以還是有達到使用者故事的目的——建立共同理解。

在這途中我也會嘗試在 Item 下面留言如果是我來寫，我會寫成怎樣，和 PO 做交流，但可惜不是每次有把我的考量傳達到。不過如果時光倒流，我能做什麼？我應該會用更多時間一起與 PO 釐清，拋問題讓他學習，而不只是做給他看。

Job Story

我來到這間公司約半年左右，CEO 邀請了一位服務設計出身的夥伴加入我們。我們也有聊到 Story 這件事，正值他最近也在研究，所以他也與我們分享了 Job Story 的寫法，相較於 User Story，更著重在使用者產生需求的情境，幫助我們有更多發想。

從此我們也會看需求嘗試使用 Job Story 去表述，或是兩個都寫一起去探討。

探討客戶需求背後的問題

同樣是那位夥伴，我在他身上學到一個更有趣的是他帶著業務團隊和 PO 去釐清需求這件事。我們在當時遇到一個問題，在於業務團隊從客戶那邊帶過來的回饋，很多時候只是擔任一個傳聲筒的角色，而沒有去釐清為什麼要這樣的新功能或變動，然後就會有許多五花八門的需求要求 PO 和開發團隊買單。

這位夥伴就帶著他們進行 Workshop，將每個客戶的需求寫出來，然後探討這些需求是遇到什麼問題而提出來，是不是有哪些需求是有共同的問題，那我們有沒有更好的方案去解決這個問題。

透過這樣直打核心的方式，可以讓我們不會疲於奔命做一些客戶以為可以解決他們問題但實際上沒有那麼好的功能。而是做一個功能就能解決數個客戶原本提出來的不同需求，因為這些需求背後都來自同樣的問題。