這兩天遇到一個問題，產(chǎn)品經(jīng)理除了畫原型外，是否還要單獨寫一份PRD文檔？今天的話題就來聊聊這個問題我的看法。

我覺得，產(chǎn)品經(jīng)理是否要產(chǎn)出PRD，還是依據(jù)公司實際情況而定，需要同時權(quán)衡公司工作習(xí)慣、開發(fā)人員使用方法、文檔管理的便捷性等幾個方面，擇優(yōu)而取。

為什么這么說呢？以我本人經(jīng)驗為例，從開始做產(chǎn)品經(jīng)理那天，我就沒有PRD這個概念，最早的時候?qū)懙氖恰盾浖乓O(shè)計文檔》、《軟件詳細設(shè)計文檔》，接觸互聯(lián)網(wǎng)后，就直接上手Axure原型，開始做的時候喜歡炫技，嘗試高保真，就是所有點擊交互都做出來，但開發(fā)經(jīng)常抱怨看不懂，不知道點哪兒怎么點，于是就把原型拆開，用流程圖組成交互稿，再后來覺得流程圖無法說明問題，就在交互稿上標注各種邏輯說明，字段描述，最后又覺得光放交互稿無法說明為什么要這么做，就把每次迭代的項目說明、開發(fā)目標、需求List、上線價值等也用Axure寫上，直到現(xiàn)在也還在不斷補充這個大Axure原型，最終結(jié)果類似下圖：

從結(jié)果來看，大家還是很認可這樣的需求描述形式的，原因有如下2點：

1、需求管理方便

每次維護一個版本迭代，直接保存當時的原型文件即可，需要修改、更新，也直接修改一個文件即可，非常方便。

2、需求溝通方便

無論是和需求方溝通，還是和開發(fā)、設(shè)計溝通，直接對照著一個個頁面講解即可，通常一個頁面，交互、需求、邏輯、字段都有標注，能夠做到高效評審。

依我的經(jīng)驗，還是比較推崇把PRD和原型文檔合在一起交付。

當然，這樣做也有如下缺點：

1、需求比較“散”，很難驗收

原型畢竟是以“頁面”為信息承載媒介，而需求是以“列表”形式存在，二者通常會交叉存在，也就是說，很可能一個頁面上的交互稿會實現(xiàn)多個需求，而1個需求也可能由多個頁面實現(xiàn)。從而對開發(fā)、測試人員造成一定識別困難。通常這種情況我會單獨在Axure開一個頁面，把需求List和原型頁面之間的關(guān)系畫一個映射表格給開發(fā)、測試來對照。如下圖所示：（“主題”一列為頁面跳轉(zhuǎn)鏈接，“redmine”一列為需求列表跳轉(zhuǎn)鏈接）

2、算法、業(yè)務(wù)邏輯和字段標識，很難用原型標明

比如排序邏輯、熱門算法、數(shù)據(jù)傳輸協(xié)議、埋點規(guī)則，這樣的內(nèi)容通常是沒有用戶界面的，也就無法和交互界面融合。通常這種情況我也會針對這樣的需求，單獨開一個頁面，用文字、流程圖的方式描述清楚。

因此，很多公司也會通過單獨撰寫一份PRD文檔，來解決我說的上述問題。

總之，是否需要PRD文檔，關(guān)鍵在于你寫的需求是否真正能被開發(fā)、測試、設(shè)計、需求方識別、認可，畢竟需求文檔的使用者是他們。所以我覺得不用拘泥于形式，只要你的思路清晰、主次明確、邏輯順暢，選擇一個大家都認可的方式產(chǎn)出需求即可。

以上就是今天的思考，你們公司是怎么寫需求的？期待你的留言~