適合90%團(tuán)隊(duì)的簡(jiǎn)易需求文檔（PRD）模版

這是Kevin的第 803 篇原創(chuàng)，

持續(xù)日更，做產(chǎn)品經(jīng)理的創(chuàng)業(yè)斜杠青年。

一個(gè)ideal到最小化產(chǎn)品的實(shí)現(xiàn)落地過(guò)程中，我們喜歡叫做MVP版本產(chǎn)品。這個(gè)最小化產(chǎn)品實(shí)現(xiàn)中，前期的投入和預(yù)算總是非常謹(jǐn)慎的。所以起初要么是創(chuàng)業(yè)團(tuán)隊(duì)，要么是一個(gè)大廠下的小項(xiàng)目組。

市面上的小團(tuán)隊(duì)比不上大廠的項(xiàng)目組，在產(chǎn)品經(jīng)理、開(kāi)發(fā)、運(yùn)營(yíng)、測(cè)試人員資源數(shù)量、和職位等級(jí)上都不如大廠。

在大廠里，存在小項(xiàng)目是團(tuán)隊(duì)成員“兼職”方式加入，比如本身處于在A業(yè)務(wù)線，但卻臨時(shí)去支援某個(gè)項(xiàng)目。

和創(chuàng)業(yè)一樣，在大廠的小團(tuán)隊(duì)里也面臨著生死攸關(guān)的問(wèn)題，但獲得的風(fēng)險(xiǎn)也低許多。比如項(xiàng)目遲遲沒(méi)有達(dá)到預(yù)期指標(biāo)，項(xiàng)目就會(huì)下架直接原地解散，但這創(chuàng)業(yè)的小團(tuán)隊(duì)來(lái)說(shuō)，這樣的損失成本可謂是最低的。

當(dāng)然了，如果成功了，所獲的收益也是比不上創(chuàng)業(yè)團(tuán)隊(duì)的。

因?yàn)檫@類(lèi)風(fēng)險(xiǎn)，小團(tuán)隊(duì)里每個(gè)人工作就有點(diǎn)特別了，基本上會(huì)身兼數(shù)職。比如產(chǎn)品經(jīng)理還上要能夠搞定商務(wù)、市場(chǎng)，下要搞定產(chǎn)品功能需求調(diào)研、同時(shí)還要扮演測(cè)試角色助力產(chǎn)品上線。

小團(tuán)隊(duì)在技術(shù)架構(gòu)的選型、和研發(fā)流程上都和成熟產(chǎn)品十分不同。比如在架構(gòu)設(shè)計(jì)上是選擇快速的單應(yīng)用、微服務(wù)、還是選擇成本高的分布式服務(wù)？

小團(tuán)隊(duì)寧可選擇單應(yīng)用實(shí)現(xiàn)業(yè)務(wù)，后期重構(gòu)，也不會(huì)早期做復(fù)雜的架構(gòu)設(shè)計(jì)和投入。

對(duì)于一個(gè)產(chǎn)品經(jīng)理來(lái)說(shuō)，市面上所傳播的各種需求文檔規(guī)范不盡其數(shù)，但在工作一定要要按某一個(gè)模版來(lái)嗎？

實(shí)際上不是的，同樣需求文檔也不是越復(fù)雜越好。

比如對(duì)于一個(gè)產(chǎn)品經(jīng)理，可能一份標(biāo)準(zhǔn)的需求文檔是下面這樣

登錄注冊(cè)的需求文檔

上面這個(gè)模版，包含了該頁(yè)面的測(cè)試用例、交互、前置條件、后置條件、字段規(guī)范，但實(shí)際上這類(lèi)PRD文檔完成時(shí)間需要非常長(zhǎng)的。對(duì)于每一個(gè)需求都這樣，那產(chǎn)品經(jīng)理估計(jì)有加不完的班了。

但或者至少也有這樣的

簡(jiǎn)單的需求描述

對(duì)于小團(tuán)隊(duì)，速度、和快速驗(yàn)證是第一使命。產(chǎn)品經(jīng)理的需求文檔是可以更加應(yīng)該在這小團(tuán)隊(duì)里簡(jiǎn)化的。上面2種文檔是極其笨拙的，所需要的范圍、撰寫(xiě)成本都高。

軟件類(lèi)互聯(lián)網(wǎng)產(chǎn)品，小團(tuán)隊(duì)往往就是一個(gè)產(chǎn)品經(jīng)理、前端開(kāi)發(fā)、后端開(kāi)發(fā)、UI設(shè)計(jì)師構(gòu)成，如果還要再繼續(xù)精簡(jiǎn)，那就是一個(gè)產(chǎn)品經(jīng)理、一個(gè)后端開(kāi)發(fā)、一個(gè)前端開(kāi)發(fā)即可。

團(tuán)隊(duì)雖小，但是要做的事情卻一個(gè)不能差，我們可以羅列出每個(gè)人會(huì)牽涉到的工作職能。

成員分工

麻雀雖小，五臟齊全。

在團(tuán)隊(duì)成員每個(gè)人都在多線程的工作狀態(tài)下，產(chǎn)品經(jīng)理顯然要選擇最簡(jiǎn)易的需求文檔撰寫(xiě)方式，既可以減少需求輸出時(shí)間、還能夠達(dá)到快速研發(fā)的目的。

這種方式有一個(gè)前置條件：需要有至少3年以上的工作經(jīng)驗(yàn)產(chǎn)品經(jīng)理才能勝任

理由很簡(jiǎn)單：越是簡(jiǎn)單的需求文檔撰寫(xiě)，就越需要只關(guān)注重要的部分；而不是花時(shí)間在其他無(wú)用的需求上。

簡(jiǎn)易需求文檔撰寫(xiě)模版

我建議小團(tuán)隊(duì)（10人以內(nèi)的研發(fā)團(tuán)隊(duì)），需求文檔用簡(jiǎn)易方法撰寫(xiě)，注意下面模版不是以文檔的結(jié)構(gòu)開(kāi)始的，而是列舉了文檔的必要部分

1.前置條件說(shuō)明

說(shuō)明了當(dāng)前操作是需要依靠前置條件的，比如在Pmtalk下的活動(dòng)報(bào)名H5頁(yè)面，需要用戶的賬戶完成注冊(cè)，在微信授權(quán)登錄-手機(jī)號(hào)綁定-信息填寫(xiě)后才能選擇支付。

前置條件是非常重要的，比如IOSapp是否能提供游客身份、以及用戶體系分層都是前置條件最常見(jiàn)描述的。

2.字段類(lèi)型長(zhǎng)度

字段類(lèi)型長(zhǎng)度其實(shí)需求文檔出現(xiàn)的頻率最高的，因?yàn)槊總€(gè)頁(yè)面都會(huì)有字段。人數(shù)、時(shí)間、價(jià)格、產(chǎn)品名稱(chēng)、文章標(biāo)題等，都需要一個(gè)規(guī)范定義。

3.計(jì)算規(guī)則

計(jì)算規(guī)則并不是業(yè)務(wù)邏輯，比如在下面的阿拉丁小程序榜單里涉及到了應(yīng)用榜單排名。背后就是對(duì)應(yīng)的算法規(guī)則

小程序排名

小程序排名計(jì)算規(guī)則

當(dāng)然這類(lèi)計(jì)算規(guī)則越到后期肯定是希望系統(tǒng)來(lái)完成，人工的參與度降低。所以在后面也會(huì)有對(duì)應(yīng)的AI算法、數(shù)據(jù)修正。但在早期產(chǎn)品經(jīng)理必須說(shuō)明清楚

4.文案說(shuō)明

文案并不是等于內(nèi)容運(yùn)營(yíng)，而是指的是對(duì)應(yīng)產(chǎn)品的按鈕、頁(yè)面、其他樣式下的文案。尤其是做微信生態(tài)下的產(chǎn)品類(lèi)型，這類(lèi)文案和轉(zhuǎn)化率、訪問(wèn)量、傳播數(shù)據(jù)直接相關(guān)。

比如微信小程序的分享

比如H5的分享提示文案

3.圖片尺寸和大小

圖片無(wú)論是由后臺(tái)上傳還是前端展示，都需要給出對(duì)應(yīng)的尺寸說(shuō)明，否則就會(huì)造成用戶閱讀變形，體驗(yàn)極差。

當(dāng)然還有簡(jiǎn)單粗暴的方法交給系統(tǒng)進(jìn)行對(duì)應(yīng)固定尺寸的裁剪和處理。

同樣對(duì)視頻、其他類(lèi)型的文件也要說(shuō)在需求文檔中給出對(duì)應(yīng)的格式、尺寸、大小，方便在系統(tǒng)進(jìn)行存儲(chǔ)、同時(shí)提供給用戶展示。

這類(lèi)一般需要有經(jīng)驗(yàn)的前端開(kāi)發(fā)或UI設(shè)計(jì)師進(jìn)行問(wèn)題處理，否則產(chǎn)品經(jīng)理自己拍腦袋給出的尺寸很容易不適用。

4.操作交互

交互說(shuō)明要區(qū)分終端設(shè)備和產(chǎn)品形態(tài)2個(gè)緯度。

比如終端設(shè)備可以分為PC端、移動(dòng)端、還有穿戴設(shè)備等領(lǐng)域

在產(chǎn)品形態(tài)上可以分為客戶端、小程序、web、H5形式類(lèi)型。

上面小程序的hover、loading加載交互，提升了用戶體驗(yàn)。

交互說(shuō)明既要建立在終端設(shè)備上、還要建立在產(chǎn)品形態(tài)上。

比如在PMTalk里，我們最常在需求文檔描述的是按鈕的點(diǎn)擊、條件判斷2類(lèi)狀態(tài)樣式。

當(dāng)然了，如果團(tuán)隊(duì)里有資深的前端、客戶端開(kāi)發(fā)工程師，這類(lèi)交互的描述即使沒(méi)有，也能夠帶來(lái)非常細(xì)膩的用戶體驗(yàn)。

畢竟做的多了，自然就知道好的產(chǎn)品需要什么。

5.需求背景

需求背景是為了同步給對(duì)應(yīng)上下游同事，告訴當(dāng)前需求的作用。不能簡(jiǎn)單認(rèn)為給任務(wù)他們就應(yīng)該做，讓團(tuán)隊(duì)得參與感、榮譽(yù)感也是十分重要的。所以搞清楚需求背景，讓大家清楚現(xiàn)在的問(wèn)題和優(yōu)先級(jí)

為什么做，當(dāng)前需求解決了什么問(wèn)題，預(yù)計(jì)階段規(guī)劃

6.版本號(hào)&更新時(shí)間

更新時(shí)間也是需求文檔極為重要的一環(huán)節(jié)，版本號(hào)還是同理，表明了當(dāng)前文檔的有效性。在文檔中寫(xiě)明需求更新時(shí)間，同時(shí)如果是線下文檔還要標(biāo)明文檔的版本里

7.業(yè)務(wù)邏輯圖

業(yè)務(wù)邏輯圖是為了講述需求背后的業(yè)務(wù)邏輯，只有團(tuán)隊(duì)成員清楚了業(yè)務(wù)邏輯，才能著手進(jìn)行開(kāi)發(fā)。畢竟需求文檔里的文檔描述，是不能保證100%描述齊全，同時(shí)還存在閱讀者可能沒(méi)有仔細(xì)看完。有時(shí)候還因?yàn)槲臋n的排版問(wèn)題，開(kāi)發(fā)或設(shè)計(jì)直接遺漏了某部分需求，導(dǎo)致功能缺失。

業(yè)務(wù)邏輯

業(yè)務(wù)邏輯既可以讓系統(tǒng)開(kāi)發(fā)中保證串起來(lái)。

同時(shí)團(tuán)隊(duì)成員還能明確知道當(dāng)前需求的定位。業(yè)務(wù)邏輯圖可以用時(shí)序圖、泳道圖、UML圖等表示。但要想實(shí)現(xiàn)簡(jiǎn)單需求文檔的實(shí)現(xiàn)，最快的方法還是用時(shí)序圖。

8.詞匯表

和文案不同，詞匯表收集了通用的功能名稱(chēng)、字段命名。比如PMTalk在早期有簽約作者、專(zhuān)欄作者，但實(shí)際上背后是一個(gè)邏輯。所以為了避免~混淆，就統(tǒng)一更改為專(zhuān)欄作者。

好，今天的分享就在這。如果你還想下載本文截圖的需求模版，公眾號(hào)回復(fù)：PRD模版

我的新書(shū)

購(gòu)買(mǎi)后公眾號(hào)回復(fù)：迭代，進(jìn)入讀者群

資深產(chǎn)品經(jīng)理社群：每天體驗(yàn)1款app

我創(chuàng)建了一個(gè)產(chǎn)品經(jīng)理社群。加入后365天，每天體驗(yàn)一款A(yù)PP。提升產(chǎn)品設(shè)計(jì)能力，同時(shí)有1300份體驗(yàn)報(bào)告幫助你找到競(jìng)品。

從優(yōu)化&建議、商業(yè)模式、運(yùn)營(yíng)、功能描述、交互設(shè)計(jì)、產(chǎn)品定位至少6個(gè)維度，體驗(yàn)一款應(yīng)用。

平均1天1塊錢(qián)，掃碼購(gòu)買(mǎi)即可加入

連續(xù)體驗(yàn)90款應(yīng)用，通過(guò)后原路退回

推薦閱讀：

情人節(jié)小技巧｜用產(chǎn)品思維找女/男朋友

產(chǎn)品經(jīng)理必了解的技術(shù)架構(gòu)