中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

寫需求文檔對于無論在哪個領域工作的產品經理來說都是必須要做的工作，我相信大部分產品經理在寫需求文檔上有自己的一套心得，回憶我自己剛入產品崗沒幾年那會兒，更多屬于能寫但自己總覺得沒有系統性且一些例如交互細節或邊緣case都常常會遺漏，直到現在我也一直在思考什么樣的需求文檔算好的。

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

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

那什么樣的文檔對于文檔的閱讀者：設計師、程序員來說就能達到上述說的理想狀態呢？

我們可以分角色來看：

設計師：關注UI、交互、前端數據呈現規范

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

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

前端程序員：關注用戶端交互和服務端交互

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

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

后端程序員：關注字段留痕和與前端交互

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

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

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

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

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

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

3.流程圖：某些業務流程復雜或涉及到多系統多角色交互的需要流程圖

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

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

6.業務邏輯（規則）描述：在toB領域會涉及很多角色間的協作，數據流轉，寫這個目的也是為了方便研發人員理解需求以及后續測試可以參照業務邏輯規則編寫用例和測試。

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

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

養成一個好的文檔書寫習慣，一方面對產品本身是一個通過系統性的再梳理發現問題的過程，另一方面對下游對接的研發和設計同學是提高他們效率降低出錯率的核心物料。