寫在前面

我認識的很多團隊都是在敏捷的方法,近些年來,這類快速迭代的開發流程在整個圈子裡面迅速的流行起來。

不管是出於為了快速交付、快速驗證、還是不寫文檔等諸多原因。不知道大家在執行敏捷過程中,特別是作為BA或者產品經理,發現有個問題。這麼多用戶故事,這麼多高內聚低耦合的用戶故事,你有辦法組織在一起嗎?

其實我一直在考慮一個問題,就是敏捷執行一段時間後,如何能保證不偏離當初設定好的目標

有人說,我們就沒目標。

是,可能剛開始做產品並沒有一個非常清晰的目標,比如我要做個共享單車,比如我要做個共享女友。但是總會有個願景或者是想要解決的問題。我想要解決從家到地鐵的500米距離的問題,我想要結束單身狗的命運……

而且在評估一個需求或者用戶故事是否重要的時候,也很糾結。因為目標和問題不明確,所以也不知道到底重不重要。於是最後很可能演變成功能的堆砌。

連產品經理或者需求負責人都有這種感受的話,就更別說其他幹係人了。

這種只見樹木,不見森林的方法,想想可能引發的後果,就有點「不寒而慄」。

我不是來抨擊敏捷的,因為我發現即便你用瀑布,可能也會有同樣的問題。

你同樣會進行需求的拆分,類似拆故事一樣。形成需求矩陣或者需求樹進行管理。但是頂層需求之間有什麼樣的關係,和你的整體目標以及要解決的問題有什麼樣的關係,這個估計也會有欠缺考慮的時候。

最近很巧的,看了三本書,介紹了三種方法,從三個不同的角度,都是為瞭解決同樣的這個問題:

「只見樹木,不見森林」

那我這邊會結合我的理解來和大家分別說一下這三種方法。

這篇先談談第一種。

用戶故事地圖

敏捷裡面有個很重要的概念叫做「用戶故事」。

用戶故事是從用戶的角度來描述自己渴望得到的特性以及帶來的價值。

現在流行的模板是:

英文:

  As a <Role>, I want to <Activity>, so that <Business Value>.中文:  作為一個<角色>, 我想要<活動>, 以便於<商業價值>

關於用戶故事應該怎麼寫,這又是一個很大的命題了,如果感興趣我們可以另外開一系列的文來寫。

我們今天想要討論的是,如果在你們的開發流程中已經使用了用戶故事,怎樣做才能「又見樹木,又見森林」呢?

用戶故事地圖,顧名思義就是使用用戶故事組成一個地圖。

地圖的作用是什麼呢?

地圖一般的作用有兩個:尋找路徑,瞭解全貌。

  • 尋找路徑

我們一般想要去一個地方,現在都會使用電子地圖,輸入起點和終點,APP會自動幫你規劃出路徑。

以前使用紙質地圖的時候,也是在地圖上要起點和終點,然後自己謀劃一下路徑。

這個應該是我們比較常用的功能了。

  • 瞭解全貌

上學那會兒,地理課老師用世界地圖也好,中國地圖也好,來給我們講解幾大洲幾大洋,地質情況等等。

我們在知道了地球是圓的基礎上,還知道了中國就是雄雞,義大利是靴子……這就是了解全貌。我之前剛工作的時候做的就是GIS(地理信息系統),所以對於上海市(區縣合併以前)的各個區的方位以及輪廓銘記於心。

同理,用戶故事地圖也起到同樣的作用。

用戶故事地圖主要起到兩個作用。一個是找到整個產品的主幹,也就是路徑。一個就是了解整個產品的全貌。

如何繪製用戶故事地圖

通過我來描述用戶故事地圖怎麼畫,我相信大家可以理解我為什麼這麼說了。

你事先需要準備一些便簽紙。

1 按照時間順序整理出來整個產品的主要任務

就好像我們做西紅柿炒雞蛋一樣,將每個任務都寫出來。這個時候你可能會得到很多的任務。比如,打雞蛋,放油,開火,炒雞蛋……

2組織情節

把同時發生的任務放在一起。有些任務是會同時發生的,比如放鹽和味精。當然有的人可能還會放蔥花啥啥啥的。你可以把同時發生的便簽紙放在一起,同時思考下有沒有什麼細節遺漏。

3探索

有沒有什麼異常、變化可能會發生。這個要看你探索的深度了,比如鹽不夠了,或者火太大糊了甚至著火了……探索一下,你又可以得到一大堆的任務便簽紙。

4提取主幹

把這麼多的任務歸歸類,把主幹歸納出來。西紅柿炒雞蛋的主幹可能是:準備工作、放油、開火、炒雞蛋、加西紅柿一起翻炒、加調料、出鍋。這裡面,準備工作就包括:西紅柿去皮、打雞蛋……加調料就包括:加鹽、味精……出鍋可能會包括:沒有客人情況下的拿個破碗裝裝,有客人情況下的擺個炫酷的盤。

雖然我不知道西紅柿炒雞蛋怎麼炫酷擺盤,也許知乎知道答案。

5補充

把用戶、細節、可替代方案、異常以及優先順序加上去。比如,鹽沒有了,是用醬油或者用番茄醬……

基本上畫出來的用戶故事地圖差不多是長這個樣子。

其中最上面一層是用戶,這個用戶包括操作用戶和系統。

比如,炒菜的你,喫菜的客人以及控制火力的電磁爐或者燃氣竈。骨幹被分成了兩層。下面一層是第4步提出出來的按照時間順序排列的主幹。

上面一層是再進行抽象的到的高級別的任務。

骨幹的下面就是脊柱了,每個主幹任務的關聯任務會有很多。將他們按照優先順序進行排列。

這樣的一個用戶故事地圖就完成了。

我們回到之前的那個問題。

「只見樹木,不見森林」。你看這張圖是否能夠又見樹木,又見森林呢?能。

回到地圖的作用

  • 尋找路徑

我們通過按照時間順序講述的主幹故事,可以輕鬆的找到整個路徑。

通過脊柱故事,我們可以清晰的知道如何達成某一個主幹故事。

思路寬廣,細節有度。

  • 瞭解全貌

當我們看到這樣一份用戶故事地圖後,我們很清楚的可以知道整體的任務有哪些。

在開發過程中,可以很清楚的知道,整個故事的開發進展情況。如果要定義MVP,我們通過用戶故事地圖最上面的,優先順序最高的脊柱,可以很快的給出評估結果。

大家感興趣的話可以拿自己的產品來模擬的試一下。

寫在最後

《用戶故事地圖》這本書裏還有很多精彩的插圖和故事。

作者有一個觀點我很贊同:

用戶故事不是另外一種寫需求的方式,故事是用來講的,不是用來寫的,主要是為了建立共識。

小婧是一名行走在實踐路上的資深業務分析師(BA),如果想與我同行,就請關注我唄!


推薦閱讀:
查看原文 >>
相關文章