這是Product Monk產(chǎn)品管理教程的的第七章。全部章節(jié)目錄參見本文。

目前為止，你已經(jīng)了解了用戶在不同階段所面臨的挑戰(zhàn)，及其可能的解決方案。用戶故事（user story）可以幫助我們?cè)趫F(tuán)隊(duì)之間，高效溝通功能的詳細(xì)描述。用戶故事有助于讓每個(gè)人都保持在同一基礎(chǔ)上。

用戶故事是從用戶或客戶的角度，對(duì)所講述功能的簡(jiǎn)短描述。他們通常遵循一個(gè)簡(jiǎn)單的模板：

作為一個(gè)<用戶類型>，我想要<一些目標(biāo)>，(如果可以的話)這樣<一些原因>。比如“作為一個(gè)消費(fèi)者，我希望可以在網(wǎng)上買到化妝品，這樣我沒空出門的時(shí)候也可以即時(shí)補(bǔ)給化妝品了?！庇脩艄适驴梢詭椭銓⒐δ苄枨髠鬟_(dá)給工程團(tuán)隊(duì)。這樣，工程團(tuán)隊(duì)就更容易理解：他們?yōu)槭裁匆獦?gòu)建這個(gè)功能，它將如何給用戶帶來好處，或者用戶將如何使用它。

如何編寫用戶故事?

你應(yīng)該寫一個(gè)史詩(shī)般的用戶故事，然后把它分解。

這個(gè)史詩(shī)（Epic）是指非常大、而且抽象的用戶故事，它源自用戶畫像和用戶旅程映射。它告訴產(chǎn)品應(yīng)該為用戶做什么(對(duì)應(yīng)用戶畫像/客戶旅程映射中，提供的用戶目標(biāo))。它可以讓你在不提交細(xì)節(jié)的情況下，勾畫產(chǎn)品功能。這對(duì)于描述新產(chǎn)品和新功能特別有幫助：它讓你捕獲大致范圍，并為了解如何最好地滿足用戶需求，爭(zhēng)取了時(shí)間。

一旦這個(gè)史詩(shī)準(zhǔn)備好了，就可以把它分解成更小、更詳細(xì)的故事，直到它們都具備三點(diǎn)：清晰、可行、可測(cè)試。例如，某個(gè)功能描述為：“我想和朋友分享我的照片”。這可以被分解成——我想和朋友在Facebook、Twitter、Insta、WhatsApp分享我的照片，等等。這些都形成了不同的用戶故事。

讓我們看一下在第4章(用戶旅程映射部分)使用的例子——用戶預(yù)訂酒店。讓我們來看看在發(fā)現(xiàn)階段的一個(gè)史詩(shī)敘述：作為用戶，我希望在一個(gè)帶有適當(dāng)過濾器和信息的地圖上，看到酒店搜索的結(jié)果。以上敘述可以進(jìn)一步分解成更小的用戶故事：

• “作為用戶，我應(yīng)該能夠在地圖上查看結(jié)果，這樣我就不必在結(jié)果列表視圖和地圖位置之間來回切換了?！?/li>
• “當(dāng)我移動(dòng)地圖查看其他區(qū)域時(shí)，結(jié)果應(yīng)該根據(jù)新位置得到更新”
• “作為用戶，我應(yīng)該能夠在地圖視圖中查看我需要的信息(價(jià)格、評(píng)分、星級(jí)、照片)”
• “作為用戶，我應(yīng)該能夠在地圖視圖中應(yīng)用過濾器(價(jià)格，評(píng)級(jí))”

以打車服務(wù)的旅程映射為例，我們可以寫下以下史詩(shī)，并進(jìn)一步分解為更小的用戶故事。

用戶故事的驗(yàn)收標(biāo)準(zhǔn)

創(chuàng)建了用戶故事之后，要為用戶故事添加驗(yàn)收標(biāo)準(zhǔn)。驗(yàn)收標(biāo)準(zhǔn)是為了將故事標(biāo)記為已完成，必須滿足的條件。驗(yàn)收標(biāo)準(zhǔn)對(duì)用戶故事做了完善，使其可測(cè)試，并確保用戶故事可以向用戶和其他利益相關(guān)者，進(jìn)行演示或發(fā)布。

考慮下前面例子中，第一個(gè)用戶故事：

“作為用戶，我應(yīng)該能夠使用我的位置，這樣可以看到我附近可用的出租車”。

驗(yàn)收標(biāo)準(zhǔn)可以是：

• app應(yīng)該能夠檢測(cè)我的位置，并在地圖上指出來。
• app應(yīng)該能夠接收任何位置的文本輸入，并在地圖上指出來。
• 一旦確定位置，附近可用的出租車應(yīng)顯示在地圖上。

評(píng)估用戶故事的標(biāo)準(zhǔn)就是：I.N.V.E.S.T.

• 獨(dú)立（Independent）：用戶故事應(yīng)該是獨(dú)立的，因?yàn)槿魏我蕾嚩紩?huì)使它們之間的優(yōu)先級(jí)難以區(qū)分
• 可協(xié)商（Negotiable）：實(shí)現(xiàn)細(xì)節(jié)沒有指定，它們由團(tuán)隊(duì)來決定
• 有價(jià)值（Valuable）：用戶故事對(duì)客戶應(yīng)該是有價(jià)值的
• 可評(píng)估（Estimable）：它們應(yīng)該被分解成團(tuán)隊(duì)可以開展工作的最簡(jiǎn)單形式
• ?。⊿mall）：它們應(yīng)該足夠小，可以在一個(gè)沖刺（Sprint）內(nèi)完成
• 可測(cè)試（Testable）：可以根據(jù)指定的驗(yàn)收標(biāo)準(zhǔn)，對(duì)這個(gè)增量交付進(jìn)行測(cè)試

在哪里編寫這些用戶故事?

你可以使用類似Google表單這樣的簡(jiǎn)單解決方案，也可以使用如Trello、Jira、Aha、Craft以及許多其他工具的高級(jí)方案。

用戶故事評(píng)估

工作量評(píng)估是很困難的。因?yàn)閭鹘y(tǒng)軟件開發(fā)團(tuán)隊(duì)以時(shí)間(小時(shí)或天)來提供估算。然而，許多團(tuán)隊(duì)(遵循敏捷開發(fā)實(shí)踐)使用基于評(píng)估的故事點(diǎn)數(shù)進(jìn)行估算。

故事點(diǎn)數(shù)（Story points）就像一種貨幣，它告訴你開發(fā)一個(gè)用戶故事，需要付出相當(dāng)于多少的努力。故事點(diǎn)數(shù)使用斐波那契數(shù)列格式，對(duì)工作的相對(duì)工作量進(jìn)行排序，格式為： 0、0.5、1、2、3、5、8、13、20、40、100。這種抽象可以幫助團(tuán)隊(duì)用更少的工作量對(duì)工作的難度，做出艱難的決定。下面的矩陣(由Dan Olsen編寫)有助于指導(dǎo)如何將故事點(diǎn)數(shù)分配給用戶故事。

簡(jiǎn)單來說，你也可以根據(jù)以下定義來分配故事點(diǎn)數(shù)：

• 1個(gè)點(diǎn)數(shù)——我非常清楚需要做什么，也非常清楚如何去做。
• 2個(gè)點(diǎn)數(shù)——我非常清楚需要做什么，但我需要做一些研究或?qū)嶒?yàn)，弄清楚如何去做。
• 3個(gè)點(diǎn)數(shù)——我大部分了解需要做什么，對(duì)于如何去做也了解一些。(但完全否定這個(gè)故事，是大概率不會(huì)的)
• 如果用戶故事?lián)碛械墓适曼c(diǎn)數(shù)高于5點(diǎn)或8點(diǎn)，那么它們通常被分解成更小的用戶故事。

規(guī)劃撲克（Planning Poker）評(píng)估技術(shù)

在這種方法中，團(tuán)隊(duì)成員拿到的卡片上，寫有基于斐波那契數(shù)列的數(shù)字。協(xié)調(diào)人(通常是產(chǎn)品經(jīng)理/負(fù)責(zé)人)提供用戶故事的簡(jiǎn)短介紹，團(tuán)隊(duì)成員將展示用戶故事的卡片。評(píng)估點(diǎn)數(shù)的任何差異都要被討論。通常，在對(duì)評(píng)估點(diǎn)數(shù)的最低值和最高值進(jìn)行一兩輪討論之后，團(tuán)隊(duì)會(huì)達(dá)成一致意見。

下一章，我們將看看如何驗(yàn)證你的MVP。