專案研發流程一般來說分3個階段
第一階段：需求策劃。
在需求階段產品經理內部進行需求討論：討論下版本需求重點是什麼，做什麼功能，怎麼做。通過反覆調研、討論、輸出互動方案。
確認需求可行性：產品在輸出互動方案後找相應的開發討論需求方案是否可行，這個討論階段產品和開發的思維方式不同，往往會擦出新火花、新驚喜；但討論控制不好或者會演化為產品和程式設計師的撕逼大戰，呵呵。
ui設計：設計師將產品的互動方案變得更生動精美，不過精美的設計稿不見得都能實現出來。在這個過程中產品經理需要協調設計師和前端人員的溝通，制定設計規範。同時保證設計稿的質量，出稿進度。需求宣講：產品經理將互動方案和實現邏輯完善以及將上版本的bug、其他優化需求等整合出完整的版本需求文件後，拉上專案所有成員宣講。宣講目的主要讓專案成員清楚新版本需求的重點是什麼，做什麼功能，為什麼做（重點講）；簡單介紹怎麼做，講解互動方案或設計稿，給大家有乙個整體的印象，讓大家都了解版本功能的意義。
第二階段：需求研發。
專案啟動：需求宣講後，開發根據產品需求文件進行需求評審，評估出研發週期、提測時間、預發布時間點、正式發布時間點。
產品根據評審結果傳送專案啟動郵件。研發：需求研發過程中，產品跟進研發進度，保持與開發溝通確保需求被正確理解，及時解決研發過程中發現的新問題。測試用例：產品、測試、開發共同確認版本測試用例，並同步研發過程中變更的需求和細節。
提測：產品驗收開發輸出的功能模組，並輸出體驗回歸文件；測試根據用例驗證需求邏輯，提bug、優化給開發。內網環境測試通過後，測試繼續驗證預發布環境、正式環境。
第三階段：版本發布。
客服培訓：測試驗證的過程中，版本發布前，產品提前給客服培訓新版本內容。
從筆者實踐經驗來看，要保證流水線順暢，理想情況產品需求文件要領先前端開發2個版本，設計領先前端開發1個版本，後端開發領先前端開發半個版本。即在當前專案啟動同時，產品經理已經在調研討論下下版本需求；設計開始搞下版本的稿子；當前專案進行到一大半時，後端已經完成當前版本的需求，並開始準備下版本的需求預研。
版本規劃是產品經理根據需求優先順序和開發進度預估定出來的，即每個版本要做什麼，重點是什麼，研發時間，上線時間等。一般來說，專案每發布乙個版本都應該有它的意義和主打功能。
後續開發的每乙個版本都應該至少有乙個重要功能，版本研發週期最好控制在2周-3週內。這樣的好處一方面是保證專案成員有個良好的開發節奏，使研發效率最大化；另一方面保證每個版本有新東西給到使用者體驗，以及符合各大市場申請首發條件，獲得免費的推廣資源（ps：一般首發活動可以獲得幾千到幾萬的免費使用者，還是挺吸引的）。當然重大功能上線的話，確保上線後版本的穩定性，可以將研發週期延至1個月，或者進行灰度發布。要盡量避免安排超過乙個月研發週期的版本，否則要將長版本設定為若干個里程碑驗收。經驗來看研發週期過長往往會導致研發技術人員精力分散，工作拖沓，積極性下降。
一般情況不建議頻繁發布小版本，因為每個版本發布都需要測試，打包，發布市場，發公升級配置和公升級提醒等。頻繁發布小版本造成測試和運營重複性工作增加，造成資源浪費；使用者側看頻繁的公升級提醒也是件很討厭的事情。另外，建議外網運營客戶端版本最多不要超過4個。維護老版本成本還是比較高的，比如做新功能還要考慮新老版本相容情況，和各種後台資料介面公升級、更新的相容問題等。
在特殊的情況下，有緊急的bug和漏洞時，才建議緊急發布乙個bugfix版本。
專案研發流程及管理之我見
隨著工作年限的增長，我們從一開始負責乙個功能，再到負責乙個模組的資料字典及框架設計。再到負責整個系統的需求評審及架構設計。這一路見證著程式猿的成長。但當我們逐步成為一名架構師，或是一名專案管理人員時，會發現乙個專案的成功，會牽扯到各式各樣的問題及風險。無論是系統本身要相容快速發展的業務形態，還是由於...
軟體專案研發流程
前一點段時間參與了乙個公司的新專案，最近有時間開始總結一下專案的研發流程 研發流程大概分 為 6個部分可研性分析，需求分析，概要設計，詳細設計，程式編碼，測試，發布，下面就分別說一說這個幾個環節具體都幹什麼.可研性分析之後，確定產品，研發 技術leader和主程 測試同學，質量同學，需求方對接人進行...
移動app開發流程，app開發步驟
個人github 歡迎follow 隨著移動網際網路的普及，移動終端功能的日益完善，很多企業看重移動網際網路的重要，開始在這個領域完善自己的品牌，開展營銷活動。移動應用開發步驟1.規劃應用ui 移動應用開發步驟2.設計資料操作與儲存 移動應用開發步驟3.跳轉多頁面實現 移動應用開發步驟4.實現ser...