2009 年，Farhan Thawar 加入 App 開發公司 Xtreme Labs 任 VP of Engineering 一職。那時候的 Xtreme 囊中已經有很多大客戶，其中就包括了最大的社交網絡和最熱門的體育組織。而這些大客戶的共同點就是，他們都亟不可待地要在移動互聯搶占先機。
無需贅言，移動終端一次次用數據證明了自己才是大勢所趨。Facebook 公佈其在美國日訪問量的 78% 來自手機端，Twitter 是 75%。並且 Twitter 65% 的廣告收入來自手機廣告。
對於創業公司來說，他們有限的時間和金錢資源使其不得不在移動化的道路上步步為營。
今天的 Farhan Thawar 在 Xtreme 被加拿大公司 Pivotal Labs 收購後任 Pivotal Labs 的 VP-Engineering 一職，他談論了創業公司在通往移動化道路上的 5 個誤區。
誤區 ：在每個平台上建原生 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 無界面延遲，只重載數據。
跨平台工具包：要求每個平台有大量自定義 Code，這樣給每個平台寫原 Code 更容易。
與其求廣不如求精，把最熱門平台的 App 寫深寫透才最重要。
這又引發了另一個議論，究竟哪個平台能帶來最大收益？
當大多數公司都把操作系統 iOS 或 Android 放在首位時，調查結果令他們大跌眼鏡。
其實黑莓和 Windows Phone 的使用者才是一些公司的目標客戶， 這一切都取決於你想要這個 App 扮演什麼角色。為找到最佳平台就意味著要挖掘客戶群的人口統計資料，從而發現用戶們不同的使用習慣。
例如 Android 用戶和 iOS 用戶就有十分不容的使用習慣。Thawar 認為要在完全攻克一個操作平台之後再拓展到其他平台，從時間和質量上來看，這都是做出一個好 App 的唯一途徑。
誤區 ：我們已經有完善的後台支持 App 了
現實：你需要改變，升級或者完全重建後台以創造出最佳移動體驗。
API 設計和實現對構建出運行優良的 App 至關重要。很多公司都體驗到遠高於網站的來自移動終端的訪問量。試想，以銀行為例，多數人或許一周都不會登錄網銀一次卻可以每天瀏覽 50 次手機銀行。你的後台設施可以從容應對這樣大的流量嗎？
Thawar 記得曾有一個擁有優良網站後台的客戶，在移動 App 上線後，才意識到服務器在處理每個請求時就需要往回輸送 1.4MB 的數據，在這種量級的數據交換下優良的用戶體驗幾乎不可能。
Thawar 給公司們應對類似問題的建議是：
將有效載荷最大化：最好的移動用戶體驗和最小的數據傳輸並。對於移動終端來說，好的 API 允許從服務器回傳的最大的有效載荷應低於 4KB。
分頁處理：任何類型的返回列表都應當支持游標類型和分頁的結果（例如，我能夠從第四頁開始的 25 個結果）。
重試: 允許客戶端向服務器多次發送相同的 API 請求以確保收到，而「重試」同樣的 API 請求並不意味著向同一個服務器發送兩個請求。
低延遲：每一個 API 請求的延遲越小，App 的反應越敏捷。
每一個螢幕生成單個 API 請求：最完美的情形是移動終端的每個螢幕都只向後台發送不超過一個的 API 請求。允許在服務器終端多程序運行並回傳數據以達到鬆散耦合。
誤區 : 自己開發和外包給移動開發公司一樣快。
現實：自己開發至少要多花 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 給出的建議是，在挑選合作公司是關注以下問題：
1. 從過往的項目和客戶那裡，他們在技術和經驗上分別學到了什麼？
2. 能否和客戶本身的研發團隊共同開發？
3. 他們熟悉「敏捷開發（Agile Software Development）」嗎，能否做到例如緊密協作，密切溝通，頻繁交付新版本等等。
5. 他們曾犯過最大的錯誤是什麼？
Tharwar 認為最後一點是最重要的， 這是個關於誠實度和透明性的測試。也會讓你對相互間的合作方式有一個初步的試水。
誤區 ：我如果把 App 的開發外包了，那我什麼也不用做了。
現實：創業公司作為客戶，也要密切參與到開發過程中。
最完美的情況是讓雙方每天坐在一起工作，App 開發公司才能夠切實理解你究竟想要什麼。
對於 Tharwar 的 App 開發團隊而言，他們的目標是儘早以及不斷交付有價值的軟體。對於客戶方而言，通過和軟體開發公司的合作也是一個積累經驗和為未來自己開發 App 準備的過程。
一個優秀的移動開發團隊甚至可以讓你看清楚以後要雇傭什麼樣的員工，且在無形中提高你未來移動團隊的質量。
誤區 ：一旦我把項目給這個開發團隊，我就得永遠依賴他們。
現實：你隨時可以離開，也可以自己接管。
令人諷刺的一個現像是，最好的移動開發公司最後都銷聲匿跡， 因為他們教會了客戶如何去建立自己的移動開發部門。「結對編程（Pair Programming）」讓雙方尤其是客戶方的優秀的工程師們不斷進步，當創業公司羽翼漸豐時，建立自己的移動開發部就不是難事了。
作為一個創業公司，你需要一個理解你公司，產品並且把你的成功和他們自己的成功結合在一起的伙伴。這樣的伙伴不僅能夠祝你在移動業務上勢如破竹，更能給整個公司的業務帶來新的機遇。
分享自 http://buzzorange.com/techorange/2014/02/06/satya-nadella-email-to-employees-on-first-day-as-ceo/