top of page
  • 作家相片馬在飛科技

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


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):


Card 卡片

有個故事:當創業家想要找投資時,其中一位知名的投資人會要求創業家在他的名片後面寫上他的想法,等這位投資人回家後,他會找出他覺得有興趣的想法,然後再依据名片上的資訊連絡他們。而 Card 的核心也是如此,不需要詳細內容,重點在吸引或價值(所以有提到 So that/Why 很重要),其目標就是引導第2個C:Conversation 對話的發生。

Conversation 對話

透過與團隊的對話,包括:質疑、問答及討論,讓團隊能徹底理解功能對用戶帶來的價值。確認團隊都擁有共同的理解後,才會進入到有細節的部分,也就是第3個C:Confirmation確認。

Confirmation 確認

此階段會建立 Acceptance Criteria (驗收標準),也就是用戶(可能是由PO代表)覺得該功能能被視為完成的必要條件,如:購買必需支援信用卡結帳。在對User Story的理解有共識上,在更近一步讓團隊對於預計要開發的功能,有了同步的認知。

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


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


------------

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

你也可以在Medium上看到馬在飛的文章喔!前往Medium

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

大家好,我是馬在飛的 Nat。 這篇文章我們來聊聊:不懂軟體要如何建立開發功能規格? 在軟體開發上有很多專業的名詞如: Landing page、Tab bar、CSS、HTML、API、Database 等,這些都是建構APP或網頁的必要項目,在不了解這些專有名詞的情況下,真的有辧法去建立功能規格嗎?為什麼不能由委託給的軟體外包團隊建立呢? 產品的功能最好由「你」建立。因為產品的成敗最後一定是你

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

Hi!大家好,我是馬在飛的Nat,這篇文章我們來聊聊什麼叫成功的產品。 如何定議一個產品是成功的產品,你可會想到好多種可能,就像我問你成功的人生該要追求什麼一樣?你會覺得沒有標準答案,因為有些人追求事業,有些人追求生活,也有些人追求家庭…等等,看似沒有統一的答案,其實不然。不管是追求事業/生活/家庭,追根究底都是在追求幸福感,只是幸福感的來源各有不同罷了。回到產品其實也是一樣的,雖然不同產業有非常

Comments


bottom of page