本文探討了產(chǎn)品經(jīng)理在產(chǎn)品開(kāi)發(fā)過(guò)程中應(yīng)該編寫(xiě)PRD（產(chǎn)品需求文檔）還是用戶故事的選擇問(wèn)題，提供了深入的見(jiàn)解和建議，引導(dǎo)閱讀，希望對(duì)你在產(chǎn)品管理領(lǐng)域的實(shí)踐有所幫助。

產(chǎn)品經(jīng)理最基本的技能之一是編寫(xiě)需求，但應(yīng)該怎樣編寫(xiě)需求呢？我搜索了“產(chǎn)品經(jīng)理如何整理需求”的詞條，發(fā)現(xiàn)主要有以下四類方式。

1. 需求文檔（PRD）。這是目前最主流的方式之一。網(wǎng)絡(luò)上有很多PRD格式分享、撰寫(xiě)PRD的培訓(xùn)等等。
2. 以用戶為中心的PRD。因?yàn)镻RD主要以描述功能細(xì)節(jié)為主，隨著“用戶為王”的意識(shí)越來(lái)越強(qiáng)烈，PRD中開(kāi)始加入目標(biāo)用戶的部分，做用戶細(xì)分、用戶畫(huà)像、用戶流程，希望彌補(bǔ)用戶導(dǎo)向的缺失。
3. ?直接在原型軟件中寫(xiě)PRD的“一體化原型”。慢慢的用戶、或者項(xiàng)目相關(guān)干系人會(huì)發(fā)現(xiàn)word版的PRD中描述的功能，最后開(kāi)發(fā)出來(lái)的往往和想象的不一樣，和定稿的原型有諸多不對(duì)應(yīng)的地方。于是部分產(chǎn)品經(jīng)理開(kāi)始以原型為中心，詳細(xì)描述該原型頁(yè)面的功能情況，這樣可以比較大程度保證所見(jiàn)的、所約定的，就是開(kāi)發(fā)出來(lái)的結(jié)果。
4. 用戶故事。通過(guò)名字就可以看出這是一種完全以用戶為導(dǎo)向的需求編寫(xiě)方式。這樣的需求是一個(gè)故事線，講述了用戶可以通過(guò)將要開(kāi)發(fā)的這個(gè)特征、這個(gè)功能實(shí)現(xiàn)什么，從而明確這一個(gè)用戶故事對(duì)用戶、對(duì)整個(gè)項(xiàng)目的價(jià)值。

我個(gè)人傾向于寫(xiě)用戶故事。前三種需求編寫(xiě)方式在我看來(lái)依然脫離不了PRD的影子，所以下面我將根據(jù)我的個(gè)人經(jīng)驗(yàn)，對(duì)比PRD和用戶故事，分享一下更喜歡用戶故事的原因。先放一張PRD和用戶故事的對(duì)比圖，方便不了解這兩者的朋友有個(gè)基本的概念，后面會(huì)做具體的對(duì)比分析。

2018年我在一家外企剛開(kāi)始做產(chǎn)品經(jīng)理時(shí)，接受了用戶故事的培訓(xùn)。我當(dāng)時(shí)問(wèn)我老板為什么我們不寫(xiě)PRD（產(chǎn)品需求文檔）？因?yàn)槲宜私獾降倪@個(gè)職位是要寫(xiě)B(tài)RD、MRD、以及PRD的。我當(dāng)時(shí)看了一下這幾個(gè)文檔的格式和頁(yè)數(shù)，感覺(jué)比寫(xiě)用戶故事要高大上的多，看上去也更專業(yè)，因?yàn)橐獙?xiě)好幾個(gè)幾十頁(yè)的文檔呢。

當(dāng)時(shí)我在工作中已經(jīng)能夠熟練的編寫(xiě)用戶故事了，有新的需求，就按照用戶故事given, when, then的格式寫(xiě)好就可以了，感覺(jué)沒(méi)什么挑戰(zhàn)性了。

而且我也并沒(méi)有聽(tīng)懂用戶故事中的vertical slice（垂直切片）是什么，也不明白面向用戶做端到端的交付的真正意思。所以我雖然理所當(dāng)然的寫(xiě)了接近四年的用戶故事，但一直覺(jué)得PRD或許是一種更好的描述需求的方式。

后來(lái)去到一家民企，發(fā)現(xiàn)他們?cè)谑褂肞RD。剛開(kāi)始覺(jué)得這只是編寫(xiě)需求的不同方式，也挺開(kāi)心可以嘗試一下PRD這種需求寫(xiě)作格式的。但是當(dāng)?shù)枨髸r(shí)，我的一個(gè)同事把“允許用戶分章節(jié)下載”的需求放在整整6頁(yè)的word里給我時(shí)，我是懵的。第一眼就是完全看不下去，因?yàn)榭戳饲叭?yè)都看不到重點(diǎn)。

項(xiàng)目的背景，產(chǎn)品介紹等參與項(xiàng)目的人都應(yīng)該是很熟悉的了，卻占據(jù)了主要的位置。

等到終于在第4頁(yè)找到新增功能部分時(shí)，發(fā)現(xiàn)被寫(xiě)下來(lái)需求僅僅是“該功能包括1，2，3部分”的描述。

具體這個(gè)功能是怎么設(shè)計(jì)的，用戶是怎么使用的，并沒(méi)有指出來(lái)。這樣的文檔還要給用戶審核，用戶批準(zhǔn)后再開(kāi)發(fā)。但其實(shí)用戶最終得到的是一個(gè)黑盒子的功能交付，用戶其實(shí)完全不知道這個(gè)功能真正長(zhǎng)什么樣子，最后還需要再花時(shí)間去給用戶培訓(xùn)。

當(dāng)然，后面我看了其他PRD文檔的案例，得知這只是一個(gè)特別壞的個(gè)例。大多數(shù)的PRD還是會(huì)有交互式原型說(shuō)明產(chǎn)品功能的。

但當(dāng)我仔細(xì)看這些PRD文檔時(shí)，我還是發(fā)現(xiàn)PRD和用戶故事是有本質(zhì)區(qū)別的。之前我是一直不理解vertical slice用戶故事中vertical的目的和意義，直到我看到了上面那個(gè)很差的“允許用戶分章節(jié)下載”的PRD的例子。我在這6頁(yè)word的PRD文字里是完全看不到這個(gè)功能被用戶使用起來(lái)是什么樣子的，甚至這個(gè)功能長(zhǎng)什么樣子我也想象不出來(lái)。這時(shí)候我才明白一個(gè)功能點(diǎn)為什么要寫(xiě)成垂直切片用戶故事了。

這并不僅僅是為該功能點(diǎn)明確他的用戶是誰(shuí)，更是明晰這個(gè)用戶是如何使用這個(gè)功能的。如果這一點(diǎn)能夠做到足夠簡(jiǎn)單、直白，那所有參加項(xiàng)目的人一眼就能看到這個(gè)功能點(diǎn)對(duì)于某用戶的價(jià)值：用戶這樣操作這個(gè)功能，是不是對(duì)該用戶、對(duì)該階段的項(xiàng)目目標(biāo)增加價(jià)值的。

所以用戶故事垂直切片的一端是直接交付用戶價(jià)值的，而不是到這個(gè)具體功能點(diǎn)的細(xì)節(jié)部分就截止了。

PRD中的具體功能點(diǎn)對(duì)用戶的增值部分、對(duì)項(xiàng)目的增值部分我認(rèn)為是缺失的。PRD更多的是在大的層面描述項(xiàng)目的價(jià)值。例如PRD的前一部分肯定會(huì)寫(xiě)項(xiàng)目背景、項(xiàng)目意義、項(xiàng)目目標(biāo)等等內(nèi)容。甚至PRD之前還會(huì)有BRD、MRD等充分支持這個(gè)項(xiàng)目存在的合理性。證明項(xiàng)目是有意義、有價(jià)值的。

這在任何公司、任何項(xiàng)目上都是必要的，否則某個(gè)項(xiàng)目早在倡議階段就被砍掉了，大家就不會(huì)坐下來(lái)一起做這個(gè)項(xiàng)目了。

那么問(wèn)題來(lái)了，在確認(rèn)某個(gè)項(xiàng)目是有意義、有價(jià)值的時(shí)候，具體到產(chǎn)品上、具體到產(chǎn)品的某一個(gè)功能上，我們?cè)趺创_定它是有意義和價(jià)值的呢？

我們可以做競(jìng)品調(diào)研，看看別人做了ABCD哪些功能；也可以做用戶訪談看用戶說(shuō)他們需要ABCDEFGH哪些功能；以及通過(guò)用戶描述的問(wèn)題和不便，看是否可以由IJKLMN等功能點(diǎn)解決這些問(wèn)題。

然后我們把以上得到的這些ABCDEFGHIJKLMN功能點(diǎn)都列出來(lái)，篩選出優(yōu)先級(jí)高的ABCDEFMN幾個(gè)功能點(diǎn)組合成交付的第一個(gè)版本的產(chǎn)品。

但進(jìn)一步的問(wèn)題是，我們是怎么篩選出優(yōu)先級(jí)高的ABCDEFMN這幾個(gè)需求的呢？用戶反饋需要的急迫程度是一個(gè)參考點(diǎn); 在有些公司技術(shù)實(shí)現(xiàn)的難易在具體開(kāi)發(fā)過(guò)程中甚至?xí)桉{于需求優(yōu)先級(jí)之上，左右需求開(kāi)發(fā)的次序。

但僅僅根據(jù)用戶反饋的需求優(yōu)先級(jí)和技術(shù)難易程度所選出來(lái)的功能點(diǎn)，能完整的串成一個(gè)用戶場(chǎng)景嗎？如果我們把ABCDEFMN放在用戶流程圖上，發(fā)現(xiàn)它們都是分散的怎么辦？

開(kāi)發(fā)可能會(huì)最先提出質(zhì)疑。在傳統(tǒng)開(kāi)發(fā)邏輯中，開(kāi)發(fā)更喜歡整體的、橫向的開(kāi)發(fā)方式。因?yàn)樗麄冇X(jué)得可以把某一個(gè)開(kāi)發(fā)任務(wù)一起做了，例如花3天把整個(gè)產(chǎn)品所有涉及到用戶權(quán)限的功能的權(quán)限設(shè)置都開(kāi)發(fā)好。

先做高優(yōu)先級(jí)的幾個(gè)功能點(diǎn)的話，他們會(huì)覺(jué)得像是在“東一榔頭、西一棒子”，每個(gè)開(kāi)發(fā)任務(wù)都沒(méi)做完、每個(gè)開(kāi)發(fā)任務(wù)也都沒(méi)做好的感覺(jué)，例如下圖這樣。

這個(gè)時(shí)候我們就要回到vertical slice的用戶故事上來(lái)了。如果我們能保證每一個(gè)用戶故事都是一個(gè)完整的用戶特征點(diǎn)、都是一個(gè)完整的開(kāi)發(fā)模塊、都是用戶直接能夠使用的，那即使我們實(shí)現(xiàn)了一些高優(yōu)先級(jí)、但是分散的功能點(diǎn)也是沒(méi)有問(wèn)題的。

因?yàn)檫@一個(gè)用戶可以通過(guò)該功能完成TA的正常工作步驟，實(shí)現(xiàn)一個(gè)完整的 “我用這個(gè)特征點(diǎn)做了什么” 使用故事流程。

我們回到文章開(kāi)頭PRD和用戶故事的對(duì)比圖，可以更清晰的看出橫向切片PRD和垂直切片用戶故事的區(qū)別。

右側(cè)PRD文檔里包含了五大區(qū)域20多個(gè)模塊，每個(gè)模塊都是該產(chǎn)品全部?jī)?nèi)容的集合。例如產(chǎn)品結(jié)構(gòu)圖中列出的是該產(chǎn)品全部的功能；頁(yè)面邏輯區(qū)域列出的是該產(chǎn)品全部頁(yè)面的邏輯。PRD講究的是大而全、扣的是細(xì)節(jié)，更多的是關(guān)注在功能的全面羅列和細(xì)節(jié)的邏輯自洽。

每個(gè)色塊區(qū)域這么一層層橫向羅列下來(lái)，產(chǎn)品形象在ppt上，在向上匯報(bào)上很容易拔高，但具體的落地則需要大量的人力和時(shí)間去反復(fù)口頭溝通和敲定；也需要靠譜的開(kāi)發(fā)做好項(xiàng)目技術(shù)上的整體架構(gòu)，否則很容易產(chǎn)品一堆bug、代碼一團(tuán)漿糊。

而左側(cè)的用戶故事從標(biāo)題和概述可以很容易看出是哪一個(gè)用戶、哪一個(gè)功能。具體這個(gè)用戶通過(guò)這個(gè)功能要做什么的細(xì)節(jié)全部列在了acceptance criteria里了，開(kāi)發(fā)可以逐行按描述要求開(kāi)發(fā)，后續(xù)寫(xiě)test case也可以直接復(fù)用大部分。

支持這一個(gè)用戶故事的數(shù)據(jù)情況、相關(guān)項(xiàng)也都明確在了這一個(gè)用戶故事中。從上到下這么一眼順下來(lái)，感覺(jué)這一用戶需求點(diǎn)講的既具體而又明確。

每個(gè)功能的邏輯和數(shù)據(jù)都是相對(duì)獨(dú)立的，如果出現(xiàn)了什么問(wèn)題，既能夠及時(shí)、準(zhǔn)確的定位問(wèn)題所在，也不會(huì)影響其他用戶故事的開(kāi)發(fā)或者使用。

例如我工資條部分編寫(xiě)的數(shù)據(jù)表和字段的代碼僅支持工資條部分的功能，如果這里某一個(gè)字段出現(xiàn)問(wèn)題，它并不會(huì)影響到請(qǐng)假申請(qǐng)功能相關(guān)的數(shù)據(jù)表或者字段。請(qǐng)假申請(qǐng)功能依然能夠被繼續(xù)開(kāi)發(fā)或者使用。

從上面的對(duì)比可以看出，如果想要敏捷的迭代一個(gè)產(chǎn)品的特征和功能點(diǎn)，使用用戶故事也是更具有優(yōu)勢(shì)的。因?yàn)槊總€(gè)用戶故事從用戶價(jià)值到代碼實(shí)現(xiàn)都是相對(duì)模塊化、相對(duì)獨(dú)立的。后續(xù)修改功能或者新增功能，做產(chǎn)品擴(kuò)展、做產(chǎn)品整合都會(huì)方便很多。所以綜合來(lái)看，需求編寫(xiě)我更傾向于使用用戶故事的方式。