大家好，我是馬在飛的 Nat。 這篇文章我們來聊聊：不懂軟體要如何建立開發功能規格？ 在軟體開發上有很多專業的名詞如： Landing page、Tab bar、CSS、HTML、API、Database 等，這些都是建構APP或網頁的必要項目，在不了解這些專有名詞的情況下，真的有辧法去建立功能規格嗎？為什麼不能由委託給的軟體外包團隊建立呢？ 產品的功能最好由「你」建立。因為產品的成敗最後一定是你（公司）來承擔，而且只有你（公司）最了解這個產品要完成的工作是什麼？要解決的問題是什麼？所以我不建議你把關鍵的成敗交由他人。 不懂軟體要如何建立開發功能規格的關鍵就是：產品的使用者。產品的使用者大部分跟你一樣也是一般用戶，並不具備軟體的專業知識，但不需要有這些專業知識，他們仍然知道如何使用各種APP及網頁服務，由此可見的功能規格並不需要包含這些專業的名詞，仍然可以建立出讓他們喜歡的產品 ，那具體要如何建立功能規格呢？我們會採用的方法是： 使用者故事 User Story ，它具有一定的格式，你只要照這個格式把你的需求填入就即可。

Hi! 大家好!我是馬在飛的 Nat。 這篇文章我們來聊聊如何制定產品目標。 馬在飛著重於透過目標導向、結果驅動（參考閱讀：Outcome-Driven) 的方式來協助客戶開發出成功的產品，所以有明確的產品目標是重要的第一步，並且會載入合約內。但每次當我們詢問客戶：你的產品目標是什麼時，客戶總是滿頭問號的看著我們！所以我們就來說明要如何有效的制定「產品目標」： 放下手上的功能需求列表，回想初心(Product Vision, User & Business Goal)： 大部分客戶總是帶著需求規格書或想模仿的產品而來，但無助於產品的成功（參考閱讀：Output vs Outcome)。請放下這些功能，回想你當初想要做這個產品的原因？是想解決什麼問題？還是看到了什麼機會？這個問題的答案就是你的「產品願景(Vision)」。然後依据這個願景，再細想一步；這個產品的用戶是誰？產品能為他帶來什麼價值？這就是「使用者目標（User goal)」。再來，想一下你要如何透過這個產品獲得收益或降低成本，這是「商業目標(Business goal)」。「使用者目標」和「商業目標」這2個目標，就是定議你產品是否成功的關鍵（參考閱讀：什麼叫成功的產品）

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

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

上集傳送門 大家好，我是馬在飛的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，一種想做的事情)，而產品或服務就是來協助你完成工作。由此延伸出產品體驗的另一個誤區，試想一下：如果一個產品的體驗做得很好，但你並沒有需要它來完成任何工作，你是否會花錢購買？

大家好，我是馬在飛的 Nat 這篇文章我們要來聊聊什麼是 Outcome-Driven（結果驅動）。 Outcome-Driven是一種創新產品的方法， 在此之前，我們先談談創新方法的歷史：眾所周知，成功的科技創新公司（例如：Google / Facebook / Apple/AWS)帶來極大的利潤及市場價值，其展現出來的成就，讓許多公司也將創新當成新的核心，希望能複製這些巨頭的成功，但要如何發產創新呢？ 一開始主要是以技術驅動（Technology-Driven），也就是一群開發者在實驗室中發明了新技術，然後才來找市場需求來套用他們的新技術。這個方式最大的問題就是：因為是刻意找出來的市場需求，開發出來的產品常常會脫離了客戶的實際需要，進而導致做出來的產品乏人問津，創新失敗率高達九成。 有人看出了技術驅動問題與盲點，因此主張既然市場仍要以用戶需求為主，那為什麼不以用戶為導向？於是第二階段用戶驅動 （Customer-Driven） 就出現了，相對映的方法也如雨後春筍般出現，如：UX / Design-Thinking / User Survey / Persona …等等，公司的核心也由技術轉向用戶為核心，但有趣的是即使做了這些改變，產品的失敗率仍高達5成-9成。

大家好，我是馬在飛的 Nat。 這篇文章我們來聊聊 Output 和 Outcome，如果你去查英文字典，會發現Output是輸出、產出，而Outcome是結果，感覺不一樣又好像有點像，為什麼我們要特別討論這兩件事呢？ 簡單來說，Output是你做了些什麼後，實際產生出來的「東西」，而Outcome是這件「東西」帶來的結果。 我先用一個例子來跟大家說明： 話說有一天，家裡出現了老鼠。我立馬想到貓抓老鼠，所以決定找一隻貓來解決老鼠的問題，雖然不期待貓真的去抓老鼠，但嚇嚇老鼠應該是沒問題的。於是我開始找收養中心、寵物店、其至問朋友 ，其中還花了不少時間去了解品種及飼養照顧的知識，經過了幾翻折騰，這段期間，老鼠快把我家床板都咬穿了，我終於找到了看起來合適的貓，我將他帶回家，並購買了各種飼養設備，如：貓砂盆、貓砂、貓食、寵物床等；在我滿心期待的牠幫我解決鼠患，然而卻發現，這隻貓居然怕老鼠！甚至自己的食物都被偷吃了，經過兩個月，老鼠不但沒消失，反而越變越變多。

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

大家好，我是馬在飛的飛。 常有客人會問要寫 APP 要用那一種比較好，這類的問題網路上回答不少，但基本上要看你做什麼來決定，對於非技術領域的人卻無從判斷起：到底我的APP ，業務邏輯難不難？效能吃不吃重？畫面複不複雜？所以等於還是沒回答，所以我針對非技術底的客戶從商業角度來建議： 我先簡單描術一下自己的APP的經歷 (年紀大了，時間會有一些誤差，但每一種都 …