創業公司走向移動化的5個誤區

本文來自First Round Review，他們準備的文章既講故事，還同時向創業者提供可操作的建議，以助力打造優秀的公司。

誤區1：在每個平台上建原生App(“Native App”)純粹是種浪費
現實：如果你想要一個5顆星的App，不用掙紮了，5顆星是屬於原生App的。

跨平台 App(Cross-Platform App)的好處無需贅述，這是個一勞永逸的工程，一次代碼能在所有設備上使用。聽起來簡單，沒錯，Facebook，LinkedIn，甚至美國西南航空剛開始也都是這麽想的。 但圖方便的代價就是，很快 Mark Zuckerberg 就跑出來宣稱對於 HTML5 (可使網頁 App 實現接近原生 App 的體驗效果)是個巨大的錯誤。Thawar 至今仍記憶猶新的是，在西南航空還在用跨平台 App 的時候，他參加的所有會議都把這個 App 作為 App Store 裏最糟糕的案例拿出來講。

“公司們取捷徑的時候，絲毫沒有意識到，他們把最糟的用戶體驗留給了所有人“ 三家公司後來都重新開發它們的 App。然而跨平台 App 仍對在時間金錢上都捉襟見肘的創業公司最具吸引力。他們過度依賴 HTML5，混合 App (“Hybrid App”)和跨平台工具包， 盡管它們都無法生成絕佳的用戶體驗，至少現在還達不到。每個看上去很美的解決方案都有它的弊端：
HTML5：跨瀏覽器兼容問題難以解決，導致最後需要對每個平台進行優化。

混合 App：其實就是原生 app 外殼封裝的 web app，這種 app 會像網頁一樣整體刷新重繪界麵，給人慢的印象。此外，應用本身和 web 界麵間的溝通層通常較為複雜，也更容易出錯。原生 app 無界麵延遲，隻重載數據。

跨平台工具包：要求每個平台有大量自定義代碼，這樣給每個平台寫原代碼更容易。與其求廣不如求精，把最熱門平台的 App 寫深寫透才最重要。這又引發了另一個議論，究竟哪個平台能帶來最大收益?當大多數公司都把操作係統 iOS 或 Android 放在首位時，調查結果令他們大跌眼鏡。其實黑莓和 Windows Phone 的使用者才是一些公司的目標客戶， 這一切都取決於你想要這個 App 扮演什麽角色。為找到最佳平台就意味著要挖掘客戶群的人口統計資料，從而發現用戶們不同的使用習慣。例如 Android 用戶和 iOS 用戶就有十分不容的使用習慣。Thawar 認為要在完全攻克一個操作平台之後再拓展到其他平台，從時間和質量上來看，這都是做出一個好 App 的唯一途徑。

誤區2：我們已經有完善的後台支持App了

現實：你需要改變，升級或者完全重建後台以創造出最佳移動體驗。

API 設計和實現對構建出運行優良的 App 至關重要。很多公司都體驗到遠高於網站的來自移動終端的訪問量。試想，以銀行為例，多數人或許一周都不會登錄網銀一次卻可以每天瀏覽 50 次手機銀行。你的後台設施可以從容應對這樣大的流量嗎?Thawar 記得曾有一個擁有優良網站後台的客戶，在移動 App 上線後，才意識到服務器在處理每個請求時就需要往回輸送 1.4MB 的數據，在這種量級的數據交換下優良的用戶體驗幾乎不可能。

Thawar 給公司們應對類似問題的建議是：
將有效載荷最大化：最好的移動用戶體驗和最小的數據傳輸並。對於移動終端來說，好的 API 允許從服務器回傳的最大的有效載荷應低於 4KB。

分頁處理：任何類型的返回列表都應當支持遊標類型和分頁的結果(例如，我能夠從第四頁開始的 25 個結果)。

重試:
允許客戶端向服務器多次發送相同的 API 請求以確保收到，而‘重試‘同樣的 API 請求並不意味著向同一個服務器發送兩個請求。
低延遲：每一個 API 請求的延遲越小，App 的反應越敏捷。

每一個屏幕生成單個 API 請求：最完美的情形是移動終端的每個屏幕都隻向後台發送不超過一個的 API 請求。允許在服務器終端多程序運行並回傳數據以達到鬆散耦合。

誤區3: 自己開發和外包給移動開發公司一樣快。

現實：自己開發至少要多花4倍時間。

Tharwar 有著和各種公司合作的經驗，甚至是最後不選擇和他們合作的公司，他也都一一分類存檔以積累經驗。很多公司會來到 Thawar 的團隊這裏詢問多久能做好一個怎樣的 App。當從 Thawar 的團隊裏得知這個 App 需要 1 到 3 個月的時間後， 一些公司選擇自己開發了。但等他們的 App 在 App Store 上線那至少是 1 年後的事了，4 倍的推遲屬於正常範圍。

很多團隊都有自己的 HTML，CSS 或 JavaScript 的資源，但極少創業公司能有一個成熟的移動開發團隊。選擇自己開發 App 實則是在金錢和時間的權衡中選擇了後者。但為什麽開發 APP 要花創業公司這麽久的時間呢 — Tharwar 認為創業公司忽略了最關鍵的需求 : 對口的人才。

多數公司都沒有把增強工程師們在某一特定方麵技能的時間算進去。當決定自己開發時，你需要的不僅僅是出色的工程師，而是有移動產品開發經驗，QA 和 UI 設計方麵的專才。 並且這樣的一支團隊還要能達到高效密切的溝通。如果做不到，可能的結果是：錯誤的產品願景，或是不完善的 QA 等等。

如果你決定找外包的 App 開發公司，那如何選擇又是一個問題。你需要關注的對方的企業文化是否契合，相互間是否能建立起高效的溝通反饋，對方公司是否有相關經驗。Thawar 認為雙方能夠高效溝通是最關鍵的。以 Chipotle 為例，這個大型連鎖快餐店自 2009 年的第一版 App 上線後，直到 2013 年才推出第二版 – 四年的延遲歸咎於溝通低效。不要忘記，使用者期待見到是一個性能和設計上的不斷完善的 App。

Tharwar 給出的建議是，在挑選合作公司是關注以下問題：
從過往的項目和客戶那裏，他們在技術和經驗上分別學到了什麽?
能否和客戶本身的研發團隊共同開發?
他們熟悉“敏捷開發“(Agile Software Development)嗎，能否做到例如緊密協作，密切溝通，頻繁交付新版本等等。

他們曾犯過最大的錯誤是什麽?
Tharwar 認為最後一點是最重要的， 這是個關於誠實度和透明性的測試。也會讓你對相互間的合作方式有一個初步的試水。

誤區4：我如果把App的開發外包了，那我什麽也不用做了。

現實：創業公司作為客戶，也要密切參與到開發過程中。

最完美的情況是讓雙方每天坐在一起工作，App 開發公司才能夠切實理解你究竟想要什麽。對於 Tharwar 的 App 開發團隊而言，他們的目標是盡早以及不斷交付有價值的軟件。對於客戶方而言，通過和軟件開發公司的合作也是一個積累經驗和為未來自己開發 App 準備的過程。一個優秀的移動開發團隊甚至可以讓你看清楚以後要雇傭什麽樣的員工，且在無形中提高你未來移動團隊的質量。

誤區5：一旦我把項目給這個開發團隊，我就得永遠依賴他們。

現實：你隨時可以離開，也可以自己接管。

令人諷刺的一個現象是，最好的移動開發公司最後都銷聲匿跡， 因為他們教會了客戶如何去建立自己的移動開發部門。“結對編程”(Pair Programming)讓雙方尤其是客戶方的優秀的工程師們不斷進步，當創業公司羽翼漸豐時，建立自己的移動開發部就不是難事了。作為一個創業公司，你需要一個理解你公司，產品並且把你的成功和他們自己的成功結合在一起的夥伴。這樣的夥伴不僅能夠祝你在移動業務上勢如破竹，更能給整個公司的業務帶來新的機遇。