被噴慘的 PRD 長啥樣？
早上幫我們星球同學看了一份 PRD，也就是產(chǎn)品需求文檔。這是一份已經(jīng)參加過評審會的文檔，而且被噴得很慘。
這位做產(chǎn)品的同學覺得有點冤，于是來問我到底問題出在哪。
我看了整篇文檔，總結了以下幾個問題，或許對你們有一定的參考作用。
第一個問題，沒有背景，功能先行。
經(jīng)常有讀者問我，有沒有合適的 PRD 模板？
對于這個問題，我的觀點一向很明確，模板不是目的，但針對每一個問題可以制定不同的模板。
這句話聽起來可能有點繞，但實際情況的確如此。
如果我給你一份完整的 PRD 文檔，里面會有各種需要完善補充的結構，但如果此時你遇到的只是一個交互優(yōu)化需求，那么模板中的很多結構就會出現(xiàn)空白。
這會導致一個問題，看 PRD 的人需要從模板中找關鍵信息。相比之下，直接把方案呈現(xiàn)出來反而更直接。
但是，只寫方案不寫背景也會出問題，那就是看文檔的人會主觀質(zhì)疑方案的合理性。
比如我看的這份 PRD，一上來就是功能邏輯介紹，直接把之前剛開發(fā)完的功能做了至少 60% 的修改。
關鍵在于，對為什么要修改的原因只字不提。如果我是程序員，看了也會惱火。
因此，任何呈現(xiàn)在 PRD 里的改動或者新增都需要補充背景，重點不是怎么做，而是為什么要這么做。
關于這部分內(nèi)容，可以在 PRD 一開頭用「需求背景」或者「業(yè)務背景」這樣的結構呈現(xiàn)出來。
沒有背景，功能先行，這樣的 PRD 鐵定會受到質(zhì)疑，不冤。
第二個問題，只看大路，不管小路。
在這份 PRD 里我還看到一個問題，就是關于產(chǎn)品方案的描述只有主干邏輯，也就是大路通暢，但是缺乏分支邏輯的梳理，也就是不管小路。
正向來看是沒啥問題，但一旦進入開發(fā)環(huán)節(jié)，程序員在代碼實施階段就會遇到很多卡點。
作為一個有經(jīng)驗的程序員，在方案初期是能夠看出這些卡點的，這也是為什么很多產(chǎn)品經(jīng)理想不到的問題程序員能顧及到。
要解決需求方案考慮不全面的問題，我一直建議產(chǎn)品經(jīng)理可以利用一些工具，比如 UML 圖。
例如，時序圖可以幫你梳理單個功能點的各項邏輯，狀態(tài)圖可以幫你梳理一個業(yè)務規(guī)則下的所有可能情況。
當然，像流程圖這樣的常規(guī)工具都是必備的，一圖勝千言吶。
把這些圖學會了，然后在 PRD 里加以運用和呈現(xiàn)，相信我，你的 PRD 質(zhì)量一定會提升不少，程序員也會對你刮目相看。
要看大路，同時也要管好小路。
第三個問題，始于想象，終于限制。
關于這份被噴慘的 PRD，其實我覺得最大的問題在于產(chǎn)品經(jīng)理極大發(fā)揮了自己的想象力，但沒有考慮客觀情況。
在功能邏輯調(diào)整中，其中有一項是對原有數(shù)據(jù)結構做改變的，那這會產(chǎn)生一個問題，兼容性。
產(chǎn)品經(jīng)理沒有考慮到線上多個版本并存的情況，而修改后的邏輯會對之前的所有版本產(chǎn)生兼容性問題，是不可用的。
雖然圍繞這個點的修改羅列了很多具體邏輯和方案，但就是因為技術事實上的限制，導致基于這個點的所有發(fā)散都是失效的。
其實要解決這個問題，產(chǎn)品經(jīng)理就得把工作做到前面，不要拿著自己以為的方案去做評審，而是在 PRD 定稿前提前和程序員或者技術負責人做可行性探討。
某種程度上說，PRD 是一個共識備忘錄，而不是產(chǎn)品經(jīng)理單方面出具的方案細節(jié)。
所謂共識備忘錄，其實是原子溝通結果的匯總，每一個方案、每一個改動、每一個可能涉及的變化，都需要與利益相關人取得共識。
不僅是技術上的共識，還有設計、運營、法務等不同職能角色的共識。
因此，產(chǎn)品經(jīng)理的溝通工作是很重的，這是必然。沒有誰拿出一個方案就能力壓全場，都是不斷擴大共識的結果。
如果你平時產(chǎn)出的 PRD 也有上述三個問題，不妨好好復盤一下。
有則改之，無則加勉。
如果你在工作中遇到 PRD 拿不準的問題，或者上評審會前心里打顫，不妨帶著你的 PRD 來星球里問我，我會提前給你一些建議。
還不知道怎么加入星球的讀者，入口在下面????
