AAA教育

產(chǎn)品團隊，通常會輸出一套經(jīng)過確認(rèn)的全家桶，內(nèi)含：

一份《交互原型稿》（可迭代），

一份《產(chǎn)品需求說明文檔》（PRD，可迭代），

一份《功能開發(fā)清單列表》。

研發(fā)人員通過這些文檔，就能夠很清晰的了解產(chǎn)品的從宏觀到細(xì)節(jié)。

一份好的產(chǎn)品需求文檔，能夠讓產(chǎn)品人員全面的從整體到細(xì)節(jié)的，再次梳理和確認(rèn)產(chǎn)品的重要步驟；

也能夠讓研發(fā)人員非常清楚的了解，項目的背景、預(yù)期、以及產(chǎn)品的細(xì)節(jié)，盡可能全面的把產(chǎn)品各方面實現(xiàn)的，可能存在的問題都列舉做出說明，提高開發(fā)效率，節(jié)省不必要的頻繁溝通。

剛開始做產(chǎn)品時，我總是以為只要原型一畫，和大家開個會一說，然后研發(fā)們就開始搞起吧。結(jié)果你會發(fā)現(xiàn)，這之后你每天都陷入各種答疑解惑的忙碌之中（臨時召集研發(fā)開會做說明，指望他們能在兩三個小時里把所有細(xì)節(jié)都記住？別做夢了）。

有些開發(fā)也不好意思頻繁的找你，就直接按照自己的思路做了，然后你就坐等驗收的時候各種吐槽，提bug打回修改。

時間花了，還沒達(dá)到你想要的效果，你不開心，開發(fā)也不開心。何不想想該如何解決呢？這時候，PRD文檔的重要性就顯現(xiàn)出來了。

PRD文檔

文檔的基本格式我在這就不描述了，網(wǎng)上一搜一大片，兩點我重點說下：

一、文檔具備可迭代性

鐵打的文檔流水的兵，一個好的需求文檔就像一鍋好鹵，是越熬越香。

不論誰來接手正在進(jìn)行中的項目，都能夠一目了然的知道項目的前因后果：什么背景啊，每次調(diào)整都是為啥啊，哪個產(chǎn)品什么時間主導(dǎo)的啊……就像一份更新日志，記錄著項目需求變更的每一次變化。

二、文檔說明要盡可能的細(xì)致

產(chǎn)品模塊以及細(xì)節(jié)介紹的部分，需要根據(jù)已有的原型稿有圖有字的做出說明。文字部分主要針對某個模塊或者界面詳細(xì)的做出標(biāo)注和說明。

如果描述性文字不足以理解，這里需要舉幾個例子給研發(fā)做出形象化的解釋。

 

舉一個我自己經(jīng)歷的反面例子：

當(dāng)年剛到攜程做產(chǎn)品，一心以原型為大。仿佛只要原型搞定了就沒啥事了，結(jié)果導(dǎo)致立項會上產(chǎn)品由于嚴(yán)重缺乏全面思考，漏洞百出，沒有通過。

這段經(jīng)歷給故作聰明的自己當(dāng)頭一棒，經(jīng)過和同事的交流，我發(fā)現(xiàn)自己在產(chǎn)品的細(xì)節(jié)打磨和思考上沒有不足夠的深入。對于不熟悉的新業(yè)務(wù)：

流程上有沒有明顯的邏輯性錯誤？

每個界面的數(shù)據(jù)哪里來？什么接口獲??？

接口有沒有通？是否能夠拿到產(chǎn)品所需的數(shù)據(jù)？

規(guī)則性限制是否已經(jīng)考慮全面？…

這些基礎(chǔ)工作是你在編寫PRD文檔之后第一個要去一一驗證的事情，如果順利才可以按照這個確認(rèn)的需求下發(fā)開發(fā)。

另外說一點，要考慮到從客服、市場、運營等崗位角度對產(chǎn)品進(jìn)行解釋，以及他們在這個產(chǎn)品中需要注意的一些要求。（使用方和服務(wù)方都要全面考慮）

 

最后，文檔畢竟是文檔，雖然做到了迭代，但在實際工作中還是會出現(xiàn)各種難以理解的部分。這個時候就需要產(chǎn)品們及時和研發(fā)當(dāng)面做出溝通和說明工作，積極推進(jìn)產(chǎn)品研發(fā)進(jìn)度。