互聯(lián)網產品各階段的標準流程文檔

11 評論 165598 瀏覽 366 收藏 7 分鐘

[導讀]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)網產品時代

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. “PRD需進行編號,編號規(guī)則詳見“需求編碼”表格?!鼻笮枨缶幋a表格。Email:kathie@tripper.com.cn

    來自安徽 回復
  2. 言簡意賅

    來自北京 回復
  3. 不錯的文章

    來自廣東 回復
  4. 我想找個專業(yè)的產品經理怎么就那么難呢!求產品經理的蘿卜!

    來自北京 回復
  5. 發(fā)錯編輯掉

    來自廣東 回復
  6. 不錯,必須點贊

    來自北京 回復
  7. 不進行產品的整體架構設計么?

    來自美國 回復
  8. 不錯

    來自廣東 回復
  9. 很清楚……

    來自安徽 回復