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

2015-8-14    周周

 

藍(lán)藍(lán)設(shè)計(jì)www.bouu.cn )是一家專注而深入的界面設(shè)計(jì)公司,為期望卓越的國內(nèi)外企業(yè)提供有效的UI界面設(shè)計(jì)、BS界面設(shè)計(jì) 、 cs界面設(shè)計(jì) 、 ipad界面設(shè)計(jì) 、 包裝設(shè)計(jì) 、 圖標(biāo)定制 、 用戶體驗(yàn) 、交互設(shè)計(jì)、 網(wǎng)站建設(shè) 、平面設(shè)計(jì)服務(wù)

如果您想訂閱本博客內(nèi)容,每天自動(dòng)發(fā)到您的郵箱中, 請(qǐng)點(diǎn)這里

一個(gè)移動(dòng)APP項(xiàng)目研發(fā)規(guī)模可大可小,但都離不開以下幾個(gè)成員:產(chǎn)品經(jīng)理、ui設(shè)計(jì)師、前端開發(fā)、后端開發(fā)、測試等。如何合理安排項(xiàng)目成員工作、確保項(xiàng)目順利進(jìn)行呢?一個(gè)清晰合理的項(xiàng)目研發(fā)流程控制很重要。

244174-c039f5dcd16b614e

項(xiàng)目研發(fā)流程一般來說分3個(gè)階段

第一階段:需求策劃。

在需求階段產(chǎn)品經(jīng)理內(nèi)部進(jìn)行需求討論:討論下版本需求重點(diǎn)是什么,做什么功能,怎么做。通過反復(fù)調(diào)研、討論、輸出交互方案。

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

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

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

項(xiàng)目啟動(dòng):需求宣講后,開發(fā)根據(jù)產(chǎn)品需求文檔進(jìn)行需求評(píng)審,評(píng)估出研發(fā)周期、提測時(shí)間、預(yù)發(fā)布時(shí)間點(diǎn)、正式發(fā)布時(shí)間點(diǎn)。

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

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

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

客服培訓(xùn):測試驗(yàn)證的過程中,版本發(fā)布前,產(chǎn)品提前給客服培訓(xùn)新版本內(nèi)容。

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

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

 

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

從筆者實(shí)踐經(jīng)驗(yàn)來看,要保證流水線順暢,理想情況產(chǎn)品需求文檔要領(lǐng)先前端開發(fā)2個(gè)版本,設(shè)計(jì)領(lǐng)先前端開發(fā)1個(gè)版本,后端開發(fā)領(lǐng)先前端開發(fā)半個(gè)版本。即在當(dāng)前項(xiàng)目啟動(dòng)同時(shí),產(chǎn)品經(jīng)理已經(jīng)在調(diào)研討論下下版本需求;設(shè)計(jì)開始搞下版本的稿子;當(dāng)前項(xiàng)目進(jìn)行到一大半時(shí),后端已經(jīng)完成當(dāng)前版本的需求,并開始準(zhǔn)備下版本的需求預(yù)研。

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

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

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

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

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

 

分享本文至:

日歷

鏈接

個(gè)人資料

存檔