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

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

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

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

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

我們可以分角色來看：

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

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

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

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

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

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

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

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

和前端的交互邏輯大部分產(chǎn)品經(jīng)理其實也不用考慮，但要看業(yè)務(wù)，比如像我之前做的前后端需要實時音視頻交互的需求就需要需求文檔中描述清楚例如斷網(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的話還是主要注重和用戶交互層部分的需求描述。

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

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

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

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

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

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

5.功能點描述：涉及的所有交互都要描述，哪怕再簡單的“點擊彈框右上角的關(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è)計同學(xué)是提高他們效率降低出錯率的核心物料。