2015-8-14 周周
藍藍設計( m.miumiuwan.com )是一家專注而深入的界面設計公司，為期望卓越的國內(nèi)外企業(yè)提供有效的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務
如果您想訂閱本博客內(nèi)容，每天自動發(fā)到您的郵箱中， 請點這里
一個移動APP項目研發(fā)規(guī)?？纱罂尚?，但都離不開以下幾個成員：產(chǎn)品經(jīng)理、ui設計師、前端開發(fā)、后端開發(fā)、測試等。如何合理安排項目成員工作、確保項目順利進行呢？一個清晰合理的項目研發(fā)流程控制很重要。
項目研發(fā)流程一般來說分3個階段
在需求階段產(chǎn)品經(jīng)理內(nèi)部進行需求討論：討論下版本需求重點是什么，做什么功能，怎么做。通過反復調(diào)研、討論、輸出交互方案。
確認需求可行性：產(chǎn)品在輸出交互方案后找相應的開發(fā)討論需求方案是否可行，這個討論階段產(chǎn)品和開發(fā)的思維方式不同，往往會擦出新火花、新驚喜；但討論控制不好或者會演化為產(chǎn)品和程序員的撕逼大戰(zhàn)，呵呵。
UI設計：設計師將產(chǎn)品的交互方案變得更生動精美，不過精美的設計稿不見得都能實現(xiàn)出來。在這個過程中產(chǎn)品經(jīng)理需要協(xié)調(diào)設計師和前端人員的溝通，制定設計規(guī)范。同時保證設計稿的質(zhì)量，出稿進度。需求宣講：產(chǎn)品經(jīng)理將交互方案和實現(xiàn)邏輯完善以及將上版本的bug、其他優(yōu)化需求等整合出完整的版本需求文檔后，拉上項目所有成員宣講。宣講目的主要讓項目成員清楚新版本需求的重點是什么，做什么功能，為什么做（重點講）；簡單介紹怎么做，講解交互方案或設計稿，給大家有一個整體的印象，讓大家都了解版本功能的意義。
項目啟動：需求宣講后，開發(fā)根據(jù)產(chǎn)品需求文檔進行需求評審，評估出研發(fā)周期、提測時間、預發(fā)布時間點、正式發(fā)布時間點。
產(chǎn)品根據(jù)評審結(jié)果發(fā)送項目啟動郵件。研發(fā)：需求研發(fā)過程中，產(chǎn)品跟進研發(fā)進度，保持與開發(fā)溝通確保需求被正確理解，及時解決研發(fā)過程中發(fā)現(xiàn)的新問題。測試用例：產(chǎn)品、測試、開發(fā)共同確認版本測試用例，并同步研發(fā)過程中變更的需求和細節(jié)。
提測：產(chǎn)品驗收開發(fā)輸出的功能模塊，并輸出體驗回歸文檔；測試根據(jù)用例驗證需求邏輯，提bug、優(yōu)化給開發(fā)。內(nèi)網(wǎng)環(huán)境測試通過后，測試繼續(xù)驗證預發(fā)布環(huán)境、正式環(huán)境。
客服培訓：測試驗證的過程中，版本發(fā)布前，產(chǎn)品提前給客服培訓新版本內(nèi)容。
發(fā)布：后端開發(fā)、運維人員將代碼發(fā)布外網(wǎng)環(huán)境，前端輸出外網(wǎng)正式包。產(chǎn)品運營將正式包上傳各大安卓市場或ios -appstore提審。
升級：所有安卓渠道包更新好，或者appsore審核通過，新版本也沒有發(fā)現(xiàn)什么問題時，后端開發(fā)和運營人員打開升級配置，并發(fā)送升級通知。運營報告：版本發(fā)布完畢還未算完呢，運營人員在新版本發(fā)布后，收集用戶反饋，進行數(shù)據(jù)監(jiān)測、數(shù)據(jù)分析；評估新版本功能效果和影響，驗證新版本功能以及輸出下版本需求開發(fā)和優(yōu)化建議。
從以上APP項目研發(fā)流程來看，每一個版本研發(fā)都要經(jīng)歷以上3個階段12環(huán)節(jié)，理論圖上看是一條完整的流水線，但是如何保證流程順暢進行？如何使項目成員工作效率最大化？這十分考驗產(chǎn)品經(jīng)理/項目經(jīng)理的版本規(guī)劃能力。當然項目成員間的默契和溝通也很重要。
從筆者實踐經(jīng)驗來看，要保證流水線順暢，理想情況產(chǎn)品需求文檔要領(lǐng)先前端開發(fā)2個版本，設計領(lǐng)先前端開發(fā)1個版本，后端開發(fā)領(lǐng)先前端開發(fā)半個版本。即在當前項目啟動同時，產(chǎn)品經(jīng)理已經(jīng)在調(diào)研討論下下版本需求；設計開始搞下版本的稿子；當前項目進行到一大半時，后端已經(jīng)完成當前版本的需求，并開始準備下版本的需求預研。
版本規(guī)劃是產(chǎn)品經(jīng)理根據(jù)需求優(yōu)先級和開發(fā)進度預估定出來的，即每個版本要做什么，重點是什么，研發(fā)時間，上線時間等。一般來說，項目每發(fā)布一個版本都應該有它的意義和主打功能。
App首個版本相對來說時間較長：app需要搭配開發(fā)環(huán)境，確定app技術(shù)框架，以及研發(fā)各種基礎系統(tǒng)等。像這樣時間較長的版本研發(fā)，產(chǎn)品經(jīng)理和技術(shù)在需求評估時要將開發(fā)需求分階段進行并且設置里程碑（盡量不超過3個），在每個里程碑（最長不超過1周）時間點，產(chǎn)品經(jīng)理需要確認完成的情況，發(fā)現(xiàn)問題及時調(diào)整研發(fā)計劃，控制項目風險，保證項目如期完成。
后續(xù)開發(fā)的每一個版本都應該至少有一個重要功能，版本研發(fā)周期最好控制在2周-3周內(nèi)。這樣的好處一方面是保證項目成員有個良好的開發(fā)節(jié)奏，使研發(fā)效率最大化；另一方面保證每個版本有新東西給到用戶體驗，以及符合各大市場申請首發(fā)條件，獲得免費的推廣資源（ps：一般首發(fā)活動可以獲得幾千到幾萬的免費用戶，還是挺吸引的）。當然重大功能上線的話，確保上線后版本的穩(wěn)定性，可以將研發(fā)周期延至1個月，或者進行灰度發(fā)布。要盡量避免安排超過一個月研發(fā)周期的版本，否則要將長版本設置為若干個里程碑驗收。經(jīng)驗來看研發(fā)周期過長往往會導致研發(fā)技術(shù)人員精力分散，工作拖沓，積極性下降。
一般情況不建議頻繁發(fā)布小版本，因為每個版本發(fā)布都需要測試，打包，發(fā)布市場，發(fā)升級配置和升級提醒等。頻繁發(fā)布小版本造成測試和運營重復性工作增加，造成資源浪費；用戶側(cè)看頻繁的升級提醒也是件很討厭的事情。另外，建議外網(wǎng)運營客戶端版本最多不要超過4個。維護老版本成本還是比較高的，比如做新功能還要考慮新老版本兼容情況，和各種后臺數(shù)據(jù)接口升級、更新的兼容問題等。
在特殊的情況下，有緊急的bug和漏洞時，才建議緊急發(fā)布一個bugfix版本。