【人人圓桌】第六期 產品需求文檔PRD模版
人人圓桌
人人圓桌是在群討論的基礎上,通過篩選人員、限制討論時間的一種討論模式,以達到幫助新人成長、發散思路和學習交流的目的;而且因圓桌討論的特殊性,也能在討論中暴露出一些工作和思維上的問題,避免工作時再次犯錯。
規則介紹
人人圓桌開啟時間為每月第二個周四晚上20:30,歷時60分鐘。圓桌主題確定后會提前在眾多報名者中,選擇10名合適的成員單獨建群討論。
圓桌主題則在圓桌招募初期即公布,成員在獲知主題內容后都有思考、收集資料的時間,但不允許私下討論。
圓桌時間僅有一個小時,無論是否得出結果都必須結束。因而對參與者的思維能力、話題把控能力、溝通能力、時間管理等都是一大挑戰。
本期話題
對于產品經理來說最重要的三個需求文檔是商業需求文檔、市場需求文檔和產品需求文檔,而關于文檔的模板資料,質量卻參差不齊。本次討論選取產品需求文檔作為討論的話題,讓大家在圓桌討論中分享各位關于產品需求文檔寫作思路的干貨。
任務目標
針對一個工具類App應用(以zaker為例),設計一個合理、可用、完整的產品需求文檔模板。
圓桌記錄
2014年11月13日晚8點30分,經歷了嚴格篩選的產品老鳥們開始了為期一小時的思維碰撞,力求解決“產品需求文檔到底該怎么寫“這一終極難題。
首先大家一致確認了PRD的重要性,積極的Phoenix拋出了一個可供大家討論的模版。
經過大家確認,一致認為效益成本分析是MRD中已經確認的內容,不應該在PRD中討論,所以去掉了效益成本分析這一塊。
接下來按順序分析
1.概述
關于概述大家都有不同的想法
Phoenix提出概述應該包括名詞說明;產品概述及目標;產品roadmap;產品風險,節奏提出既然是概述肯定要概括的說明產品的背景;產品的目標;產品的基本介紹等,基于經驗大家又發現需要對數據的進行部分說明增添了數據字典的模塊,需要對PRD的閱讀對象進行分工定義,增添了文檔閱讀對象。
發散思維的各種討論后,講概述確定為
1.1產品概述及目標—-包括背景介紹和產品目的
1.2名詞解釋—-聲明文檔中出現的名詞含義
1.3數據詞典—-介紹本產品中數據的數據項、數據結構、數據流、數據存儲、處理邏輯、外部實體等。
1.4文檔閱讀對象—-聲明本文檔輸出的閱讀對象和注意事項
確認了概述時已經時間用去三分之一,各大神明顯覺得時間過得好快。。。所以接下來的討論加快了速度,快速的確認接下來主要討論的內容:產品描述和功能描述。
?2.產品描述
討論完概述后,大家一致認為使用者需求這個詞語容易造成歧義且范圍過窄,所以將名稱改為了產品描述。
產品描述章節介紹了產品的整體邏輯流程,概括性的描述產品需求、產品版本規劃、產品整體的框架結構以及功能列表。產品整體流程與產品框架都需要使用相應的圖表展現方式
產品描述經過確認包括
2.1產品整體流程-—展示產品框架圖和用戶流程圖。
2.2產品需求描述—-描述產品核心功能,解決哪些情景下的哪些需求。
2.3產品版本規劃—-敘述產品版本迭代計劃,版本號、主要模塊、功能點、計劃開發時間、計劃結束時間、備注。
2.4產品框架—-展示頁面層級及備注信息
2.5功能列表—-展示產品功能名稱、對應模塊、功能說明、備注等信息。
3.功能描述
功能需求章節需詳細描述產品所涉及的各個功能點。將整體框架拆成數個獨立的功能點,分別描述每個功能點的邏輯流程圖、界面、字段說明以及業務說明。統一采用usercase方式進行描述。
這塊其實是pm比較熟悉的部分,所以基本上是大神們毫無歧義的就敲定了如下內容:
3.1流程圖
3.2界面
3.3字段說明(包括數據字典)
3.4業務說明(usercase)
此時 最初的PRD框架已經被細化為一個 有細化分支的 詳細框架,如下
此時時間已經過去四分之三,開始討論非功能需求、附錄及部分大家沒有之前想到的東西。
比較重要的是非功能需求和上下線需求及后續運營計劃。
4.非功能需求
關于非功能需求,大家的考慮又開始出現分歧,主要是由于各公司的定義不同,造成內容不同的差異化,總結了下大家提及到的是安全、可用性、伸縮性、數據統計、易用性、接口需求,通過溝通消除各公司的語義差別和部分理解偏差,最后提供了一個可供參考的、比較合適的非功能需求內容。
4.1安全需求
4.2統計需求
4.3性能需求
4.4可用性需求
此時已經接近尾聲,大家大致討論了下上下線需求的內容和運營計劃該寫的方向,加上其他聲明的附錄,產出了文檔。
最后的成型模版框架為:
寫在最后:
本次圓桌在篩選人員上進行了十分嚴格的人員把控,力求選取工作一線上經驗豐富的產品人員,通過圓桌討論的方式將接觸到的文檔進行還原與輸出,大家在討論中也表現出了經驗賦予產品經理的睿智,和產品經理應有的自檢自查,高效溝通的素質。一小時的討論過程是對自己經驗的總結、考驗,也希望產出的模板在以后的實際工作中能給大家帶來參考和指引。
更多圓桌
感謝人人都是產品經理以下成員參與討論(排名不分先后):
林維艱-產品-SH、節奏-產品-北京、Ted-PD-北京 、Phoenix、Lunatic-純潔-魔都、Jason-移動社交、Darrick-本地服務
感謝?Phoenix?童鞋整理文檔
感謝?Ted?童鞋產出總結文件
本文由人人都是產品經理原創,未經許可,禁止轉載。
產品小白,希望大家能給點幫助,這些名詞真的好繞。
1# 2.1和2.4的產品框架圖有什么區別?
2# 2.1的用戶流程圖是什么意思,用戶操作流程嗎?
3# 2.4的產品框架是指什么?頁面流程圖?還是信息架構/功能架構圖?
4# 3.1的流程圖是什么意思?是每個功能實現的詳細任務流程圖嗎?
5# 3.4的業務說明,是用例圖?還是業務流程圖?
已被自己繞暈……
我想問有多少PM會寫字段說明/數據字典???
我不會,頭一次聽說數據字典的概念 ?
就是數據表,mysql沒有聽過嗎?
聽說過,我做開發工具的也會寫代碼,但作為 PM 從來不需要寫數據表。
有沒有實例的需求文檔 能否發一份參考。
產品是若干版本迭代出來的,每個迭代版本都有需求文檔。這個文檔適合若干個版本之后的整理的基線文檔,不適合迭代過程中的需求文檔。
贊
請問2.1的產品框架圖和2.4的產品框架有什么區別?頁面層級的框架圖怎么畫
數據項、數據結構、數據流、數據存儲、處理邏輯、外部實體 怎么寫
http://wenku.baidu.com/link?url=BAyvtbnBzXXyWAMd-IuNqIy9L4H4lWnxG1KYoCXtJcpRU9pwn75ggrKsxizGggxxUN5lRPz3C8Mk8lGNX27KQ15zAiO0cqCc-fx88UTVk07
主要是高保真原型+特殊需求說明就可以了,這個文檔著實復雜
原型圖更重要點吧 交互和效果能很好地展示
這么寫,完全沒有考慮到程序員對需求的可讀性,要知道程序員根本沒有耐心看這些長篇大論,導致的最終結果是不按需求開發或者是要點遺漏,尤其是一個app只由一兩個程序員,并且隨時還要切換到其他項目開發的時候的時候…
你說的很有道理,很多程序員跟我抱怨還如看流程圖來著實在
所以為什么寫這個文檔的時候不加入流程圖?不是有產品整體流程嗎?
魚精說道 完全可以給實例的,別害羞
什么是安全需求?可否給個例子? ?
同求實例
能否給一個實例
[呵呵]
老婆買了大瓶的可樂,讓我擰開。我擰了一分鐘都沒反應,老婆說:你還是不是男人啊,這點力氣都沒有。我說:那你去找別人擰吧。老婆就抱著可樂去找隔壁王大哥,過了十五分鐘,隱隱約約聽到老婆在隔壁說:王大哥用力用力啊。呵呵,我心里樂了,都二十五分鐘了【微信號:今日爆笑排行榜】