增強團隊協作,洞察真實需求,研磨優良產品——譯《使用者故事地圖》書籍有感

發表於2016-06-01

一、使用者故事地圖的來源

使用者故事(user story)是敏捷軟體開發過程中管理需求的重要方法。它就像這樣:

作為一個諮詢師,我想要操作我的郵件,這樣我就可以和客戶、同事、朋友保持聯絡。

它從使用者的角度描述了誰(who)要做什麼(what),以及為什麼要這樣做(why)。

最初的想法來自Kent Beck。他發現,使用文件來精確描述我們的需求根本是不可能的,文件只告訴我們做什麼,卻沒有告訴我們為什麼要這樣做;同樣的文件,閱讀的人不同,得到的資訊也會不一樣;如果大家能夠坐在一切討論軟體要解決什麼問題,哪些使用者會用,為什麼用,我們就可以得到解決方案,並在這一過程中達成共識。使用者故事的要義便在於團隊聚在一起對使用者故事進行充分討論。

2001年,Ron Jeffries提出了著名的3C原則,對使用者故事進行了概要總結:

  1. 卡片(CARD):把使用者想要的產品功能寫在卡片上。
  2. 對話(CONVERSATION):干係人(使用者、客戶、產品、開發、測試等)聚在一起討論使用者故事,對要解決的問題達成一致理解,並努力找到最佳方案。
  3. 確認(CONFIRMATION):確定驗收條件是什麼。

2005年,Jeff Patton在他的一篇名為《How You Slice it》的文章中提出了一種協作式的、基於卡片的方法。這是使用者故事地圖(User Story Mapping)的雛形。

二、什麼是使用者故事地圖?

使用者故事地圖的理念很簡單。它強調和他人一起協作來講述產品的故事,看到故事的全景,然後進一步細分以制定良好的規劃決策。

地圖的頂部是大故事(big stories),或者叫使用者活動(user activities),它通常需要一些小步驟來完成。活動所在的行是使用者故事地圖的主幹,從左到右的活動構成了基本的敘事流。關於活動的故事可能是這樣:

作為一個諮詢師,我想要操作我的郵件,這樣我就可以和客戶、同事、朋友保持聯絡。

對一次迭代來說,這樣的故事顯然太大了。大故事可以拆解成小故事,就像大石頭可以打碎成小石頭一樣,但石頭仍是石頭,故事也仍是故事。操作郵件可以分解成“發郵件”、“讀郵件”、“刪除郵件”、“標記垃圾郵件”等。這些稱為使用者任務(user tasks),它們是使用者為達到一定目標需要完成的動作,也是開發人員可以實現的東西。

誠如Martin Flowler在序言中所說,使用者故事地圖是拆解細化需求的重要技術,並讓我們在拆分需求過程中保持全景圖,始終牢記使用者訴求。

3

圖片來自:http://jpattonassociates.com/the-new-backlog/

三、使用使用者故事地圖的目的和優勢

3.1 促進討論和對話,建立共識,找到最佳解決方案

在產品開發過程中,建立共識的重要性不言而喻。Jeff在《使用者故事地圖》中談到,兩個人認為已經對某個功能達成了共識,而實際開發中卻發現別人的理解和自己大相徑庭。這樣的場景並不鮮見。而使用故事地圖的目的就是為了達成共識。

通過文件來完美地描述一個東西是不可能的,人們會根據自己的經驗展開想象。但(1)如果是大家聚在一起,針對故事地圖展開討論;在討論過程中,聽的人可以通過反覆提問或追問來修正對事情的最初理解,最終使所有參與者都達成共識。而且,(2)文件只會告訴我們做什麼,卻不會告訴我們為什麼要這樣做。如果需要解決問題的人和有能力解決問題人沒法充分溝通,就不可能找到最佳的解決方案。

2

3.2  故事地圖幫助我們思考故事全景

我們以功能模組來組織所有需要開發的功能,與開發團隊逐條討論。這種討論關注開發細節,忽視整體願景。當使用故事地圖來組織我們的產品創意時,在深入細節前,我們會首先關注產品全景,避免在拆分需求時迷失於細節,遺忘使用者訴求(為什麼要這樣做;預期結果是什麼),遺漏任務之間的關鍵環節,或環節之間的銜接和依賴關係。

3.3 充分思考各種可行方案,最小化投入產出比

我們想要開發的功能,總是會超過你能夠投入的資源。而最小化輸出的祕訣在於,聚焦於系統外的預期成果來決定系統需要什麼功能。

Golobo.com是巴西最大的媒體傳播公司,他們要升級目前正在使用的內容管理系統,該系統涉及的業務和團隊相當多。他們用便籤在牆上描述了內容管理系統的故事,每個團隊都是全景圖中的一部分。可是,要完成所有的事情可能1年都不夠。Jeff在對話中瞭解到,他們的CEO希望在幾個月後的巴西大選上用上這個系統。團隊開始聚焦於巴西大選,在大選中提供全新性感的互動內容,給網站訪問者、廣告商和合作媒體留下深刻的印象成為他們考慮到的最大成果,而這並不需要開發所有功能。

成果是使用者可感知的東西,即他們可以用不同的方式來解決他們的問題,相比於之前,他們變的更開心了。聚焦於成果,以成果為導向切分發布計劃。為成果排列優先順序,而不是功能。

但是,在劃分釋出計劃時,我們實際上是在假設許多事情的發生。我們假設產品釋出後使用者會使用它、喜歡它,能夠解決使用者遇到的問題;我們假設這些功能在有效的時間內可以開發出來。實際情況可能並不是這樣。學習的重要性不言而喻。

3.4  組織最小化產品試驗,進行驗證性學習

在開發產品時瞭解使用者的方式有許多,例如前期的使用者調研和使用者交流;或者通過原型、線框圖來驗證產品方案是否有用。但是,在真正接觸到可使用的產品前,使用者都只是在猜測自己是否會使用或喜歡它。真正的信心來自於使用者每天會使用我們的產品。

在開發過程中利用MVP進行學習。MVP是我們的最小可行產品,我們把它拿給我們的“開發夥伴”(他們來自於早期訪談或原型測試以驗證問題的受訪人群),從他們的真實使用和反饋中進行學習,不斷學習、持續迭代,直到得到真正解決使用者問題、讓使用者滿意的產品。

3.5 制定合理的開發計劃,預估開發時間,按時釋出

達成一致是成功預估的祕密。另外一個祕密則是,度量得越頻繁,預估就越接近實際值。通過把大計劃切分成小的部分,我們獲得了許多度量的機會。

1

四、如何建立使用者故事地圖

4.1 分步驟寫出你的故事

使用者任務(動詞短語)是構成使用者故事地圖的基本要件。

任務就像石頭,可以分解為更小的石子。目標層級的概念有助於彙總小任務、分解大任務。

4.2 從左到右組織你的故事

這是我們講故事的順序(敘事流),是我們的故事地圖。這樣做的好處是我們可以看到整個故事,找到我們可能遺漏的部分。

4.3 探索替代故事(刨根問底遊戲)

細節、替代、變化、異常構成了使用者故事地圖的主體(地圖的深度)。例如,同樣是講述一天的故事,你可以講述普通的一天、美妙的一天,或忙亂的一天。

4.4 提取故事地圖的主幹

活動構成故事地圖的主幹。所謂活動是指更高目標層級的任務,它由一群相似的人在相似的事件完成的任務組成,旨在達到特定的目標。活動所在的行是故事地圖的主幹。

4.5 切分出達成特定目標的任務集

這個環節你要思考哪些事情是可有可無的。如果早上起晚了,馬上就要遲到了,你的任務肯定與你平時不一樣。

利用切分來識別與特定結果相關的任務和細節。

五、故事對話

對話是拆解大故事的工具。一個人也可以建立故事地圖,但如果使用故事地圖時團隊沒有聚在一起對使用者故事進行充分討論,就說明使用使用者故事的方式不對。同樣的道理,故事地圖是為開展使用者和產品想法對話而服務的,如果不需要討論,就不必使用故事地圖。

5.1 從機會開始

機會是指我們認為可以解決一個問題的所有想法。機會討論的目的在於我們是決定繼續深入這一機會,還是把它當作垃圾扔掉(通過/不通過決定)。如果團隊沒有足夠的資訊來做出通過/不通過的決定,就要列出還需要了解哪些資訊,然後一起來尋求答案。對於機會,我們要討論正在解決的問題是什麼;為誰解決;我們的構想是什麼;公司如何從中獲益、是否符合公司的商業策略;成本大小等。

5.2 探索討論:將大故事進行分解,探索最小可行方案

在探索階段,你需要廣泛展開討論,不僅是和同事,而且要深入客戶和使用者,瞭解他們目前解決問題的方式;有了你的方案後,他們的世界會發生怎樣的變化;你的方案要花多長時間開發。我們需要建立起應該開發什麼的共識,並確保我們開發的東西是正確的。

在這一階段,故事地圖有助於我們理解目前人們是如何解決問題的,然後你可以為自己的方案繪製故事地圖。

5.3 故事工作坊:驗收標準

這一階段我們要回答的問題是,我們到底要開發什麼?我們需要通過對話對軟體各個模組的驗收標準達成一致,因為下一步就正式開發了。

六、總結

Jeff Patton認為,軟體本身並不重要,重要的是我們有沒有改變世界。改變世界並不一定是翻天覆地的變化,而是在軟體釋出後,人們解決問題的方式變得不一樣了,他們變得更開心了,這就是改變世界。在改變世界前,所有的產出都叫做輸出,如果有些事情需要交代給別人,這通常叫做需求。然而,產品的成功絕不是以輸出的多少或需求的多寡來評判的,唯一的度量標準只能是產品產生的影響即它的成果,即人們是否以不同於以往的方式解決遇到的問題,並且變得更開心了。Jeff Patton提醒我們,在使用故事地圖或參與產品工作時,不妨以改變世界的模型來幫助自己思考。例如以成果為導向來排列優先順序或規劃產品釋出。

當然,改變世界絕非易事。這往往需要一群人的努力。而這一群人要想產生合力、高效運作,建立共識則是第一要義。使用者故事地圖就是建立共識的一種機制。大家就使用者故事展開充分討論,產品要解決什麼問題,哪些人會用,為什麼用,一邊傾聽一邊提問,不斷修正最初的認識以在團隊間達成共識,而不是追求完美的文件來試圖達成一致;基於卡片的故事地圖也讓團隊看到故事全景,增強溝通默契,在拆分需求時時刻牢記使用者訴求。

故事遠沒有這麼簡單。我們並不能保證我們討論的東西都是事實,它們很可能只是假設而已。故事地圖幫助我們拆解出最小可用產品,建立學習目標,在迭代中不斷接近使用者的真實需求。

使用者故事地圖不僅僅是貼在牆上錯落有致引人注目的一張張卡片,它也是一種理念、一種工作方式。我希望你可以通過Jeff Patton的《使用者故事地圖》真正理解和實踐這一理念。

相關文章