【馬在飛科技】不是軟體專業,如何建立開發功能規格? User Story(下)

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

【馬在飛科技】錢不是萬能,沒有錢卻萬萬不能:成功的產品

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

台灣市場敏捷的急迫度?

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

台灣市場敏捷的急迫度?
台灣市場敏捷的急迫度?
馬在飛科技

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