2015年1月22日 星期四

把 User Stories 改成 Job Stories




我們使用 User Stories 讓 designers 跟 developers 了解使用者問題的脈絡,給我他們更多空間或方式去解決使用者發生的問題。

不過有人發現 User Stories 有很大的缺陷,每個人理解的程度不同,最後會變成定義解法 (solution),變成在解決「怎麼做」這件事,並非定義問題。

當我們在開發產品時,應該專注在定義問題,並非解法。

先認識一下兩者的不同

User Story: 
As a [persona/role] I want to [action] so that [outcome/benefit].
身為 某人/某角色,我想要 某個行為/功能,如此可以得到 某種好處/結果 (有商業價值的)。

改成

Job Story:
When [users work/life context] I want to [motivation] so that [outcome/benefit].
當 發生某種情況,我有 某個動機,如此可以期待得到 某種好處/結果。


最大的不同就是 【Motivation 動機】


來幾個例子練習一下,情境是一個 "技術討論區"

User Story:
身為一個工程師,當我是貼文者最多的人,我想要我的個人介紹裡面有一個徽章讓大家知道我是最多貼文的人。

Job Story:
當我是這個主題的最多文章貢獻者,我希望可以呈現在我的個人介紹頁上,讓大家知道我這個主題的專家。
(解法就不限制在 "徽章" 了。)


User Story:
身為一個工程師,我想要看某個人在這個主題的貼文數字,這樣我才知道這個人的開發經驗可不可靠。

Job Story:
當我看某人的個人介紹頁,我想要看這個人在每個主題貢獻的文章數字,這樣我才能了解這個人的知識領域分布。
(找出真正的動機了)


另一個有點拗口的例子

User Story:
身為一個評估者,我想要看到那些我想要評估的東西,我才能評估他們。

Job Story:
當我發現一個我需要評估的東西,我必須親眼看到它,所以才能確認那是我想要評估的東西。


那當一個系統有多種角色 (系統架構內的角色,並非故事角色) 跟事件的時候怎麼辦?例如:買方、賣方,總管理者、一般管理者、使用者、維護工程師...等。該怎麼寫 Job Story?試著伴隨著事件的情境(events) 跟因果關係 (cause and effect scenario) 一起寫。

例子1:
當買家已經競標了一個商品,即時的競標數通知對買家來講非常重要,這樣買家才有足夠的時間去評估是否繼續競標猜物品。

例子2:(加入因果關係)
當賣家對於商品的競標的狀態不滿意,想將商品下架,但已經送出競標的買家希望可以馬上知道商品被下架,這樣它們就不用繼續關注這個商品後續的變化,並可以開始注意其他類似商品。

例子3:(不同的腳色有相同的事件發生時,不用再去切分角色)
當客戶在手持裝置上,發現自己忘記密碼,他們想要利用手機可以快速的取回或是重製密碼,讓它們可以繼續登入並使用網站。




參考文章:
The Problem With User Stories and What's Better...
http://alanklement.blogspot.tw/2013/03/the-problem-with-user-stories-and-whats.html

Converting To Jobs Stories
http://robots.thoughtbot.com/converting-to-jobs-stories

Replacing The User Story With The Job Story
https://medium.com/the-job-to-be-done/replacing-the-user-story-with-the-job-story-af7cdee10c27