產(chǎn)品需求文檔的寫作(一) – 寫前準備(信息結(jié)構(gòu)圖)
當(dāng)我們初次接觸產(chǎn)品需求文檔時,首先會從網(wǎng)絡(luò)上尋找產(chǎn)品需求文檔模板,希望從中了解和學(xué)習(xí)具體的寫作要求,但實際上,現(xiàn)在網(wǎng)絡(luò)上絕大部分的PRD文檔都是與實際工作不相符的,或者說是復(fù)雜的。 前幾天一位從事產(chǎn)品類工作的朋友,發(fā)來一份他寫的產(chǎn)品需求文檔目錄截圖給我(下圖),當(dāng)時我就郁悶了,這些類目更像是MRD文檔,而不是PRD文檔了,因此我決定寫幾篇講述寫作PRD文檔的文章,分享一些我關(guān)于PRD文檔的見解和寫作方法。 PRD是英文Product Requirement Document的縮寫,中文的意思是產(chǎn)品需求文檔,具體的名詞介紹大家可以詢問Google。PRD文檔是基于BRD、MRD的延續(xù)文檔,主要用于產(chǎn)品設(shè)計和開發(fā)使用,因此閱讀這份文檔的人群絕大多數(shù)是設(shè)計與技術(shù)人員。在這類人群中,設(shè)計師更多依賴于原型進行交互或視覺的設(shè)計,因此看這份文檔的人就會偏向于技術(shù)人員。相對于技術(shù)人員,他們不太關(guān)注產(chǎn)品的商業(yè)需求和市場愿景,因為在進行產(chǎn)品討論立項時,產(chǎn)品的定義就已經(jīng)向參與設(shè)計和研發(fā)的人員宣講過,因此技術(shù)人員更多的是關(guān)注界面、功能、交互、元素等等內(nèi)容,因此PRD文檔是一份詳細的產(chǎn)品功能需求說明文檔,是產(chǎn)品文檔中最底層和最細致的文檔。 PRD文檔是一份沒有閑話,直入主題的功能說明文檔,因此我們在寫作時,腦海里構(gòu)思的是成品產(chǎn)品的界面功能的邏輯線框圖。在寫作這份文檔前,我們需要先做一些準備,把BRD、MRD的相關(guān)需求消化并融合規(guī)劃出產(chǎn)品的結(jié)構(gòu)圖。因為這些準備工作是屬于思維類的,所以我推薦使用思維導(dǎo)圖軟件(MindManager)進行規(guī)劃工作。 規(guī)劃產(chǎn)品的第一步就是梳理出產(chǎn)品的信息結(jié)構(gòu),有了信息結(jié)構(gòu)我們才能繼續(xù)往下規(guī)劃產(chǎn)品結(jié)構(gòu),并且信息結(jié)構(gòu)是服務(wù)端技術(shù)人員創(chuàng)建數(shù)據(jù)庫的依據(jù),是數(shù)據(jù)結(jié)構(gòu)的輔助文件。對于新產(chǎn)品或者新功能,沒有人能夠比產(chǎn)品經(jīng)理更加清楚所需要的信息內(nèi)容了,因此第一步我們就需要先將這些信息羅列出來,形成結(jié)構(gòu)化。(如下圖) 這張圖是以我的博客作為示例,在羅列信息結(jié)構(gòu)時,我們更多的是考慮信息數(shù)據(jù),因此在這一步,我們還不需要深入的考慮產(chǎn)品的界面與功能。信息結(jié)構(gòu)的考慮有面向前端的,也有面向后端的,具體視產(chǎn)品類型而定。 例如CMS之類的程序,這類程序采用框架式開發(fā),將功能與模板獨立,因此前端具有多變性,并且這類產(chǎn)品屬于平臺型產(chǎn)品。針對這類產(chǎn)品,我們在規(guī)劃信息結(jié)構(gòu)時,只需要簡單的考慮一些前端的功能需求,更多的是面向后端管理員操作進行考慮,從后端入手規(guī)劃和羅列出所需要的信息內(nèi)容結(jié)構(gòu)。 無論是什么樣的產(chǎn)品類型,無論從哪里入手,我們第一步都是先要羅列信息結(jié)構(gòu),因為信息結(jié)構(gòu)圖不僅是輔助技術(shù)人員創(chuàng)建數(shù)據(jù)庫的圖表,也是輔助產(chǎn)品人員進行產(chǎn)品功能規(guī)劃的參考,只有對信息或數(shù)據(jù)的結(jié)構(gòu)了解,我們才能玩轉(zhuǎn)數(shù)據(jù),玩轉(zhuǎn)產(chǎn)品。 在信息結(jié)構(gòu)轉(zhuǎn)數(shù)據(jù)結(jié)構(gòu)時,如果是針對已經(jīng)存在的產(chǎn)品而增加的新功能,那么技術(shù)人員就需要根據(jù)這個信息結(jié)構(gòu)進行數(shù)據(jù)庫對比,已經(jīng)存在的數(shù)據(jù)便直接調(diào)用,如果不存在,則就需要具體的討論,確定新信息的使用途徑和以后的擴展方向,以便確認是創(chuàng)建數(shù)據(jù)表還是創(chuàng)建數(shù)據(jù)字段。(雖然產(chǎn)品經(jīng)理不需要技術(shù)開發(fā),但是如果能夠懂技術(shù)原理和數(shù)據(jù)庫原理,非常有助于產(chǎn)品規(guī)劃和技術(shù)溝通。) 信息結(jié)構(gòu)圖是產(chǎn)品層面的理解,如果要入庫這些信息,還需要進行數(shù)據(jù)結(jié)構(gòu)的討論。一條信息的存儲有很多附加屬性,具體是存成字段還是數(shù)據(jù)表,還是說存在中間表或者關(guān)聯(lián)表,這些都需要在完成PRD文檔后和數(shù)據(jù)庫技術(shù)人員共同討論。討論時除了展示信息結(jié)構(gòu)圖,還要講解產(chǎn)品原型和功能需求,以便數(shù)據(jù)庫技術(shù)人員了解產(chǎn)品意圖,方便他們做數(shù)據(jù)庫規(guī)劃時考慮到以后的擴展。 信息結(jié)構(gòu)圖是我們將概念想法形成結(jié)構(gòu)化的第一步,也是我們接下來幾步工作的輔助文件,同時在接下來的幾步工作中,我們還會不斷的完善信息的結(jié)構(gòu)。 下一篇我將講解如何梳理產(chǎn)品需求,并根據(jù)信息結(jié)構(gòu)規(guī)劃出產(chǎn)品結(jié)構(gòu)圖和用戶流程圖。 產(chǎn)品需求文檔(PRD)的寫作:
產(chǎn)品需求文檔(PRD)的寫作方法(文章的摘要介紹)
產(chǎn)品需求文檔的寫作(一) – 寫前準備(信息結(jié)構(gòu)圖)
產(chǎn)品需求文檔的寫作(二) – 梳理需求(產(chǎn)品結(jié)構(gòu)圖和用戶流程圖)
產(chǎn)品需求文檔的寫作(三) – 原型設(shè)計(手繪原型,灰模原型,交互原型)
產(chǎn)品需求文檔的寫作(四) – 撰寫文檔(PRD文檔)
產(chǎn)品需求文檔的寫作(五) – 用例文檔(UML用例圖、流程圖)
本文出自 產(chǎn)品經(jīng)理 唐杰
現(xiàn)有房子的模塊框架,也就是功能,后再來設(shè)計對應(yīng)的房子每個模塊對應(yīng)的裝飾,也就是信息(字段)
先有
很棒的解釋
就是模塊和元素的關(guān)系
小白1號提問:”信息結(jié)構(gòu)圖不考慮界面和功能”,我想請問,以手機淘寶首頁為例,我們是先做出產(chǎn)品功能結(jié)構(gòu)圖還是產(chǎn)品信息結(jié)構(gòu)圖?
如果直接在功能結(jié)構(gòu)的不變動的情況下直接寫信息圖,這樣可行嗎?
別人的都是業(yè)務(wù)流程-功能流程-頁面流程,跟數(shù)據(jù)庫相關(guān)的(比如信息結(jié)構(gòu)圖)都是靠后設(shè)計的,不懂樓主的第一步梳理信息結(jié)構(gòu)圖的內(nèi)涵?
業(yè)務(wù)路程和信息架構(gòu)哪個先行呢?
非常好的教程,感謝分享! ??
好
風(fēng)險分析不是在BRD里面的嗎? ??
不是啊
真的很有用,以前做東西有時候不畫流程圖和結(jié)構(gòu)圖,經(jīng)常思維混亂,忘東忘西的,而且經(jīng)常把信息結(jié)構(gòu)圖和產(chǎn)品結(jié)構(gòu)圖混在一起,看起來很麻煩,你說的很清楚明白,謝謝樓主啦
這篇東西不是@唐杰 寫的么?
我看過他博客有。。。而且這里放的圖品也是@唐杰。。。
好吧~我錯了
終于看到文章最后一行字
轉(zhuǎn)載別人的內(nèi)容,然后要贊賞,我想不明白····