產品經理在寫需求文檔的時候要詳細到什麼程度呢？

01-07

這裡只是發起一個討論，為什麼老是有人趾高氣昂的俯視問問題的人呢？你真的就那麼牛逼？可以把文檔貼出來讓大家看一看吧！

貌似，最近我是這樣做產品需求的，不知道各位有提升意見的沒？

（1）用PPT表達產品價值觀等，包含簡單的功能說明；用以說服所謂的大老闆；

（2）在EXCEL中表達含「用例、步驟、規則等詳細的說明；（以前用word，發現word根本不合適）

（3）使用交互的工具來「詳細+直觀」的表達需求；（主要是比較直觀，所見即所需。）

（4）1-3步驟完成後，開始組織各部門人員進行評審、產品需求講解......等，同時也開始進入」交互設計師、用戶體驗優化、信息架構優化、視覺、開發需求........等層面的調整；

---------------備註說明如下：--------------

（1）PPT（所謂的簡稱，騙騙他）：說服大老闆，就是那個發工資養活你的人；

（2）EXCEL（需求規則）：說服開發團隊，開發都喜歡1是1,2是2，特古板哈；

（3）交互設計（需求層面）：說服團隊所有人，都是「圖形化」思維方式，看到了才理解；
(4)用戶體驗設計（技術+視覺+用戶為中心）：說服用戶及客戶。

好吧，此時真正的產品浮出水面了；

舉個例子：

A說：「給我一張紙。」

結果B給了一張A4的白紙，C給一張衛生紙，D給了一張報紙……

如果A說：「給我一張白紙，用來畫圖。」

寫得越細緻，做出來的功能就越準確。我覺得寫文檔關鍵點在於寫出來的文檔能讓看的人明白，沒歧義就OK了！

問大家，不如問看文檔的人，「以用戶為中心」，在這裡同樣適用

既然是PRD，到這個階段基本是面向開發和前端的文檔了，所以不必考慮領導層面，他們更關注MRD。

幾個關鍵點：

1. 清晰的目錄結構以及版本列表：方便日後查詢，及追溯歷史；

2. 明確的需求及適用範圍：確保從根本上不會跑偏；

3. 名詞和業務流程的解釋說明：認知要統一，否則到最後發現一個詞指代不同的內容，簡直浪費時間和繩命；另外業務的邏輯要清晰，流程圖展現的越詳盡越好；

4. 細節的考慮：比如某個功能觸發的時間點，成功/失敗的提示等。

另外PRD並不是萬能的，還要配合原型使用，這樣給開發和設計的思路才是完整的。

除開需求的目的，場景，統計點......這些基本格式或者模板。以一個為手機QQ「增加皮膚功能「的需求來做例子。首先，要考慮的是交互里的各種步驟，比如說這個皮膚功能的入口在哪裡，怎麼退出這個功能，打開功能後彈出的操作框里有哪些按鈕、元素......（這部分可以多用axure圖表示，開發人員基本是照著你的文檔開發，所以過程和按鈕什麼的要寫清楚）.其次，要考慮功能的操作過程，比如：你點擊了一種皮膚後，QQ的皮膚是隨之同時改變有預覽效果還是說你需要點擊確定退出皮膚操作對話框後才能看到皮膚的改變。第三，在皮膚功能的操作框里，放置幾種皮膚，以及怎樣排列皮膚會比較好。第四，要考慮需不需要去與其他的功能去整合，比如說」亮度調節「、」字體色調節「等等，如果要整合的話，以什麼樣方式的整合最好。第五，要從長遠的角度考慮這個功能的可生長性，比如：你可能只給出了五種皮膚，如果用戶還想要其他的，你就需要考慮設置」添加網路皮膚「」添加本地皮膚「等等入口，那如果你考慮到了」添加網路皮膚「的入口，就可以想到以後這個入口可以與一些壁紙網站合作，為用戶帶來方便的同時，為公司帶來盈利。第六，多考慮一些靈活的方案，分析比較不同方案的利弊。還有很重要的一點，是這個功能帶來的風險以及特殊場景下的考慮。

花大力氣寫一篇長文檔，不如一個短小精悍的原型。

註：原型中依然是需要備註的。不贊成複雜的交互，用原型展現出各個功能點即可

我寫文檔的習慣是，結合交互稿，如果沒有交互設計師，那就自己學著畫。畫交互是體力活，技術的要求不是太高。

你預先把交互畫出來，或者和交互一起畫出來。那基本上你對需求相當於review一遍。

然後結合交互圖，再配上文字，就基本沒啥問題了。

一般用word可以，Excel也可以

首先要看公司職能配置。

公司是不是有交互設計師

是不是有UEDer

其次要看項目的資源

時間是否充足

團隊人員配置是否充足

需求文檔可以很簡單也可以很詳細（譬如寫成開發用例這樣的），主要還是看項目背景及公司背景

首先，我覺得需要明確的一點是這個需求文檔是給誰看的？（投資人、客戶、老闆、程序員（前端程序員，後台程序員）、交互設計師、美工）

其實，要確認這個文檔是做什麼用的？（要錢的？結帳的？審批的？頭腦風暴的？開發的？設計的？）

以工作經歷來看，目前大部分互聯網公司對產品經理這個崗位都沒有準確的定義。產品工作流程也都不太盡如人意。

產品經理，軟體架構師，交互設計師，項目經理，這些崗位在互聯網公司里的工作職責到底應該如何劃分？又有多少公司能分得清楚？

總而言之就是一個亂。

看看你的文檔是給誰看的？

給老闆的話要給出現狀、竟情分析、想法模型和願景，都是一些比較大方向的東西，數據很重要；

給交互師或者設計師看，簡單列出幾個點，當面溝通效果更好，反正也不存檔；

給開發同學看，能有多詳細就多詳細，畢竟要存檔而且開發同學也是跟著文檔來做，如果沒有寫清楚（事先一定要溝通是否功能可實現），那麼開發之後的成品很可能會跟你原先的設想相差十萬八千里。另一個很重要的，是你的產品模型，例如交互稿，好的產品模型能讓人一看就知道各種邏輯流程和功能點，開發同學看了之後就大體知道如何去實現，實現成本如何？

文檔一般有兩個功能：

1.用來溝通。

2.用來存檔。

一般來說如果寫的太細，人不愛看，還不如當面溝通，文檔主要做存檔用。

需要很細緻，畢竟從需求文檔的撰寫，交互，視覺，評審，開發測試等等都是需要看文檔的。產品經理就是產品的爸媽，產品出了任何問題都是你的責任（技術BUG除外），寫細緻點，也有助於你將問題想得很細緻。

我們做遊戲, 策劃給的需求文檔, 經過一段時間磨合, 現在相對已經比較符合文檔預期了, 能滿足80%開發人員的疑問了. 我一直覺得文檔這種東西, 不能事無巨細, 如果你想所有細節都寫進去, 最後會發現挖了個坑自己給埋了, 開發人員也幾乎會被看醉.

我們的做法是分幾步

首先, 因為我們做遊戲的, 很多需求都是比較明確的(此明確非彼明確, 被需求改動輪的死去活來, 不屬於這個明確範圍)

雖然UI還沒出圖, 但是策劃人員一般都能在已有遊戲里找到相關的功能的例子, 或者自己畫個簡陋版的UI, 非常直觀, 否則A看會以為是自己想法中的樣子, B看以為是B自己想法中的樣子. 而且策劃會標出UI上能觸發的流程, 這些事件被觸發的條件是什麼, 條件來自於xls表格里的數值, 我們都會事先約定.

然後開個會, 宣講一下文檔, 玩法. 順路作為碼農們, 噴一噴他們那是很常見的了, 遇到非常傻逼的情況, 噴成渣子. 而且也能在遇到實現難度非常高的地方, 溝通決定這麼做是否值得. 因為是照著文檔開會的, 所以開完會, 有疑問的也已經問了, 基本就開始幹活了. 實現過程中, 產生的一些疑問還是會去跟策劃溝通, 我覺得這一點很難避免的, 如果想把後期這些溝通全省掉而用文檔來實現, 那周期不知道得多久了.

人類的思維溝通是最困難的，所以首先同意「以用戶為中心」的答案，需求文檔要看寫給誰的，寫給研發的自然要做到細緻周到，同意上麵包子所說的案例，如果我是A的話，就會寫「給我一張空白A4紙」，後面還要跟上原因或者和其他的因果關聯「因為我要用來畫圖」。

如果是給開發看，盡量詳細吧。如果你覺得的需求已經寫得很詳細了，其實離開發真正看懂還有一段距離呢。至少要保證頁面中的每一個元素的屬性和觸發的事件都要有詳盡的描述，同時還要考慮各種可能的異常和故障（硬體）處理。。。。

能讓技術看懂就行了吧

最重要的是別人知道你想表達的內容是什麼？文檔感覺有時就像是一紙憑證，在後期產品的驗收過程中，發現與預期不同，還能將證據拿出來。

把前後台的需求功能描述的很清楚就行

（本文理念來自《用戶體驗要素—以用戶為中心的產品設計》一書，是我閱讀過程中對工作的思考與整理，非自創理論）

Ajax之父Jesse James Garrett在《用戶體驗要素——以用戶為中心的產品設計》一書中，將用戶體驗要素分為5層，並詳細介紹了每一層的定義、作用及操作手法。而每一層要素，又都對應著產品經理日常工作中重要且基本的一項內容。在我的閱讀體驗中，認為第一層（最底層）的戰略層，是指導需求文檔的重要準則。在這裡，借用《用戶體驗要素》一書中的理論，來談談一份好的需求文檔應該怎麼寫。

當我們決定做一個互聯網產品（無論是WEB端、APP或是H5）時，總會有一個因，並追求一個果。需求文檔的作用，就是定義一個產品的開發背景和預期目標。要講清楚：

1、我們要通過這個產品得到什麼？

2、我們的用戶要通過這個產品得到什麼？——即我們需要給用戶什麼？

一個合格的需求文檔，需要給這兩個問題合理的答案。所謂合理，就是邏輯自洽，並且具備操作性和價值。大部分情況是，我們看到什麼火，就頭腦一熱跟風去做。去年的直播，今年的共享單車，每一年都有大量人員跟風湧入一個熱門，陣勢浩大，慘痛撲街的現象。現實情況往往是我們沒有對自己做出梳理診斷，就拍腦袋根據熱度決定做一個產品。而忘了問自己兩個問題：

1、這個熱門是真的趨勢，還是一種炒作手段？

2、我投入這個領域具備什麼競爭力強的優勢？

這些問題都沒有想，就上馬一個項目，結果往往會很難看。我們都知道九犬一獒的原理，成功的項目自然是鳳毛麟角，但我們不能從一開始就奔著失敗去。一個項目連團隊都不能說服，成功的可能性自然大打折扣。需求文檔的重要性從源頭就顯現出來了。

當然，我們不可能每次都等需求文檔完全完成了，才開始項目，這樣又往往會導致錯失戰機。等你想清楚的時候，別人已經跑在前面了。所以需求文檔撰寫的第一要點是，不是必須寫完需求文檔，才開始產品搭建。你可以判斷出產品方向，並在開發迭代過程中不斷試驗自己的想法，在beta版完成之前，確定最終的需求文檔。因為實操過程中，你的感覺會越來越明晰。

Jesse James Garrett將戰略層分為產品目標和用戶需求兩個方面，這兩個方面即是需求文檔所涵蓋的內容。其中產品目標回答「我們要通過這個產品得到什麼」的問題，而用戶需求則回答「我們的用戶需要通過這個產品得到什麼」。回答這兩個問題的關鍵詞是明確（explicit），我們越能清楚地表達我們想要什麼，以及確切地知道其他人想要從我們這裡得到什麼，我們就越能精確地滿足雙方的需求，這個需求文檔的完成度就越高。

產品目標：我們開發這個產品想要達成的目的。定義這個概念有兩個要素：一是目的本身是什麼；二是達成的標準是什麼。

我們的目的可以是商業目標、商業驅動因素，也可以是戰略布局。目的的描述既不能太寬泛如「為公司賺錢」，也不能太細節如「做一個即時通信的工具」，我們要準確地描述產品需要支持的企業戰略目標。

達成標準是判定這個項目「什麼時候到達了終點」的依據。當我們明白什麼指標是最核心的時候，我們在產品規划過程中，就能有意識地突出和優化這個指標。它不僅能幫我們定義「什麼應該做」，更重要的是能幫我們釐清「什麼不該做」。用戶基數、活躍指數、轉化率，這幾個緯度選擇什麼作為優先順序，產品的形態會千差萬別。

用戶需求：我們始終要明白，我們並不是為自己設計自己喜歡的產品，而是為其他人設計，並讓其他人使用這個產品。因此我們要了解「他們是誰」以及「他們的需求是什麼」、「如何滿足他們的需求」。

定義用戶需求的辦法有用戶細分、用戶研究和創建人物角色三種方法。每一種方法都有其優劣，交叉使用效果更佳。弄清楚用戶需求，讓我們在規劃產品時，能始終記得代入用戶會對這個功能和流程做出怎樣的反應，從而判斷功能的必要性和優先順序。

綜上所述，寫產品需求文檔，一定要闡明兩個基本要素：目的是什麼、用戶怎麼用。當我們能想清楚這兩個問題，對後續的開發會有很好的方向性指導，團隊知道自己將走向哪裡，他們在做的過程中就能夠做出良性判斷，使項目在預想的軌道中開展。

需要謹記的是，需求並不是一成不變的，隨著項目的開展、階段的不同，以及市場的發展，原定的需求文檔也可能做出調整。當我們判斷需要做出調整的時候，可以以版本迭代的方式，來制定更加貼合現有情況的需求文檔。只要做好迭代規劃，採用一致的判斷標準，項目就能夠良性地發展。

假設你是看文檔的那個人，你壓根不了解這個產品，你看完文檔之後，能不能理解作者的原意。

如果有一點偏差，文檔就不夠細緻