1樓：充電5分鐘
不到萬不得已不要用需求文件和研發撕逼，一旦這樣做也就說明你對研發的驅動力來自於職位而不是來自於個人。
一旦大家都很規矩的做開發，那即便乙個很小的改個排版也要讓你寫個文件，想想多痛苦，產品經理的目標是盡可能快速的把產品做出來，而不是如何把文件寫的好啊。
多關注工作目標，過程當中背一點鍋，多認個錯也沒什麼，只要不影響考評。
2樓：小小魚愛陽光
如何寫乙份易用的產品需求文件？ - 小小魚愛Sunny的回答 - 知乎https://www.
3樓：梯谷
不同公司有著方式方法的不同，目的都是為了把需求想到位表達清楚需求文件需要可視可讀、方便協作和維護
工具很多，office\iwork\google dcos\axure都行
本問題得票最多者 @肖光利 同學提到的針對不同物件做不同的文件，是出於需求理解方有需求載體偏好，很難將就所有人，但乙份文件從始到終想必也很有必要，需求方、開發、測試和設計都能看明白是最好的。
4樓：袁少成
文件本身就是結構化的溝通工具，更根本的任何一種語言也是，可以認為指令碼【電影指令碼】也就是乙份PRD文件，這沒什麼很大的差別
產品經理如果是乙個專案負責人或者是公司創始人，我覺得應該為團隊創造乙個適合彼此的結構化溝通工具，可以是TXT也可以是PRD也可以是原型，這視乎團隊的成員能力和溝通成本
如果是乙個執行，乙個產品助理，這個問題最好的和最直接的解決方案應該是問主管
5樓：
既然是PRD，到這個階段基本是面向開發和前端的文件了，所以不必考慮領導層面，他們更關注MRD。
幾個關鍵點：
1. 清晰的目錄結構以及版本列表：方便日後查詢，及追溯歷史；
2. 明確的需求及適用範圍：確保從根本上不會跑偏；
3. 名詞和業務流程的解釋說明：認知要統一，否則到最後發現乙個詞指代不同的內容，簡直浪費時間和繩命；另外業務的邏輯要清晰，流程圖展現的越詳盡越好；
4. 細節的考慮：比如某個功能觸發的時間點，成功/失敗的提示等。
另外PRD並不是萬能的，還要配合原型使用，這樣給開發和設計的思路才是完整的。
6樓：艾薇兒.拉維尼
如果是給開發看，盡量詳細吧。如果你覺得的需求已經寫得很詳細了，其實離開發真正看懂還有一段距離呢。至少要保證頁面中的每乙個元素的屬性和觸發的事件都要有詳盡的描述，同時還要考慮各種可能的異常和故障（硬體）處理。。。。
7樓：
我寫文件的習慣是，結合互動稿，如果沒有互動設計師，那就自己學著畫。畫互動是體力活，技術的要求不是太高。
你預先把互動畫出來，或者和互動一起畫出來。那基本上你對需求相當於review一遍。
然後結合互動圖，再配上文字，就基本沒啥問題了。
一般用word可以，Excel也可以
8樓：
需要確定的一件事情，你真的在寫需求文件嗎？我們需要產品經理做的的是針對產品的規劃，而不是需求文件，需求應該是由更專業的人來做，人的思維和理解能力都是有限度的，並不是所有人都是Jobs或者Gates，專業的人做專業的事，真正深入到軟體過程中去，需求文件是有它的規範的，不是你怎麼寫都行的，否則就不是需求文件，而是草案。需求文件不但有格式的要求，還有表述的要求，它不是散文也不是七律，是開發的依據，需要有依據，就要能追朔到源頭，有分析的過程，而不是你想怎麼寫就怎麼寫的。
都在說以使用者為中心，你怎麼以使用者為中心，憑什麼說你是以使用者為中心，怎麼找到使用者，如何確定你給使用者提供的價值，這都是有一套嚴格的分析流程的。現在國內很多人對於這一塊的重視程度太低了，很多公司所謂的需求分析不過都是拍拍腦袋想出來的，繼而決定了其需求文件不過是某某產品經理或者是專案經理做的草案而已，其解釋權都在編寫者手上，無法在所有人當中形成共識，其對於具體開發的意義也就不言而喻了，最終的結果就是導致不斷的變更，而其實這些變更是可以在初期需求分析的時候就能避免的。
9樓：李宇飛
人類的思維溝通是最困難的，所以首先同意「以使用者為中心」的答案，需求文件要看寫給誰的，寫給研發的自然要做到細緻周到，同意上面包子所說的案例，如果我是A的話，就會寫「給我一張空白A4紙」，後面還要跟上原因或者和其他的因果關聯「因為我要用來畫圖」。
10樓：咖啡酒精茶
最重要的是別人知道你想表達的內容是什麼？文件感覺有時就像是一紙憑證，在後期產品的驗收過程中，發現與預期不同，還能將證據拿出來。
11樓：陳東龍
看看你的文件是給誰看的？
給老闆的話要給出現狀、竟情分析、想法模型和願景，都是一些比較大方向的東西，資料很重要；
給互動師或者設計師看，簡單列出幾個點，當面溝通效果更好，反正也不存檔；
給開發同學看，能有多詳細就多詳細，畢竟要存檔而且開發同學也是跟著文件來做，如果沒有寫清楚（事先一定要溝通是否功能可實現），那麼開發之後的成品很可能會跟你原先的設想相差十萬八千里。另乙個很重要的，是你的產品模型，例如互動稿，好的產品模型能讓人一看就知道各種邏輯流程和功能點，開發同學看了之後就大體知道如何去實現，實現成本如何？
12樓：
花大力氣寫一篇長文件，不如乙個短小精悍的原型。
注：原型中依然是需要備註的。不贊成複雜的互動，用原型展現出各個功能點即可 :)
13樓：肖光利
貌似，最近我是這樣做產品需求的，不知道各位有提公升意見的沒？
（1）用PPT表達產品價值觀等，包含簡單的功能說明； 用以說服所謂的大老闆；
（2）在EXCEL中表達含「用例、步驟、規則等詳細的說明；（以前用word，發現word根本不合適）
（3）使用互動的工具來「詳細+直觀」的表達需求； （主要是比較直觀，所見即所需。）
（4）1-3步驟完成後，開始組織各部門人員進行評審、產品需求講解......等，同時也開始進入」互動設計師、使用者體驗優化、資訊架構優化、視覺、開發需求........等層面的調整；
備註說明如下
（1）PPT（所謂的簡稱，騙騙他）：說服大老闆，就是那個發工資養活你的人；
（2）EXCEL（需求規則）：說服開發團隊，開發都喜歡1是1,2是2，特古板哈；
（3）互動設計（需求層面）：說服團隊所有人，都是「圖形化」思維方式，看到了才理解；
(4)使用者體驗設計（技術+視覺+使用者為中心）：說服使用者及客戶。
好吧，此時真正的產品浮出水面了；
14樓：包子
舉個例子：
A說：「給我一張紙。」
結果B給了一張A4的白紙，C給一張衛生紙，D給了一張報紙……如果A說：「給我一張白紙，用來畫圖。」
寫得越細緻，做出來的功能就越準確。我覺得寫文件關鍵點在於寫出來的文件能讓看的人明白，沒歧義就OK了！
15樓：Siri
首先要看公司職能配置。
公司是不是有互動設計師
是不是有UEDer
其次要看專案的資源
時間是否充足
團隊人員配置是否充足
需求文件可以很簡單也可以很詳細（譬如寫成開發用例這樣的），主要還是看專案背景及公司背景
產品經理如何寫PRD需求文件？
劉歡迎 PRD 產品需求文件 是讓所有團隊成員保持一致的答案。它作為乙個單獨文件，所有團隊成員和利益相關者，都可以理解產品的目的和需求。它不需要是乙個非常詳盡的文件，但它應該提供產品的基本概念。乙個好的PRD文件應該有以下幾個部分 產品簡介，願景和目標 產品為誰開發 為什麼要開發這個產品 競爭態勢與...
需求分析 產品經理寫需求文件需要涉及系統流程和資料流程嗎？
小婧 我個人覺得這個要看團隊。如果開發團隊裡面的人都比較認真負責，自己也比較有想法，流程也比較規範的話，你可以不寫太多的技術細節。但是如果不是這樣，那最好還是寫，否則可能真的會出現掰扯不清楚的情況。我個人覺得，在大部分的情況下，需求分析 產品經理寫一些設計系統流程和資料流程的部分是從業務和需求的角度...
工作中接到產品經理片面性考慮的設計需求，要求一定要按照他的想法實現，是接受還是說服（最好有案例）？
文君 產品上線後，則要對結果有覆盤，該互相打臉就打臉，該互相安慰就安慰，該開除開除 產品策略的問題產品經理要負責，技術質量問題技術要負責。沒有爭論的產研團隊不是好團隊 沒有信任的產研團隊不是好團隊。心裡不爽又不能充分表達的產研團隊是缺少爭論辦法和信任的團隊，幾乎沒有成事兒的可能。 小小夏木 1.首先...