產品運營文檔
1. 產品經理需要輸出哪些文檔
吹降淖盅凼牽翰
2. 產品需求文檔模板
首先告訴你產品需求文檔肯定是有的！一個經過實際工作檢驗、經歷過「質疑」、「挑戰」和「斗爭」之後沉澱下來的模板，肯定是已經吸收了各類人的偏好、意見，固化了很多符合實際業務必須的內容要求，能夠起到很好的業務承接作用。格式化、標准化本身是一個很好的思維、工作方式，可以讓你在編輯文檔和接受文檔的雙方關系中建立一種「標准」的溝通機制和預先定義的溝通基礎，減少額外的溝通成本，提高效率。
不過，在享受別人智力和經驗梳理好的模板進行需求編寫的同時，還是應該了解模板形成的原因，並在此過程中形成自己對於模板的理解，進而形成對於產品需求文檔的理解，在理解中使用，裁剪和優化。
要理解和分析模板，理解和分析產品需求文檔，可以運用以下幾個方法：
一、描述-解釋-預測-監控
描述，是對觀察過程和觀察結果的描述。觀察的對象因不同的研究而有差異，其目標是盡可能完整地將觀察者根據自己的觀察得到的現象、由此現象所產生的思想和感覺，以及在觀察過程中選擇納入的過程參與者對現象的反應等信息進行描述。
解釋，是回答 「為什麼」，是對於描述的理解、歸類、定義和解釋。其目標是將描述內容背後的成因、原理、動機，內容中各部分之間的相關，依存、依賴和影響關系等進行說明，以便對於描述內容有更清晰、更細致、全面的了解。
預測，根據以因果關系為內容的內在聯系，相互影響來推導未來的發展或者將要發生的事情。通過研究解釋內在的聯系，准確地表達內在聯系，從中推導出正確的預測。
監控，是對於預測行為、現象的觀察和監督，包括了觀察到的預測中的行為、現象的發生或者預測以外的行為、現象的外發生，以及因此而採取的對應的反映動作；這些反映動作是預測過程中根據內在聯系制定的「響應」機制，並任其自然發生或者通過提供「系統」的自製能力來實現。
二、需求准備、編寫和檢查
回歸到產品經理的日常工作中，在時間佔比上較為集中的就是產品需求管理了，包括了需求的准備、分析、編寫和檢查過程。在這個過程中，描述——解釋——預測——監控這個通用的科學分析過程也同樣使用，且可以貫穿其中，並可以幫助理解、形成並固化成我們前文提到的需求文檔的模板。這個科學分析的過程、方法在不同階段運用的側重點會有所不同。
1. 描述
描述的過程是客觀的進行「需求向」描述的過程，是一個「背景」信息的補充，用來說明，這個需求文檔的源出是什麼，是針對什麼問題，這個問題是在具體什麼領域，在怎樣的范圍內，涉及到的是那些人；在需求相應的功能設計實現之前，當前的解決方案存在的問題是什麼，參與者是怎麼解決的，解決的情況怎麼樣，是好，還是不好，還是勉強可以，對於新的需求的緊迫性是什麼樣的。此外，描述的過程還需提供一個基礎的概念和流程的解釋，用來統一作為背景去理解一個現實的業務場景和「溝通字典」，避免在溝通中因為誤解而產生不必要的偏差。
需求准備的過程：了解需求來源（管理部門、市場部門、運營部門等），需求背景（行業、同業規則現狀等）；
需求分析的過程：了解需求目標、預期效果（時間、結果等）、使用者習慣、相關人影響；
需求編寫的過程：描述需求目的、背景、時間和結果要求、業務流程、交互過程、系統架構、干係人角色和影響范圍；
需求檢查的過程：需求的背景、目標、過程、干係人、結果預測和預防的完整性檢查；
2. 解釋
解釋在需求來源的基礎上描述了 「為什麼」接下來這個需求可以解決遇到的問題，同時還加入了「是什麼」和「怎麼樣」的部分。就是這個需求是通過怎麼樣的方法解決了「描述」過程中提到的問題，這個新的解決方法需要要做什麼，對於原有的業務過程有哪些改變，會提升什麼，會降低什麼，會影響哪些人、哪些業務部分、哪些業務系統以及哪些數據的產生。這個部分，是需求文檔的最主要、最核心的內容部分，也是在內容上佔比最大的一部分。
這里的解釋根據產品需求面向的要解決的問題不同，而可能存在多個層面，多個維度的層面，比如對於運營的影響，對於前端市場的影響，對於用戶的影響，對於財務、法務的影響；從技術開發、技術實現維度，比如對於前端開發的影響、對於服務端開發的影響、對於數據平台的影響，還可能涉及到對於運維資源的影響等；因此對應到實際的產品需求工作中：
需求准備的過程：了解需求可能涉及的相關業務系統及系統對應的數據流程和邏輯、了解需求可能涉及的外部服務的數據流程和邏輯；了解面向的內外部用戶的產品使用水平、學習能力和使用習慣；
需求分析的過程：選擇和制定最有效的，滿足時間、資源投入等要求的方案；
需求編寫的過程：詳細描述需求的業務流程，通過各種圖表格式說明新的解決方法在各服務系統之間、各業務部門之間、用戶與產品，產品與後服務之間的數據、文件和行為的交互過程、詳細的信息輸入、信息處理和信息輸出；每個業務節點明確的輸出物和節點標志，重要性和優先順序；系統架構、干係人角色和影響范圍；
需求檢查的過程：需求的流程、用戶交互動作、系統信息交互等完整性檢查；
3. 預測與監控
預測與監控在產品需求文檔的管理上是聯動的，是對於預測的事件發生的時候，進行管理的機制，監控=預測+干預。在產品需求文檔的管理上，對於設計好的業務流程、使用功能，在實際過程中可能會出現這樣或者那樣的 「非規劃」的使用，也就是我們通常說的「用戶並不總是按照產品設計的方式來使用產品，而且，往往相反。」因此，這部分內容很大的比例需要來對於用戶的行為進行預測和監控，並提供「預防」或者「解決」方案。其中：
預防在於，預測產品的用戶在使用的過程中，可能會進行的一些超過產品使用半徑的操作，一旦進行這些操作，操作的任務流程會中斷，掉出，進入其他業務流程中且無法回滾，從而使得操作無法進行下去，功能使用失敗，使用者會感覺產品、功能沒有包容性，缺乏引導性，導致了最後操作的失敗，預想的結果沒有實現，而且造成了一定的挫敗感，甚至造成了一定的損失。預防的具體方法多採用導航、提示等，不同的系統都有各自標准化的控價，我們在這里不做展開。
解決在於，預測產品的用戶在使用產品的過程中，因誤解、操作手誤而進行了「非標」、「超規」使用「掉出」原本設計的業務流程和操作流程的情況下，需要提供額外的流程和控制來「回轉」用戶的操作，來幫助用戶回到預先設定和他所需要的流程上來。解決的具體方法多通過「導航」引導「跳轉」和「返回」、「回退」來實現。對應到實際的產品需求工作中：
需求准備的過程：了解用戶特徵和使用水平、評估、比較不同方式實現需求對於用戶行為的可控性和「非常規」操作的危害程度；
需求分析的過程：選擇和確定需求實現方案，評估行為管理方式和管理機制；
需求編寫的過程：詳細描述需求的業務流程和交互過程中可能出現的用戶異常操作，相應異常操作中系統反應，系統對應的控制和引導；
需求檢查的過程：需求「異常」流程和相應引導、控制地完整性檢查；
在需求管理的過程中，就可以按照這個 描述——解釋——預測——監控流程來進行。這四個既是步驟，是需求文檔內容的組成部分，也是需求編寫完成之後的檢查。
四個模塊構成了需求文檔的完整性，且同時有各自獨立，有對應的說明，引導、要求和標准。所謂標准文檔，就可以按照這四個模塊作為框架、內容和格式。
寫在最後
產品需求文檔作為產品經理同視覺設計、交互設計以及技術開發人員進行需求溝通的一個載體，我平時用的比較多的是摹客的服務進行創作。一個完整的、充分溝通確認，並最終達成多方理解和共識的產品需求文檔，能夠最大限度的還原產品、功能的設計，保證產品、功能的實現，最大限度的減少因為各方理解的偏差而造成的時間、人力和經濟資源的浪費及復工。
3. 產品需求文檔模板新版
您想問產品經理需求文檔的模板是吧？我告訴你是有的，一個經過實際工作檢驗、經歷過「質疑」、「挑戰」和「斗爭」之後沉澱下來的模板，肯定是已經吸收了各類人的偏好、意見，固化了很多符合實際業務必須的內容要求，能夠起到很好的業務承接作用。格式化、標准化本身是一個很好的思維、工作方式，可以讓你在編輯文檔和接受文檔的雙方關系中建立一種「標准」的溝通機制和預先定義的溝通基礎，減少額外的溝通成本，提高效率。
不過，在享受別人智力和經驗梳理好的模板進行需求編寫的同時，還是應該了解模板形成的原因，並在此過程中形成自己對於模板的理解，進而形成對於產品需求文檔的理解，在理解中使用，裁剪和優化。
要理解和分析模板，理解和分析產品需求文檔，可以運用以下幾個方法：
一、描述-解釋-預測-監控
描述，是對觀察過程和觀察結果的描述。觀察的對象因不同的研究而有差異，其目標是盡可能完整地將觀察者根據自己的觀察得到的現象、由此現象所產生的思想和感覺，以及在觀察過程中選擇納入的過程參與者對現象的反應等信息進行描述。
解釋，是回答 「為什麼」，是對於描述的理解、歸類、定義和解釋。其目標是將描述內容背後的成因、原理、動機，內容中各部分之間的相關，依存、依賴和影響關系等進行說明，以便對於描述內容有更清晰、更細致、全面的了解。
預測，根據以因果關系為內容的內在聯系，相互影響來推導未來的發展或者將要發生的事情。通過研究解釋內在的聯系，准確地表達內在聯系，從中推導出正確的預測。
監控，是對於預測行為、現象的觀察和監督，包括了觀察到的預測中的行為、現象的發生或者預測以外的行為、現象的外發生，以及因此而採取的對應的反映動作；這些反映動作是預測過程中根據內在聯系制定的「響應」機制，並任其自然發生或者通過提供「系統」的自製能力來實現。
二、需求准備、編寫和檢查
回歸到產品經理的日常工作中，在時間佔比上較為集中的就是產品需求管理了，包括了需求的准備、分析、編寫和檢查過程。在這個過程中，描述——解釋——預測——監控這個通用的科學分析過程也同樣使用，且可以貫穿其中，並可以幫助理解、形成並固化成我們前文提到的需求文檔的模板。這個科學分析的過程、方法在不同階段運用的側重點會有所不同。
1. 描述
描述的過程是客觀的進行「需求向」描述的過程，是一個「背景」信息的補充，用來說明，這個需求文檔的源出是什麼，是針對什麼問題，這個問題是在具體什麼領域，在怎樣的范圍內，涉及到的是那些人；在需求相應的功能設計實現之前，當前的解決方案存在的問題是什麼，參與者是怎麼解決的，解決的情況怎麼樣，是好，還是不好，還是勉強可以，對於新的需求的緊迫性是什麼樣的。此外，描述的過程還需提供一個基礎的概念和流程的解釋，用來統一作為背景去理解一個現實的業務場景和「溝通字典」，避免在溝通中因為誤解而產生不必要的偏差。
需求准備的過程：了解需求來源（管理部門、市場部門、運營部門等），需求背景（行業、同業規則現狀等）；
需求分析的過程：了解需求目標、預期效果（時間、結果等）、使用者習慣、相關人影響；
需求編寫的過程：描述需求目的、背景、時間和結果要求、業務流程、交互過程、系統架構、干係人角色和影響范圍；
需求檢查的過程：需求的背景、目標、過程、干係人、結果預測和預防的完整性檢查；
2. 解釋
解釋在需求來源的基礎上描述了 「為什麼」接下來這個需求可以解決遇到的問題，同時還加入了「是什麼」和「怎麼樣」的部分。就是這個需求是通過怎麼樣的方法解決了「描述」過程中提到的問題，這個新的解決方法需要要做什麼，對於原有的業務過程有哪些改變，會提升什麼，會降低什麼，會影響哪些人、哪些業務部分、哪些業務系統以及哪些數據的產生。這個部分，是需求文檔的最主要、最核心的內容部分，也是在內容上佔比最大的一部分。
這里的解釋根據產品需求面向的要解決的問題不同，而可能存在多個層面，多個維度的層面，比如對於運營的影響，對於前端市場的影響，對於用戶的影響，對於財務、法務的影響；從技術開發、技術實現維度，比如對於前端開發的影響、對於服務端開發的影響、對於數據平台的影響，還可能涉及到對於運維資源的影響等；因此對應到實際的產品需求工作中：
需求准備的過程：了解需求可能涉及的相關業務系統及系統對應的數據流程和邏輯、了解需求可能涉及的外部服務的數據流程和邏輯；了解面向的內外部用戶的產品使用水平、學習能力和使用習慣；
需求分析的過程：選擇和制定最有效的，滿足時間、資源投入等要求的方案；
需求編寫的過程：詳細描述需求的業務流程，通過各種圖表格式說明新的解決方法在各服務系統之間、各業務部門之間、用戶與產品，產品與後服務之間的數據、文件和行為的交互過程、詳細的信息輸入、信息處理和信息輸出；每個業務節點明確的輸出物和節點標志，重要性和優先順序；系統架構、干係人角色和影響范圍；
需求檢查的過程：需求的流程、用戶交互動作、系統信息交互等完整性檢查；
3. 預測與監控
預測與監控在產品需求文檔的管理上是聯動的，是對於預測的事件發生的時候，進行管理的機制，監控=預測+干預。在產品需求文檔的管理上，對於設計好的業務流程、使用功能，在實際過程中可能會出現這樣或者那樣的 「非規劃」的使用，也就是我們通常說的「用戶並不總是按照產品設計的方式來使用產品，而且，往往相反。」因此，這部分內容很大的比例需要來對於用戶的行為進行預測和監控，並提供「預防」或者「解決」方案。其中：
預防在於，預測產品的用戶在使用的過程中，可能會進行的一些超過產品使用半徑的操作，一旦進行這些操作，操作的任務流程會中斷，掉出，進入其他業務流程中且無法回滾，從而使得操作無法進行下去，功能使用失敗，使用者會感覺產品、功能沒有包容性，缺乏引導性，導致了最後操作的失敗，預想的結果沒有實現，而且造成了一定的挫敗感，甚至造成了一定的損失。預防的具體方法多採用導航、提示等，不同的系統都有各自標准化的控價，我們在這里不做展開。
解決在於，預測產品的用戶在使用產品的過程中，因誤解、操作手誤而進行了「非標」、「超規」使用「掉出」原本設計的業務流程和操作流程的情況下，需要提供額外的流程和控制來「回轉」用戶的操作，來幫助用戶回到預先設定和他所需要的流程上來。解決的具體方法多通過「導航」引導「跳轉」和「返回」、「回退」來實現。對應到實際的產品需求工作中：
需求准備的過程：了解用戶特徵和使用水平、評估、比較不同方式實現需求對於用戶行為的可控性和「非常規」操作的危害程度；
需求分析的過程：選擇和確定需求實現方案，評估行為管理方式和管理機制；
需求編寫的過程：詳細描述需求的業務流程和交互過程中可能出現的用戶異常操作，相應異常操作中系統反應，系統對應的控制和引導；
需求檢查的過程：需求「異常」流程和相應引導、控制地完整性檢查；
在需求管理的過程中，就可以按照這個 描述——解釋——預測——監控流程來進行。這四個既是步驟，是需求文檔內容的組成部分，也是需求編寫完成之後的檢查。
四個模塊構成了需求文檔的完整性，且同時有各自獨立，有對應的說明，引導、要求和標准。所謂標准文檔，就可以按照這四個模塊作為框架、內容和格式。
寫在最後
產品需求文檔作為產品經理同視覺設計、交互設計以及技術開發人員進行需求溝通的一個載體，我平時用的比較多的是摹客的服務進行創作。一個完整的、充分溝通確認，並最終達成多方理解和共識的產品需求文檔，能夠最大限度的還原產品、功能的設計，保證產品、功能的實現，最大限度的減少因為各方理解的偏差而造成的時間、人力和經濟資源的浪費及復工。
4. 產品運營的工作內容是什麼
產品運營是一項從內容建設，用戶維護，活動策劃三個層面來管理產品內容和用戶的職業。
一、互聯網產品運營的工作：
其實互聯網運營和其他行業的運營沒有本質的區別，只是由於資源和行業用戶不同，執行手段不一樣而已。總的一句話，運營策劃所做的主要工作就是及時掌握市場行情，整合周邊資源，通過一系列的運作手段，為自有產品做推廣並實現盈利。
簡單的講可以理解為市場部工作者，但是與傳統市場部不同的是，現實中大部分所謂運營策劃又承擔了很多業績支柱角色（有點像電影業里的發行商），就是傳統的銷售部門，其主要原因還是由於互聯網行業大部分公司盈利模式不清晰造成的，公司不僅僅需要一個會花錢的推廣超人，還需要他保證能為公司帶來實際的利潤，由於盈利模式不清晰，決策者不能確定某種方案漂漂亮亮的推廣後是否能奏效（當然如果像傳統行業的買賣關系的話就另當別論了）。這對運營策劃就大大提高了一個檔次要求，也就是說好的運營策劃不僅要渠道廣泛、朋友多，而且還得有獨到的眼光和市場嗅覺，能夠准確預測推廣後帶來的實際效果，後者是評價此人是優秀運營策劃還是普通運營策劃的本質標准。
二、站點規劃：
網站上線前，站點規劃包括前期調研、可行性分析、策劃文檔撰寫、業務流程及邏輯明確、站點展現規范、參與UE測試等工作;網站上線後，站點規劃則主要是指新增需求的分析、補充開發的需求明確及相關文檔落實;
5. 互聯網產品功能介紹文檔又叫什麼
需求文檔註定是給所有人看的，它就是產品的定義。
文檔圍觀的人包括：你的老闆（如果產品夠大，還會需要老闆的老闆），設計師，工程師，測試工程師。有時還應該包括產品前端：如運營，銷售，甚至市場部同事。
在通過各方的評審和簽字後，一般來說，這個文檔就是一錘定音的事。若有更改，就是需求變更了。
所以，在需求文檔撰寫前和撰寫中，對產品方向和用戶的把握要足夠強，從產品目的，到每個鏈接的含義，都需要准確地定義。基本上，當你開始寫文檔時，應該萬事俱備。一邊想一邊寫，那說明你還沒有想明白這個產品是怎麼回事。
在有些公司，需求文檔會包括產品的最終設計界面。即在文檔提交給大家圍觀前，產品界面已經確定完畢。
----------------------------------------------------------------------------------------------
需求文檔寫作的一些建議
格式無所謂。用WORD的多，html，在線文檔都成，我還見過PPT寫的！
產品定義部分一定要詳細描述。按功能模塊寫，跨功能的定義用流程和關系來描述。多站在用戶的角度上，去定義用戶任務，用戶流程，頁面邏輯關系等。
使用准確的用語，注意邊界情況。比如，一個文本框最多輸入多少個字元？是阿拉伯數字還是皆可？超過字數會怎麼樣？
多畫圖。把原型包括進去，或者把產品界麵包括進去，不然就畫出來。否則除了你，沒多少看得懂。
一個需求文檔，一些通用部分是必須要包括進去的，我總結了一個示例。
當然， 很多時候有可能是創業公司，或是小版本快速上線，要求會寬泛得多得多。
比如現比較推崇的Agile敏捷開發，會更強短平快，削弱文檔的溝通而加強團隊的直接交流，簡化流程，快速反饋，快速迭代等等。這種情況下，需求文檔會極大簡化，咱就不在這探討了。
6. 市場需求文檔和產品需求文檔區別是什麼
該文檔是軟體產品項目由「准備」階段進入到「實施」階段的第一文檔，其作用就是某個軟體產品進行市場層面的說明」，這個文檔的質量好壞直接影響到產品項目的開展，並直接影響到公司產品戰略意圖的實現。一般在互聯網企業中MRD都是由運營人員和產品設計人員共同制定完成的，互聯網軟體產品由於最終直接面向終端用戶，且需要長期運營，作為互聯網企業中的運營人員是最清晰市場動向？產品受眾是哪些人？為什麼需要產品人員配合呢，主要是因為運營人員很普遍的觀念是以運營商品的視角來考慮問題並未能深埋產品級的需求，所以兩者配合來制定編寫市場需求文檔是最合適不過的。產品需求文檔(Proct Requirement Document，PRD)，該文檔在產品項目中是一個「承上啟下」的作用，「向上」是對MRD內容的繼承和發展，「向下」是要把MRD中的內容技術化，向研發部門說明產品的功能和性能指標。該文檔一般是由產品設計人員來完成，也就是傳統意義上的需求分析，其主要內容有，功能使用的具體描述（每個UC一般有用例簡述、行為者、前置條件、後置條件、UI描述、流程、子流程、分支流程，等幾大塊），功能點業務流程框線圖，界面說明，Demo等。
7. 產品需求文檔應該包含哪些內容
規范化軟體開發過程中的《需求說明書》的編寫，使之成為整個開發工作的基礎。
2 適用范圍
本規范適用於集團開發項目的（軟體）《需求說明書》的編寫。
3 編寫內容提示
1 引言
3.1.1 背景說明
說明被開發軟體的名稱，任務提出者，用戶及實現該軟體的計算機網路。
3.1.2 參考資料
列出有關資料(名稱，發表日期，出版單位，作者等)。
3.1.3 術語和縮寫詞
列出本文件中用到的專門術語的定義，及術語縮寫詞。
3.2 軟體總體概述
3.2.1 目標
軟體開發的意圖、應用目標、作用范圍以及需說明背景材料。
3.2.2 系統模型
圖示說明該軟體的所有功能及其相互關系和數據傳遞情況。
3.2.3 假設和約束
說明影響軟體開發、運行環境和系統能力（如預告出錯類型的能力）的某些假設和約束。3.3 詳細需求
詳細描述此軟體系統的功能需求和性能需求。
3.3.1 功能需求
對系統中每一個功能，要詳細描述（圖示或文字）。
概述 敘述功能名稱，目標和作用。
輸入 輸入該功能的信息。
處理 描述該功能做什麼，如何對輸入信息進行加工並轉換成輸出信息。
輸出 列出內部生成的文件。
3.3.2 性能需求
定量地描述此軟體系統應滿足的具體性能需求。可考慮以下方面：
3.3.2.1精度
說明系統的精度要求，如：
數據的精度要求。
數字計算的精度要求。
數據傳送的誤碼率要求。
3.3.2.2 時間特性
說明系統的時間特性要求，如：
解題時間。
詢問和更新數據文件的響應時間。
系統各項功能的順序關系。
3.3.2.3 靈活性
說明當需求發生某些變化時系統的適應能力，指出為適應這些變化而需要設計的軟體成分和過程。
3.3.2.4系統容量
包括系統的設計容量和理論（計算）容量。
3.3.3 輸入和輸出
解釋各輸入輸出數據類型，並逐項說明某媒體、格式、數值范圍等。對軟體的數據輸出及必須標明的控制輸出量進行解釋並舉例，包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。
3.3.4 數據管理能力
說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求作估算。
3.3.5 故障處理
列出可能的軟體、硬體故障以及對各項性能而言所產生的後果和對故障處理的要求。
3.4 環境
描述所開發軟體運行所需的環境。
3.4.1 設備環境
描述運行軟體系統所需的設備能力，如：
處理器的型號和內存容量。
存儲媒體的數量。
通信網路（包括說明網路結構，線路速度及通訊協議等）。
3.4.2 支持軟體環境
列出與待開發的軟體互相配合的支持軟體（包括名稱，版本號和文件資料），必要時還應列出測試軟體，還要指出該軟體用的編程語言，編譯程序，操作系統和數據管理系統。
3.4.3 介面
說明本軟體與其他軟體之間的介面、數據通信協議等。
3.4.4其他
說明本軟體系統在安全和保密方面的要求以及用戶對使用方便、可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求。
8. 產品經理需要輸出哪些文檔
1. 立項階段 產品經理需要進行市場分析、用戶研究、競品分析等，輸出的文檔有: 市場與競品分析報告:市場容量背景，競品數據、操作流程、用戶體驗、優勢、用戶構成等; 用戶研究報告:這個部分內容很多，根據實際進行選擇具體方法輸出不同形式的總結，譬如問卷調研、用戶訪談、用戶觀察、頭腦風暴等等;需要考慮的問題是這個產品是滿足哪一類用戶的哪一項需求?解決用戶的什麼問題?是提升效率，還是更加有趣好玩? 產品立項評審申請:在以上的市場與競品分析、用戶分析基礎上，提出立項申請，包含項目背景、項目目標、產品形態、項目投入與產出等。 2. 產品需求階段 立項成功後，就開始進入產品需求階段，這時就要更加深入的分析用戶需求，准備如下文檔: 產品策劃需求，包含:產品目標、需求概述、產品邏輯、主要功能特性、數值策劃;產品交互設計稿; 數據需求文檔:產品關鍵指標、指標體系、計算邏輯、數據上報、報表樣式等;目的是產品上線後對產品的評估，用戶行為數據的分析，對產品優化提供決策參考; 互聯網的一些事 產品運營方案:產品上線發布策略、產品運營後台設計，產品營銷推廣，內容運營，運營工作安排，持續運營優化等; yixieshi.com 客服文檔:包含產品說明、產品邏輯、用戶有可能遇到的常見問題解答等內容，如果產品相對復雜，需要對客服進行現場培訓指引;
9. 產品經理都需要寫哪些文檔，會哪些軟體
一、PRD的含義
PRD英文全稱Proct Requirement Document，中文意思是：產品需求文檔。 PRD文檔是產品項目由「概念化」階段進入到「圖紙化」階段的最主要的一個文檔，其作用就是「對MRD中的內容進行指標化和技術化」，這個文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。
二、MRD的含義
MRD英文全稱Market Requirement Document，中文意思是：市場需求文檔。 該文檔在產品項目中是一個「承上啟下」的作用，「向上」是對不斷積累的市場數據的一種整合和記錄，「向下」是對後續工作的方向說明和工作指導。 作用是：產品項目由「准備」階段進入到「實施」階段的第一文檔，其作用就是「對年度產品中規劃的某個產品進行市場層面的說明」，這個文檔的質量好壞直接影響到產品項目的開展，並直接影響到公司產品戰略意圖的實現。
三、BRD的含義
BRD，英文全稱為：Business Requirement Document；中文意思是：商業需求描述。 基於商業目標或價值所描述的產品需求內容文檔（報告），其核心的用途就是用於產品在投入研發之前，由企業高層作為決策評估的重要依據。BRD是產品生命周期中最早的文檔，再早就應該是腦中的構思了，其內容涉及市場分析，銷售策略，盈利預測等，通常是供決策層們討論的演示文檔，一般比較短小精煉，沒有產品細節。
四、PRD、MRD、BRD之間的關系
1、PRD要把MRD中的「產品需求」的內容獨立出來加以詳細的說明，而產品需求本身是在MRD中有所體現的。
2、MRD側重的是對產品所在市場、客戶（client）、購買者（buyer）、用戶（user）以及市場需求進行定義，並通過原型的形式加以形象化。
3、如果說PRD的好壞，直接決定了項目的質量水平；那麼BRD的作用，就是決定了你的項目的商業價值。 PRD、BRD和MRD，一起被認為是從市場到產品需要建立的文檔規范。
1、Axure RP（Rapid Prototyping）
Axure（讀音為Ack-Sure）無疑是目前最受關注的原型開發工具，其能通過組件的方式幫助網站或軟體設計師快速建立帶有注釋的原型（流程圖、線框圖），並憑借自定義可重用的元件、動態面板以及豐富的script能夠建立基本功能或頁面邏輯的動態演示文件。
Axure借鑒了office的界面，能夠讓用戶快速上手，並且提供了豐富的組件樣式修改，使得通過其能夠創建低保真、高保真甚至接近於實際效果的界面。然而最讓人稱道的是，Axure的豐富的腳本模式，可以通過點擊和選擇能夠快速完成界面元素的交互，如鏈接、state切換、動態變化等效果，使得Axure能夠生成十分接近於真實產品的原型。另一方面，Axure能夠導入其他人創建的元件庫，使得Axure能夠滿足絕大多數類型產品的設計。
但Axure仍然有一個讓人頭痛的問題：對於中文的支持不太友好。在小部分元件上輸入中午的時候，經常需要像碰運氣似的反復切換輸入法，破壞了咱們設計師的用戶體驗。
瑕不掩瑜，Axure仍然是交互設計師的首選原型工具。
2、Microsoft Office Visio
Visio在2000年被微軟收購，並在2002年成為office2003套件中的一個組件，最新版本是2007。Visio能夠獲得推薦的原因是因為Visio的適用性非常之廣，從網站界面、資料庫模型，到平面布置圖到工藝流程圖，Visio都提供了相應的元件庫和模板來進行快速創建。
相較Axure而言，Visio更適合於傳統行業的生產或流程設計，或者軟體及互聯網行業中的信息、數據和流程的說明，而不太適用於web界面。因為其的基於web的元件庫還是比較少，並且形式和結構也更類似於word中的圖形工具，因此在原型開發效率上都有所不足。
3、Balsamiq Mockups
這個基於Adobe AIR Runtime的工具實在是有讓人眼前一亮的感覺，手繪風格的元件樣式粗獷淋漓，能創建接近於紙上手繪的原型文件。其提供了豐富的手繪風格的web常用元件，包括常用的html控制項、以及一些組合控制項，如多媒體控制器、標簽頁、列表、Iphone界面元件等。
Mockups最值得贊賞之處在於其提供的多數組件都可定製外觀，對於中文的支持也不錯（選擇View > Use System Fonts）。
4、Mockflow
Mockflow和以上工具最大的不同在於Mockflow是一項基於Adobe Flex技術開發在線服務，提供了與Balsamiq Mockups基本相似的功能，甚至更豐富的組件，雖然其元件定製化不夠強大，但其提供的元件庫默認樣式卻非常適合用來做商業產品原型的搭建。有一個讓我愛不釋手的功能是模板，可以設置基於任何頁面的模板來進行新的頁面設計。
與其他模板工具相比，mockflow有一個非常特色的功能，基於web的存儲可以在任意電腦上聯機打開，同時可以其他人進行快速的分享，並收集在線反饋意見，非常適合虛擬團隊的原型設計交流。
雖然在線服務的基本帳號只能創建一個文件，但單個文件卻沒有限制頁數，因此也基本上足夠使用。
5、Pencil sketch
Pencil 是一款基於Firefox的擴展組件，安裝之後即可在Firefox的工具菜單中打開Pencil的繪圖面板。功能比較簡單，僅能用以日常簡單工作的輔助 說明。提供的默認元件都是基於軟體工程，因此更適合用於windows桌面程序的簡易界面搭建，或者是基本的頁面功能說明，並不適用於嚴肅的原型開發，但 好在體積小、又輕便，能夠方便將網頁中的元素直接拖到或者復制到當前的畫布中，這也是Pencil安裝在Firefox所帶來的便利之一吧。
更多工具...
在以上列舉的原型開發工具都是較為常用的，也是在國內的交互設計師們比較常討論的，但其實和Axure功能相似的軟體還有很多，下面也就一些簡單說明：
6、GUI Design Studio
這 是一款真的非常強大的原型製作工具，沒有在上面推薦的原因是因為我還沒有實際體驗過，但沖著這工程級的界面設計就沒有去嘗試的沖動，但是從官方網站的截圖 和視頻演示來看，這款軟體的操作模式和前面的原型工具大有不同。Axure之類多是基於頁面的原型設計，對於web網站盡管很實用，但是對於軟體界面的流 程設計卻略顯繁瑣。而GUI Design Studio卻另闢蹊徑，直接以建立元素與元素之間的關聯的方式來自動化的創建動作流程，而從視頻演示來看，這樣的確很大程度上提升了軟體界面原型搭建的 效率。
7、Prototype Composer
Serena 公司免費提供的原型開發工具，功能確實強大，提供了基於項目管理主要流程的產出物文檔模板、原型工具以及開發流程式控制制，這個軟體的開發理念非常好，用這一 款工具來滿足項目開發流程中各個環節的溝通和決策。但軟體的學習和使用成本比較高，要了解其中的全部功能，貌似需要花不少時間。另外軟體的效率和穩定性還 有待提高，試用的過程中多次出錯及停止響應。
8、Lucid Spec
由 Elegance科技推出的Lucid Spec是一款很類似Pencil的原型工具，僅僅是提供了更多控制項。不過Lucid Spec強調了生成干凈的說明文檔的功能，這可能是針對於多數原型工具的自動化生成規范的冗餘而言的，不過老實說Lucid Spec提供的原型界面太過簡陋，並且生成的說明文檔也未見優化有怎樣的提升。視頻介紹
9、Irise Professional Edition
Irise與其他原型工具相比其中一個特色在於提供了樣本數據的功能，這是類似於excel表的一個樣本資料庫，可以通過界面元素直接獲取樣本資料庫中的數據，這樣所生成的原型甚至可以使動態數據更新的。
10、Adobe Reader
Adobe reader？沒錯。其實理論上任何可以創建圖形和文本的工具都可以用來原型開發，因為原型本身就是對於業務邏輯和功能界面的模擬或模擬，因此有何理由不能使用PDF格式呢？BoxandArrow的這篇文章《PDF Prototype》提醒了我們，所有的原型工具都只是工具，而不是設計本身。
另外這里的也可參考一下.http://www.oschina.net/project/tag/291/ui-design/
但個人推薦:
原型
• Axure 7.0
• UIDesigner
思維
• Mindmanager
• Xmind
流程
• Visio 2013
• EDraw Max
知識
• 有道雲筆記
• 印象筆記
時間
• Todolist
• Worktile
圖形
• Photoshop
• Colorpix
交互
• 快現
• UIDesiger
10. 產品經理需要寫的文檔有哪些
這些客戶是什麼樣子的？ 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確定;業務邏輯的細節確定;表結構設計功能詳細說明