剛?cè)胄械漠a(chǎn)品新人,你其實可以寫一份合格產(chǎn)品需求文檔

22 評論 95182 瀏覽 1187 收藏 15 分鐘

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

一、簡述

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

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

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

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

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

20160605154019

模塊化的功能點(倒爺當年做的一個功能)

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

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

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

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

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

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

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

為什么,我們需要進行業(yè)務(wù)、功能、概述這些偏宏觀不實際的描述呢?這樣不是很麻煩,且浪費時間?

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

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

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

BTW,這些我就不都說了,自己工作中慢慢積累!

下面,我對組成業(yè)務(wù)描述的組成元素進行描述:

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

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

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

對當前功能進行概述,所設(shè)計的產(chǎn)品或功能的功能模塊,新增、完善、優(yōu)化那些產(chǎn)品功能;

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

本產(chǎn)品或功能,希望對那些轉(zhuǎn)化率指標或?qū)崿F(xiàn)那些目的;

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

Visio、Axure(Axure畫的流程圖好丑)。

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

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

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

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

功能框架:

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

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

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

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

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

面向?qū)ο?/strong>

表達產(chǎn)品或功能主要是為那類用戶服務(wù)的。將面向用戶是誰,擁有哪些權(quán)限清晰的表達出來即可,對個人進行功能設(shè)計也有很大的幫助。

應(yīng)用對象

本功能需要在那些應(yīng)用端或版本進行上線,清晰的描繪出來,方便后續(xù)進行業(yè)務(wù)交接。

名詞解釋

將本次文檔涉及一些奇葩的明詞進行解釋,這點很重要!有些PM喜歡將一些非常簡單的內(nèi)容包裝成非常牛逼,讓人看起來很難懂,而事實上也就做哪些一件簡單事,但是看的人會很痛苦:看PRD時會想:“這玩意,究竟想表達什么。

參考文檔

將所做的本次功能,所參考的那些文檔,附屬上來;目的的在于,方便后續(xù)的業(yè)務(wù)方、研發(fā)方進行查看。

三、功能描述

功能描述能否描寫清晰,描寫清晰,開發(fā)找茬都不怕了。如何才能完整的對功能點進行描述呢?圍繞三個點“功能是誰?功能來自哪里?功能要到哪里去?

同時,功能需求主要分為核心功能、其它功能。不論是核心功能還是其它功能,都可以由以下元素構(gòu)成:

  • 功能名稱
  • 面向用戶
  • 用例圖(Axure、mocking(適合移動端進行敏捷性開發(fā)))
  • 前置條件
  • 后置條件
  • 功能簡述
  • 詳情描述

而具體的功能描述內(nèi)容,則根據(jù)業(yè)務(wù)(功能點)的復雜程度,進行篩選描寫??梢匀珜?,也可以不全寫。但務(wù)必記住:不論何種方式,目的在于將業(yè)務(wù)價值完整、清晰、有條理的傳遞給查看文檔的參與角色。

功能名稱(我是誰)

本功能在系統(tǒng)里的命名。

面向用戶

本功能的使用對象。(在前臺,功能的參與者是少數(shù)的;但后臺與企業(yè)級應(yīng)用里,功能的參與者是多個的)

用例圖

表達功能在表現(xiàn)層的邏輯圖;可以是傳統(tǒng)意義上的用例圖,或者是簡化版的原型圖、流程圖;

前置條件(我來自哪里)

使用該功能的前提、邏輯關(guān)系說明;公司大了后,每個開發(fā)都只寫個人所負責的業(yè)務(wù),所以一定要將每個模塊來源都清清楚楚的表達出來,方便開發(fā)之間的銜接。

后置條件(我要到那里去)

使用該功能后,對業(yè)務(wù)、數(shù)據(jù)功能,產(chǎn)生的影響與結(jié)果;

功能簡述

描寫本功能需要實現(xiàn)的商業(yè)價值或目的;

詳情描述

將功能”我怎么來,我怎么去“清清楚楚的表達出來。變成計算機邏輯便是,頁面布局、操作邏輯進行詳細的說明。常規(guī)而言:

  • 前臺:主要是字段、交互邏輯組成;
  • 后臺:主要是判斷邏輯、列表表單、查詢條件、交互邏輯組成;

四、其它功能

其它功能目的在于,功能描述針對于本次產(chǎn)品功能的核心業(yè)務(wù),而其它功能針對于觸發(fā)或需要其它功能變動的業(yè)務(wù)。功能描述清晰的讓開發(fā)了解核心,而其它功能便讓開發(fā)清晰的了解非核心。

而其它功能,主要由以下內(nèi)容組成

其他接口

對其它系統(tǒng)產(chǎn)生“字段、業(yè)務(wù)流程”進行說明;本次產(chǎn)品或業(yè)務(wù),對前后臺那些非主流程模塊產(chǎn)生影響;

系統(tǒng)風險評估

當前設(shè)計的功能存在哪些缺陷、注意事項與后期的功能拓展如何解決這些問題;

其它需求

對一些非核心的功能點進行詳情描述。如:一些需過濾的關(guān)鍵字、新增某個欄目字段。

五、綜述

通過上述內(nèi)容,能以通用版的形式,清晰的將所負責產(chǎn)品與功能表達出來,而業(yè)務(wù)描述、功能描述、其它功能。是產(chǎn)品需求文檔重要的組成部份,將產(chǎn)品需求較為全面、有效的描述出來。

同時,能訓練PM邏輯思維,提升文字表達能力、業(yè)務(wù)理解能力,從整體上讓PM在需求管理上,明顯更加專業(yè),所負責功能的邏輯關(guān)系、數(shù)據(jù)流的來與去都能很好的把控。

六、附語

不論是什么格式,倒爺堅持一個觀點,適合團隊才是好的模板。當前很多的公司在進行MVP迭代的時候會使用Axure+內(nèi)容描述的形式。雖然,這種形式,是很難將邏輯關(guān)系表達清晰,同時會有非常多的思維漏洞。在進行文檔歸檔時,也很難對根據(jù)關(guān)鍵字進行檢索。但,確實挺適合進行MVP迭代,出現(xiàn)問題修改起來也方便,這種方式比較適合項目流程完善的企業(yè)平臺使用。

而在敏捷性開發(fā)匯總,倒爺習慣流程圖+功能框架(功能點)+Axure(原型圖繪制),從核心的業(yè)務(wù)流開始,逐漸迭代至功能完善,這個過程也將文檔補齊。

但有些公司會在EXCEL里進行需求文檔撰寫,進行版本管理(這個也不錯)。

但,作為新人,需要記?。耗隳軐憦碗s的東西,簡單的東西也能能寫;但當然一開始只寫簡單的東西,那你一輩子只能做簡單的東西。

大道至簡,簡難而繁易;經(jīng)歷過復雜的訓練與要求,才能簡化再簡化。

 

作者:倒爺,微信:ftl_keen。

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 回復
  2. 非常詳細,感謝作者,今天剛好是寫第一份需求文檔,清晰很多

    來自廣東 回復
  3. 回復
  4. 黃晶晶?

    回復
  5. 那么好,已加,謝謝!

    來自北京 回復
    1. ?? ?? ?? ?? ??

      來自廣東 回復
  6. 延伸閱讀:http://theventurebank.com/pmd/354258.html

    來自廣東 回復
  7. 但是開發(fā)的朋友們一般只會看設(shè)計稿。數(shù)據(jù)邏輯全靠口口相傳。 ?

    來自上海 回復
    1. 真相 ?

      來自上海 回復
    2. +10086

      來自廣東 回復
  8. 人人都是產(chǎn)品經(jīng)理大把需求模板和案例,可以搜搜看。

    回復
    1. ?? ?? ?? ??

      來自廣東 回復
  9. 你好,倒爺001頭像是貓咪??

    回復
  10. 其實講這么多,能給一份正式的需求文檔模板才是是最好、最直接能學到知識的。

    來自廣東 回復
    1. 實在

      來自湖北 回復
    2. 我也覺得

      回復
  11. 微信搜索到的不是公眾號 而是個人微信 頭像是貓 是這個嗎 謝謝親

    來自安徽 回復
  12. 邏輯清晰,對于新人只要按照模塊寫,基本就能梳理清晰,贊!

    來自江蘇 回復
  13. 準備進入這個行業(yè)新手一個,都不知道怎么寫

    回復
  14. 希望有一個合格的范文展示,想寫但是還沒寫過很想看看別人是怎么寫的。

    來自北京 回復
  15. ??

    來自廣東 回復