互聯(lián)網產品各階段的標準流程文檔
[導讀]1、需求階段 a、需求產生。需求產生有三種渠道: 一,UI(User Interface用戶界面)設計師或PD(Product Desiger產品策劃)研究市場需要,提出需求,應獲得市場策劃或市場調研員的認可; 二,業(yè)務部門提出需求,包含總經理、研究部、內容編輯部、客服部、展
1、需求階段?
a、需求產生。需求產生有三種渠道:
一,UI(User Interface用戶界面)設計師或PD(Product Desiger產品策劃)研究市場需要,提出需求,應獲得市場策劃或市場調研員的認可;
二,業(yè)務部門提出需求,包含總經理、研究部、內容編輯部、客服部、展業(yè)部、市場部等部門。
三,UI或PD研究用戶,提出需求。此步驟需提供用戶習慣報告,體驗目標,用戶訪談、調研,流量數據統(tǒng)計等作為依據,不得憑空想象。
所有需求需經過PD。不經PD的需求,技術部門有權拒絕開發(fā),也沒有人為需求負責。即使不需進行策劃和設計,也應提交給PD備案。
b、MRD(Market Requirements Document市場需求文檔)。
MRD需明確傳達產品需求的目的和目標,指出什么樣的新產品、方案和服務為什么可以在市場上或者內部取得成功,以及希望取得怎樣的成功。MRD說明“是什么”和“為什么”,但不要寫“如何”(即不要包含流程圖和原型圖)。
當產品需求為高優(yōu)先級(即項目立項)時,需求方必須提供MRD文檔。產品需求的優(yōu)先級、權重和是否立項由項目實施委員會確定,日常需求由委員會負責人確定,非常規(guī)需求開會確定。個別小修改甚至不需PRD,可由PD與技術部門直接溝通完成。
c、需求評審。PD接到顯性需求后,應仔細透徹地分析需求方的真正意圖。有時候需求方的想法不一定正確,也有些是突然的想法并不可行,PD需進行判斷;當這種情況出現(xiàn)時,PD有權提出自己的解決方法,包括否定需求。因判斷失誤造成需求沖突、重復開發(fā)等情況,責任由PD承擔。當發(fā)生爭執(zhí),由PM(Product Manager產品經理)協(xié)調解決。PD完成需求評審后,需告知需求方完成PRD的時間、產品開發(fā)的預估難度及完成工期。此步驟必須。
2、策劃階段?
a、PRD(Product Requirement Document產品需求文檔)。PRD側重對產品產品功能和性能的說明,相對于MRD中的同樣內容,要更加詳細,并進行量化。PRD一般包含流程圖、原型圖等,使用用例等手段,以準確說明。若無MRD,則PRD需對目標進行說明。PRD為必須經過的步驟,由PD或UI完成。PRD需進行編號,編號規(guī)則詳見“需求編碼”表格。
b、專家評審。需求方、相關領域的顧問(即有豐富經驗者)、PD或UI參與的評審PRD的會議,一般項目經理、PM需參與會議。若項目較大,需邀請總經理參與。會議必須有主持,并在會后出MEMO(備忘)或PRD更新說明。專家評審結束后,PD出設計結果方案,需求方簽字確認。程序員接到PRD方案后,需評估完成開發(fā)的大致時間,以及任務分解安排。當需要GUI方案作為輔助判斷時,需明確提出。
c、交互DEMO。ID(Interaction Designer交互設計師)根據PRD定稿做出交互設計方案,真實再現(xiàn)用戶交互過程,并與PD、UI進行內部評審。視情況,PM參與。(因公司沒有ID,此步驟由PD與美工,視覺設計師,口頭溝通完成)
d、視覺界面。由美工(視覺設計師)設計頁面風格、布局、關鍵界面等,交由PD、UI、ID進行內部GUI(Graphical User Interface圖形使用者接口)評審。GUI方案通過后,頁面制作師開始切割頁面,編寫HTML。
3、開發(fā)階段?
a、后臺編碼。在編碼之前,程序員應視其系統(tǒng)需要,進行概要設計、數據庫設計,并進行內部討論和評審,邀請顧問參與。程序員對文檔有疑問或不理解,需與PD進行溝通,了解其真實涵義,不得以任何理由私自更改已確定的PRD、GUI方案。確有功能需做調整,程序員需與PD、需求方共同協(xié)商完成。改動應出具文檔,由需求方、技術經理、PM簽字后生效。
b、α(alpha最初)測試。在開發(fā)小組內部進行,測試的方法也較多,黑盒、白盒、??壓力、應力等。此階段應完成80%以上的需求開發(fā),測試以PRD為準。測試完成后,收集反饋,修復BUG,優(yōu)化流程。開發(fā)者在場。
c、β(beta第二次)測試。有選擇地請一些最終用戶實際使用,將發(fā)現(xiàn)的問題反饋,開發(fā)者對系統(tǒng)進行最后的修改,之后準備發(fā)布最終產品。β測試開發(fā)者不在場。產品估算開發(fā)時間,以完成β測試為準。
d、產品發(fā)布。β測試后,PD校驗產品。如產品與策劃方案相差較大,有權不接受產品,責任由開發(fā)部門負責。將產品發(fā)布日設為里程碑,以此考核整個項目的運作效率。
4、校驗階段?
a、發(fā)布跟蹤。產品上線后,PD或市場調研員負責收集用戶操作數據,檢測各個反饋渠道,篩選數據,出具用戶檢測報告,檢驗產品改進是否達到預期目標。立項產品應專門出具報告,非立項改動需在數據分析報告中體現(xiàn)。
source:互聯(lián)網產品時代
“PRD需進行編號,編號規(guī)則詳見“需求編碼”表格?!鼻笮枨缶幋a表格。Email:kathie@tripper.com.cn
言簡意賅
不錯的文章
我想找個專業(yè)的產品經理怎么就那么難呢!求產品經理的蘿卜!
發(fā)錯編輯掉
不錯,必須點贊
不進行產品的整體架構設計么?
不錯
很清楚……