prd是一個用于跟開發(fā)、ui、測試等團隊進行溝通的基礎(chǔ)文件，所以把prd看成一個產(chǎn)品的話，開發(fā)、ui、測試就是這個產(chǎn)品的用戶，為了把我們的想法盡可能的無損的傳遞給上述人員，我們需要在prd上盡量完整、準(zhǔn)確的描述清楚。作為天天把用戶體驗掛在嘴邊的產(chǎn)品經(jīng)理，非常慚愧的表示，我的prd用戶體驗好像不及格：缺少細(xì)節(jié)。

現(xiàn)在寫prd的方式，基本上就是直接出原型，然后在原型文檔上更多的是把正常流程、異常流程、主體業(yè)務(wù)邏輯描述清楚，而一些交互細(xì)節(jié)、界面控制等內(nèi)容則更多的依靠口頭溝通。這樣就帶來一些問題，由于文檔中缺少一些細(xì)節(jié)，所以在開發(fā)的過程中，開發(fā)人員就需要經(jīng)常的就一些細(xì)節(jié)問題進行確認(rèn)。

那么問題來了：

1、信息同步問題：
作為產(chǎn)品經(jīng)理，我跟開發(fā)的同事是坐在一起辦公的，而測試雖然是在一個大辦公室，但還是有一定距離，ui則在另外一個辦公室。開發(fā)提出問題的時候，我們口頭就溝通了，事后也許又插入進來一個其他的事情，這個時候之前溝通的結(jié)果，可能就沒有傳達給測試和ui，然后測試同學(xué)、ui同學(xué)就接收不到最新的變化，導(dǎo)致信息不同步；

2、進度問題：
1）開發(fā)過程中對需求進行細(xì)化，可能新的方案跟開發(fā)的設(shè)計方案有較大的差異，可能導(dǎo)致開發(fā)返工；
2）如果變化未及時同步給測試同學(xué)，容易導(dǎo)致測試用例沒有及時更新，在測試的時候按照老的用例進行測試，瞎耽誤工夫；
3）ui也可能需要跟著變化，需要ui進行支持，ui是緊缺的資源，很可能無法及時響應(yīng)改動，反過來又影響開發(fā)進度；

3、信任問題：
經(jīng)常出現(xiàn)這種問題，導(dǎo)致開發(fā)、測試、ui對產(chǎn)品汪的信任下降，在后續(xù)的工作中，可能帶來消極的影響：這個產(chǎn)品不靠譜。

尼瑪，細(xì)思恐極！

怎么破？

在產(chǎn)品設(shè)計階段，好好的把各種場景都考慮清楚，各種頁面交互流程、異常處理、分支流程、頁面控制、數(shù)據(jù)埋點等等，都在原型上描述清楚，爭取提交一份符合用戶心理模型的原型文檔。