上集傳送門 Hi!大家好,我是馬在飛的Nat。 上篇最後有提到了 User Story 是刻意模稜兩可(ambiguity),其原因在於透過模糊而促使你去和團隊的溝通。為什麼要刻意促進溝通呢?因為在 User Story 的方法出現之前,大家建立規格方式,就是儘可能的收集資訊,最常見的方式叫使用案例(Use Case ),Use Case 指的是使用者與產品之間的各種交互行為,以下是以售票系統為例的Use Case: 1. 成功買到票 2. 信用卡餘額不足 3. 選錯終點 4. 無票可售 5. 沒有網路 … 你會發現,一但細分下來,會有很多可能的路徑及情況會發生。Use case 的原意是隨著產品的開發及釋出,逐步增加案例,而不是一次性的完整文件,但太多組織誤用,閉門造車悶著頭寫Use Case,各種腦補路徑,高達數個月的寫文件工作後,再把看似「完整」功能規格書移交給開發團隊進行開發。但因為在設計過程中缺泛持續的溝通,反而造成有些功能根本無法開發或是不符合實際使用,畢竟設計師不是工程師也不是用戶。這將會導致兩種結果:第一種是之前花費的數個月撰寫打了水漂,規格要重新規劃、文件要重新撰寫。第二種可能是工程師只關心規格文件,還是按照規格文件開發,完全忽略了功能對使用者是否有用、是否有價值,最後產出無用的產品。甚至兩種都發生。

上集傳送門

Hi!大家好,我是馬在飛的Nat。

上篇最後有提到了 User Story 是刻意模稜兩可(ambiguity),其原因在於透過模糊而促使你去和團隊的溝通。為什麼要刻意促進溝通呢?因為在 User Story 的方法出現之前,大家建立規格方式,就是儘可能的收集資訊,最常見的方式叫使用案例(Use Case ),Use Case 指的是使用者與產品之間的各種交互行為,以下是以售票系統為例的Use Case:

1. 成功買到票

2. 信用卡餘額不足

3. 選錯終點

4. 無票可售

5. 沒有網路

你會發現,一但細分下來,會有很多可能的路徑及情況會發生。Use case 的原意是隨著產品的開發及釋出,逐步增加案例,而不是一次性的完整文件,但太多組織誤用,閉門造車悶著頭寫Use Case,各種腦補路徑,高達數個月的寫文件工作後,再把看似「完整」功能規格書移交給開發團隊進行開發。但因為在設計過程中缺泛持續的溝通,反而造成有些功能根本無法開發或是不符合實際使用,畢竟設計師不是工程師也不是用戶。這將會導致兩種結果:第一種是之前花費的數個月撰寫打了水漂,規格要重新規劃、文件要重新撰寫。第二種可能是工程師只關心規格文件,還是按照規格文件開發,完全忽略了功能對使用者是否有用、是否有價值,最後產出無用的產品。甚至兩種都發生。

反觀User Story因為其保留的模糊空間,反而促進了團隊去思考、溝通,進而精煉出更好的功能作法,避免了上述的情況發生。要能要能更好的去運用User Stoyr,你需要記住三個C ( 3Cs):

  1. Card 卡片
    有個故事:當創業家想要找投資時,其中一位知名的投資人會要求創業家在他的名片後面寫上他的想法,等這位投資人回家後,他會找出他覺得有興趣的想法,然後再依据名片上的資訊連絡他們。而 Card 的核心也是如此,不需要詳細內容,重點在吸引或價值(所以有提到 So that/Why 很重要),其目標就是引導第2個C:Conversation 對話的發生。
  2. Conversation 對話
    透過與團隊的對話,包括:質疑、問答及討論,讓團隊能徹底理解功能對用戶帶來的價值。確認團隊都擁有共同的理解後,才會進入到有細節的部分,也就是第3個C:Confirmation確認。
  3. Confirmation 確認
    此階段會建立 Acceptance Criteria (驗收標準),也就是用戶(可能是由PO代表)覺得該功能能被視為完成的必要條件,如:購買必需支援信用卡結帳。在對User Story的理解有共識上,在更近一步讓團隊對於預計要開發的功能,有了同步的認知。

透過上述 3Cs 建立的 User Story ,就可以讓團隊理解並有相同認知的情況下進入到了功能的開發,即便釋出後不如預期,團隊也可以在相同的理解下進行改善或討論。

大家都知道:團隊要合作的好,溝通很重要,而 User Story 這是促進你團隊溝通的好方法,大家可以試試用這個來建立需求並和團隊溝通。謝謝!

立即洽詢馬在飛科技,找到產品成功的秘訣。前往馬在飛科技官網

--

--

大家好,我是馬在飛的 Nat。

這篇文章我們來聊聊:不懂軟體要如何建立開發功能規格?

在軟體開發上有很多專業的名詞如: Landing page、Tab bar、CSS、HTML、API、Database 等,這些都是建構APP或網頁的必要項目,在不了解這些專有名詞的情況下,真的有辧法去建立功能規格嗎?為什麼不能由委託給的軟體外包團隊建立呢?

產品的功能最好由「你」建立。因為產品的成敗最後一定是你(公司)來承擔,而且只有你(公司)最了解這個產品要完成的工作是什麼?要解決的問題是什麼?所以我不建議你把關鍵的成敗交由他人。

不懂軟體要如何建立開發功能規格的關鍵就是:產品的使用者。產品的使用者大部分跟你一樣也是一般用戶,並不具備軟體的專業知識,但不需要有這些專業知識,他們仍然知道如何使用各種APP及網頁服務,由此可見的功能規格並不需要包含這些專業的名詞,仍然可以建立出讓他們喜歡的產品 ,那具體要如何建立功能規格呢?我們會採用的方法是: 使用者故事 User Story ,它具有一定的格式,你只要照這個格式把你的需求填入就即可。

1. 身為一個 <角色> As a <role/persona> / Who
確立使用你這個功能的角色是誰,如:你想做售票系統,就會有購票的人、賣票的人或財會等不同角色。

2. 我要 <做什麼> I want to <behavior> / What
描術這些角色想做的事或想達到的狀態,如:買到票(購票的人)、把賣票出去 (賣票的人)或能統計帳目(財會)。

3. 所以我才能 <達到什麼價值> So that <the value> / Why

這是很重要但卻常常被遺忘的部分,就是使用者為什麼要做這些事,也就是需要這個功能的原因(Why),如:(買票)才能搭車,(賣票)才能收錢,(統計帳目)才能計算營虧。有了這些原因,從原因出發去思考,你才有機會想到更好的功能或流程做法,如果你很難寫出這個User Story的Why,那很高的機會是你並沒有很好的理解用戶,或是重新思考這個User story的必要性。

把上述的其中一個例子集合起來,就會變成一個完整的User Story:

身為一個{旅客}

我要{買到車票}

所以我才能{坐上車回到家}

很簡單對吧,你現在馬上就可以試試看,但你可能還是會覺得,只有短短幾個字的描術,開發團隊就知道要做什麼了嗎? 沒有UI畫面,沒有操作流程,誰知道做出來會變成什麼樣子?這真的足夠嗎? 其實 User Story 是故意讓它自己變的簡短且模稜兩可(ambiguity) ,其原因我在下一篇會提到。

謝謝。

下集傳送門

立即洽詢馬在飛科技,找到產品成功的秘訣。前往馬在飛科技官網

--

--

Dream big. Set goal. Take action.

Hi! 大家好!我是馬在飛的 Nat。

這篇文章我們來聊聊如何制定產品目標。

馬在飛著重於透過目標導向、結果驅動(參考閱讀:Outcome-Driven) 的方式來協助客戶開發出成功的產品,所以有明確的產品目標是重要的第一步,並且會載入合約內。但每次當我們詢問客戶:你的產品目標是什麼時,客戶總是滿頭問號的看著我們!所以我們就來說明要如何有效的制定「產品目標」:

  1. 放下手上的功能需求列表,回想初心(Product Vision, User & Business Goal):
    大部分客戶總是帶著需求規格書或想模仿的產品而來,但無助於產品的成功(參考閱讀:Output vs Outcome)。請放下這些功能,回想你當初想要做這個產品的原因?是想解決什麼問題?還是看到了什麼機會?這個問題的答案就是你的「產品願景(Vision)」。然後依据這個願景,再細想一步;這個產品的用戶是誰?產品能為他帶來什麼價值?這就是「使用者目標(User goal)」。再來,想一下你要如何透過這個產品獲得收益或降低成本,這是「商業目標(Business goal)」。「使用者目標」和「商業目標」這2個目標,就是定議你產品是否成功的關鍵(參考閱讀:什麼叫成功的產品
  2. 只有1–2個月,你最希望達到什麼結果?
    產品開發週期可能會長達半年甚至一年之久,重要的事要先做。先把時間限制在1–2個月內,並列出 1–2個你預期達到結果最需要要做的事,但不用去述描如何達到,這時你就取得了第一階段「產品目標」。
  3. 為你的初步目標,收集資訊:
    如果是既有產品,可以收集和目標相關的資訊如:某功能的使用率、用戶回訪、收益等;如果是新產品,可以做 市場/競品/產業的研究,為驗証需求的初始資料,如:市佔、定價…等。
  4. 為你的產品目標可加上評分系統:
    你可以根据收集到的資訊,為目標加上可被衡量的標準,如:使用率增加5%, 如此便有明確的標準並可以再進一步判斷優劣。但注意:數字是指標,而不是目標,如果你把提升營業額 10 %當目標,會有太多可能的做法太多,甚至是投機取巧的做法,反而會增加試錯成本。比較好的產品目標與指標的案例是:舉辦抽獎活動來提升10%營業額。

最後讓我們舉個網路上的例子說明:(https://www.romanpichler.com/blog/product-goals-in-scrum/)
Product Vision: 讓人們吃個更健康
User Goal: 降低罹患二型糖尿病的風險
Business Goal: 創造新的收入來源

=>Product Goal 1: 幫助用戶了解他們的飲食習慣和業務並獲取初始用戶群

=>Product Goal 2: 幫助用戶改善他們的飲食習慣並增長用戶群10%

希望以上能協助到大家,但如果你還是不確定要如何制定你的 Product Goal, 也歡迎和我們聯絡,謝謝!

立即洽詢馬在飛科技,找到產品成功的秘訣。前往馬在飛科技官網

--

--

Hi!大家好,我是馬在飛的Nat,這篇文章我們來聊聊什麼叫成功的產品。 如何定議一個產品是成功的產品,你可會想到好多種可能,就像我問你成功的人生該要追求什麼一樣?你會覺得沒有標準答案,因為有些人追求事業,有些人追求生活,也有些人追求家庭…等等,看似沒有統一的答案,其實不然。不管是追求事業/生活/家庭,追根究底都是在追求幸福感,只是幸福感的來源各有不同罷了。回到產品其實也是一樣的,雖然不同產業有非常不同的用處,但我們可以把成功的產品定議成二個核心要素: 讓你的產品的使用者覺得好用 你(公司)有賺到錢 是的,就那麼簡單直白。難題是你覺得要如何讓用戶覺得你的產品好用?有些人認為「體驗為王」,只要產品的體驗做好了,那用戶自然覺得好用,但眾口難調,每個人的「好」都是主觀的,要如何做到呢?簡單來說:就是你要把你的產品或服務,當做是用來來協助用戶完成他的工作,例如學語言 / 訂票 / 打發時間…等。不同的產品對應不同的客戶會有不同的體驗分數,舉例來說: 如果用戶需要從台北到高雄,常見的交通選擇有:高鐵/台鐵/巴士等,高鐵是體驗最好的,但如果是學生,通常為了成本考量,反而會選擇巴士,因為綜合考量的體驗和成本,巴士對他而言是綜合分數最高(參考閱讀: Outcome-Driven)。

Hi!大家好,我是馬在飛的Nat,這篇文章我們來聊聊什麼叫成功的產品。

如何定議一個產品是成功的產品,你可會想到好多種可能,就像我問你成功的人生該要追求什麼一樣?你會覺得沒有標準答案,因為有些人追求事業,有些人追求生活,也有些人追求家庭…等等,看似沒有統一的答案,其實不然。不管是追求事業/生活/家庭,追根究底都是在追求幸福感,只是幸福感的來源各有不同罷了。回到產品其實也是一樣的,雖然不同產業有非常不同的用處,但我們可以把成功的產品定議成二個核心要素:

  1. 讓你的產品的使用者覺得好用
  2. 你(公司)有賺到錢

是的,就那麼簡單直白。難題是你覺得要如何讓用戶覺得你的產品好用?有些人認為「體驗為王」,只要產品的體驗做好了,那用戶自然覺得好用,但眾口難調,每個人的「好」都是主觀的,要如何做到呢?簡單來說:就是你要把你的產品或服務,當做是用來來協助用戶完成他的工作,例如學語言 / 訂票 / 打發時間…等。不同的產品對應不同的客戶會有不同的體驗分數,舉例來說: 如果用戶需要從台北到高雄,常見的交通選擇有:高鐵/台鐵/巴士等,高鐵是體驗最好的,但如果是學生,通常為了成本考量,反而會選擇巴士,因為綜合考量的體驗和成本,巴士對他而言是綜合分數最高(參考閱讀: Outcome-Driven)。

第二個「你(公司)有賺到錢」就更直白了,你做產品-不管直接或間接-如果沒有收益維持,你也無法讓產品持續存活。但有不少人做產品的期待是:先把產品做起來,用戶數成長到一定數量後,再考慮收益。有趣的是這類型的產品或許得到用戶的好口碑,但往往最後還是破產倒閉,因為用戶數量增加代表維持用戶的成本也升高了,很少有投資者面對這麼高的營運成本卻還沒有明確的獲利模式下,還願意投資。其實獲利模式也需要試錯,建議大家一開始就把獲利模式一併考慮進到產品設計中,即使在產品初期,用戶數不多的情況下,還能達到損益平衡,甚至收益,即便不多也代表你產品的潛力,也會讓你有更多的時間可以試錯。

謝謝大家!

立即洽詢馬在飛科技,找到產品成功的秘訣。前往馬在飛科技官網

--

--

大家好,我是馬在飛的 Nat。 這篇文章我們要來聊聊「如期/如質/如預算」產品開發就算成功了嗎? 在回答這個問題前,我們先來看看在軟體產品開發領域的實際問題: 軟體開發是一個未知性很高的產業,這基於軟體本身的複雜度高,以及社會環境的多變性,在用戶實際用到你的產品前,你無法預知用戶會又怎麼樣的反應、你的產品是否符合市場需要。甚至在產品還沒有上市前,開發就會遇到各種挑戰,最常見與最令人困擾的其中兩項: Bug:功能有錯誤,無法如預期運作,發生閃退導致無法使用。 延遲Delay:產品無法在指定的時間完成,或是因為Bug仍在處理中無法準時上線,連帶原本安排好的行銷活動也必須延遲。 以上的兩個問題,都會造成人力與時間成本的增加,甚至行銷的費用也要疊加上去,更甚者,因為這些問題,讓使用者對產品產生負面的觀感。 雖然客戶使用產品的反應無法預期,但光自身的開發流程上就有很大的進步空間了,所以大部分公司的做法是要求開發團隊,不管是內部或外部團隊,要能做到 如期、如質、如預算,而這三項其實就是對應到專案(Project)三要素:時間、範圍和預算,但卻不是產品成功的關鍵(參考閱讀:成功產品) ,也就是說對於「專案」而言,成敗取決於能不能符合預先計畫,愈符合這個專案就愈成功。

【馬在飛科技】早晚虔心禱告,保證有效:如期/如質/如預算 就是好產品?
【馬在飛科技】早晚虔心禱告,保證有效:如期/如質/如預算 就是好產品?
看完你就懂為甚麼政府標案總是產出 如期/如質/如預算「好」產品。

大家好,我是馬在飛的 Nat。

這篇文章我們要來聊聊「如期/如質/如預算」產品開發就算成功了嗎?

在回答這個問題前,我們先來看看在軟體產品開發領域的實際問題:

軟體開發是一個未知性很高的產業,這基於軟體本身的複雜度高,以及社會環境的多變性,在用戶實際用到你的產品前,你無法預知用戶會又怎麼樣的反應、你的產品是否符合市場需要。甚至在產品還沒有上市前,開發就會遇到各種挑戰,最常見與最令人困擾的其中兩項:

  • Bug:功能有錯誤,無法如預期運作,發生閃退導致無法使用。
  • 延遲Delay:產品無法在指定的時間完成,或是因為Bug仍在處理中無法準時上線,連帶原本安排好的行銷活動也必須延遲。

以上的兩個問題,都會造成人力與時間成本的增加,甚至行銷的費用也要疊加上去,更甚者,因為這些問題,讓使用者對產品產生負面的觀感。

雖然客戶使用產品的反應無法預期,但光自身的開發流程上就有很大的進步空間了,所以大部分公司的做法是要求開發團隊,不管是內部或外部團隊,要能做到 如期、如質、如預算,而這三項其實就是對應到專案(Project)三要素:時間、範圍和預算,但卻不是產品成功的關鍵(參考閱讀:成功產品) ,也就是說對於「專案」而言,成敗取決於能不能符合預先計畫,愈符合這個專案就愈成功。

你會覺得這「如期如質如預算」沒什麼問題,很合理的要求,因為如果連這個都做不到,那用戶不是連用的機會都沒有嗎?但實則不然,舉個例子吧:你有聽過蚊子館嗎?就是花很多錢蓋了,結果根本沒人用,浪費國家資源,大部分的公標案,對於政府和外包商來說,重點不在有沒有人用,重點是能否如期驗收。那今天如果是花你自己的錢!這是你想要的產品嗎?所以反過來說:如期/如質/如預算就代表產品成功嗎?相對於要「如期如質如預算」完成哪些計畫的功能,你更應該重視的其實應該是結果Outcome (參考閱讀: Output vs Outcome)。

立即洽詢馬在飛科技,找到產品成功的秘訣。前往馬在飛科技官網

--

--

是否有一個平行時空,那裡不曾有New Coke的存在?

上集傳送門

大家好,我是馬在飛的Nat。

這篇文章接續上一篇文章,創新開發在經歷了技術驅動和用戶驅動的失敗後,我們總算迎來了結果驅動(Outcome-Driven)。

首先要離清的是,這裡的 Outcome 不是指產品進入市場後的 Outcome。在精實創業Lean startup中提到的MVP(Minimum Viable Product)的概念,是用最小可行性產品來進行快速驗証,然後再根據驗證的結果, 決定是否要進行轉折(Pivot),這聽起來就很像Outcome-Driven對嗎?但此Outcome(Lean startup)非彼Outcome(Outcome-Driven)。

Outcome-Driven的Outcome指的是客戶期待的Outcome,而非概念產品的驗證結果。

客戶期待的Outcome有三個關鍵要素:

1. 「人們購買產品或服務都是為了完成工作(get-job-done)」
不管是學語言、記帳、甚至是打發時間,都可以視為一種工作(job,一種想做的事情),而產品或服務就是來協助你完成工作。由此延伸出產品體驗的另一個誤區,試想一下:如果一個產品的體驗做得很好,但你並沒有需要它來完成任何工作,你是否會花錢購買?

2. 「用戶會使用各種尺標來衡量工作完成的如何或產品的效率如何」
當客戶使用了產品或服務完成工作後,會自然的在心中評價,如:這個產品好用、這根本沒用、還不錯但有點貴等..

3. 「這些客戶的尺標讓我們有機會用系統性的方式來創造突破性的產品和服務。」

如果你能找出這些指標,就可以利用這些指標在開始開發產品前,進行產品規畫,尤其是在避免以下兩項產品規劃的誤區:不必要的功能太多(過度服務) ,而導致產品價格太高,或必要的功能並未達成(未達到服務),雖然便宜但並沒有辦法幫用戶完成工作。

讓我們舉個實際例子:

我用 output vs outcome 裡的例子繼續延申,我家裡出現老鼠,我希望消滅老鼠,所以我的選擇有:捕鼠器 / 老鼠藥 / 捕鼠大隊 ,並列出以下分析:

1. 捕鼠器:抓到後我要如何處置這個老鼠?=> 服務不足,雖然抓到了,但接下來呢?

2. 老鼠藥:我需要處置老鼠大體?=> 同上一樣服務不足。

3. 捕鼠大隊:價格太高 => 很有效但服務過度

那我發現到 捕鼠器/老鼠藥 都有服務不足的問題,在於如何處置抓到的老鼠,由此延伸出或許可以研發一種老鼠藥,讓老鼠吃完後,回到鼠窩再毒發,這樣的產品價格可以高於這兩者但低於捕鼠大隊,讓用戶有更好的選擇。

謝謝大家。

立即洽詢馬在飛科技,找到產品成功的秘訣。前往馬在飛科技官網

--

--

花費了4百萬美金開發的 新 • 可口可樂 怎麼就成了黑歷史呢?

大家好,我是馬在飛的 Nat

這篇文章我們要來聊聊什麼是 Outcome-Driven(結果驅動)。

Outcome-Driven是一種創新產品的方法, 在此之前,我們先談談創新方法的歷史:眾所周知,成功的科技創新公司(例如:Google / Facebook / Apple/AWS)帶來極大的利潤及市場價值,其展現出來的成就,讓許多公司也將創新當成新的核心,希望能複製這些巨頭的成功,但要如何發產創新呢?

一開始主要是以技術驅動(Technology-Driven),也就是一群開發者在實驗室中發明了新技術,然後才來找市場需求來套用他們的新技術。這個方式最大的問題就是:因為是刻意找出來的市場需求,開發出來的產品常常會脫離了客戶的實際需要,進而導致做出來的產品乏人問津,創新失敗率高達九成。

有人看出了技術驅動問題與盲點,因此主張既然市場仍要以用戶需求為主,那為什麼不以用戶為導向?於是第二階段用戶驅動 (Customer-Driven) 就出現了,相對映的方法也如雨後春筍般出現,如:UX / Design-Thinking / User Survey / Persona …等等,公司的核心也由技術轉向用戶為核心,但有趣的是即使做了這些改變,產品的失敗率仍高達5成-9成。

讓我們看看幾個實際用戶驅動 (Customer-Driven)的經典例子:

  • 1985 New coke : 最經典的案例就是可口可樂的New Coke,1980年可口可樂公司的市場份額遭到百事可樂追趕,可口可樂公司因此想要開發新的配方來對付。可口可樂花費了4百萬美金,找了 20萬位用戶進行訪談,但最終的產品口味卻令人失望,負評如潮,僅僅銷售79天就被下架。
  • 2006 日本麥當勞麥克沙拉:2006年日本麥當勞推出麥克沙拉這個產品,因為他們做了用戶問卷調查,發現許多人反饋:「我想吃健康沙拉。」 / 「我不吃麥當勞,因為對身體不好。」 等意見,為了滿足消費者的需求,日本麥當勞推出了麥克沙拉,相信結果你已經知道了: 根本就沒人吃,甚至遭到停售。

為什麼會這樣呢?簡單來說,就是用戶的需求沒有被正確的翻譯出來。參與New Code訪談的用戶,認真投入協助開發「新」口味可樂,但實際在店面買可口可樂時,用戶期待的喝到是「原版」的可口可樂,一但口味不一樣,他們就倍感失望。麥當勞案例則是用戶雖然嘴上裝模作樣的說要健康,但實際上還是渴望在麥當勞吃不健康但是好吃的食物,尤其是年輕人。這種口是心非是因為用戶想成為理想中的自己,但現實上仍會推持自己習慣的行為模式。

除此之外,在創新產品還有另一種常見的問題:用戶沒辦法回答他從來沒看過的東西。例如汽車大享享利福特曾說: 「如果我問人們要什麼,他們肯定告訴我要一匹更快的馬(If I had asked people what they wanted, they would have said faster horses.)。」蘋果創辦人賈伯斯也說:「人們不知道自己需要什麼,直到我們拿出產品(People don’t know what they want until they’ve seen it.) 。」透過這兩位產品大神的表述,更加的証明不要問用戶他從來沒看過的東西 。因為這個問題,所以有人干脆用採用引導式的問法,如:「如果有 xxx 你會覺得如何?」而大部份都會得到正面的回應,但實際做出來後卻仍然乏人問津。

因上述兩個用戶驅動面臨的問題,以至於後來的用戶調研方式都會特別強調不要問用戶要什麼,重點在於觀察和洞察力,這樣就解決問題了嗎?很不幸的,我必須告訴你,洞察力總是因人而異,不光只是你是否有適合觀察的個性與天賦,在觀察與解讀時,還會不自覺得帶入自己的成長、家庭背景、求學與工作經歷、社交經驗等主觀偏見。當你把用戶反饋的問題帶回來大家一起 Brain Storming時,你會發現你得到非常多想法,每個人都說得頭頭是道,但卻無法成功說服彼此,反而會增加非常大的試錯成本,畢竟這個世界上有多少像福特/賈伯斯這樣的產品大師?

但人總是不停地在尋求進步,技術驅動和用戶驅動都碰壁後,我們終於迎來了的第三個方法:Outcome-Driven(結果驅動)

下集傳送門

立即洽詢馬在飛科技,找到產品成功的秘訣。前往馬在飛科技官網

--

--

家中鼠患氾濫,你需要的是貓還是消滅老鼠?

大家好,我是馬在飛的 Nat。

這篇文章我們來聊聊 Output 和 Outcome,如果你去查英文字典,會發現Output是輸出、產出,而Outcome是結果,感覺不一樣又好像有點像,為什麼我們要特別討論這兩件事呢?

簡單來說,Output是你做了些什麼後,實際產生出來的「東西」,而Outcome是這件「東西」帶來的結果。

我先用一個例子來跟大家說明:

話說有一天,家裡出現了老鼠。我立馬想到貓抓老鼠,所以決定找一隻貓來解決老鼠的問題,雖然不期待貓真的去抓老鼠,但嚇嚇老鼠應該是沒問題的。於是我開始找收養中心、寵物店、其至問朋友 ,其中還花了不少時間去了解品種及飼養照顧的知識,經過了幾翻折騰,這段期間,老鼠快把我家床板都咬穿了,我終於找到了看起來合適的貓,我將他帶回家,並購買了各種飼養設備,如:貓砂盆、貓砂、貓食、寵物床等;在我滿心期待的牠幫我解決鼠患,然而卻發現,這隻貓居然怕老鼠!甚至自己的食物都被偷吃了,經過兩個月,老鼠不但沒消失,反而越變越變多。

在上述悲傷例子中,有三個元素:

  • 目標(goal):第一個就是我希望消滅老鼠
  • 產出(output):透過各種努力,我得到了一隻貓
  • 結果(outcome):老鼠變多了,因為這隻貓不抓老鼠,反而還怕老鼠

你會發現,雖然我目標明確,希望得到預期的Outcome(老鼠消失),但我卻放錯重點,把所有的精力放在尋找貓咪(Output )上,甚至過度投入,到糾結於貓咪的品種、毛色與飼養方法等,而忽略了這個Output能否真的達成我要的效果Outcome,在花費了很多時間和金錢,卻得到一個完全超出我預料之外的壞結果。你可能覺得這個做法沒問題:盡人事聽天命,就努力去做,但結果如何只能歸究於運氣,人生不如意之事本來就有十之八九,但,真的是這樣嗎?現在我們現在來看看另一種做法:

我的目標不變仍然是消滅老鼠,但我會先上網或找人問問有什麼方法可以快速有效的解決鼠患,我可能會得到很多不一樣的方式:老鼠藥、捕鼠夾、滅鼠大隊、堅壁清野(不要有食物,堵住老鼠的出入路線),當然可能也會得到養貓或養蛇的建議。 請注意此時上述的方法都還不算 Output,因為此時的我實際上什麼都還沒做。在希望老鼠消失的這個重點Outcome上,面對這麼多方法,我可能還會考慮到:

第一是有效性

第二個是執行的成本

找滅鼠大隊可能是最有效的方法,但可能花費的成本也比較高。綜合考慮後,我會優先選擇看起來可能有效而且成本較低的方案來試試看,可能是堅壁清野(不要有食物、堵住老鼠的出入路線),如果成功消滅老鼠,後續就不用在做什麼了,如果不行,就再挑一個方案來嘗試。這種思考並解決問題的模式就是 Outcome-Driven,如果運氣好,我會得到一個成本極低但有效的解決方案,如果不行,我會逐步升級我的解決方案直到問題被解決,這個方式是不是比第一個靠譜多了?

兩種作法的差別,只在於我把重心從關注產出(Output)移到結果(Outcome),

哈佛商學院教授西奧多•萊維特(Theodore Levitt)曾說:「人們想買的並不是1/4 英吋的鑽孔機, 而是牆上1/4 英吋的那個孔。」就是提醒大家應專注於Outcome(牆上的洞)而非Output(鑽孔機)。

現實生活中,我們也可以看到很多專注於Outcome比Output好的案例,比如:你打算創業開家店,你可能會先從網店開始試水溫,先採取預購模式,確認有市場,在開始建立庫存,達到業績後,再逐步加大資源,設立實體店…等,而不會一開始就把所有資金賭在開一間店面上,因為你真正想要達成的是靠這間店賺錢(Outcome),而不是要開一間店(Output)。聽起來很合理吧?但奇妙的是,在軟體產業仍然有九成以上的人,在開發新產品時,把資源全放在Output上,甚至過度投入,然後期待好的Outcome就會自動發生。

不相信我說的嗎?讓我們把Output這個詞換成:規格/功能模組/UI介面/使用者體驗,這樣是否更直觀了?在軟體界,我們很常看到一個產品花了好幾年、斥資百萬千萬來開發,這些資源都投入在開發功能、設計美麗和好用的介面上,但整段冗長的開發期,沒有一個人把資源放在驗證這個產品是否能達到期待的Outcome上,人們天真的認為,只要功能夠豐富、介面夠漂亮、使用者體驗夠好,產品上市後就能一砲而紅。這是真的嗎?答案是:不可能,我自己就曾看過一個很經典的案例,一間跨國的知名日本遊戲公司,斥資一千多萬想要開發一個社群互動APP,因為公司資源足夠,在開啟專案前,他們已經先投注了幾十萬進行市場和用戶調研,並經挑細選UI設計師、功能規劃人員還有開發人員,結果?花費了一千多萬,產品比預期上架延遲了一年多才上市,上市6個月後,只有不到1000人的下載量。這樣的投入產出比是否讓你相當驚訝?(我們還沒算上行銷的費用呢!),我相信,你一定不希望這個案例發生在自己身上。

當你在做產品時,首先你要知道什麼能算一個好的、成功的產品,其次,不要把資源浪費在Output上,記住,Output只是一種方法,你應該專注於Outcome,根據能有效達到Outcome來決定Output,謝謝大家!

立即洽詢馬在飛科技,找到產品成功的秘訣。前往馬在飛科技官網

--

--

大家好,我是馬在飛的飛,之前參加 Open Space — Agile & DevOps 2022 議題討論,其中我丟出了這個問題想找到答案(因為公司是走敏捷外包的,想看看市場大不大)會議結束後我也有個答案和想法(個人意見),今天來和大家分享一下。 先說結論: 台灣市場有需要但不急迫,但銀行業好一點,有比較急一點點點。 急迫來自於追趕,想像你是一間公司的老闆,沒有敏捷前公司還是一樣賺錢,那為什麼一定要導入呢?除非你的同業突然甩了你幾條街,然後過來拍拍你的臉說:老弟,哥就是用敏捷甩了你幾條街,就問你氣不氣?臉腫不腫? 這時你就會想拚了命導入,告訴你的主管們從今天起我們要敏捷,搞不定的就回家吃X,這就有急迫度了,但是~就又會是另一個問題: 舉個不恰當的比喻: 民末清初,八國聯軍就像敏捷一樣,讓中國和日本都被驚呆了,打怕了,現在兩國都有急迫度要學(打不贏你,就加入你,很正常的邏輯,沒毛病),但一個開始買槍買炮學武器(我們有檢討會,也有daily …),一個穿西裝帶手裱學文化(敏捷精神+框架),過了幾年後,差異就出來了,那中國怎麼辦?只好革命啦 ,所以說就算有了急迫度,就是另一個問題,有了錯誤的期待就會有錯誤的結果,當然如果能質變量變,量變質變,最終能活下來的終究還是好的,以上有點離題,個人意見。

台灣市場敏捷的急迫度?
台灣市場敏捷的急迫度?

大家好,我是馬在飛的飛,之前參加 Open Space — Agile & DevOps 2022 議題討論,其中我丟出了這個問題想找到答案(因為公司是走敏捷外包的,想看看市場大不大)會議結束後我也有個答案和想法(個人意見),今天來和大家分享一下。

先說結論: 台灣市場有需要但不急迫,但銀行業好一點,有比較急一點點點。

急迫來自於追趕,想像你是一間公司的老闆,沒有敏捷前公司還是一樣賺錢,那為什麼一定要導入呢?除非你的同業突然甩了你幾條街,然後過來拍拍你的臉說:老弟,哥就是用敏捷甩了你幾條街,就問你氣不氣?臉腫不腫? 這時你就會想拚了命導入,告訴你的主管們從今天起我們要敏捷,搞不定的就回家吃X,這就有急迫度了,但是~就又會是另一個問題:

舉個不恰當的比喻: 民末清初,八國聯軍就像敏捷一樣,讓中國和日本都被驚呆了,打怕了,現在兩國都有急迫度要學(打不贏你,就加入你,很正常的邏輯,沒毛病),但一個開始買槍買炮學武器(我們有檢討會,也有daily …),一個穿西裝帶手裱學文化(敏捷精神+框架),過了幾年後,差異就出來了,那中國怎麼辦?只好革命啦 ,所以說就算有了急迫度,就是另一個問題,有了錯誤的期待就會有錯誤的結果,當然如果能質變量變,量變質變,最終能活下來的終究還是好的,以上有點離題,個人意見。

--

--

Native vs. React native vs. Flutter vs. KMM 孰佳?

大家好,我是馬在飛的飛。

常有客人會問要寫 APP 要用那一種比較好,這類的問題網路上回答不少,但基本上要看你做什麼來決定,對於非技術領域的人卻無從判斷起:到底我的APP ,業務邏輯難不難?效能吃不吃重?畫面複不複雜?所以等於還是沒回答,所以我針對非技術底的客戶從商業角度來建議:

我先簡單描術一下自己的APP的經歷
(年紀大了,時間會有一些誤差,但每一種都踩過坑),

2010 iOS objectC, android java ( MVC )
2012 phoneGap / JQueryMobile / Sencha touch (html5, web)
2016 React-native (redux)
2017 Android Kotlin ( RX, MVVM, data-binding) iOS Swift (MVP, MVVM, VIPER, other design pattern )
2018 React-native (hooks)
2019 Flutter (mvvm, scoped , provider, provider,)
2020 Flutter ( bloc)

直接說結論:如果你來找我們做APP,我首推 flutter / react-native,原因很簡單: 節省時間和金錢,Time to market 愈早愈好(MVP的概念)

Q1. 那有沒有可能有 RN/Flutter 做不到的功能?有,但機率很小,如果真發生,我們有native
Q2. 那 flutter 和 rn 有沒有差別?有: 對經營者來說,很大的差在維運(找工程師來維謢)
1. 找我們外包APP後的功能新增或維運交給我們, 我們會用 flutter,效能較佳,社群支援度提升很快。
2. 如果你要自己找工程師維運可選 RN,因為產品不只APP,也會有後端甚至Web, RN 用 node-js ,可以寫 Server (express, AWS lambda, …), 也可以寫 Web (react js, vue …),在台灣 小公司/新創 要找工程師不好找,如果只有nodeJS可增加人力效率。

當然有另一種選擇是用 flutter + AWS amplify 變成偏前端的全端工程師,但這變成你的商業邏輯都集中在APP上,另一種相反做法,則讓APP只是資料呈現和操作互動,讓主要的還輯在後台;各有優缺點:(個人偏好第二種)
1. 集中在APP端,Server的負載低,費用也低,但是一但有發現bug, 改完APP重新送審,中間的等待堪稱煎熬。
2. 另一種做法就剛好相反,但Server的費用高,但如果發生問題,大部分要解決可能更新 Server 就好了。

最後身為一個APP工程師,目前 flutter 的 漲勢看好,但 react-native / react 的 Hooks 確實好用簡單;但不管那種,你都最好都要有 native 的基礎,才能應對各種問題,而 KMM, 雖然沒寫過,但能理解,在 kotlin/swift 寫習慣後再回去寫別的語言都會很懷念它們的好,但做一個產品涉及到的不光只是APP端的開發語言,還有後端及網頁,還有未來的維運。

若你有軟體開發或專案管理的需求,請點擊此並留下你的需求,我們會盡快與你聯繫

前往馬在飛科技官網

--

--

馬在飛科技

不要浪費錢買 Output(產出),你要的是 Outcom(結果)! 客製軟體要花不少錢,但你知道你買的是什麼嗎? 你以為就是 APP/網站?其實不然,你真正需要的是達成目標,目標可能是:增加收入/提高回客率/降低成本...等等,APP/網站只工具,目標才是你真正花錢買的東西。立即洽詢馬在飛科技,找到產品成功的秘訣。