從入職這行業到創業已有 7 載,對 APP 產品開發的流程已經再熟悉不過了,現在把這幾年積累的一些經驗和大家分享一下,一個產品是怎麼從想法一步一步落地為具體成品的,這個過程中會經歷一些怎樣的必要流程呢,下面大致說一下:
大部分創業型專案在這個階段只是一些比較抽象的想法。有一份相對完善的需求文件,不僅有助於創業者自身對專案的理解和周全性分析,如果專案是交由設計公司去完成的話,也更有利於對方準確把握專案的定位和商業模式,以便給出專業的建議和解決方案。下面是需求整理過程中比較關鍵的點:
(1)清晰認識專案是為了解決什麼使用者痛點,行業需求?
(2)分析要解決這些痛點或者需求的過程中需要透過哪些有效的功能佈局去實施,逐一將核心功能列舉並適當完善一下,透過文字或圖文的方式描述清楚。
(3)建立完善並且合乎邏輯,功能完整呼應的需求文件不是一件簡單的事,如果你是 PM(產品經理)出身的話會比較容易上手,否則最好還是由第三方機構協助完成。
不論專案是由自己團隊執行開發,亦或是交由第三方公司代為設計開發,建立在一份完善且有質量的需求文件都是非常有必要的,對需求文件進行人力時間的投入,可以較準確地估算出專案需要投入的預算,同時這些文件後期會有助於產品經理,UI 設計師,技術開發人員等等對專案的理解,減少人員溝通中可能存在的誤差。(下面以我們 kollway Design 中某專案的需求文件和邏輯結構為例 )
接下來會根據上面提到的具體需求文件,專案經理進行會進行原型圖的設計,包括:(1)功能的結構性佈局(2)各分頁面的設計(3)頁面間業務邏輯的設計最終輸出每個足夠示意出頁面所包含的功能的原型設計圖,比如:
(1)APP UI : 原型圖經過反覆推敲修正後,UI 設計師會進行UI介面相關的配色設計、功能具象化處理、互動設計、以及各種機型、系統的適配。UI 設計師經過多次與專案經理溝通修改後,最終的到定稿的高保真設計圖。
(2)後臺 UI : 絕大部分 APP 專案都會有相應的管理後臺,雖然後臺是使用者無法接觸到的,但是與 APP 側的功能是意義對照的,合理的設計能讓後臺管理人員快速上手。
經過以上幾個過程之後,會正式進入到開發階段,一個完整的 APP 專案一般包含以下幾個板塊:
(1)伺服器端:編寫介面協議文件,伺服器環境架設(國內一般都是用阿里雲伺服器,國 外一般用亞馬遜),設計資料庫和編寫API介面。
(2)APP 端:根據UI設計圖進行介面開發,UI 開發完成則進入和服務端介面對接,透過服務端的介面獲取資料,編寫功能上的邏輯程式碼。
(3) Web 管理端: 根據前端的業務邏輯,後臺會有相應的功能與之匹配,同樣需要編寫功能上的邏輯程式碼。
APP 功能開發完成之後,測試人員會對整專案進行系統性測試。這個環節會調動起專案組內所有人相關人員。而測試這個環節的重要性不亞於前期功能的規劃,如果團隊沒有經過專業系統性訓練的測試人員,很可能會導致專案出現與設計初衷存在落差,以及遺漏下一些邏輯上的坑(這些坑是以後給自己帶淚跳下去的...)
而完成專案測試除錯最重要的環節是問題的管理,追蹤各個 bug 的進度以及狀態,包括指派給誰、優先順序、修復狀態等等,以便有質量地完成問題的處理。
經過至少兩輪的內部測試以及小範圍外測(或者完成滿足測試要求的週期)後,會進行最終版本的上架,以常用的 iOS 和 Android 應用市場為例:
(1)Android : 涉及的應用市場很多,主流市場是應用寶、360手機助手、小米商城,不同的應用市場的受眾屬性會有所不同,流量也有較大的差別,需要根據實際情況選擇。
(2)iOS : 釋出到 AppStore(蘋果稽核比較嚴格,是否符合最新的上架要求,是否涉及到虛擬貨幣、是否支援最新環境等等等 N 多問題都會導致稽核是否能透過,這個對經驗的要求就很高了,而最坑爹的是,比如某 APP 存在5個導致不透過的問題,蘋果是不會把5個找出來告訴你為什麼拒絕的,而是找到一個就馬上拒絕你,所以如果經驗不足的話上架 n 次花費幾個月都是很有可能的。)
產品正式投放到市場之後,會得到使用者以及市場本身的一些反饋,從而知道該如何修正或者調整運營策略,當目前系統的功能再也無法滿足專案需求時,就需要規劃新一版本功能的迭代問題了。(重新經歷:需求整理-預算評估-原型設計-UI 設計-開發-測試除錯-釋出 這個產品的生命週期 )
在專案正式運作的時候,即便是已經達到相對穩定的階段,也會有可能出現一些小問題,或者發現一些隱藏得比較深的 bug,這個時候就需要有相關的市場人員進行問題的收集以及技術人員對問題作出及時的修復,簡單理解就是需要有人值守。
從入職這行業到創業已有 7 載,對 APP 產品開發的流程已經再熟悉不過了,現在把這幾年積累的一些經驗和大家分享一下,一個產品是怎麼從想法一步一步落地為具體成品的,這個過程中會經歷一些怎樣的必要流程呢,下面大致說一下:
需求整理大部分創業型專案在這個階段只是一些比較抽象的想法。有一份相對完善的需求文件,不僅有助於創業者自身對專案的理解和周全性分析,如果專案是交由設計公司去完成的話,也更有利於對方準確把握專案的定位和商業模式,以便給出專業的建議和解決方案。下面是需求整理過程中比較關鍵的點:
(1)清晰認識專案是為了解決什麼使用者痛點,行業需求?
(2)分析要解決這些痛點或者需求的過程中需要透過哪些有效的功能佈局去實施,逐一將核心功能列舉並適當完善一下,透過文字或圖文的方式描述清楚。
(3)建立完善並且合乎邏輯,功能完整呼應的需求文件不是一件簡單的事,如果你是 PM(產品經理)出身的話會比較容易上手,否則最好還是由第三方機構協助完成。
預算評估不論專案是由自己團隊執行開發,亦或是交由第三方公司代為設計開發,建立在一份完善且有質量的需求文件都是非常有必要的,對需求文件進行人力時間的投入,可以較準確地估算出專案需要投入的預算,同時這些文件後期會有助於產品經理,UI 設計師,技術開發人員等等對專案的理解,減少人員溝通中可能存在的誤差。(下面以我們 kollway Design 中某專案的需求文件和邏輯結構為例 )
原型設計接下來會根據上面提到的具體需求文件,專案經理進行會進行原型圖的設計,包括:(1)功能的結構性佈局(2)各分頁面的設計(3)頁面間業務邏輯的設計最終輸出每個足夠示意出頁面所包含的功能的原型設計圖,比如:
UI設計(1)APP UI : 原型圖經過反覆推敲修正後,UI 設計師會進行UI介面相關的配色設計、功能具象化處理、互動設計、以及各種機型、系統的適配。UI 設計師經過多次與專案經理溝通修改後,最終的到定稿的高保真設計圖。
(2)後臺 UI : 絕大部分 APP 專案都會有相應的管理後臺,雖然後臺是使用者無法接觸到的,但是與 APP 側的功能是意義對照的,合理的設計能讓後臺管理人員快速上手。
開發經過以上幾個過程之後,會正式進入到開發階段,一個完整的 APP 專案一般包含以下幾個板塊:
(1)伺服器端:編寫介面協議文件,伺服器環境架設(國內一般都是用阿里雲伺服器,國 外一般用亞馬遜),設計資料庫和編寫API介面。
(2)APP 端:根據UI設計圖進行介面開發,UI 開發完成則進入和服務端介面對接,透過服務端的介面獲取資料,編寫功能上的邏輯程式碼。
(3) Web 管理端: 根據前端的業務邏輯,後臺會有相應的功能與之匹配,同樣需要編寫功能上的邏輯程式碼。
測試除錯APP 功能開發完成之後,測試人員會對整專案進行系統性測試。這個環節會調動起專案組內所有人相關人員。而測試這個環節的重要性不亞於前期功能的規劃,如果團隊沒有經過專業系統性訓練的測試人員,很可能會導致專案出現與設計初衷存在落差,以及遺漏下一些邏輯上的坑(這些坑是以後給自己帶淚跳下去的...)
而完成專案測試除錯最重要的環節是問題的管理,追蹤各個 bug 的進度以及狀態,包括指派給誰、優先順序、修復狀態等等,以便有質量地完成問題的處理。
釋出到應用市場經過至少兩輪的內部測試以及小範圍外測(或者完成滿足測試要求的週期)後,會進行最終版本的上架,以常用的 iOS 和 Android 應用市場為例:
(1)Android : 涉及的應用市場很多,主流市場是應用寶、360手機助手、小米商城,不同的應用市場的受眾屬性會有所不同,流量也有較大的差別,需要根據實際情況選擇。
(2)iOS : 釋出到 AppStore(蘋果稽核比較嚴格,是否符合最新的上架要求,是否涉及到虛擬貨幣、是否支援最新環境等等等 N 多問題都會導致稽核是否能透過,這個對經驗的要求就很高了,而最坑爹的是,比如某 APP 存在5個導致不透過的問題,蘋果是不會把5個找出來告訴你為什麼拒絕的,而是找到一個就馬上拒絕你,所以如果經驗不足的話上架 n 次花費幾個月都是很有可能的。)
運營迭代產品正式投放到市場之後,會得到使用者以及市場本身的一些反饋,從而知道該如何修正或者調整運營策略,當目前系統的功能再也無法滿足專案需求時,就需要規劃新一版本功能的迭代問題了。(重新經歷:需求整理-預算評估-原型設計-UI 設計-開發-測試除錯-釋出 這個產品的生命週期 )
日常維護在專案正式運作的時候,即便是已經達到相對穩定的階段,也會有可能出現一些小問題,或者發現一些隱藏得比較深的 bug,這個時候就需要有相關的市場人員進行問題的收集以及技術人員對問題作出及時的修復,簡單理解就是需要有人值守。