大拿說：從需求到上線實戰-使用者故事地圖階段

這幾年對領域驅動開發(DDD)特別痴迷, 結合我之前在看板方面的豐富實戰經驗和對<使用者故事地圖>, <微服務架構設計模式>, <實現領域驅動設計>等相關書籍的熟練掌握和運用, 自認可以寫這篇文章講講我自己的技術方法.

最近我的寫作線會圍繞研發團隊的工作方法論和基於工作實踐對於高併發高讀寫實戰方面, 工作方法論我會爭取日更, 技術實戰我會爭取3天一篇的節奏, 希望大家多多關注.

經常聽到一些做朋友的朋友說產品的需求多麼奇葩, 進度安排多麼不合理, 在大概5年以前, 我是非常認可這些朋友的說法的, 現在我跟朋友討論這些事情的時候, 我回復這些朋友的第一句話是: "其實你的方法不對."

為什麼不對呢? 因為本來你讓產品以技術的視野規劃產品的表現細節就是很不靠譜的事情, 當然很多產品的工作能力實際上也是不足, 但是技術和產品既然是一種合作關係,那怎麼樣才能讓工作更快更好地完成呢? 我來說下我的方法.

大致先說下我帶領的研發團隊的整體流程吧,大家可以看下面的腦圖

研發流程

在我看來, 研發流程分為如下階段:

使用者故事階段
頭腦風暴階段
技術預研階段
開發階段
整合測試階段
驗收測試階段
準上線階段/藍綠環境階段
正式上線階段

上面的流程並不是瀑布法, 而是指一個完整的需求從需求到上線階段應該走過的流程, 而且是作為具有責任心的研發人員必不可少要遵循的流程.

今天介紹下我在使用者故事階段的實踐經驗

研發流程階段1:使用者故事階段

我首先是跟產品經理就墨刀原型進行一番大致的討論, 我的問法是你這個功能的目的是什麼呢? 誰來用它呢? 誰會受這個操作影響呢? 能大致給我描述下使用流程嗎? ok, 這些問題產品同學肯定是能夠回答得出來的, 然後我會做個記錄, 做記錄我嘗試過如下的方案, 分別說下優缺點

1. 紙質筆記本

優點: 記錄會議重點比較省事.

缺點: 會後就不看了...

2. IPad

優點: 用電子筆做會議記錄, 錄音記錄.

缺點: 會後就不看了...

3. 故事卡片

這是我用得最久的工作方法, 也是最熟練的方法, 開始是sprint模式, 上線節奏比較慢, 2週一個sprint週期, 後來逐步演化成了看板法, 就是什麼優先順序高就先做什麼, 以重要緊急劃分四象限排序, 可以上線了就上線...

優點: 梳理清楚故事的操作角色, 遵循3W原則, who? what? why? 作為who, 需要做what, 為了why. 以user story使用者故事的方式把產品的需求從使用者, 使用方式, 要達到的目的進行了記錄, 對技術同學理解需求有很強的幫助. 後續開發任務分配, 如前端工作, 後端工作是在另一塊白板上黏貼.

缺點: 對開發人員來說故事卡片只是某個頁面, 某個功能要開發, 對於使用者故事背後的關聯性毫無頭緒. 而且如果我不提前進行架構, 往往技術同學就無從下手或者最終推翻反覆.

看板

開發人員正在整理看板

4. 使用者故事地圖

在跟產品開發需求確認會後, 或者我期望產品在畫墨刀Axure前跟我先溝通使用者故事地圖, 根據產品人員的配合情況, 這兩種場景都適合使用使用者故事地圖, 大家有讀過<<使用者故事地圖>>這本書的或者在知乎等平臺上看過使用者故事地圖概念的, 會認為使用者故事地圖應該這樣梳理, 這種方式優點是比較直觀, 方便和物理看板進行關聯, 而且不論產品是否已經畫了墨刀Axure原型, 都有助於產品和技術評判業務缺失點和確認具體需求.

使用者故事地圖