寫了30+產(chǎn)品需求文檔后,我對PRD有了新的認(rèn)知

20 評論 27737 瀏覽 255 收藏 16 分鐘

講到PRD,有兩種不同的意見:有的人認(rèn)為PRD十分關(guān)鍵,能夠體現(xiàn)出產(chǎn)品方案、設(shè)計(jì)思路;而有的人則認(rèn)為PRD無用,價(jià)值小。對此筆者認(rèn)為:我們應(yīng)該結(jié)合公司、業(yè)務(wù)、產(chǎn)品等去自定義PRD,發(fā)揮它的最大價(jià)值。

一、寫作緣由

PRD、原型可以說是產(chǎn)品經(jīng)理工作中最常見、最高頻的交付物了。但是最近與許多同事的交流中卻發(fā)現(xiàn),很多產(chǎn)品人員、開發(fā)人員都對需求文檔抱有一種輕視、鄙夷的態(tài)度,產(chǎn)品經(jīng)理對于需求文檔敷衍了事,開發(fā)更是看都不看。加之一些不知從何處來的言論鼓吹,“一個(gè)好的產(chǎn)品經(jīng)理絕對不等同于寫文檔、畫原型”“寫文檔就是搬磚”,PRD更加成為了一個(gè)尷尬的存在。

然而事實(shí)并非如此。

對于產(chǎn)品經(jīng)理個(gè)人而言,需求文檔是產(chǎn)品方案、設(shè)計(jì)思路、實(shí)現(xiàn)思路的綜合體現(xiàn)和結(jié)果輸出,不管是使用可交互原型、手繪原型還是文字描述,產(chǎn)品經(jīng)理總是需要這樣一個(gè)載體來表達(dá)自己的思維結(jié)晶。

對于團(tuán)隊(duì)配合而言,隨著分工越來越細(xì)化以及員工流動(dòng)性的增加,需求文檔轉(zhuǎn)而擔(dān)負(fù)起了聯(lián)絡(luò)產(chǎn)品、開發(fā)、測試以及新老員工的溝通工具。

對于公司或者業(yè)務(wù)這個(gè)抽象實(shí)體而言,需求文檔是其業(yè)務(wù)發(fā)展、變革的沉淀……

上面講到需求文檔存在的價(jià)值,不過我們也應(yīng)該看到,圍繞著目標(biāo)或者第一性,需求文檔可能只是交付產(chǎn)品或用戶價(jià)值的工具,我們確實(shí)應(yīng)當(dāng)結(jié)合公司、業(yè)務(wù)、產(chǎn)品的具體情況去自定義“需求文檔”,而不是直接生搬硬套。

下文所述,是基于我個(gè)人不到一年的產(chǎn)品工作以及PRD寫作經(jīng)驗(yàn)。我相信隨著經(jīng)驗(yàn)的不斷積累,還會(huì)不斷生發(fā)出新的認(rèn)知來,屆時(shí)通過比較,我也能感知到自己的成長,在這里也歡迎大家與我共同探討。

二、重新定義需求文檔

1. 面向人群與寫作目標(biāo)

需求文檔的使用人群主要包括產(chǎn)品經(jīng)理、開發(fā)、測試。對于產(chǎn)品產(chǎn)品經(jīng)理而言,使用并撰寫需求文檔應(yīng)當(dāng)可以幫助:

  1. 細(xì)化產(chǎn)品方案
  2. 輸出文字版的產(chǎn)品實(shí)現(xiàn)方案
  3. 幫助整理思路、發(fā)現(xiàn)不足、促進(jìn)溝通
  4. 用于對內(nèi)對外的溝通展示

對于開發(fā)和測試而言,需求文檔應(yīng)當(dāng)可以幫助其了解業(yè)務(wù)、功能、成功標(biāo)準(zhǔn),從而更好的進(jìn)行開發(fā)和測試。

因而寫作PRD的過程,可以視為一個(gè)梳理產(chǎn)品思路、細(xì)化產(chǎn)品方案、細(xì)化技術(shù)方案的迭代的過程,而最終的PRD可以作為產(chǎn)品的藍(lán)圖、實(shí)施方案以及溝通工具。

2. 寫作思維

下面總結(jié)了在PRD寫作中我認(rèn)為比較重要的幾種思維模型:

(1)目標(biāo)思維

首先最頂層的思維應(yīng)當(dāng)是“目標(biāo)思維”,通過思考這些問題找到寫作目標(biāo):這份文檔給誰看?他們想看哪些信息?他們會(huì)以何種方式看?我應(yīng)該以什么樣的形式、內(nèi)容來寫才能更好的幫助讀者?

我寫作的常見目標(biāo)可能是這樣的:

  1. 通過需求文檔梳理整個(gè)產(chǎn)品設(shè)計(jì)思路,并簡要的傳達(dá)給項(xiàng)目成員。
  2. 通過需求文檔,將產(chǎn)品方案細(xì)化為文字版的解決方案,這個(gè)文字版方案應(yīng)當(dāng)涵蓋所有開發(fā)細(xì)節(jié),以便開發(fā)可以快速展開工作而無需多次找我溝通確認(rèn)。
  3. 需求文檔應(yīng)該有良好的組織結(jié)構(gòu),便于以后加入新的文檔。
  4. 跟隨敏捷與迭代的原則,需求文檔也應(yīng)是敏捷并且不斷迭代的。
  5. 需求文檔應(yīng)當(dāng)及時(shí)記錄和告知變更。

(2)基本的邏輯思維

產(chǎn)品文檔的各個(gè)組成模塊,應(yīng)當(dāng)具備合理的邏輯關(guān)系,而不是雜亂地鋪在文檔里。

例如,可以首先描寫和論證用戶需求;然后簡要敘述為了解決需求,選擇了怎樣的產(chǎn)品方案或業(yè)務(wù)模型;隨后列出為了實(shí)現(xiàn)業(yè)務(wù)模型需要鋪設(shè)的產(chǎn)品功能點(diǎn);進(jìn)一步的,通過功能流程圖,將功能點(diǎn)進(jìn)一步細(xì)化為一個(gè)個(gè)頁面路徑和頁面元素;最后還要有對于頁面元素的詳細(xì)描述。

可以看到,這樣的需求文檔是邏輯清晰、有說服力的,出現(xiàn)問題也很容易定位到具體環(huán)節(jié)。

(3)微言大義

對語言文字有所敬畏,語言文字作為溝通工具,是非常容易造成歧義的,要想準(zhǔn)確地將自己的思路想法傳達(dá)給別人是一件非常難的事情。需求文檔在文字表達(dá)上應(yīng)該力求簡潔、清晰、無歧義,多試著以讀者的角度去審視自己的文字表達(dá),相信你會(huì)發(fā)現(xiàn)很多問題。

(4)產(chǎn)品思維

我個(gè)人將PRD的寫作過程看作對產(chǎn)品思路的梳理和記錄。這個(gè)產(chǎn)品思路或許并沒有唯一正確答案,我個(gè)人的思路可以概括為:

(1)自上而下,基本遵循目標(biāo)-概要性產(chǎn)品解決方案–詳細(xì)解決方案(對于常見的2C互聯(lián)網(wǎng)產(chǎn)品,這個(gè)詳細(xì)解決方案可能包括從功能結(jié)構(gòu)到頁面視覺的一系列工作)

(2)由內(nèi)而外,主要用于對現(xiàn)有功能的優(yōu)化,基本遵循可用-易用-好用的迭代原則。

因而實(shí)際工作中,我的寫作思路一般也遵循上述原則,對于新功能通常按照目標(biāo)-概要方案-詳細(xì)方案去寫;對于功能優(yōu)化,結(jié)合現(xiàn)有使用場景和痛點(diǎn),去提出優(yōu)化方案。

(5)技術(shù)思維

產(chǎn)品思維比較偏重于分析決策和提出面向用戶或商業(yè)的解決方案,而技術(shù)主要考慮如何去實(shí)現(xiàn)這個(gè)解決方案,以及這個(gè)解決方案對既有技術(shù)框架的影響有多大。

實(shí)際上,一個(gè)好的解決方案絕不僅僅只考慮用戶或商業(yè),技術(shù)實(shí)現(xiàn)也是必須考量的要素。技術(shù)將解決方案落實(shí)并決定項(xiàng)目的資源和成本,技術(shù)方案的好壞也會(huì)直接決定用戶的使用體驗(yàn),甚至有些時(shí)候技術(shù)實(shí)現(xiàn)可以驅(qū)動(dòng)商業(yè)和用戶需求的變革。

產(chǎn)品經(jīng)理缺失技術(shù)思維,就會(huì)很容易將自己沒完成的任務(wù)無意識的甩鍋給開發(fā),實(shí)際工作中開發(fā)經(jīng)常跑來找產(chǎn)品溝通需求細(xì)節(jié)也是源于此。

以一個(gè)簡單的例子來說明:

技術(shù)層面,用戶在登錄注冊后,可以本地緩存賬號信息,從而下次訪問應(yīng)用時(shí)無需手動(dòng)進(jìn)行登錄操作。如果產(chǎn)品經(jīng)理不懂這個(gè)緩存技術(shù),在PRD中就會(huì)缺失相應(yīng)描述,開發(fā)人員無法明確是否要做這樣一個(gè)自動(dòng)登錄的功能,就只能拍腦袋決定了。

再舉一個(gè)登錄注冊相關(guān)的例子:

網(wǎng)站登錄注冊需要考慮是否限制用戶多賬號登錄的問題,網(wǎng)站運(yùn)行在瀏覽器上,瀏覽器在緩存用戶信息的時(shí)候是按域存儲(chǔ)的;如果網(wǎng)站允許多賬號登錄,在不加以設(shè)計(jì)的情況下,這些同時(shí)登錄的賬號會(huì)出現(xiàn)數(shù)據(jù)混亂的情況。因而必須在產(chǎn)品設(shè)計(jì)之初就從需求上定義是否需要多賬號登錄,進(jìn)而才能由開發(fā)給出一個(gè)完善的多賬號數(shù)據(jù)存儲(chǔ)或請求方案。

現(xiàn)實(shí)工作中,產(chǎn)品經(jīng)理可能無法達(dá)到技術(shù)人員的水平,解決之道可以是自己多學(xué)習(xí)、和技術(shù)多去溝通產(chǎn)品方案;還可以通過制定設(shè)計(jì)&開發(fā)規(guī)范,讓產(chǎn)品、設(shè)計(jì)、技術(shù)可以協(xié)同工作(類似于ant design,定義了一套常用的設(shè)計(jì)開發(fā)規(guī)范,產(chǎn)品設(shè)計(jì)和開發(fā)都可以基于共同規(guī)范去開展,而不用重復(fù)造輪子)。

在我最初的認(rèn)知中,產(chǎn)品經(jīng)理應(yīng)該盡量去定義一套足夠詳盡的解決方案,而開發(fā)人員、設(shè)計(jì)人員只需根據(jù)PRD去進(jìn)行自己的工作。

在對設(shè)計(jì)、開發(fā)有了一定的了解后,我認(rèn)為,單靠產(chǎn)品經(jīng)理一人之力去輸出詳盡的解決方案是不太可能的(除非產(chǎn)品經(jīng)理既懂得產(chǎn)品設(shè)計(jì)、又懂得技術(shù)、還懂得交互設(shè)計(jì)和視覺設(shè)計(jì)等)。一個(gè)真正優(yōu)秀的產(chǎn)品方案應(yīng)該由產(chǎn)品人員、開發(fā)人員、設(shè)計(jì)人員、測試人員通力合作,這些人員不是上下游關(guān)系、規(guī)劃與執(zhí)行關(guān)系,而是一種能力互補(bǔ)的關(guān)系,這些人員的才能共同造就一個(gè)優(yōu)秀的產(chǎn)品。

另一方面,在不斷的配合中,產(chǎn)品、設(shè)計(jì)、開發(fā)應(yīng)該嘗試去將常用功能封裝成一個(gè)設(shè)計(jì)&開發(fā)框架,在以后的工作中可以直接沿用或改動(dòng)現(xiàn)有框架,提高工作與溝通效率。

三、PRD結(jié)構(gòu)

下面簡要介紹我個(gè)人常常使用的PRD的基本結(jié)構(gòu):

1. 需求

也是產(chǎn)品方案要達(dá)到的目標(biāo),需求可能是用戶需求(即以用戶價(jià)值為導(dǎo)向),也可能是業(yè)務(wù)需求(即以商業(yè)價(jià)值為導(dǎo)向),后面的產(chǎn)品方案細(xì)節(jié),最終都是為了達(dá)到這一目標(biāo)。

在PRD中闡述項(xiàng)目的目標(biāo),有助于激發(fā)團(tuán)隊(duì)成員的動(dòng)機(jī),從而在目標(biāo)上達(dá)成一致。

2. 設(shè)計(jì)模型

面向需求或目標(biāo),提出解決方案或設(shè)計(jì)模型,可以以泳道圖、流程圖等可視化的方式或者文字表達(dá)的方式描述主要的業(yè)務(wù)邏輯、產(chǎn)品架構(gòu)。

3. 功能列表

根據(jù)設(shè)計(jì)模型,將用戶需求、業(yè)務(wù)需求轉(zhuǎn)換為大大小小的產(chǎn)品功能模塊或非功能性要求,闡述這些模塊間的業(yè)務(wù)關(guān)聯(lián)、數(shù)據(jù)關(guān)聯(lián),對于功能進(jìn)行優(yōu)先級分析和版本規(guī)劃。

4. 功能流程

針對每一個(gè)功能模塊,圍繞著功能目標(biāo),設(shè)計(jì)功能流程。如圍繞著用戶賬號登錄這一目標(biāo),設(shè)計(jì)登錄注冊的流程。這里要注意:

根據(jù)功能模塊的特性,使用不同種類的流程圖,比如泳道圖、時(shí)序圖、狀態(tài)圖。

突出主流程、弱化分支流程、以文字表達(dá)異常流程,將三者區(qū)隔開來。

(產(chǎn)品設(shè)計(jì)應(yīng)當(dāng)優(yōu)先考慮引導(dǎo)用戶走向主流程,次之考慮對于用戶的分支行為作出一定約束,最后還要考慮整個(gè)環(huán)境系統(tǒng)可能出現(xiàn)的異常。對于用戶、設(shè)計(jì)人員、開發(fā)人員而言,這三者的作用和優(yōu)先級都是不同的)。

5. 頁面設(shè)計(jì)與頁面元素

頁面設(shè)計(jì)是對功能流程的進(jìn)一步細(xì)化,許多的頁面元素串聯(lián)起來,引導(dǎo)用戶走完整個(gè)功能流程并達(dá)成目標(biāo)。根據(jù)功能流程圖,考慮以最少的頁面和最清晰有效的頁面布局實(shí)現(xiàn)功能。

6. 頁面詳細(xì)說明

對于頁面之間的邏輯和每一個(gè)頁面元素進(jìn)行必要的說明。

頁面元素包括信息和控件等,在說明信息時(shí),需要對信息的展示效果、信息來源、信息的計(jì)算規(guī)則、信息的刷新規(guī)則等進(jìn)行說明;對于控件,以輸入性控件為例,對控件類型、控件樣式、控件交互、輸入限制、輸入校驗(yàn)等屬性進(jìn)行說明。

個(gè)人覺得,頁面詳細(xì)說明是開發(fā)和測試最終要參考的部分,也是產(chǎn)品經(jīng)理最容易有遺漏的地方,因?yàn)檫@里會(huì)涉及很多細(xì)節(jié);對于這里的寫作也是爭議最多的,是否要寫得足夠詳盡?我只能說,對此要具體情況具體分析,如果團(tuán)隊(duì)已經(jīng)有了成熟的配合模式和規(guī)范,這里自然可以簡化;但是我想每個(gè)產(chǎn)品經(jīng)理都應(yīng)該具備寫一份詳盡文檔的能力。

那么怎樣才能避免遺漏細(xì)節(jié)呢?

我個(gè)人覺得,還是要有技術(shù)思維。換位思考如果你是開發(fā),你需要知道哪些必要因素才能開工。

對此,個(gè)人認(rèn)為最快的學(xué)習(xí)途徑不是看別人怎么寫需求文檔,而是讀一些技術(shù)的書,真正明白當(dāng)一個(gè)開發(fā)在寫代碼時(shí)是在做什么。

以網(wǎng)頁表單為例,前端需要通過html和CSS來定義表單的結(jié)構(gòu)和樣式,通過javascript執(zhí)行一些輸入限制和校驗(yàn),通過AJAX和服務(wù)端通信,發(fā)送POST請求將用戶輸入的一些字段信息上報(bào);服務(wù)端需要編寫程序?qū)φ埱筮M(jìn)行處理并在處理完成后發(fā)送響應(yīng)給前端。

因而從前端的角度出發(fā),PRD里應(yīng)當(dāng)包含頁面控件樣式的描述、控件交互的描述、輸入限制的描述、數(shù)據(jù)上報(bào)的描述等;從后端的角度出發(fā),PRD里應(yīng)該包含有數(shù)據(jù)上報(bào)的描述。

7. 全局說明

一些各個(gè)頁面都有的功能點(diǎn)、交互模式、設(shè)計(jì)樣式,或者一些通用的異??刂?,可以放在全局說明里。

四、總結(jié)

在PM的日常工作中,對于PRD有了一些認(rèn)知上的升級,在這里進(jìn)行了初步總結(jié)。主要講述了:

(1)PRD寫作的目的和價(jià)值

(2)PRD寫作中應(yīng)該具備的思維模式

(3)PRD的常見結(jié)構(gòu)

此文雖以PRD為主要話題,但實(shí)質(zhì)上重在對產(chǎn)品經(jīng)理邏輯與理性思維的體察。誠如很多大佬說的,產(chǎn)品經(jīng)理需要有一秒內(nèi)變?yōu)榘装V的能力;但個(gè)人認(rèn)為,除了直覺與感性,良好的邏輯思維與理性亦是產(chǎn)品人必不可少的。

 

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

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 我覺得現(xiàn)在需求文檔的重要性已經(jīng)被公司一個(gè)接一個(gè)的快速需求“弱化了”,按說應(yīng)該是先寫需求文檔,但是開發(fā)、UI沒有時(shí)間等你寫,會(huì)追著你要原型了,如果是后期寫,那意義就不大了,再發(fā)現(xiàn)問題也沒時(shí)間大改了;我和很多開發(fā)同事聊過,他們更愿意看原型和邏輯需求寫在一個(gè)頁面的,這樣他們看起來方便,不想看個(gè)原型去翻需求文檔,浪費(fèi)時(shí)間;一個(gè)大的項(xiàng)目寫一個(gè)需求文檔需要將近一周時(shí)間(不加班的情況下),誰會(huì)給這么多時(shí)間去寫呢。。。不過2B的項(xiàng)目甲方要這個(gè)東西,他們覺得專業(yè),其實(shí)他們也不看,也看不懂,我是在開發(fā)間歇期每天寫一點(diǎn),我反而把使用手冊作為了后期的重點(diǎn),因?yàn)槠髽I(yè)甲方最后都認(rèn)為使用手冊作為交付的完成點(diǎn),這是我的個(gè)人經(jīng)歷,肯定不是所有人的,希望我們經(jīng)常切磋。

    來自北京 回復(fù)
    1. 有同感!

      來自北京 回復(fù)
  2. 有沒有技術(shù)的書介紹一下?

    來自廣東 回復(fù)
    1. 你可以看一下我寫的其他文章,有技術(shù)相關(guān)的,也有推薦相關(guān)的技術(shù)書籍。

      來自臺(tái)灣 回復(fù)
  3. 求一份完整版PRD文檔學(xué)習(xí),1421268275@qq.com 十分感謝!

    來自北京 回復(fù)
  4. 想學(xué)習(xí)下經(jīng)典案例,能否屏蔽關(guān)鍵字給看個(gè)呢,或者大體框架結(jié)構(gòu)、思路給看下也行,先謝謝你了。大家都蠻期待的

    來自山東 回復(fù)
  5. 我覺得寫得很棒??!剛好我也是一年pm??,很感同身受,為樓主??

    回復(fù)
    1. 想轉(zhuǎn)pm,可是不知如合去轉(zhuǎn),求答惑下,謝謝

      來自北京 回復(fù)
    2. 可以說下PM工作流程嗎?我也會(huì)交互設(shè)計(jì) 原型設(shè)計(jì) 視覺設(shè)計(jì) 但總感覺力不從心,缺少一個(gè)正規(guī)的工作流程和完成辦法,請大佬指教(可私信)

      來自上海 回復(fù)
    3. 就差一點(diǎn)自信了。

      來自江蘇 回復(fù)
  6. 看了還是不怎么會(huì)寫。我是一臉懵逼的來做了產(chǎn)品 ??

    來自四川 回復(fù)
    1. 想轉(zhuǎn)pm,可是不知如合去轉(zhuǎn),求答惑下,謝謝

      來自北京 回復(fù)
  7. 在下也正有此問,理論再多不如一個(gè)例子來的明了。方便的話,能不能提供一份呢?謝。

    回復(fù)
    1. 非私人文檔,所以目前還不方便分享~~~

      來自廣東 回復(fù)
  8. 能不能提供一份呢

    回復(fù)
    1. 非私人文檔,所以目前還不方便分享~~~

      來自廣東 回復(fù)
  9. 標(biāo)題可以改為《寫了30+產(chǎn)品需求文檔后,關(guān)于PRD寫作的一些老生常談》

    來自浙江 回復(fù)
    1. ? 這個(gè)文筆水平對于寫prd一定是極為擅長的

      來自廣東 回復(fù)
    2. 哈,這位同行有沒有什么新知,大家可以探討一下~

      來自廣東 回復(fù)