閱讀1479
標籤：
產品經理最近， 就“一篇好的需求文檔是什麼樣的”這個問題， 我和研發大哥討論了很長時間。 發現過去自己認為的“好文檔”， 和技術眼中的”好文檔“， 有著天差地別！
為此， 寫總結一篇， 整理了需求文檔寫作中的一些注意事項。
一、寫作前需要思考的問題
1、問題&起因
為什麼要做這個需求？遇到了什麼問題？
2、可量化目標
做完這個需求， 你想要達到什麼樣的結果？從“PV增長5%”到“轉化率提高3%”， 你需要一個明確的目標來衡量自己的產出價值。
3、需求背景
你該如何向同事、不相干的人去解釋這個需求？如何讓別人聽明白你在做什麼？
4、方案詳情
需求從發起到落地， 需要切實可行的方案來保證它一步步推進。 而其中的每一步都會受到別人的質疑。 因此， 需要盡可能想到每一個細小的邏輯分支。
5、時間軸（Roadmap）
關鍵的時間節點包括：確認交互、視覺定稿、需求評審、進入開發、聯調測試，
二、開始著手PRD寫作
1、快速完成一個草稿（1-2 個小時）
先把腦海中所有想到的細節都列出來， 用通俗易懂的語言列出一個清單——給自己看， 這樣便於整理之後的思路。
2、和相關人員分別進行一對一討論 （1-4 個小時）
這個步驟的目的是過一遍文檔中的細節， 優化你的方案。
干係人包括：需求owner、交互視覺負責人、研發、其他相關的人。
從不同崗位的視角來看， 你的方案夠合理嗎？在這個環節， 你會受到很多異議， 把它們都記錄下來， 因為這些很有可能成為研發時的大坑。
3、撰寫和編輯文檔 （0.5-3 天）
將上一環節確定的細節一一梳理， 添加到文檔的相應位置。 同時， 需要不斷優化文檔的結構，
4、群發文檔 & 安排需求評審會（15 分鐘）
將文檔群發給項目的所有利益相關方， 並且抄送給其他可能對文檔感興趣的團隊（例如你所在的產品團隊， 整個支援團隊等）。
跟進這些關鍵人員是否接受了會議邀請：將會執行這件事情的人， 和所有對這件事情有通過/否決權力的人。
5、需求評審（1小時）
在開始會議之前必須做的一件事：確保所有人都看過了你的文檔。 如果沒有， 先花一兩分鐘讓大家把文檔流覽一遍。
在評審時， 你需要盡可能讓所有人都知道， 你想要做一件什麼樣的事， 為什麼要做它， 能給整個團隊帶來怎樣的利益。
在方案闡述完成後， 給研發充足的時間來思考可能存在的問題，
6、通過評審後， 及時建立工作群組和工單 （1-2 小時）
在工單上附上PRD的連結， 同時， 在建立工單時就敲定專案排期。 如果可以， 把排期&責任人放在PRD首頁， 讓研發每次進入文檔都看到它。
三、Tips：如何寫出研發愛看的PRD文檔？
1、簡潔， 再簡潔
冗長的下場就是研發人員根本不想打開你的PRD。 因此， 為了確保他們有動力讀完， 儘量使用簡潔的語言， 不說廢話。
2、在圖表上下功夫
流程圖、線框圖、各類交互和視覺效果圖， 這些能讓人更好地理解需求。
3、和研發一起完成PRD
從開始動筆到最終定稿， 儘量多地和研發討論方案細節， 以確保技術可能性和實現方式。 這樣研發也會有參與感， 積極性也會更高。