產(chǎn)品需求文檔是產(chǎn)品項(xiàng)目由“概念化”階段進(jìn)入到“圖紙化”階段的最主要的一個(gè)文檔，其作用就是“對(duì)MRD中的內(nèi)容進(jìn)行指標(biāo)化和技術(shù)化”，這個(gè)文檔的質(zhì)量好壞直接影響到研發(fā)部門是否能夠明確產(chǎn)品的功能和性能。

一、簡(jiǎn)述

產(chǎn)品需求文檔是產(chǎn)品人員非常核心的基本功！是協(xié)調(diào)研發(fā)、測(cè)試、UED、業(yè)務(wù)非常重要的重要工具。但是，往往很多新入行的PM與互聯(lián)網(wǎng)領(lǐng)域的PM，產(chǎn)出的文檔往往不盡人意，主要體現(xiàn)在：

• 缺乏邏輯，語(yǔ)言啰嗦不精練；
• 通俗的用詞過多，整體顯的不專業(yè)；
• 無(wú)法將字段的數(shù)據(jù)結(jié)構(gòu)、邏輯關(guān)系清晰的表達(dá)出來(lái)；
• 缺乏開發(fā)思維；

而出現(xiàn)這種原因在于：

• 新人入職，沒有經(jīng)過嚴(yán)謹(jǐn)?shù)奈臋n撰寫、流程設(shè)計(jì)訓(xùn)練；
• 大多數(shù)的PM非研發(fā)出身，對(duì)前后臺(tái)的業(yè)務(wù)邏輯、數(shù)據(jù)結(jié)構(gòu)了解不清晰；
• 分工細(xì)，版本迭代迅速，對(duì)功能點(diǎn)理解不夠透徹；

完善的產(chǎn)品需求文檔，不但利于PM對(duì)所承接的功能進(jìn)行有效的管控，將業(yè)務(wù)邏輯梳理清晰，對(duì)分解的功能點(diǎn)，進(jìn)行協(xié)調(diào)測(cè)試、研發(fā)、設(shè)計(jì)、運(yùn)營(yíng)同時(shí)開展工作；

模塊化的功能點(diǎn)（倒?fàn)敭?dāng)年做的一個(gè)功能）

雖然，不同的公司擁有不同的產(chǎn)品需求文檔模板！但，不論模板格式如何，文檔的本質(zhì)在于：“有效的將功能清晰的表達(dá)出來(lái)，并且能支撐后續(xù)的業(yè)務(wù)交接與版本迭代參考，對(duì)上與下進(jìn)行價(jià)值傳遞。”并且，隨著平臺(tái)業(yè)務(wù)的發(fā)展，歸檔、倉(cāng)儲(chǔ)起來(lái)的業(yè)務(wù)文檔，便是極其有價(jià)值的知識(shí)庫(kù)，里面匯總了各個(gè)時(shí)期里PM、研發(fā)、測(cè)試、項(xiàng)目經(jīng)理、設(shè)計(jì)….對(duì)業(yè)務(wù)是如何進(jìn)行思考，對(duì)文檔研究的本身，側(cè)面也反應(yīng)了企業(yè)是如何將戰(zhàn)略進(jìn)行細(xì)節(jié)落實(shí)。

而，“業(yè)務(wù)描述、功能描述、其它需求”是組成產(chǎn)品需求文檔非常重要的模塊；本篇章，將以通用版的角度，對(duì)這些模塊行介紹；

二、業(yè)務(wù)描述

任何的業(yè)務(wù)或需求，都有業(yè)務(wù)提出方，業(yè)務(wù)提出是相關(guān)的業(yè)務(wù)部門或產(chǎn)品經(jīng)理自身。

業(yè)務(wù)來(lái)源的本質(zhì)，便是希望通過這個(gè)業(yè)務(wù)解決那些實(shí)際的問題，達(dá)到提升某些轉(zhuǎn)化率或某些目的；業(yè)務(wù)描述清晰的表達(dá)出來(lái)即可，不需要多復(fù)雜，但常規(guī)包括：

• 業(yè)務(wù)背景
• 產(chǎn)品功能概述
• 產(chǎn)品前景分析
• 產(chǎn)品功能整體流程
• 產(chǎn)品邏輯關(guān)系
• 面向?qū)ο?/li>
• 應(yīng)用對(duì)象
• 名詞解釋
• 參考文檔

上述的這些層面，以通用版的角度，將產(chǎn)品的價(jià)值傳遞給研發(fā)方與業(yè)務(wù)方，實(shí)現(xiàn)之間有效的銜接。

為什么，我們需要進(jìn)行業(yè)務(wù)、功能、概述這些偏宏觀不實(shí)際的描述呢？這樣不是很麻煩，且浪費(fèi)時(shí)間？

我們要知道，每新增或刪除一個(gè)功能，狹義來(lái)看也沒啥大不了。但站在宏觀的角度去看，功能研發(fā)是需要耗資企業(yè)運(yùn)營(yíng)成本。如果處理不完善，浪費(fèi)運(yùn)營(yíng)成本同時(shí)，甚至影響整個(gè)用戶體驗(yàn)與開發(fā)規(guī)則。

身為產(chǎn)品人員在未傳達(dá)產(chǎn)品的業(yè)務(wù)價(jià)值前提條件下，便強(qiáng)勢(shì)驅(qū)動(dòng)研發(fā)人員進(jìn)入開發(fā)階段，這是錯(cuò)誤的！我要是研發(fā)，我也會(huì)拍死這位PM。那么業(yè)務(wù)描述的本質(zhì)便很清晰了，便將業(yè)務(wù)價(jià)值，傳遞給團(tuán)隊(duì)成員。

另一方面，非常多的企業(yè)，內(nèi)部的項(xiàng)目流程是不完善的，且并非每一位研發(fā)人員都是善類。產(chǎn)品經(jīng)理往往需要兼?zhèn)渲?xiàng)目經(jīng)理的職責(zé)，推動(dòng)著項(xiàng)目實(shí)現(xiàn)研發(fā)上線。在這種情況下，如果業(yè)務(wù)價(jià)值描述不清晰，功能在開發(fā)與上線后出現(xiàn)問題，這個(gè)鍋?zhàn)⒍ㄊ且车摹?/p>

BTW，這些我就不都說(shuō)了，自己工作中慢慢積累！

下面，我對(duì)組成業(yè)務(wù)描述的組成元素進(jìn)行描述：

業(yè)務(wù)背景描述：

這里，你必須將業(yè)務(wù)提出方描寫出來(lái)，并且細(xì)致到業(yè)務(wù)方為什么將這個(gè)需求提出來(lái)！為什么？一方面，你要告訴研發(fā)人員，你為什么設(shè)計(jì)這個(gè)產(chǎn)品或功能，這個(gè)需求從來(lái)源到設(shè)計(jì)是有原因的。另一方面，拉上相關(guān)業(yè)務(wù)部門，你至少不是一個(gè)人在戰(zhàn)斗。

產(chǎn)品功能描述：

對(duì)當(dāng)前功能進(jìn)行概述，所設(shè)計(jì)的產(chǎn)品或功能的功能模塊，新增、完善、優(yōu)化那些產(chǎn)品功能；

產(chǎn)品前景描述：

本產(chǎn)品或功能，希望對(duì)那些轉(zhuǎn)化率指標(biāo)或?qū)崿F(xiàn)那些目的；

產(chǎn)品的整體流程：

Visio、Axure（Axure畫的流程圖好丑）。

通過而言，簡(jiǎn)單的需求將主業(yè)務(wù)流與邏輯關(guān)系流表達(dá)出來(lái)便可以；但涉及復(fù)雜的業(yè)務(wù)，便將產(chǎn)品或功能涉及的主要流程繪制出來(lái)；而流程目的，主要是清晰的將前后臺(tái)的邏輯關(guān)系與數(shù)據(jù)結(jié)構(gòu)表達(dá)出來(lái)；一方面方便開發(fā)理解業(yè)務(wù)與數(shù)據(jù)流，另一方面也方便產(chǎn)品人員梳理自身需求的業(yè)務(wù)邏輯；利于后續(xù)與研發(fā)進(jìn)行溝通。

具體的流程數(shù)量，根據(jù)業(yè)務(wù)的復(fù)雜程度決定，一般只需要將核心的流程繪制出來(lái)便可；

• 前臺(tái)：主要是交互、數(shù)據(jù)流程；
• 后臺(tái)：主要是業(yè)務(wù)邏輯判斷、數(shù)據(jù)流；

前后臺(tái)的流程湊在一起，能清晰的看到前后臺(tái)的模塊之間，是如何進(jìn)行耦合的，數(shù)據(jù)儲(chǔ)存、提取、處理、分析。

功能框架：

Mindjet Minmanager、Xmind畫的框架圖好丑。

框架圖的意義在于，能讓查看或了解業(yè)務(wù)的人，全方位的了解功能之間的功能點(diǎn)的邏輯關(guān)系。同時(shí)，一份優(yōu)秀的框架圖，能讓PM站在全局的基本面上，對(duì)個(gè)人所負(fù)責(zé)的產(chǎn)品進(jìn)行全局的規(guī)劃，對(duì)前后臺(tái)的功能進(jìn)行把握，達(dá)到支撐平臺(tái)業(yè)務(wù)。

• 產(chǎn)品架構(gòu)：對(duì)前后臺(tái)的各個(gè)系統(tǒng)與管理模塊的邏輯關(guān)系，一般是對(duì)業(yè)務(wù)極其熟悉的業(yè)務(wù)構(gòu)架師與資深的產(chǎn)品總監(jiān)搭建，里面涉及每個(gè)接口如何進(jìn)行對(duì)接耦合。
• 功能架構(gòu)：所負(fù)責(zé)的產(chǎn)品或功能的前后臺(tái)功能的邏輯關(guān)系，簡(jiǎn)單點(diǎn)的就是一個(gè)產(chǎn)品或功能的前后臺(tái)，大一點(diǎn)就是一個(gè)系統(tǒng)涉及的功能點(diǎn)之間的耦合。
• 功能框架：功能點(diǎn)所涉及的邏輯關(guān)系。
• 功能結(jié)構(gòu)：功能點(diǎn)所涉及的邏輯關(guān)系。

而“架構(gòu)、框架、結(jié)構(gòu)”區(qū)分在于，所負(fù)責(zé)的業(yè)務(wù)究竟有多大。但不論如何，它們的表現(xiàn)的原理是一致的。將分解的功能點(diǎn)，之間是如何聯(lián)系的功能結(jié)構(gòu)關(guān)系清晰、簡(jiǎn)練的表達(dá)即可。

關(guān)于架構(gòu)，包含“功能分解、面向用戶”就夠用了。若再深入，可將分為：“應(yīng)用對(duì)象、BI分析（BI需求也寫上去）、系統(tǒng)集成….”。后續(xù)可根據(jù)BI數(shù)據(jù)，對(duì)產(chǎn)品進(jìn)行版本迭代與優(yōu)化。

面向?qū)ο?/strong>