先讓英雄救貓咪 session ppt

.

01.png

.

%e8%8b%b1%e9%9b%84-save

視覺圖像記錄師 – Mina Liou 的最後紀錄成果

.

01_01.png

.

03.png

.

03_01

.

03_02.png

.

04.png

.

06

.

07.png

.

08.png

.

10.png

.

09.png

.

10

.

13.png

.

14.png

.

15.png

.

16

.

17.png

.

15_1

.

19.png

.

20.png

.20_1.png.

10%e6%ad%a5_1

.

21.png

.

22

.

23.png

.

24.png

.

 

接下來是 彩蛋時間 …

 

.

19

.

20

.

.

.

.

.

.

.

.

47.png

.

48.png

.

註:

  1. 這是預定的演講內容,但提醒大家: 當我們在窺視未來時,未來也會跟著改變的。
  2. 奇異博士片段參考自yutube上的早期預告,與實際上映稍有不同,強調需求與現實必定有所差異,請大家重視版權,上電影院欣賞吧。
  3. 場景示意圖取材自 Google Sprint 的佳作,它才是說好故事的流程圖示,適合探索及開發需求時全程採用(而 使用者故事地圖影響地圖 則是絕佳的分析工具)。

.

 

 

 

先讓英雄救貓咪 2

在這個創意橫行的時代,如果你突然間靈感乍現,行雲流水般的寫下絕佳構想(起碼你是這麼認為的)之後,接著該怎麼辦呢?

首先,是不是要先到處尋訪專家學者,來肯定一下這個概念是否可行?到底有沒價值?

再來呢,便是開始到處找找看從前有沒有人作過類似的產品?試想,我不可能是第一個想到這個概念的人類吧? 總之,先看看別人是怎麼作的。

接著:找伙伴,找志同道合的有志之士,一起合作,團隊的力量一定會大於個人的。我們群策群力,仔細的把過往數十年來的相類似產品都拿出來好好剖析一番(聽起來好像誇張了一點,但其實並不為過),試著找出攸關成敗的原因或要素,細細的思考一下,如果是我來作。應該是如何?

最後,務必要弄清楚二件事:

一、你想開發的東西,跟同「類型」的產品之間,到底差異在那裡?憑什麼你會成功呢!

二、決定「架構」,架構是這個產品能否存活下來的關鍵因素。

 

這就是我從《先讓英雄救貓咪 2》裡學到的東西,他在前言裡的第10頁到 13頁。

save2.png
布萊克.史奈德出第二輯了,更精彩!

拿同一類型的產品作借鏡

先以類似的產品做為參考,千萬不要閉門造車,一個人的視野通常都會有所侷限的。因此務必要找一群志同道合的朋友,大家一起討論一起剖析,讓共同成長成為最快的一種成長方式(這叫做團隊開發)。當然產品也會以更快速的方式來誕生。但前題是;這個idea 夠好,真得值的我們去做。 接下來,我要解釋「架構」為何是這個產品能否存活下來的關鍵因素。

 

「架構」才是重點

好的概念不是全部! 要知道;創意有一大部分來自持續的演進跟堅持。但若是一開始的架構建錯了,要隨著趨勢脈動來作修正的屏障就會大上許多,它經常會大到你無法克服而必須從來。所以好的創意,往往需要好的架構來支撐的。

身為程式設計師,我們經常會突然有一二個好的 idea 就這麼出現了,而通常它們的下場都是無疾而終,或許你可以稱他們是不夠成熟的創意吧! 但我總以為他們是少了真實場景(scneraio)的支撐,所以沒能繼續下去。如果你一開始就依據5個 W的問題方式來加深創意的內涵的話,則成功的機率自然會再上升一些。

很多時候;先想一下客戶(使用者)會怎麼去使用它,而我們要如何設計好的使用者經驗,讓客戶能夠真正獲利,而願意持續的去使用它才是重點。這種前期的設計思考,正是衍生出產品架構的必要途徑。前萬不要推說這是UX工程師的責任,因為需求跟設計本就是環環相扣的,而架構是支撐功能的基礎,工程師要落實解決問題的模式,它正是用來衍生出架構的。

 

是好萊塢拍戲難還是我們寫程式比較難

因為我一直喜歡拿拍電影或是寫劇本來做為開發程式的參考,所以就經常會遇到這個問題,結論是大家都覺得「好萊塢拍戲比較難」,因為他要討好的客戶群實際上要比我們要多得多了! 而軟體開發也越來越像是在拍電影或寫劇本一般,要找到客戶真正的需求才是重點。

 

借助「先讓英雄救貓咪 2」所做的結論,一部電影是否成功只取決於以下二點:

 

  1. 和同類電影相比,劇情是否有所突破。
  2. 架構是最關鍵的因素。

 

》這不正是新創公司應該有的思維嗎? 我還是想強調先去做影響地圖Impact MAPPING 吧!

 

 

 

 

 

 

 

 

先讓英雄救貓咪

 

未命名
這是一本很棒的編劇教學手冊,作者: 布萊克.史奈德。

 

(這裡不打算介紹這本書,我只是要把從書裡面學到的東西,講出來。當然我一直相信,我們是自己人生的導演,所以就一定要有好的劇本囉!)

 

英雄為什麼要先救貓咪呢? 目的只為了在電影一開始的時候,能夠快速的朔造英雄的形象。而執行Scrum的計畫會議也是要如此。

 

Scrum的計畫會議;要由PO說故事開始

我總是要求需求提出者,也就是PO(Product Owner),在計畫會議(Planning Meeting)一開始時,不要直接把使用者故事一個一個陳列出來,隨後就開始平鋪直敘的進行討論。要倒過來;要把感情放進去的好好地說一段完整的故事,一段能把團隊拉進任務裏頭的故事。首先,要做一段 200字以內的故事描述,試試看工程師是否被你感動了,然後團隊決定主動的協助你完成任務。也就是,嘗試把要討論的個別存在的使用者故事,都濃縮在這段要描述的故事內容裡。目的正是;先讓英雄救貓咪。(讓團隊清楚的知道為何而戰,這一段衝刺的真正目標在哪裡?)

 

PO常常會反問我,所有的使用者故事都要放進去嗎? 這樣會有一點困難,且會有一點不順暢!

 

 

老實說;這正是我的目的,那些串不起來的,很難硬塞進來的使用者故事,他們通常就是那些比較不重要的需求了,或是完全屬於另一個功能區塊的使用者故事了,所以當然會比較難融入到一個完整的故事裏頭。這種作法,可以讓 PO在會議之前的準備工作中,透過自己編寫故事的時候,自行意識到要做的這些使用者故事,是否真正的解決了使用者的需求,做完之後是否就能夠得到真正的價值。(另一個好方法是透過製作影響地圖 impact mapping的方式,讓團隊弄清楚 Why? 也就是為何而戰,Who?我們要價值給誰以及How? 如何交付價值)透過這種思維的自我回饋,先做一次優化,對使用者故事先做好一定的區隔。

 

範例: 由po以故事的方式描述了他的需求。

83

故事開始: 從先詢問在場的學員,你(妳)們出遊會拍照片嗎? 會拍很多照片嗎?

那拍完的照片什麼時候會看呢?

(這是一個家庭出遊後回到家中齊聚一起觀賞照片時的景象)

84

 

使用者故事已經隱含在上面的整體故事裡了

 

溝通是為了造成共識

其實要求PO講故事的目的還不只於此;因為使用者故事的目的就是為了描述需求,然後對需求進行溝通討論,進一步造成使用者與開發人員之間的共識。而以這種講故事的方式作為開始,對需求的探討而言會有一個比較好的融入感和完整性。當然,故事說得好的時候,效果自然也會好上許多。這種作法,比起一個一個使用者故事的表列式討論方式要好上許多(離題一下,這也是 refinement meeting最為人詬病的地方,大家只是想快速的對個別的使用者故事進行大小估算與討論,很容易忽略了這個衝刺(Sprint)增量的目的,也就是它所應該有的整體性目標)。

 

我們都知道;要想在演講的前5分鐘就抓住聽眾的心,只有一種方法,就是講一個感人的故事。PO的任務就是要把需求明確的轉達給大家,讓團隊有感同身受的意味,自然的把任務當成是自己的事,為完成任務來負責,所以就該從故事開始囉!

 

下一回;我們來談「先讓英雄救貓咪2」 – 老實說,二版更精彩! 它對軟體開發更為有用。你相信嗎?