pablo (9)
2016 年 08 月 21 日

Google衝刺計畫workshop心得

很感謝柯仁傑兄David在新竹交大辦了這個workshop活動。利用了4個小時的時間讓參與這個活動的網友一起體驗整個Sprint衝刺流程。

從這個活動體驗到的經驗

參加這個活動前,David已經先通知參加的人要先準備功課

  1. 先了解目前高鐵訂票系統的使用方式, 以及跟其他業者的合作模式。
  2. 找尋目前其他常見的訂票系統,有哪些不錯便民的設計, 以及有跟哪些異業結合的做法。

然後在workshop簡單介紹了Sprint的流程,參與的角色,與核心精神。於是就在課堂上出了一道題目–如果高鐵公司希望搭乘的客戶成長30%,那要如何做才能達到這個目標?

這次的活動,每個小組分配到6人,書中是建議7個人(剛好跟Soft & Share讀書會的上限人數一樣) ,然後依照David的分階段任務去模擬Sprint對應的活動。

星期一 以終為始 要產出示意圖,並決定衝刺計畫的焦點,與要解決問題的針對對象 。

14040075_10154546084575982_8299087539913161253_n 14054191_10154546044310982_4208326434531411137_n

我們這組在這個階段提出的假設是–如果高鐵可以跟周邊的景點有多一些合作交通運輸業者,讓搭乘者容易找到轉乘資訊與搭配不同的運輸工具,會是一個提高使用者搭乘高鐵意願的關鍵,解決問題的針對對象是–高鐵乘客。

因為沒有「專家」這個角色,所以就當作是在瞎掰 😄

書裡面有強調,衝刺團隊要有一個專家的角色,這個專家也許是對問題的核心很了解例如書中有一個講癌症醫療服務的團隊,裡面就配置一位對癌症治療很熟悉的醫生擔任專家的角色,或是對市場與客戶很熟悉,這些專家扮演被諮詢的角色,他們可以給予衝刺團隊正確解決問題的方向。但是書裡面也強調,決策者的決定凌駕所有人之上,作者舉了一個衝刺失敗的案例–原因就是決策者沒有參加,即使衝刺團隊提出的解決方案很好,但那卻不是決策者想要解決的問題,也就是大家白忙了一場,搞錯了方向 😄 。回到我講的這個workshop沒有專家角色,所以跑起來就會很像是在做–腦力激盪。剛好相反的,作者認為腦力激盪對於解決問題沒有多大幫助。但是David說IDEO的主張又是相反,到底那一方面是正確的? 因為我對IDEO不是很熟悉,所以就不多加評論。

這個階段倒是一直聽到David跟在場的網友叮嚀,因為參與的人以工程師背景居多,這個階段還不是提如何實作的階段。有工程思維的人,這時候很容易就跳到後面的產品功能那方面去了XD 這確實要避免的。

星期二-畫出方案草圖

14117803_10154546318660982_6702091029883231572_n

這個階段需要動手畫草圖,這部分真的要多加練習,不然腦袋空空,要在時間內生出一些圖還真有點困難。

這個部分有分兩個階段做投票,第一階段是大家不要討論,自己走到草圖前面,用直覺的方式投下藍色的票。稱之為稻草人投票。

第二個階段由促進者針對草圖解說,並與草圖提供者問答解說,結束後大家再用紅色的貼紙重新選擇。

David解釋這兩個階段主要去測試使用者在不經解說下,對於設計最直覺的想法,與解說後的差異。確實大家經過解說後,投下的票跟原本投下的票不一樣。但是要思考的是–產品出去了,旁邊可是沒有人解釋給使用者聽。

星期三-選擇最佳方案,分鏡草圖

14021452_10154546430275982_5300198903954406123_n

分鏡圖這個階段也是一樣,平常沒有在畫草圖也是有點困難,建議平常可以拿現成的產品介面做練習畫分鏡圖。當在做衝刺計畫後,腦袋會有比較多的連結,以供參考。

星期四-模擬、原型

這部分時間有限,就沒有做練習

星期五–訪問客戶

David請每一組請出兩位,一位當作是訪談者,一位當作使用者。訪談者向使者者解說分鏡圖,然後將使用者的回饋記錄下來。

問題與討論

IDEO跟Sprint有何不同?

IDEO

想要了解初步了解IDEO流程,David建議可以先去看這個影片

幾個名詞 Design Sprint ,Pretotype vs Prototype ,Fake door。

Sprint和敏捷的關係

Agile.jpg

必須先經過衝刺計畫驗證後再來談敏捷開發。但是我發現大家似乎都是先使用敏捷開發的方式先去做所謂的MVP,然後認為經過不斷的Iteration,認為這樣產品就會變好,但是按照衝刺計畫的精神,寧可花5天先經過出衝刺流程去驗證然後再進入實作,這樣可以避免掉後面的開發浪費。不過如果你是opensource開發者一定不會這樣想,寫到這邊想到了opensource,確實很難將一些opensource的成功案例去用Sprint衝刺計畫來解釋。

一些感想

看書跟實作真的是兩回事,在回家的路上一直在思考一件事,Sprint應該是不適合用來尋找或是驗證Business model,反而比較適合在某個Domain有一定的技術基礎–例如書中的做服務機械人的公司,或是公司在商業上已經有一定的客群–例如書中的賣咖啡公司,想在上面增加新的功能或是新的服務,然後進行一連串的驗證與決策流程,看了書裡面的幾個範例還有這篇文章–5天设计产品?Google Design Sprint 实战 裡面講的郵件前端的統計功能,都是在這種模式下跑Sprint,所以我的想法是Sprint是蠻適合A+B式的創新,如果是從0到1的創新適用嗎? 因為我的想法是從0到1的過程,領域專家何處尋會是一個很關鍵的問題,大家都在猜一個不知道的領域,沒有專家可供諮詢。但是A+B至少有一個Domain是可以找到專家出一些意見。初步的想法,先整理下來,歡迎指正。

附記

 

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

你正使用 WordPress.com 帳號留言。 登出 / 變更 )

Twitter picture

你正使用 Twitter 帳號留言。 登出 / 變更 )

Facebook照片

你正使用 Facebook 帳號留言。 登出 / 變更 )

Google+ photo

你正使用 Google+ 帳號留言。 登出 / 變更 )

連結到 %s

分類

00-精實雲端讀書會, 閱讀筆記