詳解產(chǎn)品商業(yè)文檔、市場文檔、設計文檔、功能文檔

詳解產(chǎn)品商業(yè)文檔、市場文檔、設計文檔、功能文檔在產(chǎn)品未進入生產(chǎn)性開發(fā)之前，所做的所有工作成果都是以文檔的形式進行體現(xiàn)的，是新產(chǎn)品開發(fā)最重要、也是價值最大的工作內(nèi)容，包括商業(yè)文檔、市場文檔、設計文檔及功能詳述，如圖5-11所示。從廣義上來講，產(chǎn)品文檔內(nèi)容包含有產(chǎn)品的戰(zhàn)略和戰(zhàn)術，戰(zhàn)略是指：目標市場、客群定位、競爭對手、產(chǎn)品概念、價值主張、產(chǎn)品定位、商業(yè)模式等；戰(zhàn)術是指競爭策略、產(chǎn)品創(chuàng)意、創(chuàng)新設計、產(chǎn)品結構、核心業(yè)務流程、具體用例描述、功能及內(nèi)容描述等。圖5-11產(chǎn)品設計相關四大文檔一、商業(yè)文檔BRD商業(yè)需求文檔是指基于商業(yè)目標或價值所描述的產(chǎn)品需求內(nèi)容文檔（報告），其核心的用途就是用于產(chǎn)品在投入研發(fā)之前，由企業(yè)高層作為決策評估的重要依據(jù)。作為報告的撰寫者，你必須讓高層明白，你的報告中將展現(xiàn)出怎樣的商業(yè)價值，如何用有力的論據(jù)來說服企業(yè)對你這個項目的認可，并為之慷慨地投入研發(fā)資源及市場費用。如果說PRD的好壞，直接決定了項目的質(zhì)量水平，那么BRD的作用，就是決定了你的項目的商業(yè)價值。優(yōu)秀的BRD文檔，可以讓決策層充分被你的報告觀點所吸引，或許財務主管會因為報告呈現(xiàn)的低投入高產(chǎn)出的經(jīng)濟效益預測而蠢蠢欲動；或許技術主管會因為項目的牽涉面廣泛而頭疼不已；又或許公司的VP之流因之報告而看到了未來一年業(yè)績的飛速發(fā)展的廣闊前景……BRD需要產(chǎn)品經(jīng)理（產(chǎn)品設計師）像對待PRD一樣，充分應用市場調(diào)查、用戶研究、需求分析等各種設計手段來充分闡述報告,內(nèi)容和格式要求夠直觀、精煉，要點突出，一般比較短小精煉，沒有產(chǎn)品細節(jié)。產(chǎn)品經(jīng)理通常需要向上匯報商業(yè)文檔，供決策層們討論，匯報會議主要內(nèi)容如下。會議開始，產(chǎn)品經(jīng)理首先要給與會的領導介紹一下產(chǎn)品要做什么吧（解決什么問題或滿足什么用戶需要）？為什么要做談談背后的原因（背景、市場空間、競爭對手、環(huán)境）？打算怎么做（產(chǎn)品規(guī)劃、模塊規(guī)劃、研發(fā)計劃、運營計劃）？需要多少資源（人力成本、軟硬件成本、運營成本）？最終能獲得什么收益（帶來收入、帶來用戶、擴大市場、占有市場先機、滿足未來三年戰(zhàn)略規(guī)劃等）？做這個有沒有風險（開發(fā)失敗？失去市場機會？失去先機？競爭不過對手？沒有帶來收入？沒有帶來用戶？與公司戰(zhàn)略背道而馳？）？二、市場文檔MRD市場需求文檔是產(chǎn)品項目由“準備”階段進入到“實施”階段的第一文檔，其作用就是“對某個產(chǎn)品進行市場層面的說明”。該文檔中，側重的是對產(chǎn)品所在市場、客戶、購買者、用戶以及市場需求進行定義，并通過原型的形式加以形象化。這個文檔的質(zhì)量好壞直接影響到產(chǎn)品項目的開展，并直接影響到公司產(chǎn)品戰(zhàn)略意圖的實現(xiàn)。該文檔在產(chǎn)品項目中是一個“承上啟下”的作用，“向上”是對不斷積累的市場數(shù)據(jù)的一種整合和記錄，“向下”是對后續(xù)工作的方向說明和工作指導。文檔包含主要內(nèi)容如下。1.市場說明目標市場、市場規(guī)模、市場特征、未來3~5年的發(fā)展趨勢，現(xiàn)在市場存在的問題和機會。一般來說，這里會得到一個比較有市場商業(yè)價值的結論。2.用戶說明目標客群的共性分析，常用用戶特征（要求準確：年齡段、收入、地區(qū)、學歷），通過用戶畫像建立虛擬用戶角色：形象化，用戶名稱，用戶技能、與產(chǎn)品相關的用戶特征，演示性的場景，用戶在時間、地點，完成的某個事的故事。從技術層面剖析市場，洞察用戶心理案例分析（動機和目標是不一致的）影響用戶使用的主要因素。3.產(chǎn)品定位我們用什么樣的產(chǎn)品滿足用戶或用戶市場；針對什么用戶，做什么事。4.產(chǎn)品價值解決目標市場、用戶的核心需求（核心價值優(yōu)先級最高）。5.產(chǎn)品架構整體結構，不是功能結構。是產(chǎn)品的核心目標、市場定位、產(chǎn)品定位的直接體現(xiàn)。6.產(chǎn)品路線圖以時間為節(jié)點，任務為導向。7.產(chǎn)品功能性需求用戶注冊、留言等等。8.非功能性需求有效性、性能、擴展性、安全性、健壯性、兼容性、可用性、用戶體驗等。三、設計文檔PRD產(chǎn)品設計文檔是把我們想做的東西變成一張清晰明了的“圖紙”，讓研發(fā)人員看到這張“圖紙”就知道我們要做啥，需要做到什么程度，大概需要什么技術，并能對成本進行一個預估。不同平臺和不同行業(yè)的產(chǎn)品的設計文檔有所區(qū)別，但思想都差不多。這里以網(wǎng)站為例，設計文檔一般包括網(wǎng)站結構圖、線框圖和網(wǎng)頁描述表。產(chǎn)品設計文檔伴隨著產(chǎn)品整個生命周期，幫助產(chǎn)品團隊與研發(fā)團隊和高層領導達成共識，進而明確研發(fā)計劃和指導研發(fā)過程。不同的公司、不同的產(chǎn)品會有自己不同的要求和模板，但在這里我想提醒一些大家需要注意的地方。1.保持簡短對于產(chǎn)品設計文檔，保持簡短很重要，因為越是簡短，包含的錯誤越少，同時更容易閱讀，同時也越可能帶來簡潔的設計。但是一定要在窮盡的基礎上簡短，不要為了最求簡短而忽略一些細節(jié)，在產(chǎn)品設計中，每一個小細節(jié)對產(chǎn)品的質(zhì)量來說都很重要。所以一定要仔細思考，認真推敲。2.消滅錯誤錯誤的文檔會花費研發(fā)團隊大量的時間，甚至會導致大規(guī)模的改動，這時對研發(fā)來說沒有誰會很爽，一個個都恨不得把你給撕了。有點夸張了。但心里面絕對是一萬個“操尼瑪”！同時也會讓產(chǎn)品團隊在研發(fā)團隊面前抬不起頭。當然，也不用太想不開，畢竟沒有錯誤的文檔和沒有錯誤的代碼一樣，都是不存在的，我們需要做的是盡可能地消滅錯誤，讓錯誤能在可承受范圍內(nèi)。錯誤有很多種，有產(chǎn)品邏輯錯誤（最致命的），有多個需求相互矛盾的錯誤，還有錯別字等層面的低級錯誤。在撰寫產(chǎn)品設計文檔的時候，產(chǎn)品團隊因?qū)a(chǎn)品邏輯進行充分的討論和測試，最終要組織評審會議，采用審核通過的方式把關。3.別對他人（主要是研發(fā)人員）的工作指手畫腳也就是說在設計文檔中不要提一些技術性的東西。比如：將其存入數(shù)據(jù)庫的一個新表中，連續(xù)存放，以優(yōu)化查詢效率。別提之類的需求，你很可能犯一些細節(jié)上的錯誤。己所不欲，勿施于人，別人在你的領域內(nèi)指手畫腳你也會感到很煩。如果你是個技術專家，可以私下溝通，別把應該寫在技術文檔中的內(nèi)容寫在設計文檔里。4.用適當?shù)姆绞奖硎鲂枨筮x取適當?shù)姆绞秸宫F(xiàn)特定的信息，是產(chǎn)品經(jīng)理的一項重要技能，面對研發(fā)團隊的時候要用到，面對最終用戶的時候也會用到，怎樣去表現(xiàn)我們的需求讓研發(fā)或客戶能快速有效的理解是相當重要的，不僅可以提高工作效率，還可以避免很多因理解不當造成的錯誤。因理解不一致這種錯誤是很常見的，和不同領域類的人提需求理解不當更是家常便飯了，選用適當?shù)谋硎龇绞绞窍喈斨匾?。比如，用敘述性文字說不清楚我們就用表格或其他的，有時候還需要選擇一些圖形工具。5.使用肯定的語言在產(chǎn)品設計文檔中，使用肯定的、確切的語言，切勿出現(xiàn)“也許，可能”這類詞語。我們最終提交的文檔內(nèi)容都是確切的，可被執(zhí)行的，含糊不清的東西一定要全部消滅掉。如果有吃不準的東西，就放在內(nèi)部充分討論后在做決定。6.切勿忽視溝通很多產(chǎn)品新人在寫產(chǎn)品設計文檔的時候，獨自埋著頭寫，寫好了之后再出去溝通，這樣文檔有99%的概率會被大幅度修改，這等于是在做無用功，所以在寫設計文檔的時候千萬不要忽略和團隊溝通。四、功能詳述FSD功能詳細說明定義產(chǎn)品功能需求的全部細節(jié)，這是一份可以直接讓工程師創(chuàng)建產(chǎn)品的文檔。FSD建立在BRD、MRD和PRD的基礎上，從這步就開始往開發(fā)銜接了，產(chǎn)品UI、業(yè)務邏輯的細節(jié)都要確定，細化文檔并保持更新。功能需求是所有的產(chǎn)品功能的描述和規(guī)劃，以互聯(lián)網(wǎng)產(chǎn)品為例包括以下內(nèi)容。1.簡要說明介紹此功能的用途，包括其或背景，能夠解決哪些問題。2.場景描述產(chǎn)品在哪種情況下會被用戶使用，就是用戶場景模擬。這也是產(chǎn)品經(jīng)理講“好”故事的必備條件。3.業(yè)務規(guī)則每個產(chǎn)品在開發(fā)時都有相應的業(yè)務規(guī)則，將這些規(guī)則清晰地描述出來，讓開發(fā)、測試人員能夠直觀的明白該規(guī)則，且沒有產(chǎn)生歧義。業(yè)務規(guī)則必需是完整的、準確的、易懂的。業(yè)務規(guī)則的描述上如果涉及到頁面交互或者頁面的修改，建議給出頁面的草圖或者頁面截圖在圖上說明要修改的內(nèi)容。另外也建議對頁面的輸入框、下拉框的內(nèi)容格式、長度、控件之間的關聯(lián)性做出說明，什么時候可見、不可見、灰掉或點亮的條件在文檔中都給出說明，方便閱讀者理解業(yè)務規(guī)則。4.界面原型如前所述，涉及到頁面交互的部分，產(chǎn)品經(jīng)理需要設計頁面原型。原型設計通常需要產(chǎn)品經(jīng)理和UI設計師一起來完成。建議的做法是，產(chǎn)品經(jīng)理可設計一個頁面框架，將該頁面要呈現(xiàn)的字段及其特征以及頁面要使用的場景向交互設計師解釋清楚，之后交互和視覺設計師完成產(chǎn)品的原型設計。5.使用者說明對產(chǎn)品使用者做出說明，可融入簡要說明中。6.前置條件該需求實現(xiàn)依賴的前提條件。比如，上傳照片時，需要存有圖像的文件。7.后置條件操作后引發(fā)的后續(xù)處理。8.主流程把主流放在最后是有道理的，結合上面所說的，做出主流程說明，對每個功能流程走向分點說明（這是非常重要的）?？催^很多的PRD（包含F(xiàn)SD），文檔中對既沒有前提條件，也沒有后置條件，只對主流程做了說明，但是在描述主流程時卻沒有描寫主流程中每個功能流程的各種走向，只有一個主走向，讓人感覺PRD成了操作手冊。事實上，對分支的介紹是非常重要的，開發(fā)和測試中提出的各類問題均與對分支的定義不明有關。一個合格的PRD不僅要描述主流程，同時對分支流程所出現(xiàn)的各類問題都要做詳細闡述并給出解決辦法。PRD的特征一定是明確的、全面的闡述需求及各類