「不要從產(chǎn)品開(kāi)始，從故事開(kāi)始」。

需求不明確？

在項(xiàng)目推進(jìn)過(guò)程中，將需求轉(zhuǎn)化為開(kāi)發(fā)團(tuán)隊(duì)可操作的東西是一項(xiàng)非常具有挑戰(zhàn)性的任務(wù)。很多時(shí)候用戶(hù)或者客戶(hù)的需求是這樣的：

「我需要一個(gè)登錄功能」

「我希望能拉黑別人」

……

但假如向開(kāi)發(fā)者這樣提需求，往往會(huì)得到這樣的回復(fù)：「為什么要這樣做？這么做的意義是什么？」。僅僅從這些需求來(lái)看，由于需求的不完整性，不但難以實(shí)現(xiàn)開(kāi)發(fā)，同時(shí)也無(wú)法成為最終需求驗(yàn)收的標(biāo)準(zhǔn)。

遇到這種情況，可以試著講一講「用戶(hù)故事」。

用戶(hù)故事

目前用戶(hù)故事作為需求的基本形態(tài)，應(yīng)用于產(chǎn)品的敏捷開(kāi)發(fā)過(guò)程中。用戶(hù)故事的典型格式是：

作為 < 用戶(hù) >，我想要 < 愿望 >，這樣我就可以 < 收益 >。

我們?cè)倩氐缴厦妗咐凇沟睦又?，按照用?hù)故事的格式，就可以這樣對(duì)需求進(jìn)行描述：

作為 < 社區(qū)成員 >，我想要 < 增加一個(gè)拉黑的按鈕 >，這樣我就可以 < 屏蔽那些我不喜歡的用戶(hù) >

很明顯可以看出，在一個(gè)用戶(hù)故事中包含如下這幾個(gè)部分：

1. 角色主體，即誰(shuí)要使用這個(gè)功能
2. 功能，也就是經(jīng)典格式中的「愿望」，它具體描述了整個(gè)需求需要實(shí)現(xiàn)的內(nèi)容。愿望是用戶(hù)故事的核心
3. 收益，即完成這個(gè)需求后能給角色主體帶來(lái)的價(jià)值

以往我們只關(guān)注需求的「功能」，忽視了功能主體和預(yù)期用法，而用戶(hù)故事很好地彌補(bǔ)了這一缺陷，將需求放到實(shí)際場(chǎng)景中，有助于避免需求提供者和實(shí)際開(kāi)發(fā)者之間的誤解。

怎么寫(xiě)用戶(hù)故事

用戶(hù)故事應(yīng)該能清晰地體現(xiàn)需求的具體內(nèi)容和對(duì)使用者帶來(lái)的價(jià)值，因此最好的方法是讓一線人員，如客戶(hù)團(tuán)隊(duì)或商業(yè)團(tuán)隊(duì)來(lái)描述故事，產(chǎn)品管理者或測(cè)試者對(duì)故事進(jìn)行總結(jié)和后續(xù)的拆分。《用戶(hù)故事與敏捷方法》一書(shū)中提到了用戶(hù)故事的 INVEST 原則，可以作為用戶(hù)故事的編寫(xiě)指導(dǎo)。

• 獨(dú)立的（Independent）：所講述的故事應(yīng)該獨(dú)立并且完整，相互之間應(yīng)沒(méi)有依賴(lài)關(guān)系。

比如說(shuō)一個(gè)故事中會(huì)使用到微信和支付寶兩種支付方式，則「使用微信支付賬單」不是一個(gè)獨(dú)立的故事結(jié)構(gòu)，正確的說(shuō)法應(yīng)該是「使用支付功能支付賬單」。

• 可談判的（Negotiable）：需要明確一點(diǎn)，用戶(hù)故事其實(shí)是「討論需求」，而不是「下達(dá)指令」，它需要小組內(nèi)成員對(duì)用戶(hù)故事的需求討論達(dá)成一致，如果沒(méi)有，則用戶(hù)故事是失敗的。

• 有價(jià)值的（Valuable）：明確當(dāng)前需求的價(jià)值，為后續(xù)迭代做準(zhǔn)備

需注意這里的價(jià)值主體為「用戶(hù)」。比如說(shuō)技術(shù)人員希望對(duì)管理后臺(tái)進(jìn)行優(yōu)化，這種優(yōu)化的價(jià)值普通用戶(hù)是無(wú)法感知的，不需要體現(xiàn)在以普通用戶(hù)為「用戶(hù)」的故事里。

• 可估算的（Estimable）：用戶(hù)故事需要可以被估算，這就要求用戶(hù)故事不能太大，同時(shí)討論人員需要具備一定的技術(shù)知識(shí)。

這里有一點(diǎn)需要明確，有時(shí)候用戶(hù)故事中的需求被駁回，并不是因?yàn)樾枨蟛缓侠砘驘o(wú)法實(shí)現(xiàn)，可能是技術(shù)團(tuán)隊(duì)目前的技術(shù)債沒(méi)有償還，因此估算時(shí)需要技術(shù)人員對(duì)當(dāng)前涉及的技術(shù)方案進(jìn)行評(píng)估，綜合考慮是立即執(zhí)行還是對(duì)以往技術(shù)債修補(bǔ)后再開(kāi)展，甚至可以單獨(dú)拉出一個(gè)版本進(jìn)行技術(shù)重構(gòu)，否則會(huì)導(dǎo)致技術(shù)債越堆越多，反而影響后續(xù)迭代。

• 小規(guī)模的（Small）：好的工作故事不能太大，最好能保證在一個(gè)迭代內(nèi)可以完成。如果用戶(hù)故事過(guò)大，則違反了上述可估算性，在后續(xù)開(kāi)發(fā)安排上就會(huì)有較大風(fēng)險(xiǎn)。

繼續(xù)說(shuō)上面「拉黑」的例子，「需要一個(gè)拉黑功能」看起來(lái)是一個(gè)需求，但其中還有很多細(xì)節(jié)沒(méi)有說(shuō)清楚：

• 用戶(hù)如果不想拉黑對(duì)方了，是否可以解除拉黑？
• 拉黑有沒(méi)有期限？
• 拉黑之后能不能給對(duì)方發(fā)消息，如果不能應(yīng)該怎么提示？
• ……

以上的這些問(wèn)題都是所謂的「需求坑」，如果不能很好地進(jìn)行識(shí)別，那這樣的用戶(hù)故事會(huì)對(duì)后面的討論或者開(kāi)發(fā)帶來(lái)很大的障礙，無(wú)形中增加了很高的成本。

• 可測(cè)試的（Testable）：用戶(hù)故事必須清晰地界定驗(yàn)收測(cè)試標(biāo)準(zhǔn)。

比如說(shuō)「用戶(hù)覺(jué)得很滿意」，這是一個(gè)較為主觀的概念，無(wú)法實(shí)際進(jìn)行測(cè)試，不應(yīng)該在用戶(hù)故事中體現(xiàn)?？梢栽诋a(chǎn)品上線后進(jìn)行滿意度問(wèn)卷調(diào)研。

舉個(gè)栗子？

團(tuán)隊(duì)之前曾經(jīng)接過(guò)一個(gè)需求，要求在應(yīng)用中實(shí)現(xiàn)慢性病智慧醫(yī)療場(chǎng)景，覆蓋用戶(hù)從查詢(xún)就醫(yī)到后續(xù)護(hù)理的全流程。團(tuán)隊(duì)在討論的過(guò)程中，做了這幾件事：

1. 抽取場(chǎng)景中的關(guān)鍵流程
2. 豐富關(guān)鍵流程的分支
3. 抽取出用戶(hù)故事，并進(jìn)行拆分

部分故事截圖

上圖紅框部分即為每一個(gè)流程節(jié)點(diǎn)的用戶(hù)故事，但需要注意的是，這仍是大粒度的用戶(hù)故事，需要做進(jìn)一步的拆分。例如在購(gòu)藥的環(huán)節(jié)，又將其拆成了以下幾個(gè)故事：

粒度拆解

如上圖，這樣就使得用戶(hù)故事的工作流、業(yè)務(wù)規(guī)則都已經(jīng)足夠詳盡。

最后，當(dāng)把用戶(hù)故事抽提出來(lái)后，最好團(tuán)隊(duì)成員可以對(duì)著故事卡片再?gòu)?fù)述一遍故事，做到對(duì)故事和其中的需求充分理解，有一個(gè)完整的例子之后就可以開(kāi)始迭代，避免后續(xù)在實(shí)現(xiàn)上出現(xiàn)偏差。