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

需求文檔是產品經理日常工作輸出最重要的文檔，需求文檔是在寫什么？應當包含什么內容？

弄清這個問題，首先要明確需求文檔的讀者是誰，讀者要從需求文檔中獲取到哪些內容，讀者的不同影響到需求文檔的組織形式，而組織形式又依賴于產品經理自身的習慣，不可一概而論。

以下是我理解的需求文檔該是什么樣子的，拋磚引玉，供大家探討。

需求文檔最重要的讀者首先是產品經理自己，無論是需求實現前用需求文檔講述需求的實現思路，實現時按需求文檔進行設計、研發、測試，還是需求上線后回顧需求文檔進行復盤總結，都是依照產品經理寫的需求文檔。其次的讀者才是負責需求實現的設計師、研發人員、測試人員以及其他產品經理。

按我的習慣，需求文檔會包含以下五個部分的內容。

一、需求變更日志和版本迭代記錄

第一部分是需求變更日志和版本迭代記錄。需求從提出到最終上線，中間必然經歷一些需求變更或方案調整，因而需要有變更日志來記錄這些變更。

需求變更日志并不只是寫需求新增或減少了哪些功能，而是更仔細些。

例如：需求中的A功能點，原來打算用方案一實現，但考慮到資源、現實場景的限制，改為用方案二實現，這個也要寫，雖然從結果上看仍然是實現了需求中的A功能點，但從過程上看，方案一到方案二的轉變，是產品經理思考的升級，也是對資源限制更深的考慮。

此外還應記錄清楚需求是因什么原因變更，變更前后是什么樣子，可能會產生哪些影響，以便后面查找細節。

而版本迭代記錄，除了包括對需求中功能的版本迭代，還應包括產品經理對這個需求思考路徑的迭代。

需求中功能的版本迭代，這個大家比較熟悉，不贅述，主要想說明下產品經理對需求思考路徑的迭代是什么？為什么要這么做？

之前提過，產品經理很大的工作是在做決策，因此決策質量很重要，而決策質量需要通過不斷地優化決策思考路徑來提高，產品經理應該記錄自己對需求的思考過程，對過程進行不斷總結和優化。

另外，將這些思考的過程展示出來及與其他同事討論，可以跳出自己固有的思維模式，兼容并包。

所以我一直認為產品經理在處理一個需求時，其思考路徑、決策依據應該公開透明，能夠讓所有參與需求的人都能夠可查看、可探討（來自瑞·達里歐，有興趣的朋友可以去看看他的《原則》）。

那么，我輸出需求變更日志和版本迭代記錄的過程是怎樣的呢？

按我的習慣，在輸出一個需求文檔的時候，會先按當下我能考慮的情況先寫一個Beta版，這時候我將它命名為V0.7版本，然后隔一天我再重新思考，看自己昨天寫的需求文檔，這時能發現很多不足的地方，那就從頭開始改一遍，標明需求有哪些變更，這時的版本是V0.8版本。

下一步找其他產品經理向他講述一遍這個需求文檔或在組內組織一次需求評審，綜合意見，再修改一遍，標明需求有哪些變更，這時的版本是V0.9版本，最后再找開發測試設計的同學進行需求評審，從開發測試設計的角度對需求的實現做一遍修改，標明有哪些變更，形成最終的版本V1.0。

這樣下來，一份需求文檔能夠包含產品經理對一個需求實現方案完整的思考過程，其中不僅有自己思考的升級，還有從研發、測試、設計等各個角度對實現方案的調整補充，是針對這個需求，在當前的資源限制、背景約束下最好的實現方案。

有了需求變更日志和需求版本迭代記錄，不僅可以做到需求的實現邏輯實現思路可溯源，完整記錄整個需求從被提出到上線多個版本，期間的產品思路、實現邏輯有了哪些變化，產品經理可時?；仡櫮脕韰⒖?，產品團隊可針對大的需求做針對性復盤，也可提供給后來接手工作的產品經理了解需求的完整迭代過程。

二、背景&方案&價值

背景、方案和價值，是需求文檔的核心，是任何需求在進入到實現階段前一定要想清楚、一定要反復探討的部分。

需求是背景下的需求。這里的背景，需要寫明白的內容可包括但不限于當前產品所處行業的現狀，產品/功能模塊所處的狀態、目標，開發團隊的資源限制、技術限制等。

最開始做產品經理時，體驗其他產品的一些功能，不免吐槽，這里怎能這樣做？應該那樣做啊，要是我的話一定能比他做得更好，諸如此類。

到后來做產品的經驗見長，才明白任何一個需求都受限于當時的背景狀況、資源限制，拋開這些背景談實現都是扯淡，產品經理要做的是在當前背景下，找到最佳的實現方案。因此，梳理需求背景是產品經理對當前資源現狀的考量，是實現需求的第一步。

方案是背景下需求的實現方案。既然需求會受到資源現狀的限制，那么方案也必然有所不同，甚至可能會有折中妥協，會有不完整的方案。有時需求本身就是試驗性質的，是為了快速測試效果，那么在方案上選擇一些實現簡單、開發難度較小的方案也就不足為奇了。

在寫方案時，可以按照「用戶-場景-問題-方案」這個框架簡要寫明實現方案，也就是什么樣的用戶在什么樣的場景下遇到了什么問題，提供的解決方案是什么——這里要求方案要經過提煉，能夠通過一句話說清楚。

價值是指實現這個需求能夠帶來什么樣的價值，包括用戶價值和業務價值，用戶價值是指實現這個需求能夠給用戶帶來什么樣的價值，例如提升用戶的使用體驗等；業務價值是指實現這個需求能給產品的業務帶來什么樣的價值，例如提升用戶留存或者提升業務收入等。

需求不一定要同時提供用戶價值和業務價值，也不一定兩個價值都需要為正（例如帶來很大的業務價值而犧牲很小的用戶價值也是可以的），具體需要依據產品當前的狀態來考慮，但不能帶來價值的需求一定是有問題的。

此外，在思考需求能夠產生什么價值時，同時要思考的是以什么數據指標來評估這個價值，也就是需求上線后效果的好與壞要有量化的指標。不一定所有的需求都能夠找到量化的效果指標，但一定要盡量找到這個指標。只有需求的效果能夠被衡量，產品才能夠往更優的方向迭代。

三、業務邏輯&流程說明&功能需求詳述

第三部分主要是需求實現的部分，我把它劃分為業務邏輯、流程說明和功能需求詳述。

業務邏輯部分描述的是需求中涉及到的數據流向和用戶流向，特別是需求涉及到多個系統時，數據和用戶在系統之間如何交互的（這部分的內容偏復雜，后面再單獨寫下我的理解）。

目前針對業務邏輯部分，我主要的輸出是多通道的泳道圖來描述系統間的交互。這里應該特別注意的是在說明數據流向時要兼顧考慮正常流程和異常流程，以及在說明用戶流向時要考慮清楚需求邊界。

此外，需求的復雜程度不同，可能還會包含頁面流程圖、頁面結構圖等。

功能需求詳述就是常說的原型。

我目前的習慣，在需求文檔的早期版本不喜歡輸出高保真的原型，而是傾向于用低保真原型加文字描述的方式來說明需求中的功能實現。

功能需求詳述以需求中的頁面為單位，分為原型圖、需求說明和交互說明三個部分。

原型圖對需求涉及的每個元素進行標注；需求說明針對原型圖中的標注進行文字說明，包括字段邏輯、按鈕邏輯、頁面邏輯等；交互說明則是針對一些非邏輯的交互進行說明，例如某些字段、需要突出顯示，頁面變化時需要怎樣的特殊效果等等。

四、相關文檔的集合

日常工作中，時常出現想要找需求的某個相關文檔時，四處搜索，浪費很多時間的情況，為此我形成了一個習慣，就是把需求文檔作為一個所有相關文檔的集合。如埋點文檔、設計稿、接口文檔、測試用例文檔、開發相關的鏈接、上線后的數據等，都以鏈接的形式整理在需求文檔中，這樣每次需要找需求的相關文檔，都可以從需求文檔中快速找到。

五、需求上線后的數據

凡是需求，必然要有驗證效果的數據，而從每一個失敗與成功的需求中不斷總結和反思，是產品經理成長的重要途徑。如上文所說，產品經理應該保持開放透明，那么就意味著產品經理對于需求輸出的實現方案，最終結果無論是好是壞，都應該將效果數據按實際公開，這既能夠促使產品經理自己不斷改進產品思路，也能夠讓參與需求的相關同事了解自己的工作成果，增加他們的參與感與成就感。

以上便是我理解的需求文檔應該包含的一些內容，可能過于繁雜，具體還是要根據每個人自己的工作習慣做取舍，僅供參考。

希望能幫到你。

本文由 @Isaac 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議