編輯導語:作為一名産品經理,撰寫需求文檔是必不可少的。那麼要如何去寫一份完整的需求文檔?作者總結了四個部分,詳細介紹了需求文檔的撰寫指南,有興趣的童鞋一起來看看吧。
對每位産品經理都知道需求文檔是最基礎的基本功,但是要想寫好需求文檔還真不是一件簡單的事情,那麼本篇文章我就向大家來分享一下這麼多年做産品經理以及帶産品線新人得出的經驗,要如何去寫一份完整的需求文檔。
一、需求文檔描述層次要想寫出好的需求文檔,那我們首先要明白什麼樣的文檔才算是一個好的需求文檔。在我看來,一份頂級的需求文檔至少要講清楚三個層次的問題:
- 是否設計正确:設計的需求是否正确(重要性:60%);
- 是否設計全面:産品模塊與業務規則描述是否全面(重要性:30%);
- 設計是否高效:設計的是否有可優化點(重要性:10%)。
我們來一個一個講。
第一個點實際上就是要求我們去設計對的需求,比如我們需要一個用戶下單功能,我們以是否完整的講通這個下單模塊作為依據,也就是在需求描述的過程中,我們來看你所設計的方案是否能跑通?開發是否可以實現?這樣稱之為需求的設計正确。
第二個點就是要求我們。對我們所定義的需求,例如下單需求在設計的過程中,不僅要描述主流程還要将與該流程相配合的相關其他模塊都描述清楚。
例如,下單過程中涉及的用戶中心,支付中心,風控中心都與你的訂單流轉有密切的關系,所以我們都應該去描述與之交互的規則。
第三個點實際上是在前兩者的基礎上進行一個升級,也就是當我們能正确的完整的描述一個需求之後接下來希望你所描述的需求能是最優方案,也就是能給用戶帶來更好的用戶體驗的一種方案。
例如我們下單可以設計的很麻煩,也可以在網站上增加一鍵快捷下單的方式那麼明顯後者就是優化後的設計方案。
二、需求文檔公式前面我們主要給大家談了需求文檔撰寫的,原則以及對應的重要性。接下來我們要談一談寫需求文檔經常會遇到的一些情況。
需求文檔其實本身撰寫沒有什麼複雜性,問題在于很多人撰寫需求文檔都寫不完整。這裡的寫不完整不是指他沒有遵循我們上面提到的全面性原則,也就是少了哪對哪個模塊的描述。
而是在他描述需求的時候描述的規則不完整。要麼是缺少對于某個環節具體的計算邏輯,要麼是缺少對于頁面上錯誤提示的描述。那麼這種問題的出現,實際上就是他對需求文檔的一個完整框架沒有建立一個認知。
我們寫需求文檔除了描述能看到的交互外,更多的要深入系統定義運行規則。因此我們可以用一個公式來解讀需求文檔:
需求文檔=系統規則 界面交互
- 界面交互:指的是原型加對應的交互規則,常見的如按鈕的交互樣式,錯誤提示,字段長度限制等等。
- 系統規則描述:指的是一個系統在各個節點運作時信息流處理邏輯。大家都知道計算機的本質或者說軟件系統的本質就是一個信息黑盒。
其實拆解一下需求,需求的本質就是将用戶所輸入的信息在一系列的規則處理情況下得到了用戶希望想要的信息結果。
像圖中我們就是将用戶想要計算的兩個數輸入到了一個系統中,在我們用程序定義的規則——除法規則的運算處理下,得到了用戶希望的信息輸出也就是商。
所以說,需求文檔中最重要的部分其實就是規則的描述,一個規則描述的完整與否決定了這個系統是否是用戶所需要。
三、需求文檔組成元素在前面說了這麼多之後,我們具體來看一下一份完整的需求文檔到底有哪些組成部分?我用這樣一張表來概括需求文檔的完整組成部分。
四、需求評審評什麼?
除了需求文檔之外,另一個相信大家都是有一定陰影的就是需求評審會。可能有無數同學在初次上需求評審會的時候。在面對各個。評審方提出的種種質疑下,讓自己對自己的設計喪失了信心。
所以我來為大家解讀一下需求評審。實際上,需求評審本質上就是在評審下邊這三個東西。
角色1:業務方
評審中關注方向:是否符合業務要求。
角色2:技術方
評審中關注方向:開發可行性。
角色3:上級
評審中關注方向:投入産出比。
因此隻要我們在實際評審和需求設計的階段,圍繞這三個角度去進行思考,就能大大避免一會少了這個部分邏輯說明,一會少了這個流程說明的局面。
五、最後作為一個産品經理,我們的工作核心是圍繞産品方案輸出的,不斷的通過一個新産品或者産品叠代來開展自己的持續性工作。
不管是日常的溝通,還是參加各式的會議,以及輸出相關的方案,我們的很多工作都需要通過一個核心中介來産出,這個核心中介産出就是:PRD。因此請大家練好基本功,這也是産品人最基本的職業要求了。
#專欄作家#
三爺,三爺茶館,人人都是産品經理專欄作家,2019年年度作者。《中台産品經理寶典》作者,原萬達高級産品、MBA特約講師、獨立創業者,現叮咚買菜B端産品線負責人,擁有多款集團項目從零到一經驗并帶領實現商業化布局。
本文原創發布于人人都是産品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
,更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!