David Ko的學習之旅

在處理敏捷開發的需求時, 敏捷社群常使用 user story 來描述要做的需求. 有天我忽然發現到, IDEO 設計思考的流程中, 有個叫做設計觀點 (POV, Point of View)的東西, 和 user story 很相似. 讓我們來比較一下吧

使用者故事(User Sotry) 的格式如下:
As a [Role], I want [Feature] because of [Some Reason].
範例: [身為買書的客戶], 我希望能[利用部分書名來找書], 因為[我無法記得完整書名]

POV, Point of View 是將遭遇到的問題, 重新用以下方式來描述
[User] needs to [User’s Need] because [Surprising Insight]
範例: [一位住在外面的上班族], [需要規律的飲食], 因為[繁重的工作壓力無法準時去吃飯]

那遭遇到的問題是從哪裡來呢? 通常我們在進行 IDEO 的 design thinking 時, 我們會利用 empthy map 或是 customer journey map 去描述使用者目前的現狀. 

而在 agile 中, user story 通常是希望客戶能夠撰寫他們所想要的功能. 可是你也知道, user 不一定知道他們想要的是什麼, 就如亨利福特所說的, 如果你問使用者要什麼, 他們只會說要一匹跑的更快的馬, 但是他們絕對不會說是汽車. 這裡 agile 是少了一些東西. 沒有提到要如何收集或是描述使用者的痛苦. 也許因為 agile 是屬於開發流程, 它應該是在比較後面的階段才會使用到, 所以在需求收集和分析這塊, 並沒有太多琢磨.

當 POV 列出來之後, 接下來我們通常會利用 HMW (How Might We) 來找出可能的解決方向. 例如:
POV: [一位住在外面的上班族], 需要[規律的飲食], 因為[繁重的工作壓力無法準時去吃飯]
HMW:
     我們是否能提供一種提醒機制, 讓上班族知道要去吃飯
     我們是否能讓公司提供加班可獲得免費晚餐的福利, 來促成公司和員工互利的狀況
     我們是否能夠提供減壓並且方便取得的食譜
     我們是否能夠提供均衡飲食的菜單
     …

在 agile 中如果直接列出 user story 後, 通常是直接開工了. 不過 user story 還是有提醒大家, 重點是要和 user 溝通, 為什麼她想要這個功能, 背後的動機或是痛點是什麼, 這樣才能做出真正 user 想要的系統, 而不是只是照做, 或者只是釐清功能細節而已.  user story 雖然沒有講具體步驟是什麼, 但是精神上確實有考慮到 POV/HMW 想要處理的面向.

結論: 大家的機制和想法都差不多, 但是跨界合作可以讓你看到不同做法, 可以趁機彌補自己的不足. 留下周圍 7 個人的電話吧 XDDD

參考文獻:
IDEO design thinking process
https://dschool.stanford.edu/groups/k12/wiki/17cff/Design_Process_Steps.html