敏捷開發使用者故事系列之二：如何面向客戶價值編寫故事

這是敏捷開發使用者故事系列的第二篇。（欄目目錄）

敏捷開發中的使用者故事採用的文法模式看似簡單，卻蘊含著深刻的思想。

“作為一個……，可以……，以（以便）……”不同於一般專註於功能的需求條目描述方法，三個……把角色、功能、價值躍然紙上。然而使用不當，卻有可能形似而神不似。

下面就三個部分分別舉出一個例子。

網路遊戲的熱門排行榜功能

“作為一個玩家，可以通過顯示排名，以便讓自己在伺服器中的地位獲得認可。”

這個功能可以激發玩家的“鬥志”，鼓勵購買道具，是個不錯的想法，但實現起來卻有技術問題：伺服器中的玩家太多了，即時查看排名非常不現實。另一個問題是小蝦米們其實對自己的排名不太關心，即使關心，也不會為了提升排名去購買道具，只有一批（也有上百個）頂級大佬才會真正受此蠱惑。

這個故事後來被改為：每周重新排名一次，而且只顯示TopXXX（很像csdn的“排名兩萬以外”）。所以如果寫成故事，就變成：

“作為一個排名靠前的付費玩家，可以通過顯示排名，以便讓自己在伺服器中的地位獲得認可（以刺激消費）。”

當然，對小蝦米們也有刺激消費的方法，比如打怪掉落了一個很棒的道具，卻要花錢買打孔材料和鑲嵌寶石，即使用保健因素而非激勵因素讓他們消費，那是另外一個故事了。筆者曾經體驗過的一個遊戲中有幫派戰爭，大號會爭當“連斬狂客”，小號則有“尋寶冠軍”可得，且人人均有積分，因此各層人物都爭相參加。

這個故事讓我們理解到：“使用者”這個詞太籠統了，如果他們的“價值觀”差別很大，就要分別為他們寫故事，才能吸引他們使用功能，達成價值觀。

許可權查詢功能

“作為管理員，可以查詢所有使用者的許可權，以瞭解所有使用者的許可權”。

一種很常見的寫之無味不寫不行的故事，因為好像功能=價值。其實管理員不會平白無故地查看所有使用者權限的，多半有其目的：有人反映自己訪問不了某個檔案，有個項目死活加不上新使用者，有人剛剛離職，有三個外包團隊的人需要在最近三個月在項目中作為成員一起工作……

知道這些就好多了，當點擊“許可權”這個tab後，多半不會出現“所有使用者的許可權”（倘若想想有10000人的企業），而是繼續出現幾個子連結：查詢個人許可權，項目成員，人員離職，限時許可權（外包人員管理）……

當然，這需要一大堆故事了，但如果一個給客戶帶來明確價值操作友好的產品正是我們所追求的，我們極有可能選擇開發其中最高價值的幾個，然後再留下之前那個“萬能”但又什麼都幹不太好的。

這個故事讓我們理解到：功能不等於價值，要理解使用者操作功能的業務目的，不要隨意拋出萬能的功能。

殺毒軟體的防打擾功能

“作為一個使用者，可以選擇‘認可所有相似操作’，以便同意或禁止連續的相似操作。”

這看起來也是個很不錯的功能，但筆者曾經在安裝軟體的時候用到這個功能，儘管選擇了“認可所有相似操作”，視窗仍然跳個不停，直到後來仔細查看彈出的資訊，原來在軟體安裝過程中要進行很多“不相似”的操作：修改註冊表，建立C盤目錄，向system32中拷貝dll……而這個殺毒軟體在處理的時候，連註冊表不同位置的修改都認為是“不同的操作”。

要改好這個故事，就要從最後的客戶價值入手。比如如果安裝軟體是最常見的需要“認可所有相似操作”的過程，就可以寫一個這樣的故事：

“作為一個使用者，可以在安裝軟體時選擇‘認可本次安裝操作’，以便一鍵完成正常的安裝操作。”當然何為“正常”的操作需要額外說明，但整體客戶價值卻更精準地表達出來了。

這個故事讓我們理解到：“客戶價值”是要從客戶的角度來理解的，否則極可能跑偏。

 

 

編者註：本部落格是以前的舊文，因符合本系列內容，稍加修改穿插於此。

 

 

點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》