1樓：產品幫
有的公司要求也不是很高，大部分只要求畫原型，不寫文件，有的公司要求的比較高，原型和文件都需要寫，這些都不一樣，從產品經理的角度來說，產品經理需要做的不只是寫文件，畫原型，還需要做好需求溝通，需求調研等一系列的工作。寫PRD文件是必須的，因為不寫PRD文件的話版本不好更新迭代，所以一般公司都要求寫的。
但一些產品經理的能力也許不足，還有一部分是公司工作流程也不合理，導致的差異化還是很大的。但是文件是必不可缺的一步，這是真實的。
如果要系統學習產品經理的能力體系可以在產品幫進行學習。
產品經理培訓_產品經理培訓班_產品經理培訓課_產品幫產品幫：產品經理實訓基地介紹
2樓：產品一哥
題主你好，PRD它是產品經理將需求輸出為下游各職能可直接執行的文件。PRD可以高效指導各職能執行，協助溝通，解決糾紛，確立標準，降低交接負擔。不僅不會降低效率，而且大大提公升效率
乙個真正優秀的產品經理需要考慮的事情早已不是「我要不要畫不畫原型」這樣的。有時間專案趕時間，就用紙和筆，簡單花個草圖，程式設計師能看懂就行了。
產品一哥：萬字乾貨！0基礎如何拿到產品經理offer《0基礎如何拿到產品經理offer-資料分享》，資料提取碼【z8nr】
0基礎如何拿到產品經理offer-資料分享產品經理求職-面經分享
產品經理求職-面經分享
3樓：程式猿產品經理
必須要寫PRD，最簡化PRD文件大綱如下：
因為在快速迭代過程中需求隨時會變化，所以我們要隨時更新PRD文件，並同步給開發者。PRD文件主要面向開發者、設計師，所以一定要多跟相關同事交流，不斷完善文件，真正意義上提高協同效果。
4樓：啊波
完全合理
文件，原型，描述，都是溝通的手段，一切是為了傳達意圖，產品的輸出成果，是將客戶的意圖清晰的轉化並轉達給研發。
轉化的手段可以是文件，圓形，口頭描述，也可以不是，有何不可。
當然，研發覺得產品這樣太輕鬆，想故意找點麻煩，就是另乙個話題了
5樓：張佳毅
做產品？看你怎麼定義你的產品在什麼賽道。
如果你自己能研發，自己能切圖，自己能融資，那麼就不需要原型和文件。
計畫或者說施工手冊，是用來統一思想、協調推進的。乙個事情乙個人幹和許多人幹，是不一樣的，需要增加管理成本，或者說比理想狀態需要增加耗散的成本。
一兩句記在筆記上的話可以讓你迅速回憶起五年前的奇特創意，但是卻不是幫你開發的人。如果你可以用語言搞定開發，可以重複再重複的溝通，讓對方記住，其實也可以，大部分老闆就是這樣做的。
偏題了。
用什麼方式，還是要明確目的是什麼？
能把產品逼出來就行？
有的人用了高明的方法
有的人用了團隊接受的方法
有的人用了流行或看起來與眾不同的方法
有的人用了上司指定的方法
有的人用了熟悉習慣的方法
有的人用了個人可以被認同為老手的方法
有的人用了自己擅長的方法
有的人用了高技能門檻要求的方法
有的人用了招聘廣告要求的方法
有的人用了延長時間確保思考質量的方法
.....
好吧，我喜歡PRD。
我幹的活是否漂亮不是自己說了算。
人們說你漂亮，你才漂亮；人們說你成功，你才成功；人們為你的產品買單，你才能收到錢。
6樓：誰禿誰知道
產品的底層架構對每個業務都非常重要，創業初期我們往往因為沒有足夠優秀的團隊，沒有足夠的時間，沒有足夠的重視等原因，沒能設計好產品的底層架構，當業務快速迭代到一定階段後發現產品已經無法快速響應業務變化，支援新業務拓展，這時候就面臨是否需要做重構的選擇。做好底層架構其實並不花費太多時間，需要的是足夠的重視和找合適的人來架構。
我認為要做好底層架構，就要從最基礎的實體關係圖（ER 模型）開始。實體關係圖是對現實世界業務的物件、屬性級的抽象，是資料建模的基礎，實體對應著資料表，屬性對應著字段，關係對應著表間的約束，是產品經理和技術重要的溝通橋梁，是技術了解業務全域性的物件。
7樓：大尾巴
我喜歡把需求說明寫在原型裡面。因為文件很不直觀，開發小夥伴都懶得看。
但是不能僅僅只畫乙個原型。得把功能，業務流程，判斷條件，互動效果等細節的東西講清楚。不然開發出來和產品想的東西不一樣，就是無盡的撕逼和返工。
8樓：隨夢奔飛
以文件進行流程傳遞是瀑布式開發
以人為核心進行流程傳遞是敏捷開發
你們需要根據實際的產品情況確定使用的開發模式打造產品。
PRD文件、原型檔案這些都屬於資訊傳遞的載體，你們團隊如果協作良好，快速迭代那可以考慮不用太多文件資料，目的是加速研發進度和上線。適當情況下還是建議少部分的文件作為留存
9樓：一章
要明確PRD的兩個作用，乙個是用於團隊落地需求，乙個是用於文件記錄。
前者取決於團隊配合的需要，可以極簡到只有原型稿+規則說明+資料上報（攜程不少團隊為快速迭代就用類似方式），這個時候原型稿本身就是一種PRD。也可以是相對完整的PRD，甚至在比較大專案的時候PRD的範圍會擴大。
其實PRD寫的好壞完整度都取決於團隊本身需要，即PRD本身的服務物件和服務目標是什麼。服務於專案團隊，幫助推動專案落地，主要物件是開發、測試。
對於不同型別的產品，PRD的要求也是不一樣，偏後端的產品甚至要求細化到資料庫欄位的定義、資料流等，而偏前端的產品則往往需要在互動細節、異常邏輯方面下功夫。
建議多參考團隊以往的PRD，以查漏補全的心態，梳理出PRD模組，比如乙份C端產品的PRD通常包含：版本記錄、迭代背景和目標、專有名詞定義、功能闡述（定義與流程）、互動稿、異常邏輯、資料埋點。
如果遇到比較大的專案，比較有效的PRD文件，往往是乙個寬泛的PRD文件。舉乙個C端產品X.0級迭代的例子：此時PRD可以拆成好幾個文件來達成不同的目標。比如可以拆成：
專案背景和服務目標與關鍵收益、解決方案、競品對比、後續規劃，作為專案介紹的文件，用來做「預宣講」，核心目標是團隊對其方向和目標、增強開發對於迭代價值的理解、開發技術預研與成本粗估；
前面介紹的PRD作為落地的宣講會文件，核心目標是用於保障開發實現和測試驗收；
資料埋點單獨羅列，並可以將核心資料指標及計算公式羅列上，來增加開發對於資料埋點價值的理解；
不管怎麼樣的PRD文件，難免都會有遺漏和迭代，關鍵要勤溝通、多同步和記錄，翻過的錯不要犯第二遍。
10樓：夏丹
"5年了，乙份PRD文件沒見過，整個產品連乙份完整的PRD文件也沒。"
如果不是你剛編的故事，貴司5年還沒有倒閉，那麼，合理。
尋寵啟事 - 四個爪爪
11樓：敏捷
這個問題可以分開說：
所以不寫prd是否合理不是重點。重點是只寫原型也要把背景，使用者需求故事，產品邏輯主流程，產品架構和基本頁面互動寫清楚，提高整個團隊的工作效率和確認產品的價值是關鍵。
12樓：發條怪獸
看階段，在早期，為了速度，簡化流程是比較有效的辦法，這個非常考驗產品經理的溝通表達能力，長期去看，PRD文件的存在必要性還是很高的，沉澱、積累、精準描述、減輕溝通成本
13樓：JK Joker
單靠原型完全不能表達清楚意思呀，肯定要把相應的文字描述寫上去。等你把相應的文字描述補充完全了，那跟prd又有什麼區別呢？？？
這個概念性的東西為啥到現在還有人爭論。作為產品難道不清楚文件寫得不清晰，開發來找你，測試來找你。不斷中斷你的思考通路，這效率就很低。
14樓：西門吹牛
合理不合理看團隊是否默契，如果溝通順利不寫的話確實能提高效率。但是一切還是以工程，專案目標為主。如果不寫，造成研發人員難以理解，或者導致邏輯不對，造成的反工，那就弊大於利了。
但是從能力的角度看，有PRD，有原型，這是一種基礎能力和基礎素養。作為產品提供給研發是基本職責，也是側面體現乙個產品素質，能力的地方。
很多東西存在即是合理的，產品如果沒寫，要是我配合的話，首先我會給他的專業能力減分。然後就留下乙個不好的印象了。
15樓：程Caton
不合適，好記憶不如爛筆頭！PRD的主要用途不只是研發依據，還是留檔，很多需求在研發過程中都可能微調，直接交流解決，如果沒有留檔會很麻煩。產品經理也需要寫PRD，寫的過程中可能發現需求存在問題，提前修正避免浪費開發資源。
PRD這東西應該是公司資源，保證人員更迭的時候專案能盡可能正常交接，後人快速上手。
不寫PRD是不對的，耍流氓行為。即使前期時間緊沒寫，後期也應該補全，工作的一部分。
16樓：
在特定情況下，是可以接受的。比如：時間極其緊張，且產品owner、研發團隊確實都很有經驗。另外，如果就是抄襲，直接看別人產品別PRD來都更快。
結合後面補充都內容，明顯產品經理比研發說話更有力度。這個產品，我認為只能算專案經理，軟體行業的專案經理。
業務邏輯複雜，且經常會變（不同客戶不同邏輯）這種情況下，人腦比文件好用。
一方面，產品負責人的存在價值比較高，可取代性比較低。另一方面，去寫文件太繁瑣，因為邏輯太繁瑣了，如果都要去寫問題，可能他的工作量要翻翻。
所以，具體判定這個事情是不是合理，還是要看具體業務。
17樓：Huan Chen
很多產品不是不寫 PRD，根本就是不會寫。不畫原型就不知道能寫啥了。曾經有個pm跟我說，「產品不畫原型，不就是專案經理了.....
"。我跟他說，除了原型圖，能做的事多的是：業務目標是什麼，目標如何測量，場景是什麼，用例是什麼......
我作為設計，對接的產品，沒乙個文件寫的清楚的。每次都要從原型倒著推需求，讓產品補全。有的時候原型還起了誤導作用。
就算這個公司沒有設計，產品原型直接進開發，只有原型也是不好的。原型只對這個專案的實施有意義。而產品需求是對產品特性的描述，是有長遠價值的，是重要資訊和決策的承載。
我對接乙個複雜業務組對接了一年多，那些系統究竟有多少不同使用者角色，角色之間的關係，有多少業務流程，我至今都沒有乙個系統性的認識。產品乙個專案乙個文件，資訊極度碎片化，還很冗餘。
大多數人是知道文件重要性的，老找理由不好好寫文件的是產品自己。現在大多數網際網路公司結果導向，文件寫不寫，寫的好不好，不影響產品工作，反正有設計，開發，測試兜底。
18樓：Agile2-張恂老師
通常是不合理的，有意思的是背後的原因。
研發提建議需要PRD文件，產品負責人答覆很多網際網路公司都是這樣，還說「產品即文件」。
「產品即文件」，這是胡說八道，一種託辭。
UI、原型圖主要是給大前端看的，而反映產品需求的 PRD 是給全團隊成員看的，包括中端、後端等，所以研發提出要 PRD，很合理、自然。
PM 堅持不寫PRD，我分析主要可能有這幾個原因：
1、這個 PM 缺乏軟體工程、軟體開發過程的基本常識。
作為多年的 PM，這種可能性不大。
2、不寫 PRD ，主要是為了某種職業保護。
盡量不寫或少寫需求文件、開發文件是乙個老傳統，30 年前就有了。
如果明知需要，卻反常地故意不寫，主要還是為了自我保護，作為一種針對公司、老闆，進行防禦與自我保護的手段，以防被中途「換人」。
所以，即便寫了，也要交乙份質量較差的，不含或缺少關鍵資訊的。
5年了，乙份PRD文件沒見過，整個產品連乙份完整的PRD文件也沒。產品經理現在經常找研發問半年以前的需求邏輯，問某個兩三年前早已經實現需求能不能做。
可見並不是不需要 PRD，沒有價值，而是故意不寫的可能性較大，寧願堅持低效率工作。
當然，這位 PM 的工程管理水平確實不行，有點稀里糊塗，也是有可能的。
為什麼沒有 PRD，還能維持多年，保持成功？
主要關鍵人物還在。
關鍵人物一走，可能就會造成研發癱瘓，要的就是這種效果。所以，重要的、有價值的知識資產都盡量留在關鍵人物的大腦中， 而不要留在書面的公司文件上（留給他人）。
這就是江湖的現實，很正常，可以理解。
3. 待補...
移動網際網路公司多是如此？
不僅是移動網際網路企業，許多
二、三流研發團隊確實有這種現象，主要是與軟體工程成熟度、公司管理成熟度以及企業政經學等方面的原因有關，不是特例。
開發複雜產品的一流團隊沒有 PRD 或 SRS 通常是不可想象的，許多開發過程、管理制度上的風險、漏洞都被預先防範了。
產品經理如何寫PRD需求文件？
劉歡迎 PRD 產品需求文件 是讓所有團隊成員保持一致的答案。它作為乙個單獨文件，所有團隊成員和利益相關者，都可以理解產品的目的和需求。它不需要是乙個非常詳盡的文件，但它應該提供產品的基本概念。乙個好的PRD文件應該有以下幾個部分 產品簡介，願景和目標 產品為誰開發 為什麼要開發這個產品 競爭態勢與...
感覺產品助理入門要求好高，畫原型圖，寫prd，做競品分析，我應該先 從哪方面 入手呢？
空楚 首先，競品分析應該是你入職之後關於產品的第一件事。目的不是讓你乙個小白真的去分析這個市場，分析競品而是要你了解行業然後快速的融入專案。所以這種產品分析你只需要把行業內的明星產品列出來，然後把它們的功能列出來，做乙個對比入職的競品分析就完成了。你的團隊每兩周或者每個月或者其他更長時間週期性的會重...
需求分析 產品經理寫需求文件需要涉及系統流程和資料流程嗎？
小婧 我個人覺得這個要看團隊。如果開發團隊裡面的人都比較認真負責，自己也比較有想法，流程也比較規範的話，你可以不寫太多的技術細節。但是如果不是這樣，那最好還是寫，否則可能真的會出現掰扯不清楚的情況。我個人覺得，在大部分的情況下，需求分析 產品經理寫一些設計系統流程和資料流程的部分是從業務和需求的角度...