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

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

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

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

2018年我在一家外企剛開始做產(chǎn)品經(jīng)理時，接受了用戶故事的培訓。我當時問我老板為什么我們不寫PRD（產(chǎn)品需求文檔）？因為我所了解到的這個職位是要寫B(tài)RD、MRD、以及PRD的。我當時看了一下這幾個文檔的格式和頁數(shù)，感覺比寫用戶故事要高大上的多，看上去也更專業(yè)，因為要寫好幾個幾十頁的文檔呢。

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

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

后來去到一家民企，發(fā)現(xiàn)他們在使用PRD。剛開始覺得這只是編寫需求的不同方式，也挺開心可以嘗試一下PRD這種需求寫作格式的。但是當?shù)枨髸r，我的一個同事把“允許用戶分章節(jié)下載”的需求放在整整6頁的word里給我時，我是懵的。第一眼就是完全看不下去，因為看了前三頁都看不到重點。

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

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

具體這個功能是怎么設計的，用戶是怎么使用的，并沒有指出來。這樣的文檔還要給用戶審核，用戶批準后再開發(fā)。但其實用戶最終得到的是一個黑盒子的功能交付，用戶其實完全不知道這個功能真正長什么樣子，最后還需要再花時間去給用戶培訓。

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

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

這并不僅僅是為該功能點明確他的用戶是誰，更是明晰這個用戶是如何使用這個功能的。如果這一點能夠做到足夠簡單、直白，那所有參加項目的人一眼就能看到這個功能點對于某用戶的價值：用戶這樣操作這個功能，是不是對該用戶、對該階段的項目目標增加價值的。

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

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

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

這在任何公司、任何項目上都是必要的，否則某個項目早在倡議階段就被砍掉了，大家就不會坐下來一起做這個項目了。

那么問題來了，在確認某個項目是有意義、有價值的時候，具體到產(chǎn)品上、具體到產(chǎn)品的某一個功能上，我們怎么確定它是有意義和價值的呢？

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

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

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

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

開發(fā)可能會最先提出質(zhì)疑。在傳統(tǒng)開發(fā)邏輯中，開發(fā)更喜歡整體的、橫向的開發(fā)方式。因為他們覺得可以把某一個開發(fā)任務一起做了，例如花3天把整個產(chǎn)品所有涉及到用戶權(quán)限的功能的權(quán)限設置都開發(fā)好。

先做高優(yōu)先級的幾個功能點的話，他們會覺得像是在“東一榔頭、西一棒子”，每個開發(fā)任務都沒做完、每個開發(fā)任務也都沒做好的感覺，例如下圖這樣。

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

因為這一個用戶可以通過該功能完成TA的正常工作步驟，實現(xiàn)一個完整的 “我用這個特征點做了什么” 使用故事流程。

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

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

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

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

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

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

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

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