程序員怎麼寫prd

『壹』 BRD MRD PRD應該怎麼寫，提綱如下

這些客戶是什麼樣子的？ 2、我可以滿足他們什麼樣的需求(提供什麼樣的價值，核心價值是什麼)？我要滿足他們什麼樣的需求？我(暫時)不打算滿足他的哪些需求？二、商業價值；1、我可以為企業創造什麼樣的價值？ 2、這些價值是否符合企業的整體戰略目標？三、路線規劃；1、我先滿足什麼需求？再滿足什麼需求？為什麼？ 2、每個階段的核心價值是什麼？ 3、執行計劃(時間…)？四、歷史回顧；1、客戶價值和商業價值是否發生了變化？ 2、二期產品的路線規劃和原規劃是否一致，（如有調整）調整原因是什麼？ 3、之前的實際運營效果和計劃的差異是什麼？為什麼？五、成本估算；1、整合各類資源所需要的運營成本、營銷成本。 2、研發和維護所需要的人力成本。 3、同時，還需要對未來的風險進行預估，並給出合理的預案。 六、評估方法 1、為什麼指定這個目標？這個目標是如何顯現出來的？ 3、憑什麼可以做到這個目標 向公司申請需要的費用、資源得到各級領導支持； MRD階段一、 更細致的市場與競爭對手分析；二、 通過哪些功能來實現商業目的；三、 功能/非功能需求分哪幾塊；四、 功能的優先順序； ——可能產出物有Mind Manager的思維圖，Excel的Feature List一、產品介紹；二、用戶描述；1. 用戶/市場統計；2. 用戶剖析；3. 關鍵用戶需求；4. 替代品和競爭品三、產品輪廓；1. 產品前景；2. 產品定位四、功能需求；五、非功能需求；六、 附件：用戶需求調查報告 收集、分析、定義主要的用戶需求和產品特性——不用考慮系統如何滿足這些需求以及需求的技術和資源局限PRD階段一、 功能使用的具體描述；二、Visio版功能點業務流程；三、 界面的說明；四、Demo(註：可是dreamweaver、ps、畫圖板的簡單版，有時也會有UI/UE支持)一、項目邊界；二、驗收標准；三、業務流程圖；四、用例說明；1. 用例總圖；2. 單個用例說明五、性能需求；1. 響應時間；2. 空間使用量等六、維護性需求；七、質量需求；1. 安全性；2. 可操作性；3. 可靠性；4. 兼容性；5. 移植性八、介面需求 外部介面需求； 內部介面需求 對MRD中的內容進行指標化和技術化；明確產品的功能和性能FSD階段（類似概要設計） 產品UI確定; 業務邏輯的細節確定; 表結構設計 功能詳細說明

『貳』 產品經理的PRD到底該怎麼寫

PRD（Proct-Requirement-Document，產品需求文檔），寫作目錄如下：
1、文件命名（編號）
文件的編號很關鍵，因為產品迭代過程會有不同的文件版本，一般命名規則「公司名+產品名+PRD+D1.0」（以第一版為例），這樣命名有利用版本號的迭代。
2、修訂控制頁
一般有這么幾項：編號、文檔版本、修訂章節、修訂原因、修訂日期、修改人。
3、目錄
4、請與以下部門討論PRD
PRD作為一個承接作用的「載體」，會與技術、運營、財務等人員的溝通，而與這些人員溝通的主題都將會出現在子功能或在細節細化的基本上，需要與相關人員確定「溝通內容」，這對於產品整體流程將是很重要的。
5、概述
概念就是總結，它包括的點有：名詞說明、產品概述及目標、產品roadmap、產品風險。
6、使用者需求
使用者需求一般只有個需求描述。需求描述有以下幾項內容：目標客戶、需求描述、場景描述、優先順序。
7、可選方案
列出所有可以選擇的達到該產品目標的方案要點（主要思路），給各方案適當的評價，並推薦最優方案。
8、效益成本分析
產品經理是個全才，在這點上得到了體驗。產品經理得知道財務知識。很大一部分是產品的環境搭建成本和支持人員的成本。一般的效益成本分析包括三個方面：效益預測、產品技術中心成本、非產品技術中心支持成本。
9、功能需求
功能需求一般是由四部分組成，功能總覽、功能詳情、整合需求、BETA測試需求。
10、整合需求
產品經理很重要的一個能力就是體現在產品整合能力上，利用公司現有的資源或外部資源（合作公司等）實現產品功能需求的整合。
11、BETA測試需求
很多產品都有BETA版本放出，為了就是收求意見和一些性能測試。
12、非功能性需求
都說產品經理是全才，在這點上得到徹底的體現。很多產品經理在這點上忽視了，但很多方面使用到的，只是在產品過程中弱化了。
13、上、下線需求
上線時限需求：此產品預定上線日期？上線日期有無任何特殊依據或規定？
下線需求（活動類需求必須明確下線時間）：此產品預定下線日期？下線日期有無任何特殊依據或規定？
14、運營計劃
說明產品的後續運營計劃。包括與運營部的協作運營。更多的是給產品經理如何讓更多的產品功能展示給用戶，產品經理是核心需求的把握者，參與到產品整體運營計劃顯得特別的重要。
……
寫PRD並不是產品經理的全部工作，但卻是不可少的一部分，很大程度上反應了產品經理的思維和產品核心功能把握上，同時對產品經理溝通、協調、規劃等
想學習更多PRD文檔寫作方式，可以來官網學習

『叄』 怎麼寫prd文檔

這些客戶是什麼樣子的？ 2、我可以滿足他們什麼樣的需求(提供什麼樣的價值，核心價值是什麼)？我要滿足他們什麼樣的需求？我(暫時)不打算滿足他的哪些需求？二、商業價值；1、我可以為企業創造什麼樣的價值？ 2、這些價值是否符合企業的整體戰略目標？三、路線規劃；1、我先滿足什麼需求？再滿足什麼需求？為什麼？ 2、每個階段的核心價值是什麼？ 3、執行計劃(時間…)？四、歷史回顧；1、客戶價值和商業價值是否發生了變化？ 2、二期產品的路線規劃和原規劃是否一致，（如有調整）調整原因是什麼？ 3、之前的實際運營效果和計劃的差異是什麼？為什麼？五、成本估算；1、整合各類資源所需要的運營成本、營銷成本。 2、研發和維護所需要的人力成本。 3、同時，還需要對未來的風險進行預估，並給出合理的預案。六、評估方法 1、為什麼指定這個目標？這個目標是如何顯現出來的？
3、憑什麼可以做到這個目標向公司申請需要的費用、資源得到各級領導支持；MRD階段一、 更細致的市場與競爭對手分析；二、 通過哪些功能來實現商業目的；三、 功能/非功能需求分哪幾塊；四、 功能的優先順序；——可能產出物有Mind Manager的思維圖，Excel的Feature List一、產品介紹；二、用戶描述；1. 用戶/市場統計；2. 用戶剖析；3. 關鍵用戶需求；4. 替代品和競爭品三、產品輪廓；1. 產品前景；2. 產品定位四、功能需求；五、非功能需求；六、 附件：用戶需求調查報告收集、分析、定義主要的用戶需求和產品特性——不用考慮系統如何滿足這些需求以及需求的技術和資源局限PRD階段一、 功能使用的具體描述；二、 Visio版功能點業務流程；三、 界面的說明；四、 Demo(註：可是dreamweaver、ps、畫圖板的簡單版，有時也會有UI/UE支持)一、項目邊界；二、驗收標准；三、業務流程圖；四、用例說明；1. 用例總圖；2. 單個用例說明五、性能需求；1. 響應時間；2. 空間使用量等六、維護性需求；七、質量需求；1. 安全性；2. 可操作性；3. 可靠性；4. 兼容性；5. 移植性八、介面需求外部介面需求；內部介面需求對MRD中的內容進行指標化和技術化；明確產品的功能和性能FSD階段（類似概要設計）產品UI確定;業務邏輯的細節確定;表結構設計功能詳細說明

『肆』 如何撰寫PRD文檔

prd文檔是產品項目由「概念化」階段進入到「圖紙化」階段的最主要的一個文檔，其作用就是「對MRD中的內容進行指標化和技術化」，這個文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。

開發工具推薦 ：
Rational Rose★★★★－－熟悉項目發生的相關業務行為。
visio 2007★★★★－－將業務，從產品層面肢解開來，做到抽絲剝繭部分與整體統一
mind manager★★★－－把項目條目化，條理化，目錄結構具體規定好。
Axure★★★－－前台結構布局，合理規范的將系統脫去朦朧的華紗。
Word★★★★★--穿針織網，把需求綜合起來，整理成最終的產品需求文檔。

也就是用以上任意一種軟體都可以打開，不過應該有版本要求。

『伍』 PRD文檔到底有什麼用

PRD的最大作用是指導產品設計的，讓ui設計的時候不會跑偏。

稍微大一點的團隊產品經理未必能向每個人傳達產品需求，這就需要有一個文檔的形式來向項目的所有成員來傳達需求，這就是文檔的來源。

簡介

由於產品經理經常會變更需求，經常愛拍腦袋，容易變卦，所以程序員就想到用一個文檔來約束產品經理。

測試人員需要根據產品需求文檔來驗收產品質量。

當你的項目有新人進入的時候，可以讓新人更快的了解產品。當你離職的時候，繼任的產品經理也可以根據你的文檔來熟悉產品迭代的內容。

『陸』 怎樣開發互聯網產品

互聯網產品開發階段大致有以下幾點
需求階段
需求產生
需求產生有三種渠道： a) 業務部門（或根據客戶的需求）提出需求，包含行業應用部、市場部、互聯網部等部門。
2. 策劃階段
2.1. PRD（Proct Requirement Document產品需求文檔）
PRD側重對產品產品功能和性能的說明，相對於MRD中的同樣內容，要更加詳細，並進行量化。PRD一般包含流程圖、原型圖等，使用用例等手段，以准確說明。若無MRD，則PRD需對目標進行說明。PRD為必須經過的步驟，由PD或UI完成。PRD需進行編號，編號規則詳見「需求編碼」表格。
2.2. 評審
需求方、相關領域的顧問（即有豐富經驗者）、PD或UI參與的評審PRD的會議，一般項目經理、PM需參與會議。若項目較大，需邀請總經理參與。會議必須有主持，並在會後出MEMO（備忘）或PRD更新說明。專家評審結束後，PD出設計結果方案，需求方簽字確認。程序員接到PRD方案後，需評估完成開發的大致時間，以及任務分解安排。當需要GUI方案作為輔助判斷時，需明確提出。
2.3. 交互DEMO
ID（Interaction Designer交互設計師）根據PRD定稿做出交互設計方案，真實再現用戶交互過程，並與PD、UI進行內部評審。視情況，PM參與。（因公司沒有ID，此步驟由PD與美工，視覺設計師，口頭溝通完成）
2.4. 視覺界面
由美工（視覺設計師）設計頁面風格、布局、關鍵界面等，交由PD、UI、ID進行內部GUI（Graphical User Interface圖形使用者介面）評審。GUI方案通過後，頁面製作師開始切割頁面，編寫HTML。
3. 開發階段
3.1. 後台編碼
在編碼之前，程序員應視其系統需要，進行概要設計、資料庫設計，並進行內部討論和評審，邀請顧問參與。程序員對文檔有疑問或不理解，需與PD進行溝通，了解其真實涵義，不得以任何理由私自更改已確定的PRD、GUI方案。確有功能需做調整，程序員需與PD、需求方共同協商完成。改動應出具文檔，由需求方、技術經理、PM簽字後生效。
3.2. α（alpha最初）測試
在開發小組內部進行，測試的方法也較多，黑盒、白盒、 壓力、應力等。此階段應完成80%以上的需求開發，測試以PRD為准。測試完成後，收集反饋，修復BUG，優化流程。開發者在場。
3.3. β（beta第二次）測試
有選擇地請一些最終用戶實際使用，將發現的問題反饋，開發者對系統進行最後的修改，之後准備發布最終產品。β測試開發者不在場。產品估算開發時間，以完成β測試為准。
3.4. 產品發布
β測試後，PD校驗產品。如產品與策劃方案相差較大，有權不接受產品，責任由開發部門負責。將產品發布日設為里程碑，以此考核整個項目的運作效率。
4. 校驗階段
4.1. 發布跟蹤
產品上線後，PD或市場調研員負責收集用戶操作數據，檢測各個反饋渠道，篩選數據，出具用戶檢測報告，檢驗產品改進是否達到預期目標。立項產品應專門出具報告，非立項改動需在數據分析報告中體現。
以上只是對產品開發的常見流程進行的解讀，不同公司，不同項目間會有部分的優先順序變動，但大體流程是類似的。因此，了解了大致流程，就會在工作中做到心中有數，不會在與產品、UI、技術、測試人員溝通時出現大的障礙，使得項目可以快速推進

『柒』 PRD怎麼寫

1、文件命名（編號）
文件的編號很關鍵，因為產品迭代過程會有不同的文件版本，一般命名規則「公司名+產品名+PRD+D1.0」（以第一版為例），這樣命名有利用版本號的迭代，如果是小的產品需求變動可以直接命名為「公司名-產品名-PRD-D1.01」，如果涉及到功能需求增加可以命名為「公司名-產品名-PRD-D1.1」，當出現產品第二版時，可以命名為「公司名-產品名-PRD-D2.0」。
2、修訂控制頁
一般有這么幾項：編號、文檔版本、修訂章節、修訂原因、修訂日期、修改人。編號只是為了給個修改的順序，文檔版本顯示的當前修改的內容是在哪個版本中出現，修訂章節是具體到哪個章節哪個功能模塊的修改，修訂原因說明此功能修改的問題所在。修訂日期以修改當日的日期為修訂日期，修改人顯示修改內容模塊的人，可能是當前用戶也可能是其它產品人員。
3、目錄
不建議自己去添加一個新的目錄，你可以去其它的文檔中拷一個過來，不考慮目錄的內容，等寫完PRD可以再去更新。但建議用Mind manager來整理一下思路。
4、請與以下部門討論PRD
PRD做為一個承接作用的「載體」，會與技術、運營、財務等人員的溝通，而與這些人員溝通的主題都將會出現在子功能或在細節細化的基本上，需要與相關人員確定「溝通內容」，這對於產品整體流程將是很重要的。同時對於產品核心功能的提取也是一個重要環節。產品經理很重要的一個職能就是溝通。例與客服中心：客服服務部，討論的內容：預測客服成本、工作量；討論客服如何支持；協助評估詐欺/數據竄改風險：欺詐/數據竄改風險、不正使用風險。這就是要寫在與其它部門討論PRD中的。一個產品經理需要考慮如何與其它部門之間的溝通合作，文檔很大一部分的功能是提醒你要做的工作，同時不斷補充將要面臨的工作。

『捌』 如何寫出好的PRD

首先，先了解清楚PRD的閱讀對象，使用者。
PRD的模版中一般有如下信息：
PRD預期的讀者包括：產品、開發、測試人員及相應的負責人和用戶方代表。產品、開發、測試人員會從中了解到本次需求的背景和詳細要求，以及每個需求點未來的優化方向或對用戶的價值。而用戶方代表則可以通過該文檔了解PRD中所描述內容是否是自己期望中的需求，是否符合以及是否都覆蓋到了自己的預期。因此PRD也是產品經理同相關角色確認開發任務的重要依據。當所有角色認可了PRD中的內容後，這份PRD將作為後續開發、測試、需求驗證的依據。
其次，一個完整的PRD還應該具備的要素有
1、文檔的命名和編號
文檔的編號和命名很關鍵，每個產品都是經過若干個迭代才完成的，而每個迭代所完成的產品功能或者升級的需求都可能是不一樣的，因此需要定義清楚該文件屬於產品的哪個迭代，修改了幾個版本。文件命名的方法一般是通過版本號定義，比如簡單的方法是，XX產品V1.0PRD_V2,前面的V1.0是產品迭代的編號，後面的V2 PRD的版本號。稍微詳細點可以定義成，XX產品XXXX需求PRD_V2,即對本次迭代的需求任務做命名，這樣更便於閱讀和記憶。
2、文檔的版本歷史
包括，編號、文檔版本、章節、修改原因、日期、修改人。編號只是為了記錄修改的順序，文檔版本顯示的當前修改的內容屬於文檔的第幾個版本(或第幾次修改，一次修改一般為一個版本)，章節是具體到修改內容屬於的功能模塊，以便閱讀人及時找到修改後的內容，修改原因說明為什麼要修改該需求，讓閱讀者直觀的了解原因。日期是指需求文檔修改的時間，修改人是指需求內容的修改者。
3、目錄
不需要自己新建，文檔完成後直接更新模版中的目錄即可。目錄是用來了解文檔結構的
4、引言
這部分的內容有：產品概述及目標、產品roadmap、預期讀者、成功的定義標准和判斷、參考資料、名詞說明
產品概述：解釋說明該產品研發的背景以及核心功能。
預期讀者：文檔的使用對象
成功的定義和判斷標准：旨在說明產品的目標
參考資料：PRD的參考資料
名詞說明：名稱、說明。名稱就是對文檔中會出現的比較新的名稱，說明則是對這些名稱進行解釋。
5、需求概述
需求概述通常包括需求概覽、用戶類與特徵、運行環境、設計和實現上的限制、項目計劃、產品風險等等
需求概覽：分兩部分，一是業務流程圖，對產品整個業務流程的發生過程做圖形化的展示，是對產品整體功能流程的闡釋。二是需求清單，對本次要開發的需求任務做分類，給出簡明扼要的需求描述並標注優先順序。
用戶類與特徵：產品的最終用戶，確定產品的最終使用者，並對使用者的角色和操作行為做出說明。
運行環境：該產品上線後的使用環境，比如支持的瀏覽器及其版本，操作系統、資料庫的要求等等，測試人員在看到環境要求後會在測試時重點測試，而最終上線產品時需要把最佳的運營環境告知給用戶。
設計和實現上的限制：比如控制項的開發環境、介面的調用方式等等
項目計劃：對於prd中要開發的內容，給出關鍵里程碑，比如需求評審通過的時間、開發的完成時間、上線時間等等
產品風險：描述產品可能存在的風險，比如性能瓶頸，沒有解決的問題，用戶不當使用的風險等等。
6.功能需求
功能需求一般是由功能詳情和主流程說明兩大部分。功能詳情是所有的產品功能的描述和規劃。功能詳情包括以下內容：
簡要說明：介紹此功能的用途，包括其來源或背景，能夠解決哪些問題。
場景描述，產品在哪種情況下會被用戶使用，就是用戶場景模擬。這也是產品經理講「好」故事的必備條件
使用者說明：對產品使用者做出說明，可融入簡要說明中。
前置條件：該需求實現依賴的前提條件。比如，上傳照片時，需要存有圖像文件。
後置條件：操作後引發的後續處理。
主流程：把主流放在最後是有道理的，結合上面所說的，做出主流程說明，對每個功能流程走向分點說明(這是非常重要的)。
推薦一個方法：「用例」，在面向對象的軟體設計模型中，用例是一個被闡述的內容，用例是對功能使用場景的解釋。用例很條理的介紹了每個功能的前置、後置條件，主流程介紹，幫助開發、測試等角色快速的了解產品功能。
7、可選方案
列出所有可以選擇的達到該產品目標的方案要點(主要思路)，給各方案適當的評價，並推薦最優方案(在功能需求中描述的)。你在做這個產品規劃時一定有很多的備選方案，別放棄這些方案，永遠沒有過時的idea，只有最適合時機的idea。所以可以寫出幾個可選方案，或許是你下期產品改版一個方向。記住，多思考方案是永不為過的
8、效益成本分析
通過這一點上能看出產品經理必須是個全才，不僅要具備行業知識，還需要有財務知識。一個產品的成本衡量一般包括三個方面：效益預測、產品技術成本和其他成本支出。
9、整合需求
產品整合能力是產品經理很重要的一個能力，業務合作通常是不可避免的，將隸屬於兩個不同來源的業務功能做整合也是常見需求，比如系統登陸使用公司的域用戶登陸，或者付款使用財付通、支付寶付款，解決好整合需求也是體現產品經理核心競爭力的一大重要表現。
10、BETA測試需求
很多產品在正式上線前都有BETA版本或者內測版本，或者叫灰度版本，目的是在測試產品的一些核心功能或者性能。這部份內容不是必須的，但如果需要，需要給出在此階段要實現的目標或測試、衡量標准。
11、非功能性需求
一般情況下非功能性需求包括以下幾個部分：產品營銷需求、運營需求、財務需求、法務需求、使用幫助、問題反饋等。這些信息構成了產品上線的完整內容，也很好的體現了產品經理的綜合素質。
12、運營計劃
產品上線後如何運營，目標受眾是什麼，建議的推廣策略、問題反饋途徑、風險監控、亮點宣傳等等，以及與運營人員的協作方式。作為產品的設計人員不是開發完產品就能畫句號的，讓產品用起來、用得好，有口碑更為重要，所以非常建議運營計劃的制定上有產品設計人員的參與。

『玖』 剛入職的Java程序員，怎樣去看公司的項目，看不懂怎麼辦

首先你入職的是什麼等級，一般來說公司都有等級的劃分比如：初級 中級 高級軟體開發工程師。
一般進公司都會給你一個星期的適應期，在這適應期你必須做好理解業務，理解公司文化，理解架構等。
如果你是初級 會有項目經理指導你核心問題。建議不要問的太頻繁，畢竟招你進來是解決問題的，不是製造問題，看不懂，主要是哪裡看不懂，代碼都是通過業務來寫的，你如果看到業務代碼不懂可以直接先看prd或者產品文檔，介面文檔等一切可以梳理業務邏輯的代碼，如果有技術問題，可以大方的問你的項目經理，他會告訴你的。
如果是中級，成本就不一樣了，所以你的基礎必須要扎實，一些消息隊列（rabbitmq,activemq等），nosql（redis,mongo等）,分布式（spring cloud，bbo等），db（mysql等）。一般來說都夠了，再不懂的也可以問項目經理，畢竟是中級。
如果是高級，那完全都不用說了，基本什麼都懂了，框架類的都是浮雲，業務邏輯隨隨便便看看就好了，而且一般打代碼也很少了，主要是框架類的維護。

當然了，如果你是實習生，就相當於打打雜了，他會安排你學習什麼，然後修補一下bug，讓你有獨立性，所以不用擔心。不過也少說多做。
純手打，工作經驗累積出來，如不喜歡，勿噴。謝謝！

『拾』 產品經理應該怎麼寫BRD、MRD、PRD（需求文檔）呢

因為內容較多，我就簡要說一下寫作目錄
BRD文檔
01 BRD說明
概念：BRD文檔是產品生命周期中最早的文檔，是我們產品定義階段的匯總。
用於：說明市場分析，銷售策略，盈利預測，產品構思等。
目的：說服領導及同事為此項目提供資源支持。
02 BRD撰寫
撰寫結構：方案背景、產品規劃、運營規劃、收益&成本、盈利模式、風險&對策
整體結構梳理如下：
1. 方案背景
描述背景的所有的數據最好註明數據來源。可以通過上市公司財報，艾瑞咨詢，或一些知名網站的采訪文章來獲取數據，甚至是內部人士的消息，都是重要的參考來源。
基於整個行業，描述以下內容：
(1)行業背景和現狀
(2)商業價值/市場規模(開辟新市場的情況下)
(3)用戶需求
(4)盈利模式
(5)發展趨勢
(6)競爭對手發展情況
2. 產品規劃
產品規劃主要是包括對於產品的定位、產品的核心目標、產品的結構和迭代路線進行一個整體的呈現。這部分內容可以借鑒產品的迭代更新文件(如果有的話)，主要是基於當前產品的規劃，描述以下內容：
(1)產品定位
(2)核心目標
(3)產品結構
(4)產品路線
3. 運營規劃
完整的運營規劃，包括內容運營，用戶運營，社區運營，活動運營，產品運營五個方面，但是並不是所有的產品都會占據所有的運營方式，每個產品的運營涉及的部分不一定一樣，側重點也不一樣。
(1)內容運營
(2)用戶運營
(3)社區運營
(4)活動運營
(5)產品運營
4. 盈利模式
簡單的說，就是介紹產品將通過怎樣的模式、渠道來獲得收益
5. 收益與成本
6. 風險與對策
SWOT分析：優勢、劣勢、機會、威脅;(SWOT就不多敘述了，網站內有詳細的介紹哦)
MRD文檔
1、概述:包含兩個點，背景和目標。
2、市場概述:描述一下你們要做的是什麼市場。
2.1市場特徵
從全局說說目前市場個競品的產品定位。
2.1.1市場問題
列舉市場痛點，用戶在需求產生後，遇到的各個環節的問題，目前市場是如何滿足的，以及那些需求點尚未得到滿足?或滿足不夠有深度挖掘的空間。
2.1.2市場機會
根據市場的問題，分析問題，是否還有機會做這個市場?根據市場凸顯的問題，舉例出幾種解決方案，逐一舉例。
2.2市場趨勢
可預見的估測評估未來市場的發展，可能會出現那種情況?出現巨頭壟斷?還是三足鼎立?垂直細分?020線上線下結合等等。
2.3市場細分
舉例市場都有哪些細分?和這些細分相對應的產品都有哪些?
2.4市場壁壘
要切入市場，有哪些難題，有什麼壁壘?
成熟壁壘。市場已經非常成熟，品牌體驗已經深入人心，不細分切入幾乎沒用勝算。
資金壁壘。市場處於初期紅海或者到了火拚時代如以前的百團大戰、打車、拼車、外賣市場等。一種就是起動需要大量的資金，如京東的自建物料。
技術壁壘。如人工智慧、搜索這些需要高精尖技術人才，才能實現的。
壟斷壁壘。例如醫療、電信、支付等，需要國家批準的。
2.5市場緊迫性
基於市場發展的趨勢，項目的啟動是否需要一些特殊的需求?
3.用戶需求分析:詳細說明用戶需求的動機。
3.1用戶類型細分
說明用戶群體的細分維度，對用戶進行分解，可通過典型用戶、類型特徵特徵等進行描述。不同需求用戶，對產品的關注點不同。
3.2用戶場景
用戶發生需求的場景，和不同場景的特徵。比如睡覺時、坐地鐵坐公交時、開車時等等。
4、競品分析
直接競品
間接競品
競品模式分析
PRD文檔
一、PRD文檔頭
文檔名稱、作者或則撰寫人、文檔編寫日期、版本紀錄、目錄。
二、PRD文檔內容結構
PRD文檔內容結構包括：概述、產品需求說明、產品流程說明、產品結構和功能說明、其他產品需求、上線需求說明。如果需要的話有相關文檔，附件說明。
1、概述
從大的方向，講講項目的相關背景、有什麼目標、有沒有競品對像?而階段性計劃是什麼?傳遞做這個需求的目的是什麼?要達到什麼樣的目標?要達到這個目標階段性計劃是什麼?
2、產品需求
落到具體的地方，產品有哪些需求?增加了哪些需求?調整了什麼?取消了什麼?需不需要其他資源的配合?有什麼影響?，從這幾個地方說清楚。
3、產品流程說明
講清楚每個邏輯點，每個地方應該怎麼走?應該做什麼樣的判斷?如果進行這個操作返回給用戶什麼內容?用戶觸發之後得到什麼內容?
4、產品結構說明
根據產品的內在邏輯，分解、細化需求，將需求細化說明。
5、其他產品需求
涉及到其他產品的產品線時，需要協同多個產品線進行多方面考慮。協同調整，避免出現遺漏，出現不必要的偏差。
6、相關文檔
如果一個項目分解成多個團隊。多個需求文檔協同合作。如一個UGC社區，有PC端社區，有APP端社區。
7、上線需求
測試通過的需求，具體的上線時間，具體一些特殊的流程需求等。
8、其他需求、附件
作為需求的一種補充，對一些需求進行補充說明，或者需要的文件說明等
歡迎來起點學院學習更多產品文檔寫作方法