目前分類:敏捷需求探索 (14)

瀏覽方式: 標題列表 簡短摘要
這個月在新竹敏捷聚會時, 我們舉行了一個有關於用戶故事的撰寫工作坊, 介紹了什麼是用戶故事, 讓大家動手撰寫了一些用戶故事和驗收條件. 希望能讓參與的人, 對用戶故事有基本的認識.
 
 
在這次的聚會中, 有人提到在合約型的專案是否可以使用 user story, 那天因為時間不多, 我沒有解釋得很清楚, 所以我特地撰文整理了一下我的想法, 大家可以一起來討論討論.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

星期日我開了一們課程: 敏捷需求探索入門工作坊. 那時候我們實作的題目是關於旅遊的系統. 其中有一組做出的成果, 事後發現居然和目前市面上的產品很相似, 學員感到非常驚訝, 也對於他們自己感到驕傲, 他們的想法真的是可以商品化的.
 
撞衫的產品: 旅型 (https://travostyle.com/)
 
下面是學員的成果

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在探索需求時, 其中有一種做法, 就是會用故事地圖(user story mapping)如何銜接影響地圖(impact mapping). 先利用影響地圖制定產品策略, 然後再利用故事地圖列出要做的故事, 並且排出優先順序. 正如下圖所示:
 
 
可是真的能接得那麼順暢麼? 在我看來缺少了一些東西:

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在敏捷社群中, 我們常常會使用 user story 來描述要做的事情, 並且用它來啟動跟用戶的對話. 唯有深入瞭解客戶要什麼, 你才能做出接近正確的產品.
 
可是問題來了, 如果你有 200-300 張 user story 呢? 我想對於一個正式的產品, 不是練習的作業, 這樣的數量似乎很正常, 這時候你就會遇到 James Shore 所說的 Story Card Hell 問題.
 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

對於想要結合 Scrum 和用戶體驗, 這篇文章是必看的參考資料. 這是由 User Story Mapping 的作者 (Jeff patton) 所撰寫, 相信有不錯的參考程度. 以下是我整理的一些重點
 
Dual Track Development is not Duel Track
 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

最近在翻閱 Exploring Requirements 一書, 他說到需求難搞是正常的事, 以下是我整理出來他的觀點:
 
 
產品開發的工作, 就是將某人的想要 (desire), 轉化爲能夠滿足這個”想要"的產品的過程.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

有人問到新創事業需要進行需求探索嗎? 因為新創事業都是很未知的, 真的有方法可以探索啊? 
 
老實說, 沒有任何方法論可以明確知道客戶要什麼. 但是, 如果有方法能讓你保持持續改善, 並且提供良好的回饋機制, 這樣的方法就是好的做法.
 
在 Running Lean 一書中提到, 初創事業可分成以下的三個階段
(1) 問題/解決方案適配 (Problem/Solution Fit): 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在繪製完影響地圖後, 因為地圖中有的 who, 很多人接下來便會想要了解這些 who, 也就是我們的用戶. 因此, 用戶訪談往往是第一個活動, 希望透過這樣的過程, 能更清楚知道用戶想要的是什麼. 
 
 
 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(2) 人氣()

很多人在用了 story mapping,  列出了產品要提供的功能後, 接下來很多人就會想開工去寫程式了. 這樣做的話, 還是太快了些, 如果在此之前先做的驗證, 可以讓你少走些冤枉路.
 
有的人會說, 那我們來選出 MVP, 找出最有價值的部分, 先來驗證看看. 這是一個很好的開始. 但是, MVP 要做出來也是要花時間的, 因此我們還需要更簡單, 更省錢的方法, 再做出 MVP 之前再確認一下.
 
那天在上用戶訪談那門課時, 老師提到一個分鏡圖的方法, 覺得還不錯, 整理下來給大家聽聽.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在敏捷需求探索時, 一開始會用 impact mapping, 描述要產生什麼影響, 以及會什麼要做這功能. 然後使用 story mapping, 依著時間順序, 來述說產品的功能.
 
這一切看起來都很完美, 不是嗎? 可惜, 天下的事情太複雜, 不太可能用一招, 就可以解決所有問題. 例如: 防毒軟體. 使用者根本不知何時有毒要進來, 不知道他什麼時候已經中了毒, 也不知道中了以後要怎麼辦. 因此, 以時間軸為主的 story mapping 完全無用武之地. 
 
那怎麼辦? 沒有時間順序觀念的產品, 還能使用 story mapping 來進行嗎? 相信有不少人會有這類的問題.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在上次敏捷需求探索工作坊中, 還被問到一個問題, 有人提到是否可以單獨來教 user story mapping, impact mapping 和 客戶訪談. 也有人提到 persona, storyboard 這些, 每個都是一門學問, 每個都需要花好多時間學習. 
 
是的, 這些東西拆開來看, 都是很複雜, 都是一門不得了的學問. 需要花時間學習, 才能夠精通. 
 
但是, 我並沒有想分開討論他們, 或者花時間討論每個 practice. 我想要做的, 不是要告訴你, 每個劍招要使到哪個位置. 而是要讓你清楚, 這整個獨孤九劍的劍意為何.
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

在敏捷需求探索工作坊中, 另一個困擾大家的問題, 就是要如何挑選客戶. 一開始時, 大家野心很大, 認為自己的產品應該可以賣遍天下, 但真的是是這樣嗎? 讓我們看下去吧.
 
之前曾經寫過一篇文章: 由技術採納週期來看敏捷推廣.(http://kojenchieh.pixnet.net/blog/post/400902718 ). 那時候提到使用者採用新技術的週期分成五個階段. 
 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

那天新竹場在進行敏捷需求探索, 有人問我在 impact mapping 出來後, 要確認什麼, 以及要如何確認呢?
 
那時候我有跟大家說, 產品初期時, 你所想出來的東西, 大多是腦補出來的, 也就是一切都是你認為, 用戶有這些問題, 用戶想要出錢解決這些問題, 以及你的產品真的能解決問題. 
 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

這個 228 假期真是忙碌, 一連兩天台北和新竹敏捷社群都有活動. 在連續假期和天氣爆冷下, 能夠來參加的朋友, 內心真的十分感動. 你們的參與, 是辦社群的人最大的鼓勵.
 
這次在新竹的分享, 是關於利用敏捷方式來進行需求探索, 這是一個長達四個小時的工作坊, 不過還是不夠時間, 把一個完成的過程跑完, 只能跑完一半, 或許下次來個八小時吧.
 
 

kojenchieh 發表在 痞客邦 PIXNET 留言(0) 人氣()

找更多相關文章與討論

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼