如何寫出詳細且易于閱讀的PRD?

異彩
10 評論 27175 瀏覽 110 收藏 13 分鐘

PRD對于產(chǎn)品人員而言,就像開發(fā)文檔對于開發(fā)人員、測試用例之于測試人員。但PRD又有些不一樣,產(chǎn)品的PRD需要給業(yè)務(wù)人員、內(nèi)部產(chǎn)品人員、開發(fā)人員、測試人員閱讀。所以PRD不僅要詳細,同時還要對開發(fā)、測試等非產(chǎn)品崗的人員友好,讓他們便于閱讀。

相信很多剛走上工作崗位或者想要從事產(chǎn)品工作的產(chǎn)品新人做的第一件事就是上網(wǎng)搜索“什么事PRD”或者“如何寫好PRD”。當(dāng)我開始學(xué)習(xí)寫PRD的時候,我也在網(wǎng)上找優(yōu)秀的案例,搜出來的優(yōu)秀PRD案例大多模塊豐富,介紹詳細。

看著產(chǎn)品用戶角色描述、產(chǎn)品總體架構(gòu)、業(yè)務(wù)流程圖、產(chǎn)品功能需求等模塊,剛覺得似懂非懂,又發(fā)現(xiàn)每一個小東西下面又有很多分類。例如:流程圖還分為業(yè)務(wù)流程圖、任務(wù)流程圖和頁面流程圖。產(chǎn)品功能需求還分為產(chǎn)品性能需求、測試環(huán)境需求、安全性需求等等。

如果產(chǎn)品新人接到原型任務(wù)時,想要按照這些格式,摩拳擦掌地寫PRD,你會發(fā)現(xiàn),如果真有按照模板來寫,PRD的內(nèi)容少有10來頁,多的有幾十上百頁。這樣的PRD作為文檔留存固然詳細,但是當(dāng)項目時間緊任務(wù)重、或者小功能需要快速迭代的時候,開發(fā)、測試沒有時間也沒有耐心去看這樣一個詳細的文檔。他們只會認真看原型和批注的部分。當(dāng)然認不認真可能還另當(dāng)別論。

對于產(chǎn)品人員來說,我們的期望開發(fā)能夠認真閱讀PRD的原型、批注部分,了解頁面和邏輯,開發(fā)出來的產(chǎn)品能夠達到我們預(yù)想的效果;同時期望測試在了解PRD原型和邏輯的基礎(chǔ)上能夠了解功能的變化,是全新的功能還是復(fù)用以前的邏輯,順利進行測試。

此外,產(chǎn)品把PRD寫的詳細且易于閱讀,有一個非常直觀的好處:在項目進行時,開發(fā)、測試來找你詢問的次數(shù)越少,在開發(fā)的過程中,PRD在后期的改動越少,整個項目進行的會更順利。

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

所以產(chǎn)品人員在寫PRD時,要記住兩個要點:

  1. 盡可能寫詳細 ;
  2. 易于開發(fā)、測試人員閱讀

批注要事無巨細

很多產(chǎn)品一開始在寫批注時很容易想當(dāng)然,覺得這個功能的邏輯這么明顯,開發(fā)測試人員肯定知道。這個業(yè)務(wù)這么清楚,開發(fā)測試人員肯定會比我清楚的。這個按鈕這么通用,開發(fā)測試人員肯定一看就知道是干嘛的;這個邏輯在前面的頁面已經(jīng)寫過了,可以不用再贅述了…..

這是因為產(chǎn)品人員陷入了一個誤區(qū):以產(chǎn)品的角度來看這份PRD。你是產(chǎn)品,你構(gòu)想出來的方案,你當(dāng)然是熟悉業(yè)務(wù)和功能的,也知道上下頁面邏輯的關(guān)聯(lián)。所以在寫PRD的時候,會覺得很多東西都是顯而易見的。

但是開發(fā)、測試人員沒有參與用戶的調(diào)研和需求的討論,也沒有參與方案的產(chǎn)出。所以他們不知道新增的業(yè)務(wù)流程和功能按鈕的用處。而且有可能你設(shè)計的頁面是分別有幾個開發(fā)來開發(fā)的,頁面1和頁面2的某個邏輯相同,你在頁面1寫了邏輯,但是頁面2是由別的開發(fā)負責(zé)的。

所以不能想當(dāng)然,而是應(yīng)該把每一個頁面的邏輯都當(dāng)成獨立的頁面,將這個頁面存在的邏輯和細節(jié)都清晰地羅列出來。

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

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

1. 閱讀測試用例

新手產(chǎn)品可以向測試要一份測試用例,仔細研讀??纯礈y試用例中的分析。這樣在寫PRD的時候,也能夠大概清楚測試會關(guān)注哪些細節(jié)。你寫的PRD也就越對測試的胃口。到時候測試找你確認的問題越少。

如何寫出詳細且易于閱讀PRD

如果拿到了測試用例,可以先關(guān)注一下“測試前提”,這可以和批注中的前置條件進行對應(yīng)。而“驗證場景”是測試對頁面的樣式、內(nèi)容的展示、功能的檢查、校驗。而“預(yù)期”則是批注里產(chǎn)品想要實現(xiàn)的效果,這部分也是產(chǎn)品應(yīng)該在批注里詳細描述的內(nèi)容。

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

寫PRD的時候,如果對上下游業(yè)務(wù)不是特別熟悉,很容易會遺漏細節(jié)。所以在寫PRD時,要沉下心來,多問問自己:如果出現(xiàn)XX情況那怎么辦呢?

例如我們現(xiàn)在每天都要用的掃碼支付的功能,可能現(xiàn)在看來就是掏出手機,對著二維碼掃個碼。但是需要考慮很多特殊情況。例如:如果用戶手機沒有網(wǎng)絡(luò)或者網(wǎng)絡(luò)不好的情況下,怎么顯示;二維碼不是收款碼掃碼后怎么顯示;如果支付寶掃了微信的收款碼應(yīng)該怎么顯示;用戶默認的支付賬戶是哪個;如果用戶默認賬戶里的余額不足怎么提示……

一些功能可能看起來簡單,但其實里面會有復(fù)雜邏輯,所以產(chǎn)品在確定了主要方案后,需要多思考一些特殊情況,然后在PRD里進行備注。這樣不至于測試來問你的時候,你措手不及,發(fā)現(xiàn)自己的方案有很多漏洞。

3. 思考內(nèi)容“從哪兒來,到哪兒去”

這種情況大多出現(xiàn)在B端產(chǎn)品的移動端設(shè)計中,需要考慮兩端信息的對應(yīng)性。在設(shè)計移動端時,一些展示的內(nèi)容,很有可能是從系統(tǒng)中調(diào)用過來的。所以在寫批注是,要備注清楚這個字段是調(diào)用的當(dāng)前系統(tǒng)的哪個模塊的哪個字段。

而在移動端提交的內(nèi)容,則要考慮這個東西到哪里去。也要備注清楚這個內(nèi)容填完后生成的記錄會展示在當(dāng)前系統(tǒng)的哪個模塊哪張報表。

PRD要易于閱讀

PRD除了在內(nèi)容上要符合閱讀者的預(yù)期,在樣式上也要做到頁面整齊,便于閱讀。

1. 流程圖和用例

在PRD中提供流程圖和用例,能夠幫助開發(fā)、測試人員盡快地熟悉業(yè)務(wù)流程、用戶角色和核心功能。

如何寫出詳細且易于閱讀PRD

process on上的流程圖案例

如何寫出詳細且易于閱讀PRD

process on上的用例圖案例除了流程圖和用例,如果時間允許,還需要提供功能列表。這樣的話,在熟悉大致業(yè)務(wù)和核心功能基礎(chǔ)上,開發(fā)和測試還能進一步了解詳細功能。測試用例在往期的文章里提過,看這里產(chǎn)品新人第一次負責(zé)項目應(yīng)該怎么做?

2. 言簡意賅、語言規(guī)范

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

在PRD里,可以用多種形式來進行表達。例如:遇到一些比較復(fù)雜的功能,涉及到狀態(tài)變化,描述起來文字較多,難以理解。這個時候就很適合用一張把表格來展示狀態(tài)的變化。

如何寫出詳細且易于閱讀PRD

3. 頁面展示具有強關(guān)聯(lián)性

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

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

如何寫出詳細且易于閱讀PRD

總結(jié)

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

最好的PRD永遠會是下一份PRD。當(dāng)然不想寫出完美的PRD的產(chǎn)品不是好產(chǎn)品。

#專欄作家#

異彩,微信公眾號:一只蝸牛慢慢跑,人人都是產(chǎn)品經(jīng)理專欄作家。從事房產(chǎn)管理系統(tǒng)的產(chǎn)品工作,關(guān)注To C產(chǎn)品的交互設(shè)計、運營、結(jié)構(gòu)設(shè)計和商業(yè)模式。在成為一名優(yōu)秀的產(chǎn)品人的路上努力前行。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來自 Unsplash,基于CC0協(xié)議。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 感覺每一句都是在說我 句句扎心

    來自遼寧 回復(fù)
  2. 啊~我們打算加一個頁面,周一上線(今天是周五)!

    來自北京 回復(fù)
    1. 老板說:時間還是很充足的嘛。產(chǎn)品周五通個宵把方案做出來。開發(fā)周末加班通宵做出來,測試周末晚上通個宵測試,周一就順利上線啦。

      來自上海 回復(fù)
    2. 加個頁面,簡單

      來自湖北 回復(fù)
    3. 還是要看看增加的頁面里面的項目復(fù)雜度 ??

      來自上海 回復(fù)
  3. 原型圖加清晰的注釋,把技術(shù)聚在一起,口述一遍,完事。

    來自遼寧 回復(fù)
  4. 小公司,當(dāng)真沒人看這玩意。直接問來的比較快

    來自浙江 回復(fù)
    1. 真實

      來自廣東 回復(fù)
    2. 真實

      來自北京 回復(fù)
    3. 現(xiàn)在流行敏捷

      來自上海 回復(fù)