互聯網產品研發中,用戶故事怎么用?
一款產品,如果你的用戶距離你相對較遠、也抽象,比如你們隔著手機、電腦屏幕,或者國家,甚至于只是因為你所處的并非直接接觸用戶/市場的部門,那么用戶故事都會是得力助手。但怎么用?是什么?是必須搞明白的?!??2023年8月
PART 1 被打斷的抓狂午休
大中午被樓上一群討論吵醒(我在工位上午休,閣樓上幾個成員肆無忌憚的大聲嚷嚷ing),在糾結:
“用戶故事是什么?”
“用戶故事一定要能獨立上線?”
“怎么對齊產品、項目、研發、測試多方需求理解?”
無聊而深刻又簡單的疑問,你能想到這是哪些角色在討論?項目pm、開發leader、研發管理者。(內心os:能不能自己去思考一下,學習一下??!能不能來一個敏捷思想的實踐者?。。?/p>
1、用戶故事是什么?
這部分請看下面 PART 2 詳解。
2、用戶故事一定要能獨立上線嗎?
先請參照用戶故事的定義和意義。然后再回來說,用戶故事不一定要能獨立上線,用戶故事可能歸屬于史詩故事,史詩故事一定是可以獨立上線的,但是用戶故事不一定。用戶故事打散,它會對應用戶的一個完整的行為,故事是讓產品研發協作鏈路對標,顆粒度在于用戶的任務流。
3、怎么對齊產品、項目、研發、測試多方需求理解?
一句話,高質量的交付,一定是為了用戶價值,滿足用戶的交易行為。著眼腳下,心懷遠方。
PART 2 用戶故事是什么?干什么?
時間、地點、人物、事件,有用戶、有場景、有行為、有時機,背后當然也有情緒價值。
團隊最近嘗試改版以前的需求卡片,調整為用戶故事卡片,這件事情對誰最好,當然是開發、技術、測試(不接受反駁)。
史詩故事>>用戶故事>>任務>>里程碑,是不同維度和對象的拆解實現路徑。產品經理關注商業價值、用戶需求、產品架構、產品路線,拆分出來故事點,開發、測試同樣需要對齊故事背景,共同目標是:對用戶的交付目標,而不是程序、測試的實現目標,更準確的說是共同的商業目標。
用戶故事的視角,便于研發團隊成員對齊目標(大目標路上的小節點),找到方向感,共同推動總目標的達成,有點像飛書中可視的中心okr。
任務是開發基于用戶故事背景拆解的實現路徑,是程序的建構和解構動作。任務的顆粒度對應不同的開發者、工作量、起止時間,任務決定了整個項目研發的進度計劃、工作間的邏輯關系、資源計劃等。
開發關心用戶故事,不只是開發leader關心用戶故事,每個任務的開發者也需要關心當前任務服務于哪個用戶故事。這個邏輯可以對標產品維度的用戶畫像。
當然,故事是故事、任務是任務、發布是發布,故事線是用戶視角、任務線是代碼實現視角、發布線是系統版本管理/代碼分支管理雙重視角。任務從故事里面長出來,故事進入版本,任務進入發布范圍。
產品、開發、測試都關心用戶故事,目的是在相同的方向上分別結合自己的專業視角拆解,建立實現路徑、排除異常,最終滿足用戶交易價值。
本文由 @Kris_3zzz 原創發布于人人都是產品經理。未經作者許可,禁止轉載
題圖來自 Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務
- 目前還沒評論,等你發揮!