PRD對于産品人員而言，就像開發文檔對于開發人員、測試用例之于測試人員。但PRD又有些不一樣，産品的PRD需要給業務人員、内部産品人員、開發人員、測試人員閱讀。所以PRD不僅要詳細，同時還要對開發、測試等非産品崗的人員友好，讓他們便于閱讀。

相信很多剛走上工作崗位或者想要從事産品工作的産品新人做的第一件事就是上網搜索“什麼事PRD”或者“如何寫好PRD”。當我開始學習寫PRD的時候，我也在網上找優秀的案例，搜出來的優秀PRD案例大多模塊豐富，介紹詳細。

看着産品用戶角色描述、産品總體架構、業務流程圖、産品功能需求等模塊，剛覺得似懂非懂，又發現每一個小東西下面又有很多分類。例如：流程圖還分為業務流程圖、任務流程圖和頁面流程圖。産品功能需求還分為産品性能需求、測試環境需求、安全性需求等等。

如果産品新人接到原型任務時，想要按照這些格式，摩拳擦掌地寫PRD，你會發現，如果真有按照模闆來寫，PRD的内容少有10來頁，多的有幾十上百頁。這樣的PRD作為文檔留存固然詳細，但是當項目時間緊任務重、或者小功能需要快速疊代的時候，開發、測試沒有時間也沒有耐心去看這樣一個詳細的文檔。他們隻會認真看原型和批注的部分。當然認不認真可能還另當别論。

對于産品人員來說，我們的期望開發能夠認真閱讀PRD的原型、批注部分，了解頁面和邏輯，開發出來的産品能夠達到我們預想的效果；同時期望測試在了解PRD原型和邏輯的基礎上能夠了解功能的變化，是全新的功能還是複用以前的邏輯，順利進行測試。

此外，産品把PRD寫的詳細且易于閱讀，有一個非常直觀的好處：在項目進行時，開發、測試來找你詢問的次數越少，在開發的過程中，PRD在後期的改動越少，整個項目進行的會更順利。

如果PRD沒有寫詳細，在項目開發的時候，不斷地會有開發和測試來找你确認問題，問題越來越多，修改PRD的概率也會越大。在項目的過程中修改PRD，很容易“牽一發而動全身”。開發可能要重新梳理邏輯，測試也需要修改用例。

所以産品人員在寫PRD時，要記住兩個要點：

1. 盡可能寫詳細 ；
2. 易于開發、測試人員閱讀

批注要事無巨細

很多産品一開始在寫批注時很容易想當然，覺得這個功能的邏輯這麼明顯，開發測試人員肯定知道。這個業務這麼清楚，開發測試人員肯定會比我清楚的。這個按鈕這麼通用，開發測試人員肯定一看就知道是幹嘛的；這個邏輯在前面的頁面已經寫過了，可以不用再贅述了…..

這是因為産品人員陷入了一個誤區：以産品的角度來看這份PRD。你是産品，你構想出來的方案，你當然是熟悉業務和功能的，也知道上下頁面邏輯的關聯。所以在寫PRD的時候，會覺得很多東西都是顯而易見的。

但是開發、測試人員沒有參與用戶的調研和需求的讨論，也沒有參與方案的産出。所以他們不知道新增的業務流程和功能按鈕的用處。而且有可能你設計的頁面是分别有幾個開發來開發的，頁面1和頁面2的某個邏輯相同，你在頁面1寫了邏輯，但是頁面2是由别的開發負責的。

所以不能想當然，而是應該把每一個頁面的邏輯都當成獨立的頁面，将這個頁面存在的邏輯和細節都清晰地羅列出來。

對于把PRD寫詳細這一點，我總結出一個重點“用測試思維寫PRD”。

這個觀點是我從測試用例和測試工作上反推出來的。測試人員在寫測試用例的時候，會對PRD進行非常詳細的解構。大到業務的邏輯，小到一個按鈕的各種特殊情況，都是他們需要進行測試的。産品可以借鑒這個思維來寫PRD。

1. 閱讀測試用例

新手産品可以向測試要一份測試用例，仔細研讀。看看測試用例中的分析。這樣在寫PRD的時候，也能夠大概清楚測試會關注哪些細節。你寫的PRD也就越對測試的胃口。到時候測試找你确認的問題越少。

如果拿到了測試用例，可以先關注一下“測試前提”，這可以和批注中的前置條件進行對應。而“驗證場景”是測試對頁面的樣式、内容的展示、功能的檢查、校驗。而“預期”則是批注裡産品想要實現的效果，這部分也是産品應該在批注裡詳細描述的内容。

2. 寫批注的時候，考慮到各種情況

寫PRD的時候，如果對上下遊業務不是特别熟悉，很容易會遺漏細節。所以在寫PRD時，要沉下心來，多問問自己：如果出現XX情況那怎麼辦呢？

例如我們現在每天都要用的掃碼支付的功能，可能現在看來就是掏出手機，對着二維碼掃個碼。但是需要考慮很多特殊情況。例如：如果用戶手機沒有網絡或者網絡不好的情況下，怎麼顯示；二維碼不是收款碼掃碼後怎麼顯示；如果支付寶掃了微信的收款碼應該怎麼顯示；用戶默認的支付賬戶是哪個；如果用戶默認賬戶裡的餘額不足怎麼提示……

一些功能可能看起來簡單，但其實裡面會有複雜邏輯，所以産品在确定了主要方案後，需要多思考一些特殊情況，然後在PRD裡進行備注。這樣不至于測試來問你的時候，你措手不及，發現自己的方案有很多漏洞。

3. 思考内容“從哪兒來，到哪兒去”

這種情況大多出現在B端産品的移動端設計中，需要考慮兩端信息的對應性。在設計移動端時，一些展示的内容，很有可能是從系統中調用過來的。所以在寫批注是，要備注清楚這個字段是調用的當前系統的哪個模塊的哪個字段。

而在移動端提交的内容，則要考慮這個東西到哪裡去。也要備注清楚這個内容填完後生成的記錄會展示在當前系統的哪個模塊哪張報表。

PRD要易于閱讀

PRD除了在内容上要符合閱讀者的預期，在樣式上也要做到頁面整齊，便于閱讀。

1. 流程圖和用例

在PRD中提供流程圖和用例，能夠幫助開發、測試人員盡快地熟悉業務流程、用戶角色和核心功能。

process on上的流程圖案例

process on上的用例圖案例除了流程圖和用例，如果時間允許，還需要提供功能列表。這樣的話，在熟悉大緻業務和核心功能基礎上，開發和測試還能進一步了解詳細功能。測試用例在往期的文章裡提過，看這裡産品新人第一次負責項目應該怎麼做？

2. 言簡意赅、語言規範

在寫PRD的批注時，盡量語言規範，避免口語化。簡潔明了的描述能夠給讀者一個好的閱讀體驗。尤其是項目頁面較多的時候，複雜的頁面，再加上口語化、冗餘的文字描述，開發、測試人員閱讀起來會比較費勁。

在PRD裡，可以用多種形式來進行表達。例如：遇到一些比較複雜的功能，涉及到狀态變化，描述起來文字較多，難以理解。這個時候就很适合用一張把表格來展示狀态的變化。

3. 頁面展示具有強關聯性

由于頁面之間可能會存在交互的聯系，所以頁面擺放時，最好是根據順序進行擺放。這樣的話，開發和測試也能更好地理解頁面與頁面之間的關系。同時，批注也最好也頁面緊挨在一起。這樣的話，在看的時候，能夠同時看到原型和備注。

所以從PRD展示角度來看，墨刀會是比較友好的工具。使用墨刀的話，原型和批注可以展示在同一個頁面。而使用Axure，如果畫的是大幅的網頁頁面，在預覽狀态的時，無法同時看到原型和批注。這樣的話，閱讀體驗就不是很好。很容易發生開發嫌麻煩隻看原型、或者甚至找不到批注的的情況。

總結

如果沒有經曆過幾次項目，一開始寫出來的PRD，會比較簡單。開發、測試會輪番地來向你确認問題。在這個過程，會懊悔自己有很多細節在一開始沒有想清楚。當然會有優秀的人能夠一開始就思考得特别詳細。那我們這些不夠優秀的人，要在一次一次的項目中總結問題，不斷改進。同時要和團隊的開發、測試不斷磨合，綜合考慮他們的想法。

最好的PRD永遠會是下一份PRD。當然不想寫出完美的PRD的産品不是好産品。

#專欄作家#

異彩，一隻蝸牛慢慢跑，人人都是産品經理專欄作家。從事房産管理系統的産品工作，關注To C産品的交互設計、運營、結構設計和商業模式。在成為一名優秀的産品人的路上努力前行。

本文原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部