1、需求階段 

a,、需求產(chǎn)生,。需求產(chǎn)生有三種渠道：

一，UI（User Interface用戶界面）設(shè)計(jì)師或PD（Product Desiger產(chǎn)品策劃）研究市場需要,，提出需求,，應(yīng)獲得市場策劃或市場調(diào)研員的認(rèn)可；

二,，業(yè)務(wù)部門提出需求,，包含總經(jīng)理、研究部,、內(nèi)容編輯部,、客服部、展業(yè)部,、市場部等部門,。

三，UI或PD研究用戶,，提出需求,。此步驟需提供用戶習(xí)慣報(bào)告，體驗(yàn)?zāi)繕?biāo),，用戶訪談,、調(diào)研,，流量數(shù)據(jù)統(tǒng)計(jì)等作為依據(jù)，不得憑空想象,。

所有需求需經(jīng)過PD,。不經(jīng)PD的需求，技術(shù)部門有權(quán)拒絕開發(fā),，也沒有人為需求負(fù)責(zé),。即使不需進(jìn)行策劃和設(shè)計(jì)，也應(yīng)提交給PD備案,。

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

MRD需明確傳達(dá)產(chǎn)品需求的目的和目標(biāo),，指出什么樣的新產(chǎn)品,、方案和服務(wù)為什么可以在市場上或者內(nèi)部取得成功，以及希望取得怎樣的成功,。MRD說明“是什么”和“為什么”,，但不要寫“如何”（即不要包含流程圖和原型圖）。

當(dāng)產(chǎn)品需求為高優(yōu)先級（即項(xiàng)目立項(xiàng)）時(shí),，需求方必須提供MRD文檔,。產(chǎn)品需求的優(yōu)先級、權(quán)重和是否立項(xiàng)由項(xiàng)目實(shí)施委員會確定,，日常需求由委員會負(fù)責(zé)人確定,，非常規(guī)需求開會確定。個(gè)別小修改甚至不需PRD,，可由PD與技術(shù)部門直接溝通完成,。

c、需求評審,。PD接到顯性需求后,，應(yīng)仔細(xì)透徹地分析需求方的真正意圖。有時(shí)候需求方的想法不一定正確,，也有些是突然的想法并不可行,，PD需進(jìn)行判斷；當(dāng)這種情況出現(xiàn)時(shí),，PD有權(quán)提出自己的解決方法,，包括否定需求。因判斷失誤造成需求沖突,、重復(fù)開發(fā)等情況,，責(zé)任由PD承擔(dān)。當(dāng)發(fā)生爭執(zhí),，由PM（Product Manager產(chǎn)品經(jīng)理）協(xié)調(diào)解決,。PD完成需求評審后,，需告知需求方完成PRD的時(shí)間、產(chǎn)品開發(fā)的預(yù)估難度及完成工期,。此步驟必須,。

2、策劃階段 

a,、PRD（Product Requirement Document產(chǎn)品需求文檔）,。PRD側(cè)重對產(chǎn)品產(chǎn)品功能和性能的說明，相對于MRD中的同樣內(nèi)容,，要更加詳細(xì),，并進(jìn)行量化。PRD一般包含流程圖,、原型圖等,，使用用例等手段，以準(zhǔn)確說明,。若無MRD,，則PRD需對目標(biāo)進(jìn)行說明。PRD為必須經(jīng)過的步驟,，由PD或UI完成。PRD需進(jìn)行編號,，編號規(guī)則詳見“需求編碼”表格,。

b、專家評審,。需求方,、相關(guān)領(lǐng)域的顧問（即有豐富經(jīng)驗(yàn)者）、PD或UI參與的評審PRD的會議,，一般項(xiàng)目經(jīng)理,、PM需參與會議。若項(xiàng)目較大,，需邀請總經(jīng)理參與,。會議必須有主持，并在會后出MEMO（備忘）或PRD更新說明,。專家評審結(jié)束后,，PD出設(shè)計(jì)結(jié)果方案，需求方簽字確認(rèn),。程序員接到PRD方案后,，需評估完成開發(fā)的大致時(shí)間，以及任務(wù)分解安排,。當(dāng)需要GUI方案作為輔助判斷時(shí),，需明確提出,。

c、交互DEMO,。ID（Interaction Designer交互設(shè)計(jì)師）根據(jù)PRD定稿做出交互設(shè)計(jì)方案,，真實(shí)再現(xiàn)用戶交互過程，并與PD,、UI進(jìn)行內(nèi)部評審,。視情況，PM參與,。（因公司沒有ID,，此步驟由PD與美工，視覺設(shè)計(jì)師,，口頭溝通完成）

d,、視覺界面。由美工（視覺設(shè)計(jì)師）設(shè)計(jì)頁面風(fēng)格,、布局,、關(guān)鍵界面等，交由PD,、UI,、ID進(jìn)行內(nèi)部GUI（Graphical User Interface圖形使用者接口）評審。GUI方案通過后,，頁面制作師開始切割頁面,，編寫HTML。

3,、開發(fā)階段 

a,、后臺編碼。在編碼之前,，程序員應(yīng)視其系統(tǒng)需要,，進(jìn)行概要設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì),，并進(jìn)行內(nèi)部討論和評審,，邀請顧問參與。程序員對文檔有疑問或不理解,，需與PD進(jìn)行溝通,，了解其真實(shí)涵義，不得以任何理由私自更改已確定的PRD,、GUI方案,。確有功能需做調(diào)整，程序員需與PD、需求方共同協(xié)商完成,。改動(dòng)應(yīng)出具文檔,，由需求方、技術(shù)經(jīng)理,、PM簽字后生效,。

b、α（alpha最初）測試,。在開發(fā)小組內(nèi)部進(jìn)行,，測試的方法也較多，黑盒,、白盒,、  壓力、應(yīng)力等,。此階段應(yīng)完成80%以上的需求開發(fā),，測試以PRD為準(zhǔn)。測試完成后,，收集反饋,，修復(fù)BUG，優(yōu)化流程,。開發(fā)者在場,。

c、β（beta第二次）測試,。有選擇地請一些最終用戶實(shí)際使用,，將發(fā)現(xiàn)的問題反饋，開發(fā)者對系統(tǒng)進(jìn)行最后的修改,，之后準(zhǔn)備發(fā)布最終產(chǎn)品。β測試開發(fā)者不在場,。產(chǎn)品估算開發(fā)時(shí)間,，以完成β測試為準(zhǔn)。

d,、產(chǎn)品發(fā)布,。β測試后，PD校驗(yàn)產(chǎn)品,。如產(chǎn)品與策劃方案相差較大,，有權(quán)不接受產(chǎn)品，責(zé)任由開發(fā)部門負(fù)責(zé),。將產(chǎn)品發(fā)布日設(shè)為里程碑,，以此考核整個(gè)項(xiàng)目的運(yùn)作效率。

4,、校驗(yàn)階段 

a,、發(fā)布跟蹤,。產(chǎn)品上線后，PD或市場調(diào)研員負(fù)責(zé)收集用戶操作數(shù)據(jù),，檢測各個(gè)反饋渠道,，篩選數(shù)據(jù)，出具用戶檢測報(bào)告,，檢驗(yàn)產(chǎn)品改進(jìn)是否達(dá)到預(yù)期目標(biāo),。立項(xiàng)產(chǎn)品應(yīng)專門出具報(bào)告，非立項(xiàng)改動(dòng)需在數(shù)據(jù)分析報(bào)告中體現(xiàn),。

source:互聯(lián)網(wǎng)產(chǎn)品時(shí)代