借助使用者故事，我們可以将調研所獲得的使用者需求描述給開發人員。那麼，使用者故事應當遵循什麼樣的格式？我們不妨結合案例，來看看作者的分享。
一、使用者故事的概念
在靈活開發中産品負責人 (Product Owner），要建立和管理産品待辦事項清單（Product Backlog），産品待辦清單中的事項是什麼呢，本質就是使用者需求，但是以使用者故事（Story）的形式展示，使用者故事是要用最簡單的方式來将調研獲得的使用者需求描述給研發人員。
二、使用者故事的格式
它的常見形式是在卡片上寫上“誰”+“做什麼”+“為什麼”，如下所示：
作為___________；
我想/我能______________；
進而/以便我能_________________；
示例：
作為___商家________；
我想/我能___友善的釋出店鋪資訊___________；
進而/以便我能____吸引潛在客戶_____________；
再在卡片背後寫上驗收标準。
為什麼要有驗收标準，因為我想/我能，這個隻是粗略的業務需求，還達不到研發需求，我們要借着使用者故事跟研發了交流，我們要以什麼的方案來實作需求，具體方案怎麼落地，怎麼驗收，跟研發共同确認驗收标準，這個驗收标準也就是測試的驗收用例。驗收标準的常見格式是由“前提條件”+“出發點”+“期望結果”組成。
假設/給定___________；
當______________；
那麼_________________；
示例：
假設/給定___商家輸入完整的店鋪資訊________；
當______商家點選釋出按鈕________；
那麼_____使用者可以在網站檢視到對應的店鋪資訊____________；
PS：一個故事，不是隻有一個驗收标準，可以有多個，支援1對多。
三、使用者故事案例
下面用一個例子來講述一下使用者故事。
假設我們收到需求，要做一個财務系統，我們已經完成前期的使用者調研，并了解到其中一個财務的工作内容為：
因近期業務發展，收集并核對原始憑證占用财務過多時間，希望能以更便捷的方式收集。
原始憑證：
是指經濟業務發生或完成時取得或者填制的，用以記錄或證明經濟業務的發生或者完成情況的原始憑據。像等下場景中的會提到的訂單，還有提到國家稅務總局統一印制的全國通用的增值稅專用發票，除此之外還有像制造型企業生産使用的領料單，當然我們最熟悉還是打勞工發起的差旅費報帳單等；
記賬憑證：
記賬憑證又稱記賬憑單，是指會計人員根據稽核無誤的原始憑證，按照經濟業務的内容加以規歸類，并據以确定會計分錄後添置的會計憑證，作為登記賬簿的直接依據。
業務場景一：
張三（打勞工1号）：“我新人入職，購買了一台電腦，要報帳”
李四（财務）：“這麼多， 填下報帳申請，申請人、申請日期、購買單據，發票這些都填好，報帳申請表發你了”
張三（打勞工1号）：“行，這個是我購買單據，我直接截圖貼上去”
李四（财務）：“嗯，填好了再發我”
有了原始憑證之後，财務就要跟據原始憑證編制記賬憑證，如下圖所示；
這是一個記賬憑證，使用的是借貸記賬法，目前先不展開講；
收集原始憑證的使用者故事：
作為[财務人員] ；
我想要 [能夠友善地收集原始憑證]；
以便 [確定财務資料的準确性和完整性，便于後續的财務處理和審計（生成記賬憑證）]。
明确使用者故事後，就可以展開讨論，逐漸明确驗收标準：
- （系統輸入-系統加工邏輯-系統輸出）
- 怎麼友善收集原始憑證：對接自研業務系統
- 要收集原始憑證哪些資訊：要有滿足記賬憑證所需資訊，【“會計主體”、“業務名稱”、“憑證字段”、“業務日期”、“業務金額”、“往來對象”】
- 是接收所有的業務單據嗎：不是，要收集的單據類型有銷售訂單、采購……
- 需要業務人員做操作嗎：可以檢視收集到的原始憑證
- 系統響應時間、實時、容量有要求嗎……
驗收标準1：
假設接收到自研業務系統傳來的原始憑證；
當原始憑證單據類型符合要求，且滿足的字段要求【“會計主體”、“業務名稱”、“憑證字段”、“業務日期”、“業務金額”、“往來對象”】時；
提醒自研業務系統原始憑證接收成功。
驗收标準2：
假設接收到自研業務系統傳來的原始憑證；
當原始憑證根據單據類型符合要求，并不滿足财務憑證生成的字段要求【“會計主體”、“業務名稱”、“憑證字段”、“業務日期”、“業務金額”、“往來對象”】時；
提醒第自研業務系統原始憑證字段缺失，請重新複核原始憑證。
驗收标準3：
假設接收到自研業務系統傳來的原始憑證；
當原始憑證單據類型不符合要求時；
提醒自研業務系統單據類型不符合要求，請重新确認單據類型配置。
你會怎麼編制财務憑證這個使用者故事及對應的驗收标準呢？
結束語
使用者故事是很便捷，也比較友善變更，但請注意它的适用場景，不是所有開發流程都适用。
在實際操作的過程中，可能考慮的問題還有很多，比如變更需求引起的研發成本、時間變更等等。你還會發現一開始的使用者故事比較少，等進入研發階段的是，又能拆解出很多小的使用者故事，這都是很正常的，使用者故事怎麼拆解，怎麼落地，這些都是要在實戰中思考的，也再看看Invest法則，怎麼才算一個好的使用者故事。
本文由 @一心 原創釋出于人人都是産品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。