這兩天遇到一個問題，產(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)出需求即可悍赢。
以上就是今天的思考，你們公司是怎么寫需求的货徙？期待你的留言~
