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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

右側PRD文檔里包含了五大區域20多個模塊，每個模塊都是該產品全部內容的集合。例如產品結構圖中列出的是該產品全部的功能；頁面邏輯區域列出的是該產品全部頁面的邏輯。PRD講究的是大而全、扣的是細節，更多的是關注在功能的全面羅列和細節的邏輯自洽。

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

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

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

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

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

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