基於雲的應用程序過去十年以來在開發過程中發生了很大的變化,逐漸從以前長時間的需求規范--開發--質量檢驗周期,到現在很短的發布周期。
現在很多網絡平台的發布周期是1至4周,期間很多技術人員忙於持續的整合,甚至是每日更新。
關於快速的重復開發過程有很多文檔,我今天的目的不是重復說它所有的利弊,但有兩方面我必須指出:
為客戶快速提供應用的能力,測量他們的使用情況、分析並通過所獲得的信息做出更加相關的決策。
對不同的版本進行A/B測試,衡量並決定使用最好的方式。
以上這兩點能夠保證一個關鍵性的因素,即實際的客戶使用反饋經常在傳統的長期發布周期中被忽略。通過實際的客戶使用反饋,做出決策就更加容易。
關於移動應用程序
用戶對於移動應用程序的期望值比網站更高。盡管有很多不錯的移動應用程序,但任何不穩定、快速和直觀的內容在第一次下載之後,90%的應用程序都可能不再被用戶使用。
發布高質量的移動應用程序非常重要。
很好,但問題是:對於這項需要安裝在遠程設備上並可能幾個月都不用的移動應用,如何實現快速更新換代? 每項新的應用程序要幾個星期才能獲得批准發布,移動應用程序如何應對這點?
現有的分析軟件供應商也針對移動應用程序推出了一些解決方案,如Comscore (Nedstat), Omniture (SiteCatalyst)、Adobe (appMeasuremement)、Webtrends和很多其他供應商等。它們與網站解決方案很類似:跟蹤活動、登錄、將活動發回雲服務中心,然後生成報告。
但在生成報告之前,我們如何快速替代第一個版本?
以下是快速更新移動旅游應用的五大竅門:
1、使用手繪模版
你可以先在手機形狀的紙質記事本上針對用戶使用流程和布局手工設計一些功能選項。
這些記事本的大小要與常見智能手機的大小一模一樣。
然後你可以在每個用戶前面放一張卡片,讓他們寫出在移動應用程序上最期待看到的內容,哪個設計他們認為更直觀,然後過濾並選擇能夠帶來最好流程的設計。
這很簡單有效,並且成本不高。
2、快速更新互動模板
一些線框和模擬工具提供相對簡單的拖拉解決方案,幾分鐘內就可產生互動。大多數工具提供HTML5結果,甚至是基礎的應用程序。
這些預期的功能已經夠好了,完全可用於Android和iOS設備的終端用戶。
類似Tiggr、Mockflow 或Axure的工具都可以帶來互動。即使更簡單的工具如Adobe PDF、Visio/Powerpoint/Keynote、Pencils、Balsamiq或Omnigraffe都可以通過移動用戶界面模具生成靜態的實體模型,靜態的實體模型可用於體現屏幕流量。
3、小范圍測試
找到一批測試者來測試你的移動應用程序,即使它沒有百分百完成,關鍵是確保至少功能是完整的,這樣用戶可以對這些有形的應用進行測試,而不會完全失望。
每天從用戶那裡獲得反饋,讓他們可以隨時提供反饋信息。不要試圖讓他們填寫繁瑣復雜的反饋表格,這樣只會增加你的負擔。
例如,每天讓他們簡單分別寫出最喜歡和最討厭的三點反饋。
4、先選擇Android設備做測試
這不是一項宗教選擇,只是利用Android易於延伸的結構的明智選擇。
測試版應用程序可以用一個晦澀的名稱發布,並只在測試者中共享,其他用戶發現不了。
應用程序可以隨時進行更新:修復Bug或改變功能,無需等待長長的發布批准期。通過在Android設備上快速更新換代,在其他移動操作系統上創建應用程序也可以采取類似的途徑。
蘋果公司的批准期現在縮短到了2-3天,TestFlight等解決方案讓你在iOS的測試更快。
但任何參與過軟件工程的人都知道兩天的審核期意味著什麼,特別是對於不斷推陳出新的旅游業來說。
5、先在小國家發布產品
讓某個應用迅速推出的另一種方式是在更小的市場先進行發布。
萬一行不通的話,你也只是犧牲了一個小的市場,但希望你能夠在大市場順利推出。