借助用戶故事，我們可以將調研所獲得的用戶需求描述給開發人員。那么，用戶故事應當遵循什么樣的格式？我們不妨結合案例，來看看作者的分享。

一、用戶故事的概念

在敏捷開發中產品負責人 (Product Owner），要創建和管理產品待辦事項列表（Product Backlog），產品待辦列表中的事項是什么呢，本質就是用戶需求，但是以用戶故事（Story）的形式展示，用戶故事是要用最簡單的方式來將調研獲得的用戶需求描述給研發人員。

二、用戶故事的格式

它的常見形式是在卡片上寫上“誰”+“做什么”+“為什么”，如下所示：

作為___________；

我想/我能______________；

從而/以便我能_________________；

示例：

作為___商家________；

我想/我能___方便的發布店鋪信息___________；

從而/以便我能____吸引潛在客戶_____________；

再在卡片背后寫上驗收標準。

為什么要有驗收標準，因為我想/我能，這個只是粗略的業務需求，還達不到研發需求，我們要借著用戶故事跟研發了交流，我們要以什么的方案來實現需求，具體方案怎么落地，怎么驗收，跟研發共同確認驗收標準，這個驗收標準也就是測試的驗收用例。驗收標準的常見格式是由“前提條件”+“出發點”+“期望結果”組成。

假設/給定___________；

當______________；

那么_________________；

示例：

假設/給定___商家輸入完整的店鋪信息________；

當______商家點擊發布按鈕________；

那么_____用戶可以在網站查看到對應的店鋪信息____________；

PS：一個故事，不是只有一個驗收標準，可以有多個，支持1對多。

三、用戶故事案例

下面用一個例子來講述一下用戶故事。

假設我們收到需求，要做一個財務系統，我們已經完成前期的用戶調研，并了解到其中一個財務的工作內容為：

1. 收集原始憑證
2. 編制財務憑證

因近期業務發展，收集并核對原始憑證占用財務過多時間，希望能以更便捷的方式收集。

原始憑證：

是指經濟業務發生或完成時取得或者填制的，用以記錄或證明經濟業務的發生或者完成情況的原始憑據。像等下場景中的會提到的訂單，還有提到國家稅務總局統一印制的全國通用的增值稅專用發票，除此之外還有像制造型企業生產使用的領料單，當然我們最熟悉還是打工人發起的差旅費報銷單等；

記賬憑證：

記賬憑證又稱記賬憑單，是指會計人員根據審核無誤的原始憑證，按照經濟業務的內容加以規歸類，并據以確定會計分錄后添置的會計憑證，作為登記賬簿的直接依據。

業務場景一：

張三（打工人1號）：“我新人入職，購買了一臺電腦，要報銷”

李四（財務）：“這么多， 填下報銷申請，申請人、申請日期、購買單據，發票這些都填好，報銷申請表發你了”

張三（打工人1號）：“行，這個是我購買單據，我直接截圖貼上去”

李四（財務）：“嗯，填好了再發我”

有了原始憑證之后，財務就要跟據原始憑證編制記賬憑證，如下圖所示；

這是一個記賬憑證，使用的是借貸記賬法，當前先不展開講；

收集原始憑證的用戶故事：

作為[財務人員] ；

我想要 [能夠方便地收集原始憑證]；

以便 [確保財務數據的準確性和完整性，便于后續的財務處理和審計（生成記賬憑證）]。

明確用戶故事后，就可以展開討論，逐步明確驗收標準：

• （系統輸入-系統加工邏輯-系統輸出）
• 怎么方便收集原始憑證：對接自研業務系統
• 要收集原始憑證哪些信息：要有滿足記賬憑證所需信息，【“會計主體”、“業務名稱”、“憑證字段”、“業務日期”、“業務金額”、“往來對象”】
• 是接收所有的業務單據嗎：不是，要收集的單據類型有銷售訂單、采購……
• 需要業務人員做操作嗎：可以查看收集到的原始憑證
• 系統響應時間、實時、容量有要求嗎……

驗收標準1：

假設接收到自研業務系統傳來的原始憑證；

當原始憑證單據類型符合要求，且滿足的字段要求【“會計主體”、“業務名稱”、“憑證字段”、“業務日期”、“業務金額”、“往來對象”】時；

提醒自研業務系統原始憑證接收成功。

驗收標準2：

假設接收到自研業務系統傳來的原始憑證；

當原始憑證根據單據類型符合要求，并不滿足財務憑證生成的字段要求【“會計主體”、“業務名稱”、“憑證字段”、“業務日期”、“業務金額”、“往來對象”】時；

提醒第自研業務系統原始憑證字段缺失，請重新復核原始憑證。

驗收標準3：

假設接收到自研業務系統傳來的原始憑證；

當原始憑證單據類型不符合要求時；

提醒自研業務系統單據類型不符合要求，請重新確認單據類型配置。

你會怎么編制財務憑證這個用戶故事及對應的驗收標準呢？

結束語

用戶故事是很便捷，也比較方便變更，但請注意它的適用場景，不是所有開發流程都適用。

在實際操作的過程中，可能考慮的問題還有很多，比如變更需求引起的研發成本、時間變更等等。你還會發現一開始的用戶故事比較少，等進入研發階段的是，又能拆解出很多小的用戶故事，這都是很正常的，用戶故事怎么拆解，怎么落地，這些都是要在實戰中思考的，也再看看Invest法則，怎么才算一個好的用戶故事。