這個 228 假期真是忙碌, 一連兩天台北和新竹敏捷社群都有活動. 在連續假期和天氣爆冷下, 能夠來參加的朋友, 內心真的十分感動. 你們的參與, 是辦社群的人最大的鼓勵.
這次在新竹的分享, 是關於利用敏捷方式來進行需求探索, 這是一個長達四個小時的工作坊, 不過還是不夠時間, 把一個完成的過程跑完, 只能跑完一半, 或許下次來個八小時吧.
![](https://pic.pimg.tw/kojenchieh/1488180560-1884016531_n.jpg)
在這個過程中, 我們分成四個階段進行:
(1) 構思想法
一開始我們可能對某些問題有些點子, 想要幫某些客戶解決他們的痛. 這個過程我們會利用腦力激盪和 imapct mapping, 對產品想解的問題有基本了解. 並且建立商業目標與產品功能的關係, 以及找出背後關聯的假設.
(2) 了解脈絡
第一步驟的東西, 大多是我們自己腦補完成的. 因此, 需要去訪談客戶, 觀察客戶所在環境, 洞察客戶潛在的痛點. 這部分會大量借用用戶體驗領域的手法. 像是人物誌, 用戶旅程地圖, 或是同理心地圖等等. 這部分是工程的朋友最弱的地方, 不過因為時間的關係, 我也只能點到為止.
(3) 設計解法
當對用戶脈絡有了解後, 可以根據原先構思的想法, 來設計產品的解法. 這裡可以用些脈絡訪查, 或是設計思考的手法, 先想出高階的解法. 然後再使用戶故事對照 (user story mapping) 來想產品的功能.
(4) 探索細節
當高階解法出來之後, 接下來, 可以用 design studio 來設計產品的畫面流程. 讓大家可以進一步想像, 原來產品是長得這樣, 會以這樣的方式跟用戶互動. 最後, 再利用 spec by example 定義出重要的功能的細部範圍.
![](https://pic.pimg.tw/kojenchieh/1488180684-2811219440_n.png)
有人問我, 是不是敏捷需求探索都是這樣做的, 當然不是. 這只是其中一種流程. 你可以拿不同的實務 (practice), 以不同的順序來進行. 但是, 在需求探索的過程, 你會有以下的感受:
需求逐漸被展開
會利用迭代的方式進行
會由不同角色共同進行
強調共同瞭解
不斷驗證假設
利用代價地的實驗驗證假設
另外, 大家列出的產品功能, 大多是自行腦補來的, 需要不斷驗證, 才知道是不是有人要. 因此, 在每個階段, 要不斷驗證前面階段, 自己腦補出來的假設. 我發現大家很容易每個階段都分開看, 忘記去思考跟上個階段產出的關聯是什麼. 上個階段是否有些東西, 在這時候需要 double confirm.
其實, 開發時我們也常這樣. 需求分析做出來的 spec, 設計階段照單全收, 從不懷疑是否正確, 或者這功能真的有人要嗎? 要不然, 就是需求寫一套, 設計自己做一套. 自己覺得系統應該要這樣動.
還有, 在了解脈絡這個階段的手法, 人人都可以學會, 但是能不能用的很好, 重點在於洞察的能力. 你不會看一堆人教 design thinking, 但是真的能用設計思維做出好的創新, 或是好產品, 我想應該不多.
最後, 我覺得這種四小時燒腦的工作坊, 可能要準備些食物或是點心, 補充一些電力, 才能有體力撐完全場. 下次提高些收費, 從 100 到 300 元好了, 用來買些點心吧 XD
全站熱搜