項目背景
產品名稱:LearnFlow(在線學習平臺)
核心目標:6個月內上線MVP(最小可行產品),支持課程學習、進度跟蹤、測驗功能。
團隊構成:
-
產品負責人(PO)1人
-
Scrum Master 1人
-
開發團隊(全棧工程師、UI設計師、測試工程師)6人
-
關鍵利益相關者:教育機構客戶、終端教師/學生用戶
需求管理全流程
1. 需求收集與初始列表構建
-
PO行動:
-
訪談10家教育機構、50名潛在用戶,提煉核心痛點(如“無法跟蹤學習進度”、“缺少互動練習”)。
-
與市場團隊分析競品,確定差異化需求(如“AI學習建議”)。
-
-
產出物:
-
初始產品待辦列表(Product Backlog),包含粗粒度需求:
- [高優先級] 用戶登錄/注冊 - [高] 課程視頻播放(支持進度保存) - [中] 章節測驗功能(選擇題/判斷題) - [低] 學習數據報告(圖表展示) - ...(共30+項)
-
2. 需求細化與用戶故事拆分
-
梳理會議(Backlog Refinement):
-
PO主導:每兩周召開1次,團隊共同參與。
-
關鍵活動:
-
拆分大需求:例如“課程視頻播放”拆分為:
- 作為一個學員,我希望播放視頻時可暫停/繼續,以便靈活學習。 - 作為一個學員,我希望退出后再次進入時自動定位到上次進度,避免重復觀看。 - 作為一個學員,我希望看到視頻總時長和當前進度條,方便掌控時間。
-
定義驗收標準:
示例故事:視頻進度保存 - 驗收標準1:用戶播放視頻至5分鐘時退出,重新進入后應從5分鐘處開始播放。 - 驗收標準2:進度數據實時同步至服務器,網絡中斷時本地緩存。
-
估算故事點:團隊使用斐波那契數列(1,2,3,5,8)估算工作量。
-
-
3. 動態優先級排序
-
PO決策依據:
因素 案例應用 用戶反饋 早期用戶測試顯示“測驗功能”比“數據報告”更迫切 業務價值 教育機構愿為“自動組卷”付費 → 優先級提升 依賴關系 必須先完成“用戶系統”才能開發“學習記錄” 風險 第三方支付接口集成風險高 → 提前驗證 -
結果:
-
原低優先級的“測驗功能”因用戶反饋升至頂部。
-
“AI學習建議”因技術不確定性暫移至后期迭代。
-
4. 迭代規劃與執行(Sprint 2示例)
-
Sprint目標:實現核心學習流程閉環(播放→測驗→記錄進度)。
-
計劃會議(Sprint Planning):
-
PO從待辦列表頂部選取5個故事(總故事點≈20,團隊產能上限)。
-
團隊澄清細節:
-
針對“章節測驗”,確認題型支持單選/多選,暫不開放主觀題。
-
定義“完成”標準:通過測試覆蓋率≥80%。
-
-
-
迭代執行:
-
每日站會:開發反饋“進度保存”的瀏覽器兼容性問題,PO立即參與解決方案討論。
-
持續驗收:PO每天驗證完成的故事,發現“進度條UI不清晰”→ 設計師當天調整。
-
5. 評審與反饋驅動需求變更
-
Sprint評審會議(Demo):
-
團隊向教育機構客戶展示:
-
視頻播放+進度保存功能 →?客戶認可
-
測驗功能 →?新需求:“希望增加錯題自動收藏功能”
-
-
-
PO行動:
-
將“錯題收藏”作為新故事加入待辦列表。
-
根據客戶反饋,將原計劃Sprint 4的“學習報告”降級(因測驗功能需優先完善)。
-
6. 需求演進與規模化
-
第4個月關鍵事件:
-
競品上線“直播課”功能 → 教育機構要求緊急響應。
-
PO應對:
-
召開需求工作坊,拆分“直播課”為獨立模塊(創建房間、實時互動、回放生成)。
-
與客戶重新談判:延遲“數據報告”交付,換取直播功能提前上線。
-
-
-
待辦列表變化:
**原計劃**: Sprint 5:學習報告 → Sprint 6:證書生成 **調整后**: Sprint 5:直播基礎功能 → Sprint 6:直播互動優化
需求管理工具與協作
工具 | 用途 | 案例場景 |
---|---|---|
Jira | 管理待辦列表、跟蹤故事狀態 | 實時拖拽故事到不同Sprint,優先級可視化 |
Confluence | 存儲用戶訪談記錄、驗收標準 | 鏈接故事到詳細客戶需求文檔 |
Miro | 在線梳理會議(故事拆分/優先級矩陣) | PO用Kano模型分析功能價值 |
成果與敏捷需求管理價值
-
6個月交付MVP:上線核心功能(學習+測驗+直播),客戶付費轉化率超預期30%。
-
應對變化能力:
-
累計調整待辦列表優先級12次,新增需求17項,淘汰過時需求8項。
-
直播功能從需求提出到上線僅用5周(傳統模式預估3個月)。
-
-
用戶價值聚焦:通過每2周一次的用戶測試,核心功能NPS(凈推薦值)達72分。
關鍵經驗總結
-
PO的核心作用:
-
必須深度理解業務與用戶,果斷決策優先級(如為直播功能延遲報告)。
-
主動管理利益相關者期望(教育機構的需求沖突)。
-
-
需求漸進明細:
-
早期故事如“學習報告”僅需目標描述,細化延至“最后責任時刻”(避免過度設計)。
-
-
反饋即燃料:
-
客戶在評審會提出的“錯題收藏”直接轉化為高價值需求。
-
-
工具服務于協作:
-
Jira看板確保透明度,但核心依賴PO-團隊的日常對話。
-
🔍?敏捷需求管理的本質:不是“凍結需求”,而是通過持續反饋循環(構建→測量→學習)讓需求與市場真實價值對齊。此案例中,待辦列表如同“活地圖”,團隊循著價值坐標動態調整路徑,最終穿越不確定性交付成功產品。