在產品開發過程中，產品需求文件（PRD）扮演著至關重要的角色。然而，即便是經驗豐富的產品經理也可能在PRD的撰寫邏輯上存在誤區。本文旨在深入探討PRD撰寫的核心要點，提供系統化的方法論，以確保文件的邏輯性和全面性。
最近模擬面試了幾個產品同學，發現一個問題，雖然有些人已經有幾年經驗，但是在問到寫PRD的思路時，卻答得不通順，邏輯很亂。
也不是他們不會寫PRD，而是寫的思路是亂的、錯的，沒有成體系的方法。
這還讓我挺驚訝的，產品經理這個崗位，都進入下行周期了，產品的基礎技能，網上已經有非常多成熟的資料，他們竟然連最最基礎又核心的PRD，都沒有吃透，屬實有點不應該。
現在大部份公司，要求產品經理既要有高度，又要能落地，上至產品規劃，下產品需求，都要幹，寫好PRD，對於產品經理來說，非常重要。
寫PRD最重要的是什麽？
我發現很多產品經理寫PRD，都是從樣版開始。在網上找到一個覺得很完善的樣版，然後就套著樣版寫，樣版包含什麽，就寫什麽。
還有一些是對著原型寫，大部份寫的是互動說明，其實只是PRD裏面的一部份而已。
01 寫PRD最重要的是什麽？是邏輯啊！
PRD是分層次的，需要從不同的維度去寫。
新專案和叠代的專案，側重點又有一些不一樣。
02 新專案PRD怎麽寫？從0到1的新專案，最重要的是梳理清楚業務流程、系統架構和功能結構。
業務流程是整個專案設計的起點，梳理不同角色完成業務目標的過程。
業務流程可以推匯出系統架構。
系統架構是把滿足業務的所有系統遍歷出來，再按照一定結構進行組織的過程。
每個系統又包含不同的功能，把所有功能梳理出來，可以指導後續具體的產品設計。
對於一個新專案來說，PRD的結構大致是這樣的：
1、專案背景。描述當前遇到的問題，或市場機會。要達到什麽目標，以及大致的方案是什麽樣的
2、整體說明。業務流程、系統架構、功能結構、全域通用說明（名詞解釋，全域互動等）
3、功能需求。按照系統→功能模組→功能點的方式，進行拆分，一個功能點就是一個設計模組
4、非功能需求。包括安全性，並行，數據統計等
03 叠代專案的PRD怎麽寫？叠代專案，要麽是新增功能點，要麽是對已有功能點的最佳化。
叠代的專案，最重要的是弄清楚單個功能點的需求是怎麽寫的。
寫PRD，很大一部份時間都是在寫具體的功能，所以寫好單個功能的需求非常重要。
對於單個功能點來說，主要包括以下部份：
功能描述：這個功能滿足哪些使用者需求，解決使用者什麽問題。
業務流程：使用者和系統是怎麽互動的，主要流程是什麽，分支流程是什麽，異常流程是什麽。
業務規則：系統在執行邏輯判斷的時候，依據的規則是什麽。
界面互動：註意，寫PRD一定是前面的步驟梳理清楚以後，才是寫界面互動，界面互動的細節非常多，也是經常容易遺漏寫不全的模組。一個功能裏通常包含多個頁面，寫界面互動的時候，第一個是要梳理清楚各個頁面之間的跳轉關系，第二是要梳理單個頁面裏的互動。一個頁面，通常包含這些部份：
– 頁面描述：進入頁面的預設內容，進入下一個頁面後再返回，頁面怎麽處理。不同狀態下頁面的區別，進入頁面的許可權等。
– 欄位描述：輸入型表單規則，有哪些輸入型，錄入方式是什麽，是否必填，有哪些規則。輸出型的展示規則：展示哪些欄位，展示的邏輯是什麽。
– 互動描述：點選後跳轉到哪裏，界面元素有哪些變化，有哪些控制項，不通狀態的展示，操作許可權等。
– 異常情況：網絡異常、介面異常、載入超時，該怎麽處理
– 埋點/日誌：哪些事件要做埋點，數據怎麽存
互動寫多了以後，你應該能夠形成一份自己的互動走查清單，以確保需求完整，類似下圖的自查清單：
叠代裏最佳化功能的需求，大概是需求的某個模組進行調整，可能是業務流程，可能是業務規則，也可能是具體的互動。
這類需求主要是要說清楚，現在使用者的使用場景是什麽樣的，為什麽要改，修改前是怎樣的，修改後是怎樣的。
04 寫在最後以上，提供一個寫PRD的思路，對於新專案來說，重點是說清楚專案背景和整體的設計，然後再以功能為單元進行具體的設計。
對於叠代類的PRD，重點是描述每個功能的所有元素，如果是修改的話，弄清楚使用者的使用場景，為什麽要改，改成什麽樣。
實際上，PRD的具體形式，不必過於看中，可以用axure+批註，也可以用word文件，重點是邏輯，重點是思路。
