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