(完整word版)產(chǎn)品上線流程

1、In terface 用戶界面）設(shè)計(jì)師或 PD （Product Desiger 產(chǎn)品策劃）研究市場(chǎng)需要，提出需求，應(yīng)獲得市場(chǎng)策劃或市場(chǎng)調(diào)研員的認(rèn)可；二， 業(yè) 務(wù)部門提出需求，包含總經(jīng)理、研究部、內(nèi)容編輯部、客服部、展產(chǎn)品開(kāi)發(fā) 四個(gè)階段1、需求階段 a、需求產(chǎn)生。需求產(chǎn)生有三種渠道: 一，UI（User In terface 用戶界面）設(shè)計(jì)師或 PD （ Product Desiger產(chǎn)品策劃）研究市場(chǎng)需要，提出需求，應(yīng)獲得市場(chǎng)策劃或市場(chǎng)調(diào)研員的 認(rèn)可；二，業(yè)務(wù)部門提出需求，包含總經(jīng)理、研究部、內(nèi)容編輯部、客服部、 展業(yè)1、需求階段 a、需求產(chǎn)生。需求產(chǎn)生有三種渠道:,UI (User畫求階段

2、開(kāi)發(fā)階段PRO產(chǎn)品需蕈文稍發(fā)布甩蹤MRD產(chǎn)品發(fā)布hit pc / f w w w J pt im e s.er需求產(chǎn)生部、市場(chǎng)部等部門。三，UI 或 PD 研究用戶，提出需求。此步驟需提供用戶習(xí)慣報(bào)告，體驗(yàn) 目標(biāo)，用戶訪談、調(diào)研，流量數(shù)據(jù)統(tǒng)計(jì)等作為依據(jù)，不得憑空想象。所有需求需經(jīng)過(guò) PD。不經(jīng) PD 的需求，技術(shù)部門有權(quán)拒絕開(kāi)發(fā)，也沒(méi) 有人為需求負(fù)責(zé)。即使不需進(jìn)行策劃和設(shè)計(jì)，也應(yīng)提交給 PD 備案。b、MRD （ Market Requirements Document市場(chǎng)需求文檔）。MRD 需明確傳達(dá)產(chǎn)品需求的目的和目標(biāo)，指出什么樣的新產(chǎn)品、方案 和服務(wù)為什么可以在市場(chǎng)上或者內(nèi)部取得成功，以

3、及希望取得怎樣的成功。MRD 說(shuō)明“是什么”和“為什么”，但不要寫“如何”（即不要 包含流程圖和原型圖）。當(dāng)產(chǎn)品需求為高優(yōu)先級(jí)（即項(xiàng)目立項(xiàng)）時(shí)，需求方必須提供 MRD 文檔。 產(chǎn)品需求的優(yōu)先級(jí)、權(quán)重和是否立項(xiàng)由項(xiàng)目實(shí)施委員會(huì)確定，日常需求由委員會(huì)負(fù)責(zé)人確定，非常規(guī)需求開(kāi)會(huì)確定。個(gè)別小修改甚至不需 PRD， 可由 PD 與技術(shù)部門直接溝通完成。c、需求評(píng)審。PD 接到顯性需求后，應(yīng)仔細(xì)透徹地分析需求方的真正意 圖。有時(shí)候需求方的想法不一定正確，也有些是突然的想法并不可行， PD 需進(jìn)行判斷；當(dāng)這種情況出現(xiàn)時(shí)，PD 有權(quán)提出自己的解決方法，包 括否定需求。因判斷失誤造成需求沖突、重復(fù)開(kāi)發(fā)等情況，責(zé)

4、任由PD承擔(dān)。當(dāng)發(fā)生爭(zhēng)執(zhí)，由 PM（ Product Manager 產(chǎn)品經(jīng)理）協(xié)調(diào)解決。 PD完成需求評(píng)審后，需告知需求方完成 PRD 的時(shí)間、產(chǎn)品開(kāi)發(fā)的預(yù)估 難度及完成工期。此步驟必須。2、策劃階段a、 PRD （ Product Requirement Document產(chǎn)品需求文檔）。PRD側(cè)重對(duì)產(chǎn)品產(chǎn)品功能和性能的說(shuō)明，相對(duì)于MRD 中的同樣內(nèi)容，要更加詳細(xì)，并進(jìn)行量化。PRD 一般包含流程圖、原型圖等，使用用例等 手段，以準(zhǔn)確說(shuō)明。若無(wú) MRD，貝 U PRD 需對(duì)目標(biāo)進(jìn)行說(shuō)明。PRD 為 必須經(jīng)過(guò)的步驟，由 PD 或 UI 完成。PRD 需進(jìn)行編號(hào)，編號(hào)規(guī)則詳見(jiàn)“需求編碼”表格。b

5、、 專家評(píng)審。需求方、相關(guān)領(lǐng)域的顧問(wèn)（即有豐富經(jīng)驗(yàn)者）、PD 或UI 參與的評(píng)審 PRD 的會(huì)議，一般項(xiàng)目經(jīng)理、PM 需參與會(huì)議。若項(xiàng)目 較大，需邀請(qǐng)總經(jīng)理參與。會(huì)議必須有主持，并在會(huì)后出MEMO （備忘）或 PRD 更新說(shuō)明。專家評(píng)審結(jié)束后，PD 出設(shè)計(jì)結(jié)果方案，需求方 簽字確認(rèn)。程序員接到 PRD 方案后，需評(píng)估完成開(kāi)發(fā)的大致時(shí)間，以 及任務(wù)分解安排。當(dāng)需要 GUI 方案作為輔助判斷時(shí)，需明確提出。c、 交互 DEMO。ID （Interaction Designer 交互設(shè)計(jì)師）根據(jù) PRD 定稿做出交互設(shè)計(jì)方案，真實(shí)再現(xiàn)用戶交互過(guò)程，并與 PD、UI 進(jìn)行內(nèi) 部評(píng)審。視情況，PM 參與

6、。（因公司沒(méi)有 ID，此步驟由 PD 與美工， 視覺(jué)設(shè)計(jì)師，口頭溝通完成）d、視覺(jué)界面。由美工（視覺(jué)設(shè)計(jì)師）設(shè)計(jì)頁(yè)面風(fēng)格、布局、關(guān)鍵界面等，交由 PD、UI、ID 進(jìn)行內(nèi)部 GUI （Graphical User In terface圖形使用者接口） 評(píng)審。 GUI 方案通過(guò)后， 頁(yè)面制作師開(kāi)始切割頁(yè)面， 編寫 HTML。3、開(kāi)發(fā)階段a、后臺(tái)編碼。在編碼之前，程序員應(yīng)視其系統(tǒng)需要，進(jìn)行概要設(shè)計(jì)、 數(shù)據(jù)庫(kù)設(shè)計(jì)，并進(jìn)行內(nèi)部討論和評(píng)審，邀請(qǐng)顧問(wèn)參與。程序員對(duì)文檔有 疑問(wèn)或不理解，需與 PD 進(jìn)行溝通，了解其真實(shí)涵義，不得以任何理由 私自更改已確定的 PRD、GUI 方案。確有功能需做調(diào)整，程序員需與

7、 PD、需求方共同協(xié)商完成。改動(dòng)應(yīng)出具文檔，由需求方、技術(shù)經(jīng)理、 PM 簽字后生效。b、a（alpha 最初）測(cè)試。在開(kāi)發(fā)小組內(nèi)部進(jìn)行，測(cè)試的方法也較多，黑盒、白盒、 壓力、應(yīng)力等。此階段應(yīng)完成 80%以上的需求開(kāi)發(fā)，測(cè) 試以 PRD為準(zhǔn)。測(cè)試完成后，收集反饋，修復(fù) BUG，優(yōu)化流程。開(kāi)發(fā)者在場(chǎng)。c、 B（beta 第二次）測(cè)試。有選擇地請(qǐng)一些最終用戶實(shí)際使用，將發(fā) 現(xiàn)的問(wèn)題反饋，開(kāi)發(fā)者對(duì)系統(tǒng)進(jìn)行最后的修改，之后準(zhǔn)備發(fā)布最終產(chǎn)品 卩測(cè)試開(kāi)發(fā)者不在場(chǎng)。產(chǎn)品估算開(kāi)發(fā)時(shí)間，以完成卩測(cè)試為準(zhǔn)。d、 產(chǎn)品發(fā)布。卩測(cè)試后，PD 校驗(yàn)產(chǎn)品。如產(chǎn)品與策劃方案相差較大， 有權(quán)不接受產(chǎn)品，責(zé)任由開(kāi)發(fā)部門負(fù)責(zé)。將產(chǎn)品發(fā)布日設(shè)為里程碑，以 此考核整個(gè)項(xiàng)目的運(yùn)作效率。4、校驗(yàn)階段a、發(fā)布跟