在產(chǎn)品開發(fā)和管理的過程中，一份清晰、詳盡的需求文檔（PRD）對(duì)于確保項(xiàng)目順利進(jìn)行至關(guān)重要。本文將為您提供一個(gè)通用的策略需求文檔模板，幫助大家高效地撰寫出既專業(yè)又實(shí)用的PRD。

產(chǎn)品需求文檔(Product Requirement Document，簡稱PRD)是研發(fā)將產(chǎn)品方案進(jìn)行落地的依據(jù)，也是產(chǎn)品經(jīng)理所有思考的載體，因此一份優(yōu)秀的需求文檔不僅能夠順利的保證項(xiàng)目的研發(fā)進(jìn)度，而且能夠提升產(chǎn)品經(jīng)理的個(gè)人影響力。

每個(gè)企業(yè)，每個(gè)團(tuán)隊(duì)對(duì)需求文檔的要求不盡相同，今天給大家分享一份相對(duì)比較通用的策略需求文檔模板，主要包括文檔內(nèi)容結(jié)構(gòu)、內(nèi)容呈現(xiàn)顆粒度以及注意事項(xiàng)。?

01 需求概述?

和大多數(shù)PRD一樣，策略PRD的第一部分也應(yīng)該呈現(xiàn)需求概述。需求概述中一般至少包含如下內(nèi)容：需求背景和需求目標(biāo)。

1. 需求背景

通俗來講就是講就是這篇文檔中描述的方案要需要解決什么問題，及其必要性。

對(duì)于策略需求來講，這塊通常有以下幾個(gè)切入點(diǎn)：

• 用戶痛點(diǎn)捕捉，大多數(shù)的策略，尤其典型的搜推策略，解決的都是流量高效分發(fā)的問題，簡言之，如何做好人貨匹配，所以從用戶視角去進(jìn)行需求點(diǎn)分析是必需的；
• 當(dāng)前業(yè)務(wù)的問題，尤其在對(duì)接業(yè)務(wù)方需求的時(shí)候，通?？梢砸赃@樣的背景進(jìn)行切入，而且本身檢驗(yàn)策略有效性的核心就是業(yè)務(wù)指標(biāo)收益，所以明確業(yè)務(wù)問題也是定指標(biāo)的關(guān)鍵；
• 主觀評(píng)估報(bào)告的結(jié)論，相比C和B的需求來說，通過主觀策略評(píng)估發(fā)現(xiàn)策略優(yōu)化點(diǎn)通常都可以作為策略迭代的出發(fā)點(diǎn)，這是策略產(chǎn)品區(qū)別C和B端產(chǎn)品的一個(gè)非常典型的切入點(diǎn)。
• 數(shù)據(jù)前置分析發(fā)現(xiàn)優(yōu)化點(diǎn)，通過數(shù)據(jù)趨勢(shì)性分析發(fā)現(xiàn)問題，漏斗分析，session分析發(fā)現(xiàn)機(jī)會(huì)點(diǎn)，這樣能夠定量的去驗(yàn)證策略的必要性以及收益點(diǎn)。

在我們進(jìn)行完初步都需求背景表述之后，需要定義當(dāng)前策略需求的目標(biāo)。

2. 需求目標(biāo)

就是完成這個(gè)需求所有達(dá)成的收益，通常是以指標(biāo)的方式進(jìn)行定義。

策略需求的指標(biāo)通常包括CTR、CVR，UV價(jià)值等等。

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

需要注意的是，在定義需求目標(biāo)時(shí)，不僅僅要給出可衡量指標(biāo)的具體計(jì)算方式，還需要給出該需求相關(guān)的數(shù)據(jù)現(xiàn)狀分析結(jié)果，以保證目標(biāo)確定的合理性。

在實(shí)際的應(yīng)用中，這兩項(xiàng)也可以也獨(dú)立章節(jié)存在。

示例：

搜索篩選項(xiàng)是決定搜索流量分發(fā)效率的重要環(huán)節(jié)之一。相關(guān)用研結(jié)果表明有80%的用戶會(huì)在搜索結(jié)果頁使用篩選功能來進(jìn)行商品精細(xì)化選擇。
但是提取了近一周篩選功能使用數(shù)據(jù)，目前篩選項(xiàng)總體CTR大約為10%，用戶關(guān)注的很多因素沒有體現(xiàn)在篩選項(xiàng)中，基于此，進(jìn)行本次搜索結(jié)果篩選項(xiàng)優(yōu)化，以提升搜索結(jié)果頁篩選項(xiàng)的CTR。
CTR的口徑為：篩選項(xiàng)的點(diǎn)擊次數(shù)除以篩選項(xiàng)的曝光次數(shù)。

02 版本控制

版本控制是指當(dāng)前策略需求上線的版本，這個(gè)是很多策略產(chǎn)品經(jīng)理寫需求的時(shí)候容易忽略的一個(gè)點(diǎn)。

通常一個(gè)產(chǎn)品因?yàn)橛脩舾碌臅r(shí)效，以及發(fā)布規(guī)則等限制，線上會(huì)存在多個(gè)不同版本，因此需要確定當(dāng)前需求上線的版本。

另外，策略需求因?yàn)槠浣Y(jié)果的不確定性，通過版本控制也可以降低因策略帶來線上風(fēng)險(xiǎn)，方便問題緊急處理。

03 交互/視覺示意圖

如果當(dāng)前策略PRD中定義的需求屬于前端可視化類時(shí)，需要在文檔中給出交互、視覺示意圖。

一方面可以快速讓大家理解本次方案的生效范圍、需求效果；另一方面其實(shí)也能提升需求評(píng)審環(huán)節(jié)的效率。大家對(duì)于圖形的接受、理解能力要遠(yuǎn)遠(yuǎn)大于文字。

在一些完善的產(chǎn)品研發(fā)團(tuán)隊(duì)，會(huì)有專門的交互設(shè)計(jì)師來承接交互設(shè)計(jì)的工作，策略產(chǎn)品經(jīng)理需要明確評(píng)估當(dāng)前策略對(duì)用戶完成相關(guān)流程的影響，以及可能帶來的風(fēng)險(xiǎn)。

視覺示意圖一般無須產(chǎn)品經(jīng)理直接介入，做好資源協(xié)調(diào)，細(xì)節(jié)溝通和方案確認(rèn)即可。

另外，原型不僅僅可以用于前端產(chǎn)品設(shè)計(jì)，我還有一個(gè)習(xí)慣就是在策略邏輯比較復(fù)雜的時(shí)候，為了降低需求理解的成本，可以通過原型來進(jìn)行邏輯延時(shí)，尤其適合排序策略演示。

04 策略邏輯

策略邏輯是策略PRD中最核心的內(nèi)容，它其實(shí)就是一類問題的解決方案，一般包括：策略流程圖、策略內(nèi)容、優(yōu)先級(jí)定義。

• 策略流程圖主要是指該策略從開始到結(jié)束的數(shù)據(jù)流轉(zhuǎn)過程，通過數(shù)據(jù)流程圖可以清晰的看到整個(gè)策略方案的細(xì)節(jié)，以及和其他模塊的交互過程。
• 策略內(nèi)容主要是定義需求名稱、需求內(nèi)容、規(guī)則邏輯、細(xì)節(jié)說明等，策略產(chǎn)品經(jīng)理在編寫策略內(nèi)容時(shí)最主要的是注意方案的完整性，尤其涉及到數(shù)據(jù)參與計(jì)算的規(guī)則邏輯，許多邊界條件都要定義清楚。
• 優(yōu)先級(jí)定義是指當(dāng)一個(gè)策略需求文檔中包含若干策略需求內(nèi)容時(shí)候，需要指明每個(gè)需求的優(yōu)先級(jí)，以便研發(fā)資源分配。

這塊的呈現(xiàn)形式建議大家用表格的方式呈現(xiàn)，更加清晰合理。示例：

05 A/B測(cè)試方案

A/B測(cè)試是策略需求中非常常見的上線手段，策略產(chǎn)品經(jīng)理需要在PRD中定義清楚A/B測(cè)試的版本，時(shí)間范圍，測(cè)試方案以及執(zhí)行者。

核心的A/B測(cè)試方案需要定義以下內(nèi)容：

• AB實(shí)驗(yàn)前置條件計(jì)算：最小樣本量，持續(xù)時(shí)間
• 實(shí)驗(yàn)分組：按照最小樣本量，對(duì)實(shí)驗(yàn)組，對(duì)照組，空白組比例進(jìn)行設(shè)置
• 實(shí)驗(yàn)配置：實(shí)驗(yàn)名稱、流量設(shè)置、白名單配置，實(shí)驗(yàn)持續(xù)時(shí)間等等
• 實(shí)驗(yàn)類型：做正交實(shí)驗(yàn)，還是垂直實(shí)驗(yàn)？兩個(gè)的核心區(qū)別就是是否和其他實(shí)驗(yàn)共享流量。非特殊情況下正交實(shí)驗(yàn)可滿足大部分A/B需求。

示例：

本次策略上線需要進(jìn)行AB試驗(yàn)，APP版本：V5.0.2
核心觀測(cè)指標(biāo)為CTR，持續(xù)兩周。
具體分組如下：
實(shí)驗(yàn)組：20%，新策略
對(duì)照組：20%，線上策略
空白組：60%，線上策略

06 埋點(diǎn)方案

埋點(diǎn)方案是策略需求文檔中最基本內(nèi)容之一。

很多產(chǎn)品經(jīng)理認(rèn)為只有涉及到前端可視化類產(chǎn)品優(yōu)化時(shí)才需要埋點(diǎn)方案，其他無須提供。這里有一個(gè)很大的誤區(qū)，其實(shí)在之前的文章我不止一次提到過埋點(diǎn)只需要保持一個(gè)原則就行：“要看什么數(shù)據(jù)，埋什么點(diǎn)”，因此，是否需要埋點(diǎn)方案不依賴于具體的產(chǎn)品形式，而是你的數(shù)據(jù)需求。

比如為了衡量比較不同版本的算法對(duì)整個(gè)策略的效果，需要采集不同版本的算法id，每個(gè)id唯一標(biāo)識(shí)一個(gè)版本，所以即便不涉及到前端改動(dòng)，也需要增加埋點(diǎn)用來采集算法id。

以上六個(gè)模塊就是一份策略需求文檔最基礎(chǔ)、最基本的內(nèi)容要求。

當(dāng)然，在實(shí)際的工作中，可以根據(jù)團(tuán)隊(duì)要求，需求類型靈活進(jìn)行定義，增加刪除若干模塊。比如在一些線上badcase優(yōu)化中，一個(gè)簡單的excel即可進(jìn)行策略需求的定義和開發(fā)。