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