關于蘇州app開發(fā)手機App客戶端開發(fā)流程及版本規(guī)劃！一個移動APP項目的R&D規(guī)模可以大也可以小，但都離不開以下會員:產品經理、UI設計師、前端開發(fā)、后端開發(fā)、測試等。如何合理安排項目成員的工作，確保項目的順利進行？一個清晰合理的項目R&D過程控制是非常重要的。移動APP項目R&D過程控制項目R&D過程一般分為三個階段:需求規(guī)劃。第一階段:需求階段產品經理內部需求討論:討論下一個版本需求的重點是什么，做什么功能，怎么做。通過反復調研、討論、輸出交互方案。確認需求可行性:產品輸出交互方案后找到相應的開發(fā)討論需求方案是否可行。這個討論階段的產品和開發(fā)思維方式不同，往往會產生新的火花和驚喜；但是討論控制不好或者演變成產品和程序員之間的撕裂戰(zhàn)，呵呵。UI設計:設計師把產品的交互方案變得更加生動精致，但精致的設計草案不一定能夠實現(xiàn)。在這個過程中，產品經理需要協(xié)調設計人員和前端人員之間的溝通，制定設計規(guī)范。同時確保設計草案的質量和發(fā)布的進度。需求宣傳：產品經理將改進互動解決方案和實現(xiàn)邏輯，并整合上述版本的bug和其他優(yōu)化需求，形成完整的版本需求文件，然后拉動項目的所有成員進行宣傳。 宣傳的主要目的是讓項目成員知道新版本的重點是什么，他們做什么功能，為什么要這樣做（重點）；簡要介紹如何做，解釋互動解決方案或設計草案，給每個人一個整體印象，讓每個人都理解版本功能的重要性。第二階段：需求研發(fā)。項目啟動：需求宣傳后，開發(fā)應根據(jù)產品需求文檔進行需求評估，評估研發(fā)周期、測試時間、預發(fā)布時間點和正式發(fā)布時間點。產品根據(jù)評估結果發(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-應用商店進行審核升級。升級：所有安卓渠道包更新良好，或應用商店審核通過，后端開發(fā)運營人員開放升級配置時新版本沒有發(fā)現(xiàn)任何問題，并發(fā)送升級通知。運營報告:版本發(fā)布后還沒有結束。新版本發(fā)布后，運營商收集用戶反饋，進行數(shù)據(jù)監(jiān)控和數(shù)據(jù)分析；評估新版本的功能效果和影響，驗證新版本的功能和輸出下的版本需求的開發(fā)和優(yōu)化建議。 從以上APP項目的R&D過程來看，每個版本R&D都要經歷上述三個階段和12個環(huán)節(jié)。理論圖是一條完整的流水線，但如何保證過程的順利進行？如何最大限度地提高項目成員的工作效率？這是對產品經理/項目經理版本規(guī)劃能力的考驗。當然，項目成員之間的默契和溝通也很重要。從作者的實踐經驗來看，要保證流水線的順暢，理想情況產品需求文檔要引導前端開發(fā)兩個版本，設計引導前端開發(fā)一個版本，后端開發(fā)引導前端半個版本。也就是說，在當前項目開始的同時，產品經理已經在研究和討論下一個版本的需求；設計開始下一個版本的手稿；當前項目的一半以上時，后端已經完成了當前版本的需求，并開始準備下一個版本的需求預研究。版本規(guī)劃是由產品經理根據(jù)需求優(yōu)先級和開發(fā)進度進行估計的，即每個版本應該做什么，重點是什么，R&D時間、在線時間等。一般來說，該項目每發(fā)布一個版本都應該具有它的意義和主要功能。
應用的第一個版本需要很長時間：應用需要匹配開發(fā)環(huán)境，確定應用技術框架，并開發(fā)各種基礎系統(tǒng)。對于這樣一個長期的版本R&D，產品經理和技術應該在需求評估中階段和設定里程碑開發(fā)需求（盡量不要超過3個），在每個里程碑時間點（最長不超過1周），產品經理需要確認完成，及時調整研發(fā)計劃，控制項目風險，確保項目按時完成。后續(xù)開發(fā)的每個版本至少應具有一個重要功能。最好在2-3周內控制版本研發(fā)周期。一方面，這樣的好處是確保項目成員有良好的發(fā)展節(jié)奏，最大限度地提高R&D效率；另一方面，確保每個版本都有新的東西給用戶體驗，并滿足主要市場申請的首發(fā)條件，獲得免費的推廣資源（PS：一般的首發(fā)活動可以獲得數(shù)千到數(shù)萬免費用戶，這仍然非常有吸引力）。當然，如果重大功能在線，以確保在線版本的穩(wěn)定性，可以將研發(fā)周期延長至一個月，或發(fā)布灰度。盡量避免安排研發(fā)周期超過一個月的版本，否則應將長版設置為幾個里程碑驗收。
從經驗的角度來看，研發(fā)周期過長往往會導致研發(fā)技術人員精力分散、工作拖延和積極性降低。一般來說，不建議頻繁發(fā)布小版本，因為每個版本的發(fā)布都需要測試、包裝、發(fā)布市場、發(fā)布升級配置和升級提醒。頻繁發(fā)布小版本會導致測試和操作重復性增加，浪費資源；用戶看到頻繁的升級提醒也很煩人。此外，建議外部網絡操作的客戶端版本不應超過4個。維護舊版本的成本仍然相對較高。例如，在制作新功能時，我們還需要考慮新舊版本的兼容性，以及各種背景數(shù)據(jù)接口的升級，以及更新的兼容性問題。在特殊情況下，建議在出現(xiàn)緊急bug和漏洞時，緊急發(fā)布bugx版本。關于蘇州app開發(fā)手機App客戶端開發(fā)流程及版本規(guī)劃的內容已在上文簡述！