需求與使用者故事 – 艾菲肯專案管理小學堂

如何把系統需求變成明確、可實作的規格是我們首先要處理問題,規格實例化( specification  by example )和驗收測試導向開發( acceptance-test-driven development) 是兩種常見的方法,有興趣的朋友可以參考Gojko Adzic的《Specification by Example-How successful teams deliver the right software?》, Harry J.W. Percival 的《Test-Driven Development with Python》以及Jeff Patton的《User Story Mapping》。

首先透過對話建立使用者故事:需求的細節是透過開發團隊、產品負責人以及利害關係人之間的對話而建立的,而我們將各個需求寫在卡片上,成為使用者故事,卡片是一個抽象的概念,它可以是一個虛擬的線上工具或者是便利貼等等,端視你的狀況或喜好而定。

身為產品負責人,你必須讓開發團隊與利害關係人了解撰寫故事的規則與格式:

作為一個〈使用者角色〉,我想要〈目標〉,這樣我才可以〈好處〉。

按照此格式來撰寫使用者故事,同時遵循以下原則:

  • 避免在開發前期鉅細靡遺的撰寫需求,Scrum不要求嚴謹的需求,而是保留彈性與空間
  • 文件容易被誤解,頻繁且持續的溝通是必須的,以確保需求被每個人正確解讀

需求確認初期,我會使用Trello來建立使用者故事,如下圖所示:

此時產品負責人負責邀請開發團隊與利害關係人,一同撰寫這個故事看板,看板會將故事簡單的分成三個區塊:

  1. 必須有(must-have)的項目:客戶與開發團隊溝通後覺得相當重要的需求項目。
  2. 可有可無(nice-to-have)的項目:客戶與開發團隊溝通後覺得有待商榷或沒那麼重要的項目。
  3. 不會有(won’t have)的項目:客戶與開發團隊溝通後確定不使用的項目。

利用這三個分類,我們可以很容易地瞭解客戶的需求,以及排定優先順序,以便決定要先針對哪個故事做精練,以得到更詳細的需求定義。

有些使用者故事可能與其他故事相關,這時有必要寫下相關聯的故事是什麼,方便往後檢索:

由於這個階段的需求是透過對話建立的,因此溝通、提問、協調都是確保初期需求正確性很重要的因素,所謂的正確性是指在合理的成本下將資源花費在有價值的項目上,開發團隊應該給予技術面的諮詢並提供專案經驗,幫助客戶釐清需求、排除盲點與誤解。

這個階段,我們也可以撰寫一些操作介面草圖、筆記紀錄等補充資料,根據我實際的經驗,由於溝通有時得花不少時間討論,其中涉及各種需求與文件,所以最好立刻把會影響到需求的對話記錄下來,否則很容易因為忘記修改了什麼,又或者過程中討論了多種版本,時間久了,客戶自己也忘了最終定稿的版本是什麼,資訊不對稱導致開發上的浪費與損失是相當惱人的。

產品負責人需常常瀏覽相關需求,確保需求與資訊保持一致:

善用Activity,可以幫助我們檢視近期的修改紀錄,加了哪些需求,做了什麼修改與補充

Trello這套工具相當簡單直覺,可以很容易的與客戶進行溝通(遠端或面談都很方便),初期需求不確定時,我們不需要太多細節的描述(規格、功能、時間成本評估等等),這也是我在做初步需求開發時會使用它的原因,他幫助客戶與產品負責人回憶起需求的細節,容易將對話形式的需求及修改記錄下來,且跨平台,可隨時隨地進行溝通。

有關使用者故事的確認與滿足條件,將留到下一篇做介紹,我們會使用JIRA這套工具來完成產品代辦事項清單、精煉使用者故事以及撰寫滿足條件,其中會使用到故事地圖(user mapping),使用者故事對照(user story mapping)、規格實例化(specification by example)、測試驅動開發(test-driven development)等概念。

JIRA這套工具提供了驗收確認、到期日、使用者故事類型分類等各種設定,相當適合用於管理產品代辦事項清單。也因此JIRA比Trello複雜許多,這也是我為什麼我要使用Trello做初步分析的關係,客戶比較容易理解Trello,且初期的使用者故事清單都有很大的修改空間,往往經過討論後,發生重大的改變,如果一開始就使用Trello,會浪費很多時間在設定到期日、故事類型等各種屬性。

補充:

有時客戶並不知道使用者想要什麼,這時我們必須使用一些搜集故事以及探索故事的技巧,藉以得到正確的需求,這樣的問題時常發生在新創企業中。Osterwalder, Alexander/ Pigneur, Yves/ Smith, Alan (ILT)/ Clark, Tim (EDT)等人合著的《Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers》一書提供了多種方法去處理這樣的問題,本文聚焦在系統開發的部分,僅透過人物誌和同理心地圖這兩個工具,讓團隊成員能對使用者有個概括性的認識,這有助於介面設計、內容設計、功能設計。

工具一:人物誌(personas)

藉由描述使用者的基本屬性,使大家對使用者有更具體的認知。

工具二:同理心地圖(Empathy Map)

粗略的描述你的目標客層:

See? 描述顧客在他的環境中所看到的

  • 整個環境看起來如何?
  • 他周圍有些什麼?
  • 他的朋友有誰?
  • 他每天接觸到的是哪些產品或服務?(不是整個市場所提供的全部產品或服務)?
  • 他遭遇到什麼難題?

Hear?描述環境如何影響顧客

  • 他的朋友說些什麼?
  • 他的配偶說些什麼?
  • 真正影響他的是誰?
  • 如何影響?
  • 哪些媒體管道對他有影響力

Think & Fell? 試著勾勒出這個顧客心裡的想法

  • 對他來說,真正重要的(但他可能不會公然說出來)是什麼?
  • 想像她的情緒,什麼會令他感動?
  • 他可能會為了什麼通宵熬夜?
  • 試著描述一下他的夢想與渴望。

Pain :顧客的痛苦是什麼?

  • 他最大的挫折是什麼?
  • 什麼障礙讓他無法得到自己想要或需求的?
  • 他害怕冒什麼風險?

Gain:顧客得到什麼?

  • 他真正想要或需要達到的是什麼?
  • 他衡量成功的指標是什麼?
  • 想出一些他可能用來達成目標的策略