閱讀2040
標籤：
產品經理
一份好的產品需求文檔， 能夠讓產品人員全面的從整體到細節的，
也能夠讓研發人員非常清楚的瞭解， 項目的背景、預期、以及產品的細節， 盡可能全面的把產品各方面實現的， 可能存在的問題都列舉做出說明， 提高開發效率， 節省不必要的頻繁溝通。
剛開始做產品時， 我總是以為只要原型一畫， 和大家開個會一說， 然後研發們就開始搞起吧。 結果你會發現， 這之後你每天都陷入各種答疑解惑的忙碌之中（臨時召集研發開會做說明， 指望他們能在兩三個小時裡把所有細節都記住？別做夢了）。
有些開發也不好意思頻繁的找你， 就直接按照自己的思路做了， 然後你就坐等驗收的時候各種吐槽， 提bug打回修改。
時間花了， 還沒達到你想要的效果， 你不開心，
PRD文檔
文檔的基本格式我在這就不描述了， 網上一搜一大片， 兩點我重點說下：
一、文檔具備可反覆運算性 鐵打的文檔流水的兵， 一個好的需求文檔就像一鍋好鹵， 是越熬越香。不論誰來接手正在進行中的項目， 都能夠一目了然的知道項目的前因後果：什麼背景啊， 每次調整都是為啥啊， 哪個產品什麼時間主導的啊……就像一份更新日誌， 記錄著專案需求變更的每一次變化。
二、文檔說明要盡可能的細緻 產品模組以及細節介紹的部分， 需要根據已有的原型稿有圖有字的做出說明。 文字部分主要針對某個模組或者介面詳細的做出標注和說明。如果描述性文字不足以理解， 這裡需要舉幾個例子給研發做出形象化的解釋。
舉一個我自己經歷的反面例子：
當年剛到攜程做產品， 一心以原型為大。 仿佛只要原型搞定了就沒啥事了， 結果導致立項會上產品由於嚴重缺乏全面思考， 漏洞百出， 沒有通過。
這段經歷給故作聰明的自己當頭一棒， 經過和同事的交流， 我發現自己在產品的細節打磨和思考上沒有不足夠的深入。 對於不熟悉的新業務：
這些基礎工作是你在編寫PRD文檔之後第一個要去一一驗證的事情， 如果順利才可以按照這個確認的需求下發開發。
另外說一點， 要考慮到從客服、市場、運營等崗位角度對產品進行解釋， 以及他們在這個產品中需要注意的一些要求。 （使用方和服務方都要全面考慮）
最後， 文檔畢竟是文檔， 雖然做到了反覆運算， 但在實際工作中還是會出現各種難以理解的部分。 這個時候就需要產品們及時和研發當面做出溝通和說明工作，積極推進產品研發進度。
這個時候就需要產品們及時和研發當面做出溝通和說明工作，積極推進產品研發進度。