app軟體開發系統流程詳解

標籤：通過   開始   客服   程式員   內容   直播系統   app   情況下   更新   

隨著電商時代的不斷進步，對於線上的電商行業來說，使用者和消費者的直觀體驗越來越重要，你賣的東西好壞，不是看出來的，是“看”出來的。洋洋技術技術團隊自主研發的微分銷直播系統能夠協助商家提高消費者體驗度，提高轉化和銷量。

 

如果說你看到了----這套系統模式的優勢，那你會是想要自己也做一個類似的系統模式，自己來操作，看到一個系統模式的優勢所在你就是他的領航者。也如果你有一個好的項目想實現系統化：功能實現開發找陳洋150.1315-1740電微。

 

app功能開發需求流程如下：

第一階段：需求策劃。

在需求階段產品經理內部進行需求討論：討論下版本需求重點是什麼，做什麼功能，怎麼做。通過反覆調研、討論、輸出互動方案。

確認需求可行性：產品在輸出互動方案後找相應的開發討論需求方案是否可行，這個討論階段產品和開發的思維方式不同，往往會擦出新火花、新驚喜；但討論控制不好或者會演化為產品和程式員的撕逼大戰，呵呵。

UI設計：設計師將產品的互動方案變得更生動精美，不過精美的設計稿不見得都能實現出來。在這個過程中產品經理需要協調設計師和前端人員的溝通，制定設計規範。同時保證設計稿的品質，出稿進度。需求宣講：產品經理將互動方案和實現邏輯完善以及將上版本的bug、其他最佳化需求等整合出完整的版本需求文檔後，拉上項目所有成員宣講。宣講目的主要讓項目成員清楚新版本需求的重點是什麼，做什麼功能，為什麼做（重點講）；簡單介紹怎麼做，講解互動方案或設計稿，給大家有一個整體的印象，讓大家都瞭解版本功能的意義。

第二階段：需求研發。

項目啟動：需求宣講後，開發根據產品需求文檔進行需求評審，評估出研發周期、提測時間、預發布時間點、正式發布時間點。

產品根據評審結果發送項目啟動郵件。研發：需求研發過程中，產品跟進研發進度，保持與開發溝通確保需求被正確理解，及時解決研發過程中發現的新問題。測試案例：產品、測試、開發共同確認版本測試案例，並同步研發過程中變更的需求和細節。

提測：產品驗收開發輸出的功能模組，並輸出體驗迴歸文檔；測試根據用例驗證需求邏輯，提bug、最佳化給開發。內網環境測試通過後，測試繼續驗證預發布環境、正式環境。

第三階段：版本發布。

客服培訓：測實驗證的過程中，版本發布前，產品提前給客服培訓新版本內容。

發布：後端開發、營運人員將代碼發布外網環境，前端輸出外網正式包。產品運營將正式包上傳各大安卓市場或ios -appstore提審。

升級：所有安卓渠道封裝更新好，或者appsore審核通過，新版本也沒有發現什麼問題時，後端開發和運營人員開啟升級配置，並發送升級通知。運營報告：版本發布完畢還未算完呢，運營人員在新版本發布後，收集使用者反饋，進行資料監測、資料分析；評估新版本功能效果和影響，驗證新版本功能以及輸出下版本需求開發和最佳化建議。

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

 

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

 

版本規劃是產品經理根據需求優先順序和開發進度預估定出來的，即每個版本要做什麼，重點是什麼，研發時間，上線時間等。一般來說，項目每發布一個版本都應該有它的意義和主打功能。

App首個版本相對來說時間較長：app需要搭配開發環境，確定app技術架構，以及研發各種基礎系統等。像這樣時間較長的版本研發，產品經理和技術在需求評估時要將開發需求分階段進行並且設定裡程碑（盡量不超過3個），在每個裡程碑（最長不超過1周）時間點，產品經理需要確認完成的情況，發現問題及時調整研發計劃，控制項目風險，保證項目如期完成。

 

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

 

一般情況不建議頻繁發布小版本，因為每個版本發布都需要測試，打包，發布市場，發升級配置和升級提醒等。頻繁發布小版本造成測試和運營重複性工作增加，造成資源浪費；使用者側看頻繁的升級提醒也是件很討厭的事情。另外，建議外網運營用戶端版本最多不要超過4個。維護老版本成本還是比較高的，比如做新功能還要考慮新老版本相容情況，和各種後台資料介面升級、更新的相容問題等。

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

app軟體開發系統流程詳解