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