PRD需求文檔，PRD需求文檔，很熟悉吧

上次說產品經理，提到了產品需求文檔，相信沒有做產品的同事陌生這個PRD文檔的。

那麼，今天就說說這個文檔。

為什麼一個文檔，還拿出來說，那是因為，不想被罵「傻13」。

工作場景中，經常會因為一個產品開半天的會，開1-2小時，運營部，技術部，產品部，。

產品經理將產品的開發需求寫進去，這樣就完事了嗎？萬事大吉了？

那你就錯了，那你就會聽到各種各樣抱怨你的聲音。

一會程序員哥哥姐姐找你，一會運營看不懂，一會ui不能確定需求。。。

你就會一直手忙腳亂，癥結歸於哪裡呢？

PRD需求文檔，PRD需求文檔，很熟悉吧。

就是這個文檔。

那麼怎麼寫一個PRD文檔呢？

這個文檔，絕不是一個文檔，是思路，是結晶，是邏輯，是心血...

注意這個文檔的細節，但是這些細節，絕不是在一開始就能遇見的。

所以在寫這個文檔的時候，要一直完善，一直發現，一直尋找，直到讓她完美到發光。

這個文檔，終極的使命就是指導設計和開發， 建立對於項目的共同理解，所以寫這份沉澱的文檔前，一定先了解，先理解，確保每一個環節是被理解的。

經常會看到產品經理的日誌是，更新PRD需求文檔，是的。這個文檔需要不斷的更新，不斷的完善具體的需求和測試計劃，不斷的進行流程的細化，版本的控制等等。

PRD文檔中，其實就是需求文檔，那麼首先必須明確的就是需求，需求的內容，需求的背景，需求的意義...

和這個產品的需求文檔要貼合市場，貼合業務範疇，文檔中包含了很多細枝末節，像人們的毛細血管一樣，分支很多，細節很多，稍不注意就會引出不必要的麻煩，而且很難處理和解決。

那麼，文檔的需求出來了，那就要考慮這個產品需求所涉及到的公司的哪些部門，需要哪些部門配合，需要調配什麼樣的資源來一起配合這個產品需求。

技術部，運營部，市場部，...統統跑不掉，那就牢牢的把他們抓在手裡吧。

這個文檔，絕不止是一個文檔，記住，一定絕不止是一個文檔，在這個文檔中能夠看到很多細節的內容，細到讓人不容易察覺。

你的邏輯性，你的邏輯性，你的邏輯性...

被拿出來三次強調，對需求一定是縝密的，一定的理解的，這個文檔的水平自然就流露出來了。