移動APP項目研發(fā)流程及版本規(guī)劃

3 評論 214636 瀏覽 258 收藏 9 分鐘

一個移動APP項目研發(fā)規(guī)??纱罂尚。茧x不開以下幾個成員:產品經理、ui設計師、前端開發(fā)、后端開發(fā)、測試等。如何合理安排項目成員工作、確保項目順利進行呢?一個清晰合理的項目研發(fā)流程控制很重要。

項目研發(fā)流程一般來說分3個階段

第一階段:需求策劃。

在需求階段產品經理內部進行需求討論:討論下版本需求重點是什么,做什么功能,怎么做。通過反復調研、討論、輸出交互方案。

確認需求可行性:產品在輸出交互方案后找相應的開發(fā)討論需求方案是否可行,這個討論階段產品和開發(fā)的思維方式不同,往往會擦出新火花、新驚喜;但討論控制不好或者會演化為產品和程序員的撕逼大戰(zhàn),呵呵。

UI設計:設計師將產品的交互方案變得更生動精美,不過精美的設計稿不見得都能實現(xiàn)出來。在這個過程中產品經理需要協(xié)調設計師和前端人員的溝通,制定設計規(guī)范。同時保證設計稿的質量,出稿進度。需求宣講:產品經理將交互方案和實現(xiàn)邏輯完善以及將上版本的bug、其他優(yōu)化需求等整合出完整的版本需求文檔后,拉上項目所有成員宣講。宣講目的主要讓項目成員清楚新版本需求的重點是什么,做什么功能,為什么做(重點講);簡單介紹怎么做,講解交互方案或設計稿,給大家有一個整體的印象,讓大家都了解版本功能的意義。

第二階段:需求研發(fā)。

項目啟動:需求宣講后,開發(fā)根據產品需求文檔進行需求評審,評估出研發(fā)周期、提測時間、預發(fā)布時間點、正式發(fā)布時間點。

產品根據評審結果發(fā)送項目啟動郵件。研發(fā):需求研發(fā)過程中,產品跟進研發(fā)進度,保持與開發(fā)溝通確保需求被正確理解,及時解決研發(fā)過程中發(fā)現(xiàn)的新問題。測試用例:產品、測試、開發(fā)共同確認版本測試用例,并同步研發(fā)過程中變更的需求和細節(jié)。

提測:產品驗收開發(fā)輸出的功能模塊,并輸出體驗回歸文檔;測試根據用例驗證需求邏輯,提bug、優(yōu)化給開發(fā)。內網環(huán)境測試通過后,測試繼續(xù)驗證預發(fā)布環(huán)境、正式環(huán)境。

第三階段:版本發(fā)布。

客服培訓:測試驗證的過程中,版本發(fā)布前,產品提前給客服培訓新版本內容。

發(fā)布:后端開發(fā)、運維人員將代碼發(fā)布外網環(huán)境,前端輸出外網正式包。產品運營將正式包上傳各大安卓市場或ios -appstore提審。

升級:所有安卓渠道包更新好,或者appsore審核通過,新版本也沒有發(fā)現(xiàn)什么問題時,后端開發(fā)和運營人員打開升級配置,并發(fā)送升級通知。運營報告:版本發(fā)布完畢還未算完呢,運營人員在新版本發(fā)布后,收集用戶反饋,進行數據監(jiān)測、數據分析;評估新版本功能效果和影響,驗證新版本功能以及輸出下版本需求開發(fā)和優(yōu)化建議。

 

從以上APP項目研發(fā)流程來看,每一個版本研發(fā)都要經歷以上3個階段12環(huán)節(jié),理論圖上看是一條完整的流水線,但是如何保證流程順暢進行?如何使項目成員工作效率最大化?這十分考驗產品經理/項目經理的版本規(guī)劃能力。當然項目成員間的默契和溝通也很重要。

從筆者實踐經驗來看,要保證流水線順暢,理想情況產品需求文檔要領先前端開發(fā)2個版本,設計領先前端開發(fā)1個版本,后端開發(fā)領先前端開發(fā)半個版本。即在當前項目啟動同時,產品經理已經在調研討論下下版本需求;設計開始搞下版本的稿子;當前項目進行到一大半時,后端已經完成當前版本的需求,并開始準備下版本的需求預研。

版本規(guī)劃是產品經理根據需求優(yōu)先級和開發(fā)進度預估定出來的,即每個版本要做什么,重點是什么,研發(fā)時間,上線時間等。一般來說,項目每發(fā)布一個版本都應該有它的意義和主打功能。

App首個版本相對來說時間較長:app需要搭配開發(fā)環(huán)境,確定app技術框架,以及研發(fā)各種基礎系統(tǒng)等。像這樣時間較長的版本研發(fā),產品經理和技術在需求評估時要將開發(fā)需求分階段進行并且設置里程碑(盡量不超過3個),在每個里程碑(最長不超過1周)時間點,產品經理需要確認完成的情況,發(fā)現(xiàn)問題及時調整研發(fā)計劃,控制項目風險,保證項目如期完成。

后續(xù)開發(fā)的每一個版本都應該至少有一個重要功能,版本研發(fā)周期最好控制在2周-3周內。這樣的好處一方面是保證項目成員有個良好的開發(fā)節(jié)奏,使研發(fā)效率最大化;另一方面保證每個版本有新東西給到用戶體驗,以及符合各大市場申請首發(fā)條件,獲得免費的推廣資源(ps:一般首發(fā)活動可以獲得幾千到幾萬的免費用戶,還是挺吸引的)。當然重大功能上線的話,確保上線后版本的穩(wěn)定性,可以將研發(fā)周期延至1個月,或者進行灰度發(fā)布。要盡量避免安排超過一個月研發(fā)周期的版本,否則要將長版本設置為若干個里程碑驗收。經驗來看研發(fā)周期過長往往會導致研發(fā)技術人員精力分散,工作拖沓,積極性下降。

一般情況不建議頻繁發(fā)布小版本,因為每個版本發(fā)布都需要測試,打包,發(fā)布市場,發(fā)升級配置和升級提醒等。頻繁發(fā)布小版本造成測試和運營重復性工作增加,造成資源浪費;用戶側看頻繁的升級提醒也是件很討厭的事情。另外,建議外網運營客戶端版本最多不要超過4個。維護老版本成本還是比較高的,比如做新功能還要考慮新老版本兼容情況,和各種后臺數據接口升級、更新的兼容問題等。

在特殊的情況下,有緊急的bug和漏洞時,才建議緊急發(fā)布一個bugfix版本。

#專欄作家#

Genies,閨蜜圈產品經理,人人都是產品經理專欄作家。擅長產品策劃,產品運營,項目管理。專注于移動社交方向,深度調研女性社交;關注O2O電商、智能硬件、物聯(lián)網發(fā)展。厚積薄發(fā),總結,升華中…

本文系作者授權發(fā)布,未經許可,不得轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. Good

    來自上海 回復
  2. 寫得很淺顯,沒有任何收獲

    來自北京 回復