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

適合90%團(tuán)隊(duì)的簡易需求文檔（PRD）模版一個(gè)ideal到最小化產(chǎn)品的實(shí)現(xiàn)落地過程中，我們喜歡叫做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)理、開發(fā)、運(yùn)營、測試人員資源數(shù)量、和職位等級(jí)上都不如大廠。

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

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

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

因?yàn)檫@類風(fēng)險(xiǎn)，小團(tuán)隊(duì)里每個(gè)人工作就有點(diǎn)特別了，基本上會(huì)身兼數(shù)職。比如產(chǎn)品經(jīng)理還上要能夠搞定商務(wù)、市場，下要搞定產(chǎn)品功能需求調(diào)研、同時(shí)還要扮演測試角色助力產(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)理來說，市面上所傳播的各種需求文檔規(guī)范不盡其數(shù)，但在工作一定要要按某一個(gè)模版來嗎？

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

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

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

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

但或者至少也有這樣的

簡單的需求描述

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

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

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

成員分工

麻雀雖小，五臟齊全。

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

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

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

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

1.前置條件說明

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

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

2.字段類型長度

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

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

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

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

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

4.文案說明

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

比如微信小程序的分享

比如H5的分享提示文案

3.圖片尺寸和大小

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

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

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

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

4.操作交互

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

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

在產(chǎn)品形態(tài)上可以分為客戶端、小程序、web、H5形式類型。上面小程序的hover、loading加載交互，提升了用戶體驗(yàn)。

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

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

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

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

5.需求背景

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

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

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

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

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

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

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

同時(shí)團(tuán)隊(duì)成員還能明確知道當(dāng)前需求的定位。業(yè)務(wù)邏