中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)語：撰寫一份合理有效的產(chǎn)品需求文檔，有助于產(chǎn)品團(tuán)隊(duì)進(jìn)行后續(xù)管理，進(jìn)而在后期有序地推動產(chǎn)品迭代升級。本篇文章里，作者總結(jié)了撰寫B(tài)端產(chǎn)品需求文檔的方法以及相關(guān)小貼士，也許讀完之后，你能更清晰地了解PRD撰寫。

從各大招聘市場來看，B端產(chǎn)品經(jīng)理需求日漸旺盛，越來越多的產(chǎn)品新人和C端產(chǎn)品轉(zhuǎn)而投入了toB行業(yè)。在這樣的大背景下，越來越多的產(chǎn)品新人需要學(xué)習(xí)如何撰寫B(tài)端產(chǎn)品需求文檔（以下簡稱PRD：Product Requirement Document）。

那么，B端產(chǎn)品PRD到底好不好上手撰寫呢？

答案是否定的。最近，筆者在招聘產(chǎn)品實(shí)習(xí)生時發(fā)現(xiàn)了這樣一種現(xiàn)象：大部分實(shí)習(xí)生的初作品都是圍繞校園生活的C端產(chǎn)品，鮮有B端產(chǎn)品文檔；即使有一部分新人報名參加了一些產(chǎn)品培訓(xùn)，其作品也大多以C端為主。

這個現(xiàn)象從側(cè)面說明了注重交互和用戶體驗(yàn)的C端較好入門，因?yàn)楫a(chǎn)品經(jīng)理本身就可以嘗試代入角色進(jìn)行體會。而角色權(quán)限眾多、業(yè)務(wù)龐亂、流程復(fù)雜的B端產(chǎn)品則為新人樹立了一道無形的門檻，只有厘清和理解業(yè)務(wù)之后，才可能撰寫出一份高質(zhì)量的B端PRD。

因此，筆者想和剛剛?cè)胄蠦端亦或是頭疼寫文檔的你分享自己的PRD框架，幫助你又快又好地撰寫一份高質(zhì)量PRD。此外，還會額外與大家分享2個非常實(shí)用的PRD撰寫小tips，幫助你在保證質(zhì)量和準(zhǔn)確度的前提下，提升撰寫速度。

話不多說，直接上干貨。

一、我們?yōu)槭裁匆獙慞RD？

PRD的本質(zhì)是文檔，而文檔的本質(zhì)只是大腦產(chǎn)物的一種承載形式。那我們?yōu)槭裁床豢梢允褂每谑觥⒗L制草圖等方式來進(jìn)行溝通和信息傳遞呢？

并不是不行，在產(chǎn)品初期和團(tuán)隊(duì)人員較為精簡的情況下，有些公司會使用口述和手繪草圖等方式進(jìn)行溝通。但隨著時間的流逝和團(tuán)隊(duì)成員的壯大，這些方式不便于大范圍傳播和歸檔，而落筆有聲的文檔則可以肩負(fù)起記錄、參照和流傳的責(zé)任。

因此，當(dāng)達(dá)到一定的產(chǎn)品和團(tuán)隊(duì)階段，我們就需要通過PRD來保證多方目標(biāo)和需求理解一致，讓整個迭代井然有序的運(yùn)行。

那么，我們寫產(chǎn)品需求文檔是為了讓讀者了解什么呢？

首先，B端PRD的讀者和C端有很大差異。

B端PRD的讀者除了研發(fā)、老板之外，還包含需求方。不同于C端，B端的用戶往往是較為明確的一些職位和角色，他們會直接將一些需求和問題反饋至公司的銷售或是客服團(tuán)隊(duì)。這就意味著，公司內(nèi)的銷售部門、業(yè)務(wù)部門、客服部門等都會是用戶or客戶的傳話筒，從而成為我們的需求方。

其次，只有明確了讀者范圍，我們才能寫出他們真正需要了解的內(nèi)容。在參考一些前輩的思路之后，我們需要向讀者傳遞下列3個方面的內(nèi)容：

• 我們在解決xx用戶在xx場景下的xx問題；
• 我們使用xx資源、提出了xx方案，并期望收獲xx結(jié)果；
• 實(shí)現(xiàn)這個方案給我們帶來了xx價值（用戶價值、商業(yè)價值、公司價值）。

在上述3點(diǎn)中，上游的需求方（客戶、銷售部門、客服部門等）需要重點(diǎn)了解我們在解決哪些用戶的問題？場景是什么？大致的解決方案是什么樣的？下游的實(shí)現(xiàn)方（研發(fā)、測試等）則需要大致上了解用戶的需求場景，并重點(diǎn)關(guān)注實(shí)現(xiàn)方案及迭代目標(biāo)。

二、PRD框架及內(nèi)容

前面向大家傳遞了PRD的價值和目標(biāo)，第二部分就來和大家細(xì)講一下如何組織PRD的內(nèi)容、每一部分的側(cè)重點(diǎn)是什么以及怎樣才能又好又快地撰寫一份B端PRD。

如下圖所示，筆者的B端PRD框架整體分為三大模塊：項(xiàng)目信息、需求&調(diào)研、方案信息。下面我們分別就3大模塊進(jìn)行詳細(xì)介紹。

1. 項(xiàng)目信息

一次迭代就是一個小項(xiàng)目。因此，這里的項(xiàng)目信息則是我們從項(xiàng)目經(jīng)理的角度出發(fā)，向各方闡明本次迭代的總體規(guī)劃、團(tuán)隊(duì)資源及職責(zé)、并對相關(guān)評審及變更做出記錄。

1）迭代人員

按照不同職責(zé)列出項(xiàng)目迭代負(fù)責(zé)人及成員，并明確各個成員的職責(zé)。

2）評審記錄

用戶記錄需求評審的里程碑會議及結(jié)論。這里需要提醒大家一點(diǎn)，寫需求評審記錄時除了記錄那些確定要做的需求之外，還需要記錄確認(rèn)不做的需求并盡量說明決策原因。

記錄決策原因是一個幫助我們回顧和復(fù)盤的好方法。依據(jù)幾個月之前的決策思路，我們能很快回憶起當(dāng)時的出發(fā)點(diǎn)，在對比當(dāng)前的實(shí)際現(xiàn)狀之后，能更好地尋求成長和突破。

3）變更記錄

用于記錄迭代正式開始后的需求變更，便于追溯和復(fù)盤。其中，變更類型包含但不限于產(chǎn)品遺漏、邏輯設(shè)計缺陷、研發(fā)評估遺漏、老邏輯影響、新增業(yè)務(wù)、臨時方案趕工、版本拆分等等。

2. 需求&調(diào)研

利用金字塔原理，我們先和大家同步了項(xiàng)目的大致規(guī)劃，讓大家心里有了一個底。這一部分，我們就來和團(tuán)隊(duì)同步我們是「在解決誰在什么場景下的哪些問題」？

不同于模棱兩可、千人千面的C端產(chǎn)品，B端產(chǎn)品往往有較為明確的需求方和用戶。那么，我們還有必要向團(tuán)隊(duì)再闡述一遍需求到底是什么嗎？

當(dāng)然有必要。

一是因?yàn)閷?shí)現(xiàn)方（研發(fā)、測試等）對需求不了解，我們有必要向他們傳遞需求場景，幫助他們更好設(shè)計和架構(gòu)業(yè)務(wù)。

二是因?yàn)樾枨蠓娇谑龀鰜淼牟⒉灰欢ㄊ强蛻粽嬲男枨?。客戶往往會提出一個在他們認(rèn)知范圍內(nèi)較好的解決方案，告訴需求方“我們?nèi)边@個功能、我們想要這個功能、沒有這個功能不行”。但在真正了解之后，我們往往會發(fā)現(xiàn)客戶真正的需求不在于此，可能通過別的功能還能更好地解決問題。

這就說明我們需要對需求方收集來的客戶反饋進(jìn)行二次甄別和挖掘，最終再到PRD中把問題背后的本質(zhì)闡述出來，而僅僅照搬用戶反饋則是一種極不負(fù)責(zé)任的行為。

如下圖所示：在需求&調(diào)研部分，我們將整體的內(nèi)容劃分為調(diào)研信息和需求場景2大模塊。

一次迭代的調(diào)研信息可以分為用戶調(diào)研和競品調(diào)研，如果還包含其他類型的調(diào)研（例如行業(yè)調(diào)研），可自行加入其中）。

1）用戶調(diào)研

需求來源于客戶。因此，我們要先通過調(diào)研客戶來初步了解需求。調(diào)研報告的內(nèi)容包括但不限于時間、調(diào)研對象、調(diào)研數(shù)量、客戶類型、調(diào)研結(jié)論、調(diào)研人員等，具體視實(shí)情而定。

2）競品調(diào)研

知己知彼，百戰(zhàn)不殆。在著手實(shí)現(xiàn)之前，我們更需要對競爭對手的情況進(jìn)行調(diào)研。競品調(diào)研內(nèi)容包括但不限于調(diào)研時間、調(diào)研數(shù)量、競品名稱、調(diào)研結(jié)論等。

這里插一句，常常有人會問競品調(diào)研有沒有什么模版，需要做哪些事情？答案其實(shí)就一句話：調(diào)研只是手段，只要明確了調(diào)研目標(biāo)，從而也就確立了粒度和內(nèi)容。

3）需求場景

在通過問卷、訪談、觀察等調(diào)研手段之后，我們便能夠初步歸納出用戶的需求場景。當(dāng)然，只有產(chǎn)品經(jīng)理知道是遠(yuǎn)遠(yuǎn)不夠的，我們還需要將這些成果同步給團(tuán)隊(duì)，保證讓大家就需求場景的理解達(dá)成一致，即告訴大家我們在解決xx用戶在xx場景下的xx問題。

這里，筆者推薦用戶故事和用例圖2種工具。

故事往往充滿感情，更立體也更容易打動人。因此，用戶故事User story是從感性的角度出發(fā)，讓我們向大家講述一個典型用戶的故事：他們是一群怎樣的用戶、他們在什么場景下遇到了什么問題、他們的情緒怎樣、現(xiàn)在他們是怎么處理這些問題的。

而源自于UML的用例圖則更為理性。它能清楚地告訴研發(fā)本次迭代中涉及到哪些角色、每類角色的需求及邊界、不同需求之間的關(guān)系是什么等等。

通過第二部分的需求&調(diào)研模塊，能夠幫助團(tuán)隊(duì)成員在腦海里樹立一個亟待解決問題的用戶形象出來，我們能夠知道他有哪些問題、也能嘗試感知他的情緒。

3. 方案信息

方案指我們需要做哪些功能來幫助用戶解決問題。從篇幅上來講，方案信息是整個PRD的大頭部分，也是新人最為關(guān)注的內(nèi)容；但隨著經(jīng)驗(yàn)的增長，處于實(shí)現(xiàn)層的方案文檔撰寫能力將逐漸轉(zhuǎn)化為一種基礎(chǔ)能力，而不是競爭性能力。

可能有些人會對文檔撰寫不屑一顧，但筆者認(rèn)為這是產(chǎn)品經(jīng)理對外的第一張名片。產(chǎn)品經(jīng)理本身是一種無授權(quán)的團(tuán)隊(duì)leader，我們需要通過遞出一張張合格甚至優(yōu)秀的名片來建立團(tuán)隊(duì)影響力和信任感。因此，一個好的文檔撰寫能力至關(guān)重要。

我們將方案信息劃分為3大版塊：方案規(guī)劃、方案內(nèi)容、埋點(diǎn)信息。

1）方案規(guī)劃

在著手開工之前，我們先需要向團(tuán)隊(duì)講清楚這一次我們大致準(zhǔn)備怎么做。方案規(guī)劃的內(nèi)容包含但不限于分期規(guī)劃、滿足場景、需求清單（粗略版）、目標(biāo)價值、衡量指標(biāo)、風(fēng)險評估等。

• 分期規(guī)劃：B端客戶的需求往往龐亂而復(fù)雜，當(dāng)我們面對的客戶群體標(biāo)準(zhǔn)化程度較低、個性化需求較多時，可能會選擇分期解決、小步快跑，先滿足核心主流場景，再逐次完善分支異常場景。所以，當(dāng)我們決定分期解決問題時，就需要提前向大家告知清楚。
• 目標(biāo)價值：指該方案上線后能夠?yàn)橛脩魩硎裁磧r值、給公司又能帶來什么樣的商業(yè)價值。
• 衡量指標(biāo)：常言之，無法衡量就無法優(yōu)化。因此，我們需要明確出1-3個能夠真正衡量方案價值的指標(biāo)，便于我們未來進(jìn)行優(yōu)化和迭代。
• 風(fēng)險評估：指迭代上線前，需要對整個迭代可能遭遇或造成的風(fēng)險進(jìn)行評估，包含技術(shù)風(fēng)險、用戶體驗(yàn)變更風(fēng)險、數(shù)據(jù)修復(fù)風(fēng)險、并發(fā)風(fēng)險等。

筆者曾經(jīng)有一次慘痛的迭代教訓(xùn)就和缺少風(fēng)險評估有關(guān)。那次迭代是對原有的一些“糟糕”交互進(jìn)行了優(yōu)化，當(dāng)時并沒有考慮到是否會對用戶原有使用習(xí)慣造成影響，最終上線后，“收獲”了一大批的負(fù)面反饋。如果能提前對此有所評估，也許就會考慮通過一鍵切換回舊版本等一些緩和性的方案來進(jìn)行平滑過渡了。

2）需求清單

需求清單指我們需要滿足哪些需求、各需求的優(yōu)先級是什么樣的。其中包含但不限于需求名稱、需求描述、需求類型、所屬模塊、優(yōu)先級等。

• 需求名稱：指核心需求的簡稱、需求描述需說明具體的功能范圍及內(nèi)容。
• 需求類型：分為功能、優(yōu)化模塊：指該核心需求所歸屬的業(yè)務(wù)模塊需求優(yōu)先級說明：P0-優(yōu)先級最高的需求；P1-版本核心需求；P2-與核心需求存在關(guān)聯(lián)關(guān)系的業(yè)務(wù)調(diào)整；P3-其他調(diào)整需求；T0-承諾上線需求（優(yōu)先級分明，避免全部需求都為P0）。

3）業(yè)務(wù)架構(gòu)/流程

• 業(yè)務(wù)架構(gòu)：描述業(yè)務(wù)的整體架構(gòu)、業(yè)務(wù)模型、數(shù)據(jù)關(guān)系等（選寫，視版本所需確定）業(yè)務(wù)流程：前后端通用的核心業(yè)務(wù)流程繪圖標(biāo)準(zhǔn)：基本符合主流繪圖標(biāo)準(zhǔn)，關(guān)系/條件描述清晰無歧義。關(guān)于業(yè)務(wù)架構(gòu)/流程這里，筆者推薦3種比較常見的UML圖：活動圖、狀態(tài)機(jī)圖、時序圖。
• 活動圖：按照時間順序?qū)⒒顒拥倪壿嬚沓鰜?，與我們常見的流程圖類似；
• 狀態(tài)機(jī)圖：圍繞一個事物的狀態(tài)為中心來講述流程；
• 時序圖：在描述流程時，能夠清晰地定義角色的具體職責(zé)邊界和通信交互；

具體UML的介紹，可以參考此前筆者寫的這篇《一文解決產(chǎn)品經(jīng)理對UML的全部疑問》。

4）頁面說明

在描述好業(yè)務(wù)邏輯之后，就需要對頁面中的元素、組件、交互進(jìn)行一定的說明。C端產(chǎn)品經(jīng)理往往會花費(fèi)較多的時間在于細(xì)節(jié)體驗(yàn)和交互之上，而B端產(chǎn)品則全然不同。

因?yàn)閠oB行業(yè)業(yè)務(wù)邏輯龐大、流程復(fù)雜，產(chǎn)品經(jīng)理的核心要務(wù)就是梳理業(yè)務(wù)和流程，交互和體驗(yàn)則更多是錦上添花的作用。用一句客戶的話來說“業(yè)務(wù)都跑不動了，細(xì)節(jié)做那么好有什么用？”因此，對于B端產(chǎn)品經(jīng)理而言，我們要合理分配好文檔中業(yè)務(wù)流程和交互體驗(yàn)上的精力。

在寫頁面注釋這里，筆者為大家提供2個非常實(shí)用的小tips，幫助你在保證質(zhì)量的前提下節(jié)約大量的時間。

Tip1: 將重復(fù)邏輯創(chuàng)建為一個母版master

Axure中的母版可以簡單理解為公共元件模板，將母版應(yīng)用到相應(yīng)頁面中后，母版內(nèi)容或樣式發(fā)生變化，那么引用母版的頁面內(nèi)容或樣式同樣會跟著變化，常用于制作頁面頭部或底部內(nèi)容。因此 ，母版master常常被我們用于創(chuàng)建一些組件樣式或標(biāo)準(zhǔn)頁等，例如web端標(biāo)準(zhǔn)底頁、iPhone6標(biāo)準(zhǔn)底頁等。

但是，筆者這里要分享的是將一些重復(fù)性的邏輯也可以整理為母版。選中某段注釋文字，右鍵點(diǎn)擊創(chuàng)建母版Create Master，即可生成如下圖所示的邏輯母版：

這樣做有什么好處呢？

① 重復(fù)的組件或模塊的邏輯注釋只用寫一遍，第二次第三次直接拖拽母版使用即可，無須多次重復(fù)撰寫。

如上圖所示，若一次迭代中有3、5處都需要顯示這個沖突提示氣泡，那么我們只需寫一次，后續(xù)直接找到母版拖拽到頁面里即可。

② 文檔免不了要多次修改，那么當(dāng)這些重復(fù)邏輯一旦被修改，我們就只能挨個去窮盡，而且很容易出現(xiàn)遺漏。

但是如果使用了注釋母版，那么只需要在母版處一次修改，剩余引用母版的邏輯注釋部分將自動變更。不僅減輕了工作量，更能幫助我們避免遺漏、保證重復(fù)邏輯的統(tǒng)一性。

Tips2: 將標(biāo)準(zhǔn)化組件的邏輯注釋整理為元件庫libraries

我們常常會去Axure社區(qū)及各大資源平臺搜集各式各樣的元件庫lib，例如element、antd、iOS、Android的標(biāo)準(zhǔn)元件庫等，方便自己在畫圖時可以快速進(jìn)行樣式引用。

而B端產(chǎn)品以PC端、Web端為主，樣式整體較少（以表單、tab、列表等為主），同時相對較為標(biāo)準(zhǔn)化。因此，我們不僅可以將這些標(biāo)準(zhǔn)化組件的樣式整理為元件庫lib，也可以將這些組件對應(yīng)的邏輯注釋整理為元件庫lib。

如下圖所示，當(dāng)我們頁面中遇到一個下拉菜單的選項(xiàng)時，就可以直接拖拽元件庫中對應(yīng)的注釋到頁面中來。

通過提煉各類篩選組件、搜索組件、表單組件等的邏輯交互，不僅能夠提升我們對前端組件的抽象理解能力，同時在撰寫文檔過程中也可以拖拽即用，能夠大大減輕工作量并幫助我們避免邏輯遺漏。

5）埋點(diǎn)說明

埋點(diǎn)說明包含但不限于埋點(diǎn)人群、事件、觸發(fā)條件、對應(yīng)業(yè)務(wù)價值、指標(biāo)預(yù)測及后續(xù)方案等。這里就不展開講了，但埋點(diǎn)的重點(diǎn)是一定要先想好埋點(diǎn)的目標(biāo)是什么，然后再去規(guī)定對應(yīng)指標(biāo)。

That’s all～以上就是筆者對B端產(chǎn)品文檔的一些思考和小訣竅。

本次分享的初衷是給大家提供一個思參考，最建議的方式是在積累一定經(jīng)驗(yàn)后花1、2天做一個適合自己業(yè)務(wù)和使用習(xí)慣的模版及元件庫。文檔不是終點(diǎn)，而是起點(diǎn)。善用工具，能夠幫助我們釋放大腦、留出更多的時間進(jìn)行思考。

作者：冰冰醬；公眾號：產(chǎn)品冰冰醬

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

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