国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

作為產(chǎn)品經(jīng)理，編寫產(chǎn)品需求文檔是基本技能之一，本文詳細介紹了如何編寫產(chǎn)品需求文檔（PRD），希望對你編寫有效的PRD有所幫助。

PRD是Product Requirement Document的簡稱，翻譯為：產(chǎn)品需求文檔。該文檔是產(chǎn)品由“概念化”階段進入到“圖紙化”階段的最重要的一個文檔。編寫PRD是一個產(chǎn)品經(jīng)理最為基礎(chǔ)的工作內(nèi)容，也是一個產(chǎn)品經(jīng)理最基礎(chǔ)的能力。不夸張的說，通過一篇PRD文檔就可以體現(xiàn)出一個產(chǎn)品經(jīng)理的基本功是否扎實，這直接影響到整個研發(fā)團隊的效率。

我常年從事To B系統(tǒng)產(chǎn)品的工作，因此本文的內(nèi)容也僅針對To B系統(tǒng)的PRD文檔，并不完全適用To C的系統(tǒng)產(chǎn)品。想寫出一篇優(yōu)秀的PRD文檔，需要搞清楚如下4個問題：

1. PRD文檔的編寫目的是什么？
2. PRD文檔在編寫前需要做什么？
3. PRD文檔在編寫的過程中有哪些是需要注意的？
4. PRD文檔編寫完成后如何使用？

一、PRD文檔的編寫目的是什么

編寫PRD文檔最為重要的目的就是：協(xié)調(diào)各個相關(guān)角色，將產(chǎn)品高效正確的“生產(chǎn)”出來。PRD僅僅是為達到這個目標，產(chǎn)品經(jīng)理經(jīng)常使用的一種工具，只要是能夠高效的完成最后的系統(tǒng)化產(chǎn)品，那么PRD具體的內(nèi)容、形式也沒有非常嚴格的標準。從這個目標出發(fā)，我們能夠看到這樣幾個關(guān)鍵詞：各個角色、高效&正確和生產(chǎn)

1.1 各個角色

這里的角色是涉及到整個產(chǎn)品研發(fā)過程中全部相關(guān)的角色，每個角色在這個過程中負責(zé)的工作和關(guān)注點有所不同，PRD中需要照顧到所有參與角色的關(guān)注點，To B系統(tǒng)產(chǎn)品在此過程中主要涉及到的角色如下：

• 領(lǐng)導(dǎo)（產(chǎn)品總監(jiān)等）：這個角色的人一般不會太過關(guān)注PRD的細節(jié)，重點會看一下，做這項工作的原因、解決問題的影響范圍、成本、以及最終給客戶和公司內(nèi)部提供的價值。當(dāng)然，這些內(nèi)容如果在PRD之前就使用其他的文檔說清楚了，PRD文檔中就不需要寫了，我也建議在PRD編寫之前，通過產(chǎn)品提案等方式，把這些內(nèi)容全部確定好，達成一致。
• UI&UX設(shè)計師：這個角色的人一般會重點關(guān)注在一些頁面的元素上，設(shè)計師會根據(jù)頁面的元素進行視覺和交互設(shè)計，所以，PRD中已經(jīng)要寫清楚頁面的元素以及這些元素的含義，并且說明最終用戶在頁面上大大致操作過程。
• 前后端研發(fā)工程師：前后端工程師關(guān)注的側(cè)重點稍微有點不同，后端工程師側(cè)重具體邏輯細節(jié)，前端工程師更關(guān)注在設(shè)計師給出的設(shè)計稿、交互說明和一部分少量的前端邏輯。所以，PRD中一定要把具體邏輯寫清楚，最好把設(shè)計師的設(shè)計稿和設(shè)計說明一并匯入PRD中。
• 測試工程師：這個角色的人除了關(guān)注前后端邏輯、交互外，還關(guān)注系統(tǒng)最后希望達到的標準，以及最終的和興使用場景。所以，盡可能的寫一下最核心的幾個使用方式，相當(dāng)于最重要的幾個測試用例。
• 產(chǎn)品運營：這個角色的人會關(guān)注最終產(chǎn)生的價值以及具體的使用方式，產(chǎn)品運營作為產(chǎn)品的客戶之間的重要橋梁。所以，最好可以寫一下系統(tǒng)使用說明。

1.2 高效&正確

寫出來文檔永遠比無效的溝通更高效，工作的事件越長，對此越是認可，對于很多問題，特別是復(fù)雜問題，前午安不要覺得說一下大家就明白了，前因后果、如何做大家都清楚了，相信我一定不是這樣的。

PRD就是提高效率的，把各個角色的共識全部寫出來，大家都已PRD為最終的工作指導(dǎo)文檔，在墻漆可以討論修改，在后期可以追根溯源，多花點時間在PRD上一定會比不斷地回答問題，不斷地因為沒有大臣一致的邏輯反復(fù)修改要高效的多。

1.3 生產(chǎn)

本質(zhì)上，軟件開發(fā)也是生產(chǎn)的過程，和生產(chǎn)實物是沒有本質(zhì)區(qū)別的。PRD作為指導(dǎo)生產(chǎn)過程的重要文檔，類似實物生產(chǎn)的設(shè)計文檔，必須要滿足在生產(chǎn)過程中各種各樣問題的回答。因此需要從生產(chǎn)流程的角度進一步的來說審視PRD的內(nèi)容，包括：現(xiàn)狀、準備工作、前提條件、開發(fā)邏輯、效果要求等。

二、PRD文檔在編寫前需要做什么？

在上一小節(jié)中建議在PRD編寫之前，通過產(chǎn)品提案等方式把價值、成本等內(nèi)容全部確定好，達成一致。實際上在PRD文檔編寫之前還遠不止這些內(nèi)容。

PRD開始編寫，意味著整個業(yè)務(wù)調(diào)研、方案邏輯、可行性、價值判斷基本上已經(jīng)完成了，如果沒有完成那么是不建議直接編寫PRD文檔的，因為就算寫完了也很有可能改來改去或不做了，這不僅僅影響工作的效率，還會大大打擊個人和團隊的積極性。

• 業(yè)務(wù)調(diào)研：只有完全搞清楚業(yè)務(wù)的問題，才可以解決問題，在PRD編寫前一定要進行業(yè)務(wù)調(diào)研，根據(jù)需求的復(fù)雜程度編寫詳細或簡要的需求調(diào)研文檔，明確需要解決的具體問題和要達到的具體目標。
• 方案邏輯：雖然PRD就是最后方案的詳細說明文檔，但是，在方案設(shè)計的初期，一定是有不同的方案來解決問題的，這些不同的方案需要進行一些維度的比對，最終選擇合適的方案，因此，在PRD編寫前，需要寫一個設(shè)計思路文檔。
• 可行性：圍繞設(shè)計思路中的不同方案，要對技術(shù)可行性進行論證，這需要與具體的開發(fā)負責(zé)人進行溝通，明確方案是否可行，以及成本，最后決定最終的方案。
• 價值判斷：如果說一個問題的解決成本大于價值了，那就沒必要做了，也就沒必要繼續(xù)寫PRD了，因此需要對方案的的直接和間接價值，以及直接和邊際成本進行明確，確定推進是有意義的。

三、PRD文檔在編寫的過程中有哪些是需要注意的？

終于來到了最核心的部分了，PRD文檔的具體結(jié)構(gòu)，有哪些呢，這一部分在網(wǎng)上確實有非常多的模板可以參考，各個模板也是大同小異，但最為重要的是有一些細節(jié)上需要注意，這也和下一小節(jié)如何使用PRD文檔有很大的關(guān)系。在我看來，一個TO B系統(tǒng)的PRD的結(jié)構(gòu)大致分為：

3.1 文檔管理

版本管理需要記錄每次修改的概要說明，相關(guān)人員是為了明確具體的工作人員，開發(fā)當(dāng)中的溝通以及后續(xù)問題排查需要，設(shè)計稿一般會有一個設(shè)計工具的地址，里面會有一些圖片無法表達的內(nèi)容，相關(guān)人員需要查看。

3.2 背景

背景和目標通常是比較簡短的。

一方面是為了在內(nèi)容層面表述大的背景和目標，比如公司整體的方向是讓系統(tǒng)有更高的開放性，需要做一些API，所以本次的開發(fā)是在這個開放性的大背景下的，達到XXX部分對接，降低定開成本等等。

另外一方面是在寫作技巧上，不能上來一桿子通到底了，需要與讀者在某些信息上達成共識，引出問題后在再進行具體的說明。

3.3 需求說明和分析

需求并說明的部分主要分為2各部分，需求描述和需求分析，需求分析又分為現(xiàn)狀分析和需求分析2部分：

• 需求描述：需求描述需要原滋原味的將最原始的需求進行表達，可以是客戶的需求、競品對比的需求、老版提出的需求、售前引申的需求等等，但無論來源是什么，在需求描述中一定要回歸業(yè)務(wù)場景，沒有業(yè)務(wù)場景說明出發(fā)點就要小心了，很有可能最后不會帶來業(yè)務(wù)上的實際價值。
• 現(xiàn)狀分析：針對需求，目前系統(tǒng)是如何解決的，還是沒有任何方式解決，現(xiàn)有的解決辦法為什么不是最優(yōu)的。
• 需求分析：需求分析最考驗一個產(chǎn)品經(jīng)理的基本功（有人說是設(shè)計，我不這么認為），需求分是是在挖掘需求背后的真正目的，多問自己幾個為什么需要。

3.4 產(chǎn)品方案概覽

產(chǎn)品方案概覽是為了讓相關(guān)人員在查看詳細的設(shè)計方案前對整體的情況有一個初步的認識，直接查看一個不熟悉的產(chǎn)品方案細節(jié)，很容易無法透測理解。方案概覽一般從3各方面進行闡釋，最后在將開發(fā)的任務(wù)和范圍明確一下，為具體的功能說明做好鋪墊。

• ER圖：一般情況下，To B的系統(tǒng)都會有很多數(shù)據(jù)對象，數(shù)據(jù)對象之間存在復(fù)雜的關(guān)聯(lián)關(guān)系，特別是整個方案中如果引入了新的對象或新的關(guān)聯(lián)關(guān)系，那么一定要繪制ER圖，說明不同抽象對象之間的關(guān)系。
• 整體方案：整體方案強烈建議使用一張圖，一圖勝前言，用一張圖說明整條的方案，增加了什么頁面、增加了什么字段、增加了什么邏輯處理、增加了什么對外接口等等，根據(jù)具體的需要一般會使用架構(gòu)圖、時序圖等及西寧表達
• 使用方式：可以叫做使用方式，也可以叫做頁面結(jié)構(gòu)圖，主要是為了闡釋在真正客戶面前這個產(chǎn)品是如何被使用的，當(dāng)然如果沒有頁面的開發(fā)，這部分可以省略。

3.5 功能說明

功能說明就是對概覽性方案的拆分說明，對每一個小的功能點進行詳細的說明。一般分為原型和功能說明，沒有頁面的原型部分可以空著。功能部分一定要寫清楚具體的邏輯。

非核心功能和非功能性需求，更加考驗一個產(chǎn)品經(jīng)理設(shè)計能力的細致，優(yōu)秀的產(chǎn)品經(jīng)理需要看到功能背后的需求，比如，性能、安全等等，這些細項像一個檢查清單，產(chǎn)品經(jīng)理在自己具體的領(lǐng)域里不斷手機問題完善這個清單，然后在每個PRD里面一條一條的問自己需不需要。

3.6 驗收說明

驗收說明類似于P0的測試用例，切實描素用戶最終的使用過程。

四、PRD文檔編寫完成后如何使用？

PRD文檔編寫完成就結(jié)束了嗎，還沒有，那就是使用PRD知道整個開發(fā)過程的工作了，從Planning會議講解PRD開始，PRD文檔正式投入使用，在這個過程中那面會對PRD文檔進行一些修改，這時一定要記錄好修改的內(nèi)容，不然回頭就忘了。

另外，在PRD使用的過程中，一定要不斷的發(fā)現(xiàn)PRD模板的問題，不斷優(yōu)化PRD模板。