前言
很多產品新人，入門產品時，最想先了解的都是如何畫原型，如何寫需求文件，這很奇怪。 一個產品一個需求文件，就像在平臺上可以搜到很多關於需求文件的文章；看了這麼多文章，就沒有一個需求文件是統一的，這是為什麼？我覺得可能還是要根據需求的實際情況以及當時開發緊急程度來定需求文件的合理格式以及是否使用需求文件會比較好。不管怎麼講需求文件作為一款產品的傳承檔案，非常重要！ 告訴大家需求文件要怎麼寫，卻很少有說為什麼這樣寫的？大家把關注點都在放在如何實現，如何呈現，卻沒有關注為什麼這麼寫？像很多大咖常說的術與道，術重要，道更重要，知其然更要知其所以然！
一、萬物起源
碰到任何問題，最長見的思維方式即為：問題三要素——是什麼、為什麼、怎麼做。這是幾乎所有行業、所有人群面對事情時，最常見的思維方式。
筆者認為基於最經典、高效、實用的思維方式的基礎上，可以每個人針對不同的知識體系、思考方式、經驗總結等維度，總結出自己的思維方式。
筆者常使用的方式為多年前從社會經濟學老師那裡學來的，做了補充和最佳化，分享給大家：
在特定的時間、特定的地點、特定的人群因為特定的原因而做了特定的事件。達成該特定事件前，有哪些預期，實際達成的效果是什麼樣的，中間有怎麼的落差，以後處理該類事件時，如何最佳化方式。
按照上述思維方式，我們將要寫的需求文件當做一個特定的事件，透過剖析該特定事件被觸發的前置條件、後置補充內容，來實現對需求文件的分析。
二、什麼是需求文件？
筆者將需求文件定義為：用於闡述產品，滿足協同人員開發的內容文件。該定義中有兩個重要點：
-
闡述
-
即為說明要開發的產品是什麼。此處的“是什麼”區別於產品說明文件，產品說明文件類似於商品說明書，用於告知使用者我的產品該怎麼使用。 而此處的“是什麼”是告知該產品的相關人員，該產品有哪些功能，這個功能要怎麼呈現，該怎麼實現。具體包含以下幾個方面：
（1）為什麼要做這個產品？ 該產品是來自哪裡的需求，是內部版本迭代最佳化、Bug修復、新增功能點，還是來自業務部門的需求，或者來自使用者的反饋需求。 必須交代清楚做該產品的專案背景，一方面有利於開發人員更好的瞭解整體專案，從而更順利地制定專案計劃、專案進度、專案達成； 另一方面，產品開發完成後存檔的文件，有助於後續對該產品的覆盤、版本迭代，Bug問題溯源，甚至對出現人員異動時，有助於接盤人員快速瞭解專案，熟悉產品整體的前因後果。
（2）該產品要解決哪些衝突？ 需求來自於使用者的衝突，使用者在使用中遇到了什麼困難、疑惑、焦慮等不可調和的問題等待被解決。 在與使用者開展調研、訪談等溝通時，充分了解使用者的衝突，及急需解決的痛點，有助於產品經理在產品規劃階段，更精準地把握好方向，做出更符合使用者訴求的產品。 同時，在瞭解衝突的溝通中，除了精準獲取到使用者的核心訴求，還會得到很多非核心訴求，這些來自於使用者潛意識中的需求，為以後產品的發展提供了很好的幫助。 將這些需求羅列出來，整理到需求池，有助於以後與使用者、業務進行再次溝通時作對比，從而去偽存真，對需求池中的需求做好優先順序排序，並根據實際業務發展階段和公司整體要求，劃分好產品階段，對需求池中的需求進行實現，從而促使產品朝向更好的方向發展。
（3）該產品實現了哪些目的？ 任何產品的實現，不僅僅要滿足使用者的需求，更要在解決衝突時達成更多的目的。而這個目的分為物質層面和精神層面兩個維度。 1）物質層面 產品的上線，解決了公司業務層面的流程，滿足了業務需要，滿足了使用者的使用，這是產品首要，且是最核心的目的。 而在滿足最核心目的之後，是否有一些延伸的產品需求——減少了操作步驟、最佳化了互動流程，為實現公司層面的獲客、啟用、留存、轉化、二次推廣等各環節起到促進作用。 2）精神層面 產品的上線，解決了使用者的困難、疑惑和焦慮，解決了業務部門無法正常使用過程中的煩躁不安，這是產品最核心的目的在使用者心裡的反饋。 同時，在解決使用者優先順序最高的負面情緒的前提下，使得使用者對產品的感官，對企業品牌的好感度提升，是產品上線所能達成的最好效果了。
-
滿足協同人員
-
即該需求文件是給哪些協同人員看的。此處的“協同人員”不僅僅是開發人員，而是產品從交付原型至最終上線，過程中所涉及的所有參與者。
這些協同人員基於各自崗位和職責，對需求文件的要求也是不一樣的，這是所有產品經理在編寫需求文件時應尤為注意的點。
以筆者當前的公司為例，協同人員包括以下群體： 產品經理：大部分公司都會有不止一個產品經理。每個產品經理在負責自己的產品線時，所輸出的需求文件對其他產品經理的工作是有必要性的。 設計師：以做靜態頁面、gif圖、互動設計等視覺體驗的專業人員。 前端開發：以輸入靜態頁面、互動動效為主，包含各類判斷邏輯，最終以HTML為輸出樣式的專業人員。 APP開發：使用者能看到的APP的頁面樣式、互動樣式、邏輯輸出的專業人員。 後臺開發：後臺建表、設定邏輯規則，介面傳輸資料、欄位的專業人員。 測試工程師：檢測產品在常規環境、非常規環境，檢測所有存在因素及隱患的專業人員，是確保產品上線無Bug的最後一道防線。
-
“闡述”與“滿足協同人員”間的關係
-
凡事的存在，皆存在因果。滿足協同人員，此為因，而為了滿足協同人員，輸出的需求文件，即為果。因果之間互相作用，促成了產品最終的交付及上線。
三、需求文件的意義是什麼？
把正確的東西交給正確的人，滿足協同人員的訴求，即是需求文件存在的意義。
如何寫出滿足協同人員訴求的需求文件？首先，需要觀察不同的協同人員具體的工作場景，基於他們工作場景中的衝突，發現他們的需求，從而輸出的解決方案，就是最好的需求文件。
-
產品經理的訴求
-
（1）產品部門的版本需求討論、需求評審會。
在版本任務的討論中，在與其他產品經理講述所規劃的功能時， 版本記錄、專案背景、專案框架圖、流程圖，可以快速讓其他產品經理瞭解整體專案，並根據專案背景，給出意見。
（2）與其他產品經理所負責的內容有交叉點。
當一個完整專案，每個產品經理負責部分內容的時候，各自負責部分功能的需求文件有助於其他產品經理從文件中發現交叉點中的銜接是否合適，各功能模組的整體融合性。
（3）Bug處理。
再厲害的程式設計師也不敢保證產品上線後不出現任何問題，當產品上線後出現問題，需求文件有助於產品經理快速找到規劃的初衷，根據之前的情境給出精準的解決方案。
（4）版本迭代。
當產品在不同時期，做不同的版本迭代時，之前的需求文件尤為重要，有助於負責該專案的產品經理快速熟悉往期規劃的初衷、目的和當前的效果及不足，並在迭代版本中對往期問題進行修復，在新的規劃中避免不必要的坑。
（5）人員異動。
如果出現人員異動（人員專案變更、人員離職等），有助於新接手的產品經理快速熟悉專案，確保專案規劃不會因個人經驗、個人喜好、習慣等原因，出現太大的偏差。
基於以上場景和目的，其他產品經理對需求文件的訴求需要得到的資訊：誰、在什麼時間、因為什麼原因，做了什麼內容，滿足了什麼人的需求，變動內容及節點、階段性規劃。
-
設計師的訴求
-
設計師是專案實施階段的第一步。確定版的需求在落地執行時，首先是由設計師開始製作設計圖。專案的整體功能有哪些、基於什麼背景、未來的規劃方向，需要在文件中給出建議和說明，有助於設計師按照產品經理的設想，設計出符合或高於期待的產品設計圖。
基於上述場景和目的，針對設計師角色，產品經理在編寫需求文件時，需要告知的資訊：因為什麼原因，給什麼特點的群體，做什麼圖，當前競品什麼情況、公司什麼情況、市場什麼情況，想達到什麼效果，後期發展方向（業務、功能、設計方向等）。
-
開發人員的訴求（前端、APP、後臺、測試）
-
前端開發：開發過程中，側重瞭解涉及前端部分的頁面功能、互動效果、互動邏輯； APP開發：開發過程中，側重瞭解頁面元素、頁面樣式、功能、與後臺間的介面引數傳遞； 後臺開發：開發過程中，側重瞭解功能、這些功能在後臺的資料結構搭建、如何建表、功能邏輯、與前臺兼的介面引數傳遞； 測試工程師：在產品實現過程中，側重從產品規劃中瞭解整體功能，從而寫測試用例，以及產品上線前根據設計圖的樣式、文件表述的功能規則，做功能測試。 基於刪除場景，產品經理在編寫需求文件時，需要告知開發人員的資訊：因為什麼原因，針對什麼專案，做什麼功能，包含哪些頁面元素、頁面樣式、互動邏輯、實現效果。
-
注意事項
-
盡信書不如無書。各公司的組織架構、部門角色劃分、業務開展的推動因素、公司發展所處的階段均不相同，雖大道同源，但總有差異化表現。
需要產品經理針對協同人員做好分層、分類，切實與相關人員深入溝通，瞭解他們的習慣，瞭解他們的認知，輸出他們需要的需求文件，才能夠確保資訊的透明化，保證開發人員全面瞭解規劃的內容。
同時，輔助以良好的溝通機制和技巧，則有助於開發效率的提高和產品上線的進度保障。
四、如何寫需求文件？
-
寫文件先看人
-
需求文件與產品經理前期做使用者調研時的使用者畫像很相似。
在做使用者畫像時，透過與目標群體各種方式的溝通，獲取使用者的基本資訊、興趣、習慣、家庭情況、對產品相關業務的瞭解程度、接受程度、煩惱和期待等等，從而建立使用者檔案，輸出使用者的判斷結果。
在寫需求文件前，面對我們的使用者——相關協同人員，產品經理需要去了解他們。瞭解他們的工作方式、工作習慣、工作態度、工作認知、工作能力等與工作相關的內容，同時，對他們與人相處的方式、生活習慣、興趣愛好等等的瞭解，有助於產品經理更全面的瞭解，從而建立更加立體的使用者畫像。
在輸出判斷結果時會更準確，寫需求文件會更有側重點——哪些是他們需要知道的，哪些是他們需要特別詳細表述的，哪些是需要特殊標註的，哪些是省略表述即可的。
-
文件規範
-
（1）版本記錄 誰：該文件是誰編寫的，便於快速找到對應的負責人員，同時，後期有助於在需求文件庫中建檔分類。 時間：什麼時間編寫的該文件，旨在告知該功能是什麼時間要開始做，便於後期溯源時，快速定位。 事件：針對什麼產品、什麼功能做的規劃，其實就是文件標題。 版本號：便於記錄產品不同版本的節點做了什麼內容及調整，同時，針對不同的系統，有助於使用統一的版本號做管理。 上線計劃：依據上線計劃倒推測試周期、開發週期、設計週期，從而給參與該專案的協同人員約定好時間，便於更好的把控專案進度。 評審及修改：專案完成後的需求評審建議和結果，針對初稿內容做了哪些修改。此處一定要詳細，後續調整內容時，評審建議和修改事項是很重要的可參考的細節點。
（2）版本說明 專案背景：清楚地寫出為什麼要做該專案，誰要求做的。 核心需求：為了解決什麼衝突。 預期目的：想達到什麼結果，後續有什麼進一步的規劃。 詳細的專案背景有助於所有參與人員快速地瞭解專案是怎麼回事。
（3）設計規範 設計規範來源於產品經理對該產品的整體瞭解：在做完市場分析、行業分析、競品機構分析、使用者調研之後，針對自己要做的產品，產品經理會形成自己的整體構思和產品走向模型。
而這個構思就是需要表達給設計師的理念——要做一款什麼樣的產品，要達到什麼效果。
關於設計理念的表達，不同的公司有很大的差別，以及整個行業對這塊內容都沒有統一的觀點。
一種觀點認為，產品經理只需要輸出黑白灰原型圖即可，其他的都交給設計師處理，給設計師足夠的發揮空間；
另一種觀點認為，設計師對要做的產品，不瞭解緣由，直接去設計會有偏差，最終交付的產品大部分都不符合；
還有種觀點認為，要看設計師的水平再來決定，水平高的不需要產品經理說什麼，都可以交付足夠讓人驚豔的設計，水平低的說再多，也做不出效果，而大部分公司都屬於第二種情況。
綜上所述，崗位不同、職位不同、個人認知的不同，以及最重要的資訊接收到處理個人間都是有差異的，最終呈現在產品上的內容就會有很大的差異。
而規避這類問題，最好的方式還是溝通。充足且有效的溝通，確保產品經理與設計師間的已知資訊達到一致，雙方的理念、想法、建議等越碰撞越容易做出更好的產品。
主要對接的內容包含兩個部分： 資訊與意向：傳遞產品資訊，告知設計師關於該產品的設計原因、行業情況、要做的產品對標競品是哪些，以後對產品的規劃是什麼、產品經理的意向是什麼。 基礎設計理念：產品主題、整體色調、各樣式的字號、色號、全域性頁面的建議等。
（4）功能列表 功能列表為產品經理在經過足夠多的調研和分析，從彙總的產品需求池中篩選出的當前應處理需求列表。
功能列表的作用為便於相關人員全面瞭解產品的功能，從而評估專案週期、處理優先順序等。
功能列表主要表述都做什麼功能，哪些重要且緊急。列表引數包含： 模組 功能點 功能點描述（詳細） 優先順序（高、中、低）
（5）角色列表 角色列表為表述清楚該產品上線後，參與到該產品中的群體有哪些。列表引數包含： 角色名稱 職責：在產品參與中的簡要說明 備註：特殊情形
（6）框架圖 框架圖為該產品包含什麼內容：模組、功能。便於開發人員快速、便捷的瞭解產品全域性。
框架圖沒必要做的很高大上，高大上固然很好，會讓使用的人賞心悅目。但是，功能介紹簡單易懂和開發人員能看懂、看明白更重要，千萬不能捨本逐末。
（7）流程圖 流程圖分兩個部分： 整體流程圖：整體流程為將產品各大模組之間的互動流程，一般做正向流程居多，輔助以部分判斷流程和異常處理機制 功能流程圖：功能流程為涉及到具體的功能點的互動流程，包含：正向流程、規則、判斷流程、異常流程。
（8）功能需求
功能需求為具體的各功能點，是需求文件的核心。主要是詳細的分解各功能點，包含兩個方面：
前端：針對前端部分，頁面如何來、頁面元素、各功能點的規則、互動、跳轉規則、非常規流程的頁面元素、互動、跳轉規則等等。 後臺部分：前端功能的實現，依靠後臺的哪些邏輯和資料，是否需要做新功能模組、新功能模組的內容、資料的呼叫、儲存、介面資料傳值等等。
（9）非功能需求 非功能需求為使用者常規操作產品時的極端情況，涉及很多內容，以下列舉幾個比較重要且常規規劃中需要考慮的點： 產品效能：產品對使用者操作的響應、對群體操作的併發預防等。 安全性：公司資料、使用者資訊的保密性處理，不同角色的許可權設定、使用中的限制等。 可靠性：使用者操作中出現異常情況，是否可繼續操作，遇到異常情況時資料或使用狀態是否可被恢復等。 擴充性：擴充性主要針對公司內部而言，產品完成後，無論是設計師、開發人員，還是測試人員，針對產品所做的工作，是否可以被複用到其他地方。使用者在產品中的使用情況是否可被系統獲取後用作不同維度的分析等。
五、多說一句
需求文件中，對於功能的表述是尤為重要的，針對各功能點考慮的越詳細，越有利於開發人員評估實現難度、評估時間、順利達到所要的效果。
六、最後一句
需求文件不是越詳細越好，很多沒必要的說明，不用耗費大量時間去編寫，最核心的依舊是：讓自己公司的相關人員能快速看懂，全面瞭解。
盡信書不如無書，各公司均不一樣。產品經理應更多的站在自己公司的角度，在對相關協同人員充分了解後，輸出他們需要的需求文件。
轉載自csdn
@kuang 原創釋出於人人都是產品經理