A. 如何撰寫PRD文檔
prd文檔是產品項目由「概念化」階段進入到「圖紙化」階段的最主要的一個文檔，其作用就是「對MRD中的內容進行指標化和技術化」，這個文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。
開發工具推薦 ：
Rational Rose★★★★－－熟悉項目發生的相關業務行為。
visio 2007★★★★－－將業務，從產品層面肢解開來，做到抽絲剝繭部分與整體統一
mind manager★★★－－把項目條目化，條理化，目錄結構具體規定好。
Axure★★★－－前台結構布局，合理規范的將系統脫去朦朧的華紗。
Word★★★★★--穿針織網，把需求綜合起來，整理成最終的產品需求文檔。
也就是用以上任意一種軟體都可以打開，不過應該有版本要求。
B. 簡單介紹下PRD、Visio、Axure這幾個軟體的功能
PRD產品需求文檔(Proct Requirement Document，PRD)的英文簡稱。是將商業需求文檔（BRD）和市場需求文檔（MRD）用更加專業的語言進行描述。 [編輯本段]文檔作用 該文檔是產品項目由「概念化」階段進入到「圖紙化」階段的最主要的一個文檔，其作用就是「對MRD中的內容進行指標化和技術化」，這個文檔的質量好壞直接影響到研發部門是否能夠明確產品的功能和性能。 [編輯本段]文檔意義 該文檔在產品項目中是一個「承上啟下」的作用，「向上」是對MRD內容的繼承和發展，「向下」是要把MRD中的內容技術化，向研發部門說明產品的功能和性能指標。 [編輯本段]文檔撰寫 在該文檔中，基點依然是MRD中的內容，只是把重心放在了「產品需求」上，而產品需求本身實在MRD中有所體現的，區別就是在於，PRD要把MRD中的「產品需求」的內容獨立出來加以詳細的說明。
這部分是PD寫得最多的內容，也就是傳統意義上的需求分析，我們這里主要指UC（use case）文檔。主要內容有，功能使用的具體描述（每個UC一般有用例簡述、行為者、前置條件、後置條件、UI描述、流程/子流程/分支流程，等幾大塊），Visio做的功能點業務流程，界面的說明，demo等。Demo方面，可能用dreamweaver、ps甚至畫圖板簡單畫一下，有時候也會有UI/UE支持，出高保真的demo，開發將來可以直接用的那種。
文檔核心：
該文檔中，側重的是對產品產品功能和性能（即「產品需求」）的說明，相對於MRD中的同樣內容，要更加詳細，並進行量化。
在一些國外的公司，是允許把MRD和PRD合並成一個文檔的，通常叫做「Marketing & Proct Requirements Document」。 [編輯本段]錯誤認識 1）PRD無原始數據（MRD為體現載體）支持，只是個人經驗、部門要求或者領導指示進行撰寫。
2）在PRD中，只重視「產品功能」的描述，而缺乏對產品其它指標項的說明。在一個完整的PRD中，一共需要對產品的10個產品需求項指標進行說明，分別是「功能要求、開發要求、兼容性要求、性能要求、擴展要求、產品文檔要求、產品外觀要求、產品發布要求、產品支持和培訓要求、產品其它要求」。
3）照搬國外的PRD模板，來源於何處，不知道，將去向何處，也不知道，無頭無尾，一個被割裂的文檔。 VISIO概述 Microsoft Office Visio 2007 是微軟公司出品的一款的軟體，它有助於 IT 和商務專業人員輕松地可視化、分析和交流復雜信息。它能夠將難以理解的復雜文本和表格轉換為一目瞭然的 Visio 圖表。該軟體通過創建與數據相關的 Visio 圖表（而不使用靜態圖片）來顯示數據，這些圖表易於刷新，並能夠顯著提高生產率。使用 Office Visio 2007 中的各種圖表可了解、操作和共享企業內組織系統、資源和流程的有關信息。 Axureaxure 概述Axure RP 能幫助網站需求設計者，快捷而簡便的創建基於網站構架圖的帶注釋頁面示意圖、操作流程圖、以及交互設計，並可自動生成用於演示的網頁文件和規格文件，以提供演示與開發。
C. PRD文件用什麼軟體可以編輯
把後綴名直接改成JPG
D. 產品經理應該怎麼寫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、其他需求、附件
作為需求的一種補充，對一些需求進行補充說明，或者需要的文件說明等
歡迎來起點學院學習更多產品文檔寫作方法
E. PRD格式的文件用什麼軟體製作編輯啊
Foxit Pdf Editor 2.0 build 1011 漢化版 PDF文件編輯軟體
這個大小僅有2M不到的軟體可以簡單地實現PDF的閱讀和創建修改工作.不過擴展功能什麼的就不多了,並且不支持中文,而這可以通過安裝中文包實現.
F. prd，prd文檔用什麼軟體做
我用的摹客iDoc，感覺是為產品經理量身打造的文檔工具，支持在線撰寫或上傳本地文檔。
文檔可以和Mockplus、Axure的原型圖和Sketch、Adobe XD、PS的設計稿互相引用，相互論證。也支持自動生成歷史版本，可隨時追溯和查看。完成後可以直接生成鏈接分享給同事，同事可以在上面選中文字評論，審閱很方便，哪裡有問題也可以隨時查看修改。
G. 用axure原型中用什麼寫prd
1、我自己畫的工具，參考了網上的部分信息
2、使用圖片，思維導圖等工具來實現
H. 如何快速寫好基於AxureRP原型的PRD文檔
大公司才會有交互設計師這個崗位，也就才會有交互設計稿這種文檔產出，一般的公司都是只有產品設計師、需求分析師、商務分析師或者產品經理這樣的崗位，這個崗位基本會包辦了從需求收集，需求分析，需求設計，原型設計，編寫PRD這樣的一個過程，所以說小公司比較鍛煉人，會練就全能的本事。編寫PRD文檔是個較為苦命的工作項，具體的編寫要求參見《如何書寫好的產品需求文檔PRD》，這份文檔將會作為產品的指導性文檔，告訴開發、測試產品的需求點，實現的要求，驗證的邏輯，運營人員也需要參考，以獲知當前產品所能達到的功能層次。寫文檔的時候事無巨細吧，人家會嫌你寫的太繁瑣了；寫的太簡單吧，人家又會嫌你沒說清楚該說的；開始使用敏捷模式要求文檔弱化了，但其實只是在過需求的時候不需要提前先把PRD寫好，事後還是得補的；寫文檔耗掉的時間多了，人家會說能否除掉一半，功能需求都確認好了，你只是將它描述出來為什麼要用掉那麼多的時間？凡此種種，都讓做產品的我們感覺命怎麼這么苦，因此開拓一種寫PRD的新思路新方法是相當有必要的。現在都講究用工具來輔助，工具用的好，確實能事半功倍，那要是工具用的不好呢？那就只能自求多福了。原型設計軟體的主要功能還是用來做原型，那是否原型演示完了之後就沒有用了呢？這個我想有點工作經驗的人都不會這么認為，當然我們還是可以發揮一下原型的剩餘價值的。大家都知道，如果一份文檔裡面可以圖文結合，所描述的東西更能吸引到人去閱讀，也更能幫助別人理解。AxureRP所設計的原型支持HTML格式的瀏覽，相較於其他原型設計軟體直接產出圖片，AxureRP的原型即可以直接導出成圖片格式，也可以通過在瀏覽過程當中用截圖軟體來截圖的方式使用，當然後一種方式更為繁瑣，後面說明為什麼直接生成圖片反而不方便。 使用AxureRP自帶的文檔生成功能去生成PRD文檔這點我在之前寫AxureRP使用教程的時候有提到過，AxureRP是支持通過即定的word模板格式來導出生成文檔的，可以參考《AxureRP教程–生成規格說明書》。不過使用這個功能對自身的要求是比較高的：1、要對AxureRP所提供的注釋功能非常熟悉，其默認提供的注釋欄位是國際通用的，並不適合中國國情，要根據產品和項目的需求進行修改和自定義。要了解組件注釋和頁面注釋的使用方式，以及這些注釋會出現在文檔的什麼位置等；2、要在做原型設計的時候就做好注釋的錄入，每個組件的交互，前置觸發條件，後置反饋事件，以及每個頁面的功能說明等，這是一項細致活，挺耗時間的，和快速原型設計的要求不大相符；且萬一在確認需求的過程當中需要修改的，這個維護量也比較大；3、要熟悉word的格式排版設置，用AxureRP默認提供的word模板生成出來的PRD文檔，估計不符合大多數公司的文檔編寫要求，如果沒有要求的則可以直接使用，否則就得自己倒騰一個word模板出來，這個對word的功底要求較高，再就是還得熟悉AxureRP裡面模板導入的機制和模板使用機制；4、綜上所述，這個功能雖然很強大但實際應用的較少，其實比較雞肋，個人是已經放棄了，有興趣的朋友可以深入研究一下，到時分享一下； 基於AxureRP原型的PRD文檔編寫這個方式其實就是截圖，然後用截圖+文字的形式來書寫PRD文檔，有人就說了，圖片製作軟體那麼多，為什麼非得用AxureRP來做原型，還得截圖呀，這里有個已經使用AxureRP的前提：1、AxureRP提倡快速原型設計法，可以大大減少原型設計的時間，這是選擇使用AxureRP的一個原因；2、AxureRP支持HTML格式的瀏覽，極大的方便了原型的演示效果，可以很清楚地告訴演示對象每個頁面的跳轉，每個按鈕的操作效果，每個連接點擊結果等，這是選擇使用AxureRP第二個原因； 當然AxureRP的優點不止於此，原因可能很多，但主要的是這兩個方面，這兩個前提決定了我們當前都是使用AxureRP來做原型設計的，然後再討論如果在已經使用AxureRP的情況再來優化截圖寫PRD的方法，否則就沒法進行下去了。1、為什麼是HTML格式頁面的截圖而不是直接導出圖片？這個從操作層面上來講，導出圖片的模式操作流程如下：導出為圖片>>>打開word>>>選擇插入菜單>>>選擇插入圖片>>>搜尋圖片所在文件夾>>>選擇圖片>>>點擊按鈕完成插入圖片操作；或者是下面這種方式：導出為圖片>>>打開圖片所在文件夾>>>選擇插入圖片並打開>>>復制圖片>>>打開word>>>粘貼圖片完成插入圖片操作；這個比上面的省一個步驟；從HTML頁面截圖的模式操作流程如下：打開對象所在HTML頁面>>>用截圖工具截圖>>>復制所截圖片>>>打開word>>>粘貼圖片完成插入圖片操作；對比一下就知道，用截圖的方式所需的操作步驟是最少的，也就是最能節省時間的，這里推薦一個截圖工具：Snagit（下載地址），可以對所截的圖進行一些簡單的編輯，比如畫個圈圈提示一下，畫點箭頭什麼的。2、基於AxureRP原型截圖這種方式更能適應需求變化。大家都知道AxureRP是支持單個頁面的修改單個頁面重新生成原型的，不需要整體原型重新生成一遍，這樣某個地方修改了，只要重新生成一下原型，然後再截圖修改即可，而導出圖片的方式AxureRP只支持導出主頁和導出全部頁面兩種方式；3、截圖工具的輔助功能，上面也提到了，可以對圖片做一些必要的處理； 這是截圖+文字的模式，有了截圖之後，編寫描述文字應該就方便很多了，避免出現大段的文字。另外PRD編寫一般都是有格式要求的，有些內容不能用工具來解決，一般一份PRD文檔要包含以下這些內容：1、概述部分：簡單介紹一下產品的背景，產品的價值或者願景，產品的簡單介紹，一些預估的風險點，干係人，名詞解釋等等；2、業務需求描述部分：定義好目標用戶群體，業務流程圖，業務架構圖，腦圖等等的介紹；3、功能需求描述部分：這部分才是用到上面所述方法的點，每個功能點都可以用那樣的方式描述；4、非功能需求描述部分：與產品相關的一些輔助功能，性能要求、易用性要求等等；5、介面描述部分：與外部有相關介面的需要在這個部分描述；6、附錄部分：培訓信息、參考資料等，還可以有運營計劃等等；完整的PRD文檔中，最多的部分就是對功能需求的分解描述，AxureRP可以很好的支撐這個部分的全部內容，另外其實AxureRP也有流程圖、UML圖的功能，業務流程圖、業務架構圖等都可以在AxureRP裡面實現出來。基本上我自己目前就採用的是如上的方式來編寫PRD文檔，在原型已經設計好並演示確認了的情況下，編寫PRD文檔一般都比較快速，30頁到50頁之間的文檔，如果時間利用充分的話，可以在1天到1天半之內搞定。產品經理都是很忙的，時間擠擠總會有的，要在有限的時間內做更多的事，一是要充分利用工具，二是要發掘一些新的方法，雙管齊下，應該就可以找到適合自己的Style！作者博客：IT民工（若無特別註明，雷鋒網文章皆為原創，轉載請註明出處)
移動互聯網創業和創新 雷科技
匯聚全球面向未來的創新科技產品 愛搞機
玩智能手機就上愛搞機 超好玩
推薦超好玩的移動游戲
超好玩的推薦移動游戲 左林右狸
雷鋒網創始人林軍、笨狸二人轉
負責八卦和無厘頭，絕不賣萌！
I. .PRD格式的文件用什麼工具打開
一種圖片格式
這是轉換器
可以轉成BMP JPG之類的
http://www.onlinedown.net/soft/21413.htm
J. 如何寫出好的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、運營計劃
產品上線後如何運營，目標受眾是什麼，建議的推廣策略、問題反饋途徑、風險監控、亮點宣傳等等，以及與運營人員的協作方式。作為產品的設計人員不是開發完產品就能畫句號的，讓產品用起來、用得好，有口碑更為重要，所以非常建議運營計劃的制定上有產品設計人員的參與。