隨著行動科技的興起，咖啡店現在正利用行動應用程式來提升顧客體驗。透過讓顧客能從行動裝置的便利性中下訂單、付款並獲得獎勵，咖啡店正在徹底改變顧客與品牌互動的方式。在本文中，我們將探討行動應用程式如何改變咖啡店產業，以及它們為企業和顧客帶來的優勢。
使用使用者故事的敏捷開發流程
捕捉需求和識別使用者故事的流程包含幾個步驟：
- 問題陳述：識別IT系統旨在解決或改善的問題，例如提升客戶服務或庫存管理。
- 利害關係人訪談：與利害關係人（例如收銀員、咖啡師、經理和顧客）進行訪談，以收集他們對IT系統的需求與期望的意見和反饋。
- 腦力激盪與優先排序：根據利害關係人的意見，腦力激盪出IT系統的潛在功能或需求清單。使用如MoSCoW（必須有、應該有、可以有、不會有）等框架對這些功能進行優先排序。
- 使用者故事的建立：針對每一項已優先排序的功能，建立一個使用者故事，描述使用者對IT系統所期望的功能或行為。
- 精煉：審查並精煉使用者故事，以確保其清晰、簡明且聚焦於使用者的需求。
識別使用者故事並加以優先排序具有多項好處。首先，這有助於確保IT系統在設計與開發時以使用者的需求與目標為核心。這可以提高使用者的接受率並提升顧客滿意度。其次，優先排序使用者故事能幫助開發團隊首先專注於最重要且最有價值的功能，從而加快開發進程，並降低延遲或成本超支的風險。最後，優先排序讓利害關係人能根據功能對企業與使用者的影響，做出明智的決策。
總體而言，識別並優先排序使用者故事是敏捷開發流程中不可或缺的一步。它有助於確保IT系統符合使用者與企業的需求，並促進更高效且有效的開發。
問題描述
這家咖啡店已經使用銷售點（POS）系統好幾年了，但最近開始出現問題。系統運作緩慢且反應遲鈍，導致排隊時間長，顧客感到不滿。員工也難以操作系統，因為系統經常卡頓或當機，導致訂單錯誤與銷售損失。
更糟糕的是，咖啡店最近擴張並開設了第二家門店。新門店的POS系統與原門店完全不同，導致顧客與員工都感到困惑並產生延遲。同時，也沒有簡單的方法來追蹤兩家門店的庫存與銷售情況，使得供應管理與未來發展規劃變得困難。
咖啡店老闆擔心這些問題對業務造成的影響。顧客不斷抱怨，有些人甚至選擇前往競爭對手。老闆知道必須改善IT系統以確保業務順利運作，但他不知道該從何著手，也不清楚該如何找到適合兩家門店的解決方案。
如何從需求中識別使用者故事
要從問題描述或利害關係人中識別使用者故事，可以遵循以下步驟：
- 首先，理解問題或利害關係人的需求。他們面臨的主要問題是什麼？他們希望IT系統完成什麼目標？
- 識別將與IT系統互動的主要使用者或人物角色。這將幫助你確定系統所需的具體功能與特性。
- 與利害關係人合作，將問題或需求分解為更小的組成部分。提出問題，例如「使用者需要完成哪些具體任務？」或「使用者需要存取哪些資訊？」
- 將每個組成部分以簡潔明確的格式寫成使用者故事，使用「作為[使用者]，我想要[目標]，以便[原因]」的結構。例如：「作為一位顧客，我希望能線上訂購，以便跳過排隊並節省時間。」
- 根據使用者故事對利害關係人的價值及其對系統的影響來進行優先排序。這將幫助你決定哪些使用者故事應首先實施。
透過遵循這些步驟，你可以識別出準確反映利害關係人需求與目標的使用者故事，並能以敏捷且有效的方式引導IT系統的開發。
識別使用者故事
以下是咖啡店IT系統的一些使用者故事：
- 作為收銀員，我希望POS系統快速且反應靈敏，以便能迅速處理訂單並服務顧客，避免長時間等待。
- 作為經理，我希望能夠即時追蹤庫存水準，以便在庫存耗盡前補貨，避免缺貨。
- 作為咖啡師，我希望POS系統直覺且易於使用，以便能準確輸入飲料訂單，避免錯誤。
- 作為顧客，我希望能夠使用手機下訂單並付款，以便避免排長隊並節省時間。
- 作為經理，我希望能夠產生銷售報表並追蹤兩家門店的營收，以便識別趨勢並做出明智的商業決策。
- 作為收銀員，我希望POS系統能夠處理包含多種自定義的複雜訂單，以便我能準確輸入客戶的需求。
- 作為顧客，我希望能夠透過咖啡店的行動應用程式累積忠誠度點數並兌換獎勵，以便獲得折扣和免費商品。
- 作為經理，我希望IT系統具備可擴展性，以便我們能輕鬆新增營業據點並擴展業務，而無需完全重構系統。
- 作為咖啡師，我希望能夠透過POS系統查看詳細的飲品配方與製作說明，以便能一致且符合顧客要求地製作飲品。
- 作為顧客，我希望能夠查看菜單並了解每項產品的營養資訊，以便做出明智的點餐選擇。
如何優先處理使用者故事清單
要優先處理使用者故事清單，可以使用稱為「MoSCoW優先順序」的技巧。這包括將每個使用者故事歸類為四個類別之一：必須擁有、應該擁有、可以擁有，以及不會擁有。
以下是各類別的簡要說明：
- 必須擁有： 這些是系統運作所必需實現的關鍵使用者故事。它們代表核心功能，無法延後或從專案範圍中移除。
- 應該擁有： 這些是重要的使用者故事，應納入系統中，但並非系統運作所必需。若必要時可延後或移除，但僅限對專案影響極小的情況。
- 可以擁有： 這些是理想但非系統成功所必需的使用者故事。即使延後或移除，也不會對專案造成重大影響。
- 不會擁有： 這些是不在當前專案範圍內，或因其他原因被降級優先順序的使用者故事。未來專案中可能重新考慮，但不會納入當前迭代。
使用MoSCoW優先順序來優先處理使用者故事清單，可以：
- 審查每個使用者故事，根據其重要性與對系統的影響，將其歸類至四個類別之一（必須擁有、應該擁有、可以擁有或不會擁有）。
- 確保所有利害關係人已同意優先順序，並理解各類別背後的邏輯。
- 首先專注於實現必須擁有的使用者故事，接著是應該擁有的故事。若時間與資源允許，可考慮可以擁有的故事，而不會擁有的故事則可完全從專案中移除。
透過使用MoSCoW優先順序，可確保最關鍵的使用者故事首先獲得處理，同時根據專案時程與資源提供彈性與調整空間。
範例
以下是一張使用MoSCoW優先順序方法對使用者故事進行優先排序的表格：
| 使用者故事 | 規模 | 優先順序 | 簡要描述 | 價值 |
|---|---|---|---|---|
| 1 | 中等 | 必備 | 快速且響應迅速的收銀機系統 | 透過減少等待時間來提升客戶服務 |
| 2 | 大型 | 必備 | 即時庫存追蹤功能，供管理人員使用 | 防止缺貨並改善庫存管理 |
| 3 | 小型 | 應該具備 | 直覺式收銀機系統，適合咖啡師使用 | 減少錯誤並提升訂單準確性 |
| 4 | 中型 | 可考慮具備 | 客戶手機訂購與付款功能 | 提升客戶便利性與滿意度 |
| 5 | 大型 | 應該具備 | 銷售報表與收益追蹤功能，供管理人員使用 | 有助於識別趨勢並做出明智的商業決策 |
| 6 | 小型 | 可考慮具備 | 能處理複雜訂單的收銀機系統 | 提升訂單準確性與客戶滿意度 |
| 7 | 中型 | 可以擁有 | 客戶的行動忠誠度積分與回饋 | 提升客戶忠誠度與重複消費 |
| 8 | 大型 | 不會擁有 | 資訊系統的可擴展性 | 目前並非業務所需 |
| 9 | 小型 | 不會擁有 | 給咖啡師的詳細飲品配方與製作說明 | 並非目前業務運作的關鍵需求 |
| 10 | 小型 | 不會擁有 | 提供給客戶的菜單與營養資訊 | 並非目前業務運作的關鍵需求 |
請注意，優先順序可能根據咖啡店的具體需求與目標而有所不同。
詳細說明使用者故事
使用者故事： 作為一位顧客，我希望能夠透過咖啡店的行動應用程式下訂單，以便避免排長隊與等待時間。
1. 定義範圍： 此使用者故事的範圍是讓顧客能夠透過咖啡店的行動應用程式下訂單，目標是減少等待時間並提升顧客體驗。應用程式應允許顧客瀏覽菜單、選擇項目、自訂訂單，並支付購買金額。
2. 分解任務：
- 開發客戶用的行動應用程式介面
- 將行動應用程式與咖啡店的收銀系統整合
- 在應用程式中實作菜單瀏覽功能
- 在應用程式中實作訂單自訂功能
- 在應用程式中實作付款功能
- 徹底測試應用程式，以確保其功能性和可用性
3. 評估工作量：
- 開發客戶用的行動應用程式介面：2天
- 將行動應用程式與咖啡店的POS系統整合：3天
- 在應用程式中實現菜單瀏覽功能：1天
- 在應用程式中實現訂單自訂功能：2天
- 在應用程式中實現支付功能：3天
- 徹底測試應用程式，以確保其功能性和可用性：5天
4. 分配角色與職責：
- UI/UX設計師：開發客戶用的行動應用程式介面
- 前端開發人員：在應用程式中實現菜單瀏覽與訂單自訂功能
- 後端開發人員：將行動應用程式與咖啡店的POS系統整合，並在應用程式中實現支付功能
- 品質保證工程師：徹底測試應用程式，以確保其功能性和可用性
5. 制定計畫：
- 第1週：開發客戶用的行動應用程式介面，在應用程式中實現菜單瀏覽功能
- 第2週：將行動應用程式與咖啡店的POS系統整合，在應用程式中實現訂單自訂功能
- 第3週：在應用程式中實現支付功能，徹底測試應用程式
- 第4週：完成測試並推出行動應用程式
6. 檢視進度：團隊將舉行每日站會，檢視進度，識別任何問題或障礙，並根據需要進行調整。每週結束時，團隊將舉行回顧會議，反思已取得的進展，評估計畫的有效性，並進行必要的調整，以確保使用者故事的成功完成。
根據逐步指南制定實施計畫
以下是根據第一個使用者故事所制定的實施計畫表：
| 任務 | 描述 | 負責人 | 預估工作量 | 開始日期 | 結束日期 |
|---|---|---|---|---|---|
| 開發行動應用程式介面 | 設計並開發客戶用的行動應用程式介面 | UI/UX 設計師 | 2 天 | 第 1 週，第 1 天 | 第 1 週，第 2 天 |
| 實現菜單瀏覽功能 | 在應用程式中實現一個功能，讓客戶可以瀏覽菜單 | 前端開發人員 | 1 天 | 第 1 週，第 3 天 | 第 1 週，第 3 天 |
| 將行動應用程式與 POS 系統整合 | 將行動應用程式與咖啡店的 POS 系統連接 | 後端開發人員 | 3 天 | 第 2 週，第 1 天 | 第 2 週，第 3 天 |
| 實現訂單自訂功能 | 在應用程式中實現一個功能，讓客戶可以自訂訂單 | 前端開發人員 | 2 天 | 第 2 週，第 4 天 | 第 2 週，第 5 天 |
| 實現付款功能 | 在應用程式中實現一個功能，讓客戶可以支付訂單 | 後端開發人員 | 3 天 | 第 3 週，第 1 天 | 第 3 週，第 3 天 |
| 測試應用程式功能與易用性 | 對應用程式進行全面測試，以確保其按預期運作且使用者友善 | 品質保證工程師 | 5天 | 第三週，第四天 | 第四週，第二天 |
| 完成測試並發布 | 完成測試，解決發現的任何問題，並發布行動應用程式 | 團隊 | – | 第四週，第三天 | 第四週，第五天 |
注意：開始和結束日期僅為範例，可根據團隊的具體時間表和可用性進行調整。
摘要
本文概述了敏捷開發流程，特別著重於捕捉需求和識別使用者故事的重要性。文章說明了識別使用者故事所涉及的步驟，包括問題陳述、利害關係人訪談、腦力激盪、優先順序排序以及使用者故事的建立。
此外，本文強調識別和優先排序使用者故事的好處，例如提升使用者採用率和滿意度、加快開發進度，並就應實作哪些功能做出明智決策。總體而言，本文強調在敏捷開發中，以使用者為中心的設計與優先排序的重要性，以確保取得成功成果。