初期的需求分析文檔如何寫?
本文是一個“小白版”的需求分析文檔,主要結合“會務管理系統 – 會議報名模塊”的產品案例,對需求文檔的框架展開了詳細說明,與大家分享。
本文的“初期需求分析文檔”不是產品經理工作中輸出的產品需求說明書(prd),是為初期用研后的資料整理后進行輸出的(更落地的需求分析),文檔格式除了通用部分,都有相對的調整,與市面上的文檔區(qū)別還是很多的;比如場景圖、及文檔內對業(yè)務及流程的落地說明,并非對企業(yè)內部協作使用的專業(yè)化文檔,本文檔主要用于初期的資料(數據)留痕。
如果文章中的文檔進行深度分析,就會專業(yè)化,進而演變成需求分析文檔(專業(yè)化:對內協作使用)、產品需求說明書(PRD)、概要設計等。
一、前言
本文從“會務管理系統 – 會議報名模塊”的產品案例,說明初期的需求分析文檔到底如何寫,如何更落地;讓自己及其他閱讀伙伴更清晰的認知產品的場景、業(yè)務、流程,一步步形成完整的產品閉環(huán),說用戶懂的話,交出一份“小白版”的需求分析文檔~
二、為什么寫小白版的需求文檔?
1. 文言文 PK 白話文
(1)“文言文”
很多產品人在初期產品調研后,做了信息收集及整理,輸出需求分析文檔,雖然這份文檔輸出是更好的鋪墊接下來的工作,但往往太過于官方,或者過于業(yè)務化,對于閱讀文檔的目標用戶沒有做到同理心,領導看不懂,協作伙伴看不懂,這樣的文檔,價值何在呢?
產品人輸出任何東西都要盡可能的有價值,而我們是最應該知道什么是價值的人,這對自己也是一種沉淀性的輸出。
os:閱讀文檔的目標用戶,這里面客戶也算其一(偏B端);在特殊情況下,文檔輸出的第一版是需要與用戶核對,敲定很多業(yè)務規(guī)范及流程中的細節(jié)。
(2)“白話文”
在做內容輸出時,謹記說人話,專業(yè)性語言少來,盡可能讓閱讀人員能夠“小白化”的讀懂,盡可能場景化,通俗易懂。
2. 明確文檔的用戶
不同角色(面向群體):
- 產品人:為產品部門內相關設計人員提供需求信息的展示,同時對自己為自查,對項目做留痕。
- 用戶/客戶:這里的客戶(B端)會與產品人進行輸出文檔的業(yè)務準確性做深入碰撞,敲定業(yè)務框架。
- 團隊成員:對接協作伙伴設計、程序;清晰明了,無需精細化宣講
3. 明白文檔價值
文檔價值(文檔目的)
- 輸出:把大腦中的構思落地出來,形成文檔,給自己做自查,給伙伴清晰的視野反饋。
- 留痕:把關鍵性的信息全部囊括在內,有可追溯性,對內對外皆可做到整個項目的管理。
4. 如何讓文檔更落地
讓文檔落地,我們首先要明白,寫文檔的本質是什么?
首先我們在輸出文檔時,對于我們目標用戶必須要明確,而不是太過自我,很多業(yè)務細節(jié)延伸出來的伴生性功能需要雕琢一下,這些伴生性功能是否符合業(yè)務流、是否優(yōu)化了業(yè)務流;
那么我們需要切換到用戶的業(yè)務場景視角,去發(fā)現這些是否真的是用戶需要的,圍繞著業(yè)務場景及各個角色進行輸出內容。
三、文檔框架
框架分四部分:通用部分、場景流程、需求集合、其他說明。
os:框架的四個部分是本人泛指,自我定義,大家可以自己調整自己的文檔框架
1. 通用部分
文檔目的:
- 閱讀者介紹:簡要說明閱讀用戶是誰即可,這里點明產品的使用用戶及角色做一個定義。
- 業(yè)務名稱解釋:對于項目中涉及的業(yè)務流程中出現的業(yè)務名詞做相應解釋。
項目綜述:
- 項目背景:圍繞整個項目的背景進行說明,著重描述業(yè)務場景。
- 項目范圍:業(yè)務場景中所涉及到的主線、支線業(yè)務流(模塊)全面覆蓋;這里包括伴生性(延伸性)需求。
- 項目目標:點出產品實現的目的,而不是產品人揣摩設計出來的(這里說的揣摩是指優(yōu)化性需求,并非實際需求)
so:此部分為需求分析模板的通用部分,不做舉例說明了;切記一點,盡可能讓這部分足夠落地的闡述;用戶閱讀文檔的第一部分就如同天書,后面也不會詳細去看。
2. 場景流程
業(yè)務流程:
(1)總(核心)業(yè)務流程
(2)業(yè)務流程說明
水務行業(yè)協會會務組織人員能在會務系統上編寫和發(fā)布會議通知、酒店信息、房間信息等。
參會人員能從電腦、手機上查看會議通知和報名,報名后可以在網站上繳費、訂房、填寫發(fā)票信息、網上簽到,其中這幾個部分的操作沒有任何強關聯和限制,不分先后。
業(yè)務流可以有以下幾種情況,例如:
- 參會人員報名后可以進行繳費,之后預定房間,網上簽到;
- 參會人員可以不繳費、直接預訂房間,網上簽到;
- 參會人員可以不繳費、不預定房間,直接網上簽到;
- 參會人員可以報名后直接去現場簽到;
- 參會人員可以不提前報名,直接到現場簽到,一同辦理:報名、繳費、訂房、現場簽到多項內容。
其中現場簽到前進行網上簽到是有好處的,簽到后可以查看最新的會議動態(tài)。不進行網上簽到的必須現場簽到后才可以查看會議動態(tài);
現場簽到后,就可以按照分配的房間,辦理入住。并且領取資料和查看最新會議動態(tài)。最新會議動態(tài)可以在網頁上和手機上查看,內容包括:最新議程、酒店信息變更、房間信息更新等。
應用終端:Web、wap、H5;
業(yè)務場景:
1)前臺:會務管理系統中,前臺的用戶角色以及對應業(yè)務模塊的交互關系;
如下圖:
2)后臺:在會務管理后臺中,用戶可分為五類
- 會務組領導:會務組的領導一般只需要查詢信息,看會議的報名、繳費、簽到等情況。后續(xù)還會增加統計功能。
- 會務組信息編輯人員:主要是在會前編輯會議通知,會中發(fā)布通知變更,會后查看報名、繳費信息,退款審核等。
- 會務組現場服務人員:主要負責現場簽到,查看、修改報名及繳費信息,會后負責退款的審核等。
- 會議組財物人員:主要查看繳費和發(fā)票信息,更改繳費狀態(tài),按照退款審核結果完成退款等操作。
- 信息錄入人員:線下報名過多,會務組人員需要協助錄入時就需要本角色的進入,主要負責錄入報名和繳費的信息。如需要也可錄入簽到信息。
如下圖:
3. 需求合集
根據業(yè)務需求而來的模塊,以前臺“網上報名”為例,舉例說明。
每一模塊的結構是這樣的:
(1)業(yè)務流程圖:
(2)需求說明
參會人員可以通過手機、電腦瀏覽看到會議通知,點擊報名入口,進入報名流程;報名通道選擇:網站的原始會員可以通過會員通道報名,不是會員的用戶可以通過非會員通道報名
1)會員報名:
如果已經是本站的會員,可通過會員登錄的通道進入報名頁面;登錄方式可以支持會員賬號和手機號。
會員登錄后可以根據情況選擇,是要“為自己報名”還是“為他人報名”。
會員登錄后可以為自己報名,填寫相應的報名信息即可完成報名。
報名信息包括:會員賬號、姓名、性別、手機號、單位、職位、省市信息、是否入住、是否接受拼房、是否參觀等信息,以上信息都為必填項。
本次需要優(yōu)化的內容,主要是針對系統在使用過程中,遇到的一些問題;
具體如下:
- 有些人報名時填寫的手機號碼是明顯錯誤的,現在填寫的信息有“1”、“11111111”、“ajdiwk”等情況,希望可以提高準確率,比如可以限制位數、數字驗證等方法。
- 頁面中“姓名”的位置有填寫單位名稱或多人姓名的情況,希望本次優(yōu)化中可以減少此種情況的發(fā)生。由于參會人員中會有少數民族的情況,名字字數比較長,根據以往報名人的名字長度分析,一般都在8個漢字以內。
- 很多人的性別和拼房信息是錯誤的,因為現在的方式是有一個默認選項,部分人就直接略過不去選擇了,提交后也可報名成功,很容易被忽略。希望去掉現在的默認選項,必須選擇才可以通過。
- 為了實現報名情況按照省、市統計的功能,報名信息中還需要增加省市的信息,最好用下拉選擇的方式。
- 會員報名信息中需要帶入本會員已有的相關信息。
報名成功后希望可以收到短信提醒,說明報名的基本情況,內容可包含會議名稱、會議地點、會議時間等內容。
注:關于會員的登錄方式,現在是會員賬號登錄;現有的會員注冊包括兩種情況,一部分是用戶自己注冊的,另一部分是我們的工作人員錄入注冊的,這部分主要是為了增加會員數量,這種情況下更不容易記住用戶名和密碼,下次登錄就成了問題,所以我們采取后置關聯的方式,關聯用戶基本信息,如:手機號碼、姓名及相關信息進行識別關聯,覆蓋之前用戶信息;這樣用戶便可以使用手機號碼登錄。
為他人報名
會員登錄后還可以選擇為他人報名,選擇“為他人報名”后,填寫參會人的報名信息即可完成報名。報名完成后還可以繼續(xù)為他人報名,直到將所有需要參會的人員都報完為止。
2)非會員報名
如果還不是本網站的會員,可以選擇非會員報名的通道進行報名。
非會員報名要實現不用注冊和登錄,只要通過驗證即可進行報名。
報名人需要填寫的信息包括姓名、單位、手機號碼,需要驗證身份方可通過。比如,可以通過手機號碼進行驗證,此處需要提示填寫正確的手機號碼,以便收取驗證碼等等。
為了讓非會員報名成功后,能夠查詢自己的報名信息并增加網站的會員數量,非會員報名成功后應按照所填寫的手機號碼生成一個新的會員賬號,報名人可以用此賬號登錄本網站,并收到“新賬號”的短信提醒,希望新賬號的初始密碼是簡單的數字。
此時報名人已經成為會員,后續(xù)的操作與會員報名基本相同;可以根據情況選擇,是要“為自己報名”還是“為他人報名”。
不一一舉例了……等
4. 其他說明
此部分為“數據說明”(記錄與業(yè)務相關的資料及樣式)。
例如:報名單(原線下使用)、回執(zhí)單、會議小條、發(fā)票信息、現場簽到表。
“會議小條”數據項包括序號、繳費金額、房間類型、數量、資料份數、房間號碼;樣式如下:
現場簽到表;樣式如下:
四、總結
一個小白能看的懂的需求分析文檔,要搞定三點
- 先明白文檔讀者是誰,對癥下藥,不盲目揣測、預言;設計經驗固然有用,但請慎用,不要自以為,要用戶以為。
- 文檔呈現的內容一定要夠落地,讓任何一個用戶看見之后,能夠清晰知道這個產品是做什么的,解決什么問題,存在的價值是什么。
- 模板!模板!模板!任何一個文檔模板都是可以自行定義的,你的工作方式不同,文檔輸出內容就一定會存在差異,以上模板只是一個舉例,可以自己雕琢一番。
些許經驗分享
很多產品人都很清楚,在過往經歷中,一定存在這樣的場景,需求到手,沒有形成內容落地,直接進行設計;這里可能存在各種外在因素(項目緊急、趕進度、對行業(yè)深究不足,過于盲目…等)導致這一環(huán)節(jié)遺失,直接從需求過度到功能框架、原型設計;這可以理解,但不要掉以輕心,畢竟這是對原始需求的一種留痕。
在簡單點說,可以把這個“小白版”的需求分析文檔,當做一次會議記錄,用最簡單,最直白的大白話記錄下來,未來翻過來看看,非常清晰的知道,當初的需求是什么,而不是資料的一層層翻閱。
每日一語
年少的時日從我身邊滑過,而我從來不知道,那已是生活;
珍惜我們每一次的努力,每一次需求的探索,都是對未知的渴望,也是對自己的沉淀。
作者:逐流;微信公眾號:Unique先森說產品(ID:Unique_Mr_z)
本文由 @逐流 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議
很有幫助,謝謝
這個好像也不是需求分析文檔,還是個功能說明的文檔…前期的分析工作都沒有體現出來
很好