互連網產品各階段的標準流程文檔

標籤：

1、需求階段 

a、需求產生。需求產生有三種渠道：

一，UI（User Interface使用者介面）設計師或PD（Product Desiger產品策劃）研究市場需要，提出需求，應獲得市場策劃或市場調研員的認可；

二，業務部門提出需求，包含總經理、研究部、內容編輯部、客服部、展業部、市場部等部門。

三，UI或PD研究使用者，提出需求。此步驟需提供使用者習慣報告，體驗目標，使用者訪談、調研，流量資料統計等作為依據，不得憑空想象。

所有需求需經過PD。不經PD的需求，技術部門有權拒絕開發，也沒有人為需求負責。即使不需進行策劃和設計，也應提交給PD備案。

b、MRD（Market Requirements Document市場需求文檔）。

MRD需明確傳達產品需求的目的和目標，指出什麼樣的新產品、方案和服務為什麼可以在市場上或者內部取得成功，以及希望取得怎樣的成功。MRD說明“是什麼”和“為什麼”，但不要寫“如何”（即不要包含流程圖和原型圖）。

當產品需求為高優先順序（即項目立項）時，需求方必須提供MRD文檔。產品需求的優先順序、權重和是否立項由項目實施委員會確定，日常需求由委員會負責人確定，非常規需求開會確定。個別小修改甚至不需PRD，可由PD與技術部門直接溝通完成。

c、需求評審。PD接到顯性需求後，應仔細透徹地分析需求方的真正意圖。有時候需求方的想法不一定正確，也有些是突然的想法並不可行，PD需進行判 斷；當這種情況出現時，PD有權提出自己的解決方案，包括否定需求。因判斷失誤造成需求衝突、重複開發等情況，責任由PD承擔。當發生爭執，由 PM（Product Manager產品經理）協調解決。PD完成需求評審後，需告知需求方完成PRD的時間、產品開發的預估難度及完成工期。此步驟必須。

 

2、策劃階段 

a、PRD（Product Requirement Document產品需求文檔）。PRD側重對產品產品功能和效能的說明，相對於MRD中的同樣內容，要更加詳細，並進行量化。PRD一般包含流程圖、原 型圖等，使用用例等手段，以準確說明。若無MRD，則PRD需對目標進行說明。PRD為必須經過的步驟，由PD或UI完成。PRD需進行編號，編號規則詳 見“需求編碼”表格。

b、專家評審。需求方、相關領域的顧問（即有豐富經驗者）、PD或UI參與的評審PRD的會議，一般專案經理、PM需參與會議。若項目較大，需邀請 總經理參與。會議必須有主持，並在會後出MEMO（備忘）或PRD更新說明。專家評審結束後，PD出設計結果方案，需求方簽字確認。程式員接到PRD方案 後，需評估完成開發的大致時間，以及任務分解安排。當需要GUI方案作為輔助判斷時，需明確提出。

c、互動DEMO。ID（Interaction Designer互動設計師）根據PRD定稿做出互動設計方案，真實再現使用者互動過程，並與PD、UI進行內部評審。視情況，PM參與。（因公司沒有ID，此步驟由PD與美工，視覺設計師，口頭溝通完成）

d、視覺介面。由美工（視覺設計師）設計頁面風格、布局、關鍵介面等，交由PD、UI、ID進行內部GUI（Graphical User Interface圖形使用者介面）評審。GUI方案通過後，頁面製作師開始切割頁面，編寫HTML。

 

3、開發階段 

a、後台編碼。在編碼之前，程式員應視其系統需要，進行概要設計、資料庫設計，並進行內部討論和評審，邀請顧問參與。程式員對文檔有疑問或不理解， 需與PD進行溝通，瞭解其真實涵義，不得以任何理由私自更改已確定的PRD、GUI方案。確有功能需做調整，程式員需與PD、需求方共同協商完成。改動應 出具文檔，由需求方、技術經理、PM簽字後生效。

b、α（alpha最初）測試。在開發小組內部進行，測試的方法也較多，黑盒、白盒、  壓力、應力等。此階段應完成80%以上的需求開發，測試以PRD為準。測試完成後，收集反饋，修複BUG，最佳化流程。開發人員在場。

c、β（beta第二次）測試。有選擇地請一些終端使用者實際使用，將發現的問題反饋，開發人員對系統進行最後的修改，之後準備發布最終產品。β測試開發人員不在場。產品估算開發時間，以完成β測試為準。

d、產品發布。β測試後，PD校正產品。如產品與策劃方案相差較大，有權不接受產品，責任由開發部門負責。將產品發布日設為裡程碑，以此考核整個項目的運作效率。

 

4、校正階段 

 

a、發布跟蹤。產品上線後，PD或市場調研員負責收集使用者操作資料，檢測各個反饋渠道，篩選資料，出具使用者檢測報告，檢驗產品改進是否達到預期目標。立項產品應專門出具報告，非立項改動需在資料分析報告中體現。

 

互連網產品各階段的標準流程文檔