轉：互連網產品開發流程

標籤：des   blog   http   io   os   使用   ar   資料   div   

互連網產品開發流程

對於稍微大一點的互連網產品都要有精心部署和安排才行，否則項目進行的將會一塌糊塗。
先說一說都有哪些崗位和開發所用的軟體：
PD（產品策劃）：word,visio,Axure
PM（產品經理）：EasyMind
ID（互動設計師）：Axure, Photoshop
VD（視覺設計師）：Phtotoshop, Illustrator
WD（前端開發工程師）：Photoshop, Dreamweaver
DEV（後端開發工程師）：Dreamweaver, MyEclipse

再說說MRD（Market Requirements Document市場需求文檔）吧，MRD需明確傳達產品需求的目的和目標，指出什麼樣的新產品、方案和服務為什麼可以在市場上或者內部取得成功，以及希望取得怎樣的成功。MRD說明“是什麼”和“為什麼”，但不要寫“如何”（即不要包含流程圖和原型圖）。當產品需求為高優先順序（即項目立項）時，需求方必須提供MRD文檔。產品需求的優先順序、權重和是否立項由項目實施委員會確定，日常需求由委員會負責人確定，非常規需求開會確定。

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

接下來就應該是開發人員做PRD（Product Requirement Document產品需求文檔），PRD側重對產品產品功能和效能的說明，相對於MRD中的同樣內容，要更加詳細，並進行量化。PRD一般包含流程圖、原型圖等，使用用例等手段，以準確說明。也就是說從做PRD文檔時就是已經進入準備開發階段，這時MRD文檔應該很明確了。

接下來大家開會討論PRD方案，參與討論的應該有需求方、相關領域的顧問（即有豐富經驗者）、PD或UI，並做好記錄。接下來PD出設計結果方案，需求方簽字確認。程式員接到PRD方案後，需評估完成開發的大致時間，以及任務分解安排。

ID（Interaction Designer互動設計師）根據PRD定稿做出互動設計方案，真實再現使用者互動過程（工作室一般用強大的axure），並與PD、UI進行內部評審。視情況，PM參與，做完後要與需求方反覆交流直到需求方滿意。

接下來VD（視覺設計師）根據axure做出的原型，進行設計頁面風格、布局、關鍵介面等。和使用者交流對頁面設計是否滿意。

WD（前端開發工程師）根據設計頁面切圖，編寫HTML，CSS，JS原始碼。

下面就進入了後台開發階段，在編碼之前，程式員應視其系統需要，進行概要設計、資料庫設計，並進行內部討論和評審。程式員對文檔或原型有疑問或不理解，需與PD和ID進行溝通，瞭解其真實涵義，不得以任何理由私自更改已確定的PRD文檔方案。確有功能需做調整，程式員需與PD、需求方共同協商完成。改動應出具文檔，由需求方、技術經理、PM同意。每個人寫的代碼都不可能完全正確，這樣就需要邊開發邊測試。
α（alpha最初）測試。在開發小組內部進行，測試的方法也較多，黑盒、白盒、 壓力、應力等。此階段應完成80%以上的需求開發，測試以PRD和原型為準。測試完成後，收集反饋，修複BUG，最佳化流程。

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


產品上線後可能還存在一些bug，這就需要後期的維護了。等產品穩定後就完成了這次開發

轉：互連網產品開發流程