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