Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Honey's Data Dinner#13 跨領域專案開發經驗談(User Story Mapping)

252 views

Published on

【跨領域專案開發經驗談-User Story Mapping】
講者:彭聲揚
主辦單位:蜂巢數據 (Beehive Data Group)

採團隊模式執行專案開發時,常是不同領域的專家們與前後端不同屬性的工程師一同作業,如何溝通、攜手合作來創造最大產值?本次研討會將以實際經驗與心得來作分享,與大家共同探討,使用者故事對照(User Story Mapping)應如何導入軟體專案開發流程中?期能用最好的方式打開跨領域之間的對話。

Published in: Leadership & Management
  • Be the first to comment

Honey's Data Dinner#13 跨領域專案開發經驗談(User Story Mapping)

  1. 1. Who am I Orange 設計師、軟體工程師、產品體驗
  2. 2. Chapter 3:Plan to Learn Faster Chapter 4:Plan to Finish on Time
  3. 3. Chapter 3:Plan to Learn Faster ● Start by Discussing Your Opportunity ● Validate Problem ● Prototype to Learn ● Watch Out for What People Say They Want ● Build to Learn ● Iterate Until Viable ● How to Do It the Wrong Way ● Validated Learning ● Really Minimize Your Experiments
  4. 4. 產品負責人的工作 繼承某人的想法 設法讓他成功 或是證明他不可行 幫助團隊承攬一切責任
  5. 5. Start by Discussing Your Opportunity ● Big idea? ● Who are the Customers? User? ● Why would they want this? ● Why are we building it?
  6. 6. Validate Problem 訪談 建立客戶開發夥伴 ( customer development partner ) Early Adopter
  7. 7. Prototype to Learn 使用者劇本 User Scenarios 線框圖 wireframe sketch 原型 prototype Powerpoint , Axure, illustrator 為的是充分溝通,具象化解決方案 反覆調整,與客戶找到最佳方案 降低風險
  8. 8. https://uxdesign.cc/the-best-prototyping-tools-8d7dc5c8ee27#.osdmt3h1n
  9. 9. Watch Out for What People Say They Want 一開始少做一點?為什麼 ● 餐廳的經驗 ● 腦波弱,什麼都想要 ● 堆在倉庫裡一堆沒用的東西
  10. 10. Build to Learn Less than minimal 比最小還要少 僅足以讓使用者裡用它做「某種有用的事情」就好 不會留下深刻印象,也無法行銷 針對「潛在使用者」,真心找到解決方案 透過使用者(early adopter),提早協助修正原始的想法與原型
  11. 11. Iterate Until Viable 每次增加一點東西 開發夥伴 -> 客戶 原型 -> 產品 風險 -> 更少的風險
  12. 12. How to Do It the Wrong Way
  13. 13. Validated Learning
  14. 14. 持續釋出最小的可行產品 瞭解客戶眼中的可行產品與需求 最小可行產品的實驗 (minimum viable product experiment) 產品發掘 (product discovery) 了解是否正在建造「正確的東西」
  15. 15. Really Minimize Your Experiments Target : ● Learning ● minimize build ● 一開始不可能就緒,如果是的話就做太多了 ● 保持彈性
  16. 16. Chapter 4:Plan to Finish on Time 在多次反覆的原型建造後 開始估計你建造產品的時間 最好的估計,來自於真正理解的開發者 你足夠瞭解產品到底在做什麼嗎?(經驗與溝通,共識)
  17. 17. Plan tio Build Piece by Piece 把目標分段,切割 三分割:部分功能、強化功能、完整的細節(以及預想可能的功能)
  18. 18. 分割的概念,不是釋出給客戶用的,而是給開發團隊用的 越常量測,量測的越精準(經驗) 管理預算(或工時)
  19. 19. 反覆與漸增 重複做一樣的事情 提醒自己追加新的,或是強化既有的成果 就像畫畫一樣,越畫越具體
  20. 20. Opening game 僅建造足以看清楚頭尾運作的基本事項 Midgame 實作商業規則,測試,擴展性,持續測試 Endgame 準備釋出,吸引力,行銷,更好的效率
  21. 21. 考慮風險 驗證可行與不可行 執行成本 了解用戶需求(透過prototype) 最小化開發建造

×