對不同崗位的人而言，關(guān)注需求文檔的哪些方面呢？本文作者分享了設(shè)計(jì)師、程序員眼中理想的需求文檔，大家可以一起了解一下。

寫需求文檔對于無論在哪個領(lǐng)域工作的產(chǎn)品經(jīng)理來說都是必須要做的工作，我相信大部分產(chǎn)品經(jīng)理在寫需求文檔上有自己的一套心得，回憶我自己剛?cè)氘a(chǎn)品崗沒幾年那會兒，更多屬于能寫但自己總覺得沒有系統(tǒng)性且一些例如交互細(xì)節(jié)或邊緣case都常常會遺漏，直到現(xiàn)在我也一直在思考什么樣的需求文檔算好的。

其實(shí)對于文檔的評判，像設(shè)計(jì)師或程序員更有發(fā)言權(quán)，因?yàn)樗麄兪俏臋n的消費(fèi)對象。那這篇文章就講講我如何看待需求文檔以及目前我正在用的框架，如果大家有好的經(jīng)驗(yàn)也可以在評論區(qū)分享。

關(guān)于需求文檔有一點(diǎn)我相信能和大家達(dá)成共識的，就是一篇理想的文檔是設(shè)計(jì)師和研發(fā)通過文檔就能指導(dǎo)他們的工作開展，他們需要知道的文檔上都能找到，理論上文檔交付出去后在研發(fā)過程中不需要產(chǎn)品經(jīng)理就能順利推動了。雖然這是理想狀態(tài)，但以此為目標(biāo)其實(shí)就成功一半了。

那什么樣的文檔對于文檔的閱讀者：設(shè)計(jì)師、程序員來說就能達(dá)到上述說的理想狀態(tài)呢？

我們可以分角色來看：

設(shè)計(jì)師：關(guān)注UI、交互、前端數(shù)據(jù)呈現(xiàn)規(guī)范

針對UI這一點(diǎn)要求需求文檔內(nèi)的原型包括原型內(nèi)的每個元素都能清晰的展示出來，這個看上去基本都能做到對吧，但我在早期做產(chǎn)品的時候經(jīng)常會忘掉畫一些元素，比如空狀態(tài)、表格翻頁組件等。

除此之外，還有一些前端界面的交互，比如有些按鈕會涉及到禁用，那么禁用狀態(tài)就要出設(shè)計(jì)圖，還比如有些按鈕點(diǎn)擊后需要加載，加載樣式需要設(shè)計(jì)等，數(shù)據(jù)呈現(xiàn)規(guī)范也是一個容易忽略的要素；比如有些字段的長度限制，不同的長度限制會影響到設(shè)計(jì)，通常特別長的字段設(shè)計(jì)師把這個字段單獨(dú)用一行呈現(xiàn)，如果特別短那么就有可能一行放多個字段，還比如字段過長是截?cái)噙€是…替代超過的部分，這些都會涉及到設(shè)計(jì)稿的輸出效果，如果不約束溝通成本就會增大。

前端程序員：關(guān)注用戶端交互和服務(wù)端交互

通常設(shè)計(jì)師出設(shè)計(jì)稿后會給到前端程序員而他們會將高保真UI和產(chǎn)品需求文檔一起結(jié)合著看，我通常會在設(shè)計(jì)稿更新后把他們更新到需求文檔上，這樣程序員就直接可以在文檔上看，不用在兩個文檔上來回切：對于交互層面的需求描述過去會經(jīng)常出現(xiàn)一個問題：自己覺得交互描述差不多了，但中間會有一些細(xì)節(jié)缺失或描述的模棱兩可。

舉個例子：比如描述一個開關(guān)的組件，差的描述：點(diǎn)擊開關(guān)后開關(guān)關(guān)閉；好的描述：單機(jī)開關(guān)后開關(guān)變?yōu)殛P(guān)閉狀態(tài)的icon樣式，當(dāng)然正常情況下開關(guān)操作一般會有很多較驗(yàn)，比如某些情況下開關(guān)有依賴關(guān)系，點(diǎn)擊后不能觸發(fā)會報(bào)錯，那什么情況下出現(xiàn)報(bào)錯，不同的報(bào)錯的提示語是什么，這個就涉及到和后端交互的邏輯了，還比如有些字段是寫死的，不需要和后端交互，這類細(xì)節(jié)理想狀態(tài)下都需要寫明確。

后端程序員：關(guān)注字段留痕和與前端交互

數(shù)據(jù)留痕指的是這個需求當(dāng)中要有哪些數(shù)據(jù)是要記錄在數(shù)據(jù)庫的，當(dāng)然怎么記錄，表怎么設(shè)計(jì)這個產(chǎn)品通常不管也沒能力管，但記錄什么產(chǎn)品要定義，有些情況下如果需求目標(biāo)表明確其實(shí)后端同學(xué)也是可以根據(jù)自己的理解記字段，但在我的經(jīng)驗(yàn)當(dāng)中，如果產(chǎn)品不去約束很多時候研發(fā)會遺漏一些字段。

和前端的交互邏輯大部分產(chǎn)品經(jīng)理其實(shí)也不用考慮，但要看業(yè)務(wù)，比如像我之前做的前后端需要實(shí)時音視頻交互的需求就需要需求文檔中描述清楚例如斷網(wǎng)之后包括斷網(wǎng)重連的交互要求，還包括有的系統(tǒng)并發(fā)比較大的，那數(shù)據(jù)進(jìn)出的優(yōu)先級可能也要產(chǎn)品來定義，這也是后端和前端交互層面的東西。關(guān)于這個層面可能對于做面向toB產(chǎn)品的產(chǎn)品經(jīng)理要求比較高，對于toC的話還是主要注重和用戶交互層部分的需求描述。

清楚了上述幾個查閱文檔角色的需求后其實(shí)就可以考慮怎么輸出一份有框架性的需求文檔了，這里還要說一下文檔中的需求背景和目標(biāo)的描述在我看來也挺重要的，某些情況下即便文檔中有描述且在需求方看來沒啥問題，但理解會存在偏差，文檔想表達(dá)A但程序員理解成B，那么在這個情況下如果能明確需求目標(biāo)和背景，程序員有了這層認(rèn)知，那就能一定程度上減少偏差了。

這里我也分享下目前我采用的文檔框架（偏toB一些），供大家參考：

1.需求背景或目的：簡短描述，為了避免出現(xiàn)一些需求理解的偏差

2.需求要點(diǎn)：分要點(diǎn)概括本需求涉及的內(nèi)容，明確需求邊界

3.流程圖：某些業(yè)務(wù)流程復(fù)雜或涉及到多系統(tǒng)多角色交互的需要流程圖

4.交互原型：通常我會把描述直接通過卡片形式貼在原型邊上，這樣預(yù)覽起來更直接一點(diǎn)。

5.功能點(diǎn)描述：涉及的所有交互都要描述，哪怕再簡單的“點(diǎn)擊彈框右上角的關(guān)閉icon后彈框隱藏”。也包括一些邊緣場景極限場景等。

6.業(yè)務(wù)邏輯（規(guī)則）描述：在toB領(lǐng)域會涉及很多角色間的協(xié)作，數(shù)據(jù)流轉(zhuǎn)，寫這個目的也是為了方便研發(fā)人員理解需求以及后續(xù)測試可以參照業(yè)務(wù)邏輯規(guī)則編寫用例和測試。

7.字段表：整理出需求中涉及后端記錄的字段，字段名稱、字段所在頁面、字段描述（字段留存規(guī)則）。

以上就是我對一份好的需求文檔的理解。

養(yǎng)成一個好的文檔書寫習(xí)慣，一方面對產(chǎn)品本身是一個通過系統(tǒng)性的再梳理發(fā)現(xiàn)問題的過程，另一方面對下游對接的研發(fā)和設(shè)計(jì)同學(xué)是提高他們效率降低出錯率的核心物料。